Komentáře k článku

Jdu hacknout váš server… díl 1

Hacker inside

Jsem hacker a chci váš server. Přečtěte si, jak postupuji, čeho se snažím vyvarovat a jak mě naopak můžete odhalit. Možná jsem se přes bezpečnostní díru ve formuláři dostal na vaše SSH. Jako root. Nebo jenom k celé databázi, to přes sql injekce. Dnes začnu přípravou průniku. Pojďte mi nakouknout přes rameno.

Zpět na článek

60 komentářů k článku Jdu hacknout váš server… díl 1:

  1. kdosi

    Vicebajtove kodovani a UTF-8

    UTF8 je sice vicebajtove kodovani, ale jeho platne hodnoty jsou:

    U+00000000 – U+0000007F 0xxxxxxx
    U+00000080 – U+000007FF 110xxxxx 10xxxxxx
    U+00000800 – U+0000FFFF 1110xxxx 10xxxxxx 10xxxxxx
    U+00010000 – U+0010FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

    2 az 4 bajt tedy musi mit hodnotu vetsi nebo rovnou 128. Zpetne lomitko (92) tak muze byt pouze v prvnim bajtu. Pokud poslu (alespon do MySql) neplatny utf8 znak , dotaz selze.

    Tento typ utoku je tedy pouzitelny pouze s kodovanim, ktere nema toto omezeni. Zname je napr. GBK.

    1. KapitánRUM

      Re: Vicebajtove kodovani a UTF-8

      To je pravda, ostatně i v tom článku z odkazu je napsáno „UTF-8 does not fit this description“. Ale ano, stál bych o vysvětlení.

  2. PokerFace

    Tor ?

    „může si sice první a poslední node přečíst, co vlastně děláte“

    kazdy skolak vi, ze prvni node nevidi nic… Jak muze „hacker“ neco takoveho vypustit z ust?

    1. Dragonn

      Re: Tor ?

      Není náhodou u Toru standartně první node na localhostu? Ten přeci vidí zprávu nešifrovaně a stejně tak může být teoreticky Tor nainstalován na hraničním routeru lokální sítě a můžeme ho proto nazývat prvním nodem, ne?

      Ale jinak souhlasím s výtkou, myslím, že tohle Anonymní hacker trochu přehlédl a je to matoucí …

      1. limit_false

        Re: Tor ?

        Ne. Na localhostu je pouze SOCKS proxy. Prvni node je nektery z Tor relayu a ten vidi pouze RELAY_EXTEND cell.

    2. jenicek

      Re: Tor ?

      Myslí to dobře, ale blbě to napsal.
      Jinak nešifrovaný traffic ve směru hacker-tor-cil může číst poslední node v toru, zrovna tak zpětný proud cíl-tor-hacker může číst poslední z pohledu cíle, což je první z pohledu hackera.

  3. Hloupý Nemouš

    Jen tak dál...

    Jen tak dál a houšť. Pokud to takhle půjde dál, bude to jeden z nejlepších článků s bezpečnostní tématikou za poslední dobu.

  4. Geekon

    No jen nakousnuto

    SQL Injection je častý problém, ale co je mnohem horší, to je development stage, nebo nevypnutí zobrazování chyb.

    Spojení těchto dvou věcí je jako si namalovat na zadek terč.

    Co by začínající hacker měl přečíst, jsou určitě databázové komentáře. Ty mu umožní v požadovaném místě uříznout dotaz. Proto určitě nestačí mít escapování (nebo cokoli dalšího) na středník a uvozovky.

    Za další školáckou chybu lze považovat umístění admina v databázi jako uživatel s id 1. Injekce username ve tvaru 1′ or 1=1# nás přihlásí jako první uživatel v tabulce, což je potom většinou admin.

    Další málo známá injekce je neošetření unsinget int. Dotaz na stránkování, nebo článek ve tvaru:

    select * from articles where idarticle = {(int)get[clanek]}

    poté při nepoužití mysql_num_rows končí někde chybou. Z tohoto důvodu je vhodné rovnou při vstupu kontrolovat čísla jako regulérní výraz :

    preg_match(‚/^[0-9]{1,3}$/’,$_­GET['clanek'])

    pro int(3), kde si podvědomně hlídáme i přetečení proměnné.

    Jen na téma ošetření vstupů by se dalo napsat další dílo o rozsahu bible. Ať už unicode injection, non-alfanumerický javascript, CSRF, SQLi, LFI, uploady, dowaload ala /../../../../­../../../etc/sha­dow/, chmod0777 a tak dále ..

    1. Geeok

      Re: No jen nakousnuto

      Jen tak namátkou, na co jsem teď narazil při upravování upravování webu klienta od „další renomované firmy“..
      Máme 21 století, tak je cool mít javascript editory na texty, zrovna nyní tu mám krásný TinyMCE
      View:

      <textarea class=“editor“> <?php echo $row['body']?></tex­tarea>

      Controller:
      ..
      $body = mysql_escape_strin­g($_GET['body']);
      ..
      ..
      $query = ‚update comments set body = ‚.$body.‘ where id_articles = ‚.$id;
      ..
      (Je to psáno v MVC, na SQL se používá DIBI, kde je body escapován jako string za pomocí %s)
      Tak kolik tu je chyb ?

      1) nepoužití limit u dotazu
      V každém editu, delete už psát jako cvičená opice „limit 1 ;–“. Tedy za předpokladu, že se nejedná o hromadnou operaci.

      2) Neošetření nevhodných tagů .. první věc co udělám, je :
      vypnu javascript a do textarea vám napíšu:

      <script>alert(‚Hac­k3d by krutohacker’);</scrip­t>

      nebo je libo iframe ?

      3) další věc se mi tam nelíbí, ale zkuste na ní příjít sami.

      1. Michal Zahradnicek

        Re: No jen nakousnuto

        Mam taky maly dotaz k bodu 1.

        Poprosim o logicke vysvetlenie, ze preco mam pisat pri dotaze LIMIT, pokial mam premennu $id osetrenu – teda viem ze sa v nej nachadza iba cislo, ktore identifikuje jeden riadok v tabulke.

        3) Jasne ze chlapik zabudol dat body do uvodzoviek – pekna prasacinka, ani som netusil ze to takto ide.

        1. Sten

          Re: No jen nakousnuto

          Pokud by autor byl alespoň trochu zkušený, použil by transakce a UPDATE … LIMIT … se potom dá snadno emulovat pomocí SELECT COUNT(…) … FOR UPDATE.

    2. David Grudl

      Re: No jen nakousnuto

      > Proto určitě nestačí mít escapování (nebo cokoli dalšího) na středník a uvozovky.

      Pokud proměnnou uzavřu do uvozovek, stačí mi escapovat uvozovky a nic dalšího včetně středníku escapovat netřeba. Výjimkou mohou být dotazy pro operátor LIKE.

      Pokud proměnná není v uvozovkách, protože je to číslo, musím zajistit, aby to skutečně číslo bylo a pak jej není třeba escapovat.

    3. jfila

      Re: No jen nakousnuto

      Tak to jsem zmaten! Co je na konstrukci:
      $dotaz=“SELECT * FROM `produkty` WHERE `ID` = „.(int)($_REQU­EST["Produkt"]);

      špatně? $_REQUEST["Pro­dukt"]) je přece přetypován na číslo, pokud se nejedná o číslo, pak vrátí nulu. Což je zase ošetřeno dále a stránka řekne, že podobný produkt není. Stránky jsem testoval například proti tomuto: 5′;DROP TABLE produkty; — můžete uvést konkrétní příklady vstupů které tato konstrukce neustojí?

      1. David Grudl

        Re: No jen nakousnuto

        Skutečně to mělo být na mě? Z hlediska SQL je to v pořádku, z hlediska bezpečnosti je vhodnější použít $_GET["Produkt"], protože pokud bych vytvořil cookie Produkt, zobrazoval by se produkt i v případě, že by parameter nebyl v URL.

      2. Geekon

        Re: No jen nakousnuto

        Tato konstrukce je jak sem psal nebezpečná na nestandartní chování aplikace, web prolejzají stovky crawlerů a ty testují i vkládání nestandartní int do requestu.

        Je to spíše goog practics

        1. Čelo

          Re: No jen nakousnuto

          Jenom bokem menší výtku… píše se „nestandardní“ (vidím, že si to slovo použil třikrát a vždy špatně).

        2. David Grudl

          Re: No jen nakousnuto

          Pokud přetypuji proměnnou na integer, tak je konstrukce bezpečná, ať už bude vstupem cokoliv. Nebo máš nějaký příklad vstupu, který by příklad Jana Fíly narušil?

          To Jan Fíla: omlouvám se, že jsem to považoval za reakci na svůj komentář. „Závada“ je na straně Zdrojáku: pokud je příspěvek nový (třída .new), posune jej padding o 10px vpravo, takže vypadá jako reakce na jiné vlákno.

    4. j

      Re: No jen nakousnuto

      Podotykam, ze nejsem programator (nebo se za nej napovazuju).

      Ale samozreme, kodu sem napsal celkem hromadu. Co si pamatuju uz od ZS, tak vzdycky bylo osetreni vstupu 80% kodu. Dneska je ovsem „moderni“ vstupy neosetrovat, a pockat az to nekde zbuchne na nejake vyjimce …

      A presne podle toho to taky vypada.

      1. František Kučera

        Re: No jen nakousnuto

        No, ošetřovat vstupy… v první řadě je potřeba rozlišovat význam – zda se jedná o data nebo o program. V tomto případě je programem SQL dotaz. Uživatel mi nesmí zasahovat do programu, ale data mi může posílat libovolná (ať si řetězce obsahující apostrofy a další značky klidně vyhledává nebo zadává do formulářů).

        Následně můžu ošetřovat vstupy třeba stylem, že nedovolím, aby uživatel mohl zadat jako věk člověka 300 let nebo další omezení. Nicméně základem nedovolit, aby se data interpretovala jako program.

        BTW: mám tu jednu aplikaci (SQL Výuka), která uživateli umožňuje zadat libovolné SQL a vykonat ho – taková záměrná SQL injection. Nestojím o DoS útoky, ale pokud by si chtěl někdo hrát a zkoumat, zda se to dá nějak zneužít, budu rád, když mi pak napíše výsledek svého snažení :-)

        1. NN

          Re: No jen nakousnuto

          Kedysi dávno bola zaujímavá séria článkov/cvičení na blackhole.sk. SQL injection je tam len simulovaná, ale je to celkom dobrá zábava: http://blackhole.sk/cvicenie-na-sql-injection
          Ďalšie zaujímavé „hackerské“ cvičenia:
          http://blackhole.sk/cvicenie-manipulacia-webovych-ankiet
          http://blackhole.sk/cvicenie-na-web-aplikacie

          Kedysi dávno som skúšal hru na niečom podobnom ako je hackthissite.org akurát to fungovalo bez registrácie. Žaiľ na názov webu si už nespomeniem, ale vyššie levely tam boli už veľmi prepracované a zaujímavé.

        2. x

          Re: No jen nakousnuto

          Jenze spousta „programatoru“ trebas nekde ocekava vstup – rekneme cislo, ale nijak nezjistuje, ze to cislo skutecne je. Jednoduse se to, co tam nekdo flakne, pokusi insertnout do int pole v DB a cekaji, estli to vrati chybu (napr).

          Mam denne tu cest s jednim „erp“, kde SQL injection je standarni postup … – system samozrejme nepouziva SQL opravneni, ale resi si je na urovni aplikace => pokud se najde trochu znaly uzivatel, muze si data(jakakoli) nejen precist, ale i libovolne modifikovat na urovni databaze … Jako bonus se samozrejme neda zjistit, kdo to byl (pokud by se na nejakou zmenu prislo, coz je pri tech desitkach GB nerealny).

    5. jfila

      Re: No jen nakousnuto

      Ještě jednou, nějak jsem se zamotal do vláken.
      Tak to jsem zmaten! Co je na konstrukci:
      $dotaz=“SELECT * FROM `produkty` WHERE `ID` = „.(int)($_REQU­EST["Produkt"]);

      špatně? $_REQUEST["Pro­dukt"]) je přece přetypován na číslo, pokud se nejedná o číslo, pak vrátí nulu. Což je zase ošetřeno dále a stránka řekne, že podobný produkt není. Stránky jsem testoval například proti tomuto: 5′;DROP TABLE produkty; — můžete uvést konkrétní příklady vstupů které tato konstrukce neustojí? Hlavně mluvím o přetypování.

  5. v.sp

    SQL Injection

    Já nějak nechápu, proč je SQL injection pořád ještě takový problém. Přece i mysql umí bindované proměnné, ne? Oč je těžší dát do textu SQL „where id = ?“ než pracně lepit text?
    (A nevím jak mysql, ale třeba v Oraclu použití proměnných znamená menší počet parsování, což server velmi ocení.)

    To to neumí PHP? Nebo jsou programátoři takoví matláci? Já fakt nevím, webové jazyky zas tak dobře neznám a PL/SQL, OCI či Perl (DBI) to umí v pohodě.

    1. Geekon

      Re: SQL Injection

      1)
      Programátor stojí kolem 30-70k/měsíc, student sice neumí ani používat indexy, ale stojí kolem 10-30k/měsíc.
      2)
      Menší počet parsování se projeví až u více zatěžující aplikace, na web města, který běží na předražené VPS, nebo web na hostingu, s návštěvností 200 lidí denně se to prakticky neprojeví (== není důvod řešit,bohužel)

      Oracle neznám, to je segment trhu, kde se nepohybuji, takže nevím, jestli lze přímo quotovat unsinget int.

    2. Tomi

      Re: SQL Injection

      Presne tak, co sa webovych frameworkov tyka tak napr. z Javy take JDBC, JPA alebo Hibernate toto v pohode osetruje, takisto .Net a ku vsetkemu to riesi aj priamo SRBD tym ze nenecha po spadnutom prikaze prejst „injectnuty“ dalsi.
      …skoda ze tento clanok sa opiera o vec ktora dnes uz moc nefunguje :(

      1. MartinX

        Re: SQL Injection

        No cisto teoreticky by bolo mozne urobit SQL injection aj na J2EE appservri, ale kedze samotny SQL dotaz vytvara az JPA (alebo Hibernate framework) a data do dotazu idu z servletu/jsp vo web containeri cez perzistentne objekty v entity EJB v EJB containeri , tak to prechadza cez tolko vrstiev, ze potencialny SQL injection utok je ovela narocnejsi, ako v pripade priamej generacie SQL dotazu v PHP.

      2. zz_indigo

        Re: SQL Injection

        bohuzial v poslednom riadku sa mylis.

        NEveril by so kolko lusi naksle na sebavzdelavanie a veci programuju tak ako pred par rokmy a zmeni sa len grafika aby to bolo IN.

      3. j

        Re: SQL Injection

        Viz vejs, technika funguje velmi dobre, pocitam ze 30% webu se da pres injection napadnout. Samo nektere to primo ulehcuji.

    3. Murdej

      Re: SQL Injection

      Nevim jak primo v PHP ale Zend_DB umožňuje zapsat dotaz takto
      $db->fetchRow(„SELECT * FROM neco WHERE sloupec=? AND sloupec2=?“, array($val1, $val2));

      1. Zen

        Re: SQL Injection

        Co se prelozi jako
        SELECT * FROM neco WHERE sloupec=$val1 AND sloupec2=$val2
        A pokud nejsou osetrene hodnoty $val1 a $val2, tak se opet racite nachazet tam, kam slunce nesviti (PHP samo neosetruje skoro nic)

        1. ...

          Re: SQL Injection

          napřed bych si o tom něco zjistil než napíšu takovou blbost…pokud použijete mysqli nebo pdo tak se tyto proměnné do dotazu bindují

        2. Sten

          Re: SQL Injection

          A co si to zkusit? Zjistíte, že výsledek bude stejný jako u:
          ‚SELECT * FROM neco WHERE sloupec=“‚.mys­ql_escape_strin­g($val1).’“ AND sloupec2=“‚.mys­ql_escape_strin­g($val2).’“‚

          Btw. tohle sestavování dotazu nedělá PHP :-)

  6. enumag

    Co takhle jiné druhy útoků? SQL Injection už není moc aktuální.

    SQL Injection je známá a u nových projektů dnes už většinou důkladně hlídaná věc. Článek je tedy z mého pohledu poněkud neaktuální. Uvítal bych příklady jak hacknout server, který na SQL Injection náchylný není, tedy méně známé a tím nebezpečnější techniky.

    1. X

      Re: Co takhle jiné druhy útoků? SQL Injection už není moc aktuální.

      Nesuhlasim. Uz len z komentarov som sa dozvedel niekolko zaujimavych veci, ktore mi predtym nenapadli.

  7. David Grudl

    Dodatek

    Jsem vděčný za každý solidní článek o bezpečnosti, protože je stále podceňovaná a na také toto téma koluje řada mýtů, ale tentokrát se to úplně nepovedlo :-(

    Hlavní problém s magic quotes spočívá v „předčasném escapování“, data jsou tedy upravena pro použití v SQL dotazu v konkrétním dialektu starší MySQL či Sybase. Čímž se komplikuje provádění jakýchkoliv jiných operací s nimi, počínaje použitím v jiném dialektu a kódování SQL, přes ověření délky, zkrácení nebo prosté vypsání do HTML. Na což vlastně i autor narazil, když se mu vypsaly před uvozovkama lomítka.

    Magic quotes jsou tedy problematické už z principu a problém vícebajtových kódování je logický důsledek. Ten je v článku popsán korektně, nicméně UTF-8 se skutečně netýká. Jelikož na webu je primárním kódováním právě UTF-8, obvykle se i s databází komunikuje v UTF-8 a problém je tedy, alespoň v našich končinách, spíše hypotetický. Nicméně když už ho zmíním, je vhodné dodat, jak problému předejít: buď použitím bindovaných proměnných nebo escapovat vhodnou funkcí, např. mysqli_escape_string (či použít vyšší vrstvu).

    Příklad s ’2 OR 1=1′ v případě stránkování mi připadá nevěrohodný, nenapadá mě stránkovací dotaz, který by se tímto nerozbil a nechal všechno vypsat bez omezení. Poradíte?

    1. Ondřej Melkes

      Re: Dodatek

      Varainta: ’2 OR 1=1′
      SELECT article_name FROM article WHERE category_id = 2 OR 1=1 LIMIT 0,30

      Případně varainta: ’2 OR 1=1 –‘
      SELECT article_name FROM article WHERE category_id = 2 OR 1=1 — LIMIT 0,30

      1. David Grudl

        Re: Dodatek

        Díky. Takto je to jasné, nedává mi to smysl v kontextu toho odstavce o stránkování a věty „Kliknul jsem si tedy na druhou stránku výpisu a v url jsem přidal k číslu ještě ’2 OR 1=1′“

        1. Autor

          Re: Dodatek

          Máte určitě pravdu, že v kontextu té věty to úplně smysl nedává. V originále bylo stránkování řešené WHERE id < x AND id > x - 10, takže když jsem to psal, mluvil jsem o stránkování. Názornější bylo zmínit jenom WHERE.

          K utf-8: to je nešťastně zmíněné jako příklad dynamic width kódování, zbytek odstavce se na to nevztahuje. Beru v potaz, příště pečlivěji.

          1. David Grudl

            Re: Dodatek

            Současná formulace „Běží-li ale cílový server na kódování s proměnlivou délkou znaků…“ stále není správná, stejný problém se totiž týká i kódování s _pevnou_ vícebajtovou délkou znaků, jako je třeba UTF-32.

            1. František Kučera

              Re: Dodatek

              Problém se týká hlavně hloupého jazyka (resp. jeho standardní knihovny), pokud tam funkce tohoto typu pracuje na úrovni bajtů a ne na úrovni znaků…

    2. XXX

      Re: Dodatek

      >> Hlavní problém s magic quotes spočívá v „předčasném escapování“, data jsou tedy upravena pro použití v SQL dotazu v konkrétním dialektu starší MySQL či Sybase. Čímž se komplikuje provádění jakýchkoliv jiných operací s nimi, počínaje použitím v jiném dialektu a kódování SQL, přes ověření délky, zkrácení nebo prosté vypsání do HTML. Na což vlastně i autor narazil, když se mu vypsaly před uvozovkama lomítka.

      Toto je ale o bezpecnosti, ne o tutorialu programovani. Magic quotes jsou skutecne spatne a zadelavaji na spoustu problemu, fakt ale je, ze pro hackera jsou velkou prekazkou.

    3. Jakub Vrána

      Re: Dodatek

      Pokud bychom s obskurními kódování skutečně pracovali, tak pro správné ošetření mysqli_escape_strin­g() nestačí, je potřeba zavolat ještě mysqli_set_char­set().

  8. Pilgrim

    Pěkný článek

    I když pro mě nic nového, ale i tak oceňuji kvalitu článku zejména v jednoduchosti vysvětlení o co vlastně jde u SQL Injection. Osobně jsem již také na jednom svým webu toto zkoušel. Pravda, že schválně jsem si přizpůsoboval skripty příkazům v URL, ale to hlavně, abych dokázal ještě víc poznat, na co si dát pozor. Těším se na další díl…

  9. profi hacker

    amatéřina

    Nezlobte se na mě, ale SQL injection je opravdu amatéřina, profesionální hacker používá sociální metody a vlastní software na infiltraci do sítě, dá se pak dostat téměř všude.

    Uvedu příklad, naprogramuji si vlastní trojan, který přidám do warezu a rozšířím ho přes warezové stránky. Nádhera je, pokud není moc rozšířený, tak se v nějakých blacklistech antivirů můj trojan vůbec neobjeví.

    A co můj trojan může dělat, sebrat heslo s Total Commandera na FTP, sebrat hesla z prohlížeče atd… To je jen malá ukázka toho, kam se dá zajít. Chce to taky trošku social engineeringu, znalosti programování atd…

    Problém většiny „rádoby“ hackerů tkví v tom, že nemají sociální skilly, nejsou tedy schopni opravdu promyšlených útoků. Podle mě se mnohem lépe útočí se social engineeringem než bez něj.

    1. Sten

      Re: amatéřina

      Metoda by vždy měla odpovídat vytyčenému cíli. Pokud chcete napadnout nějaký (jakýkoliv) server a to pokud možno hodně masově, je trojan asi nejlepší řešení. Pokud chcete napadnout jeden konkrétní server a navíc u toho nechcete vzbuzovat moc velkou pozornost, jsou na to jiné metody; e-mailem poslaný trojan může projít, ale co když jej chytí heuristika antiviru? Nebo na druhé straně bude někdo, kdo není úplně blbý (anebo na ten server nemá přímý přístup)? Akorát je zalarmujete, že se o něco snažíte. Osobní sociální inženýrství je ještě účinnější (hacker vydávající se za technika jdoucího opravit klimatizaci v serverovně ap.), ale co když nevyjde? Většinou vás při něm mohou i zadržet a vaši totožnost už pak zjistí policie.

      SQL injection tak možná vypadá jako amatéřina, ale pro zahájení útoku cíleného na jeden konkrétní server, a to co nejvíce diskrétně (kolik adminů sleduje logy webserveru?) a anonymně, je velmi dobrou metodou. Nakonec se druhá strana většinou ani nedozví, že k nějakému útoku (ať již úspěšnému nebo třeba jenom pokusu, kdy se dozvíte alespoň nějaké zajímavé informace jako jména adminů nebo umístění serveru) došlo, což výrazně zvyšuje vaše šance s jinými metodami (třeba když na tom serveru nejsou data, která potřebujete, a ten server je v DMZ, ale najdete tam jména správců serveru, které uvedete u vchodu, včetně jejich pracovní doby, tedy abyste přišel, když tam zrovna nejsou, a přístupová jména a hesla, která vyzkoušíte v té serverovně nebo na počítačích v kanceláři).

    2. _diehard

      Re: amatéřina

      >Uvedu příklad, naprogramuji si vlastní trojan, který přidám do warezu a >rozšířím ho přes warezové stránky. Nádhera je, pokud není moc rozšířený, tak se >v nějakých blacklistech antivirů můj trojan vůbec neobjeví.

      nezlobte se, ale autor clanku uvedl konkretni priklady, a evidentne se v problematice vyzna i prakticky.

      Ve vasem prispevku pouze teoretizujete, viz odstavec vyse. Vyvedte mne z omylu a popiste jak konkretne budete postupovat..

      >Problém většiny „rádoby“ hackerů tkví v tom, že nemají sociální skilly,

      domnenka nebo je to necim podlozeno ?

  10. ja

    bindParam, bindValue, apod.

    No, jestli není programátor úplný amatér, tak používá vázané proměnné a vy si s vaší SQL injection ani neškrtnete. Každý schopný programátor totiž zachází s SQL takto:

    stmt = sql_prepare(dbh, "SELECT * FROM accounts WHERE username = ?");
    sql_bind_value(stmt, 0, form_input_username, SQL_PARAM_STRING);
    sql_execute(stmt);

    Váš uživatelský vstup se syntaxu SQL ani nedotkne. A v horším případě (pro vás) jsou všechny takto čisté a univerzální SQL výrazy dokonce předkompilované a nabindované přímo v databázovém enginu jako package, u nichž má RDBMS předem připravený optimální access plan a které může využívat třeba 10k aplikací zároveň s nulovou režií.

    Jakékoli „magické uvozovky“, escapování desítek znaků a sekvencí a podobné blbosti jsou jen chatrné berličky, které „pomáhají“ špatným programátorům být ještě horší.

    Celý obsah článku je zvláštní. Možná by byl marginálně relevantní před 10 lety, ale dnes? Podle chvástání ve vašem perexu jsem čekal něco zcela jiného. Že třeba root.cz konečně lapil někoho fakt dobrého. O čem bude příští článek? Jak využít string format vulnerability v SSH-1.5? To vám ale asi příliš fandím… Možná by se však někde ještě taková verze našla. Že by stará SPARCstation v knihovně nějaké Kazachstánské základní školy? :)

    Jestli je článek o tom, jak útočit na domácí stránky fanboyů PHP, tak beru zpět. I když ti se na víc než sdílený hosting nezmůžou a tam vám popen(), system(), passthru() ani nic podobného fungovat nebude. Tím se vám zřejmě narušil váš velkolepý plán, protože bez nich vy na serveru nespustíte jediný proces a váš sen o shellu, který byste mohl mít za 100,- ročně legitimně, opět končí v slzách. ;o)

    Omlouvám se, že vám dávám tak zabrat, ale bylo to ve mně jako v koze. :) Nemyslím to zas až tak vážně. Cokoliv je lepší než ostatní články-reklamy tady. Tohle byl první článek, který jsem si přečetl po několika měsících. I když jen ironicky. Už jsem sem úplně přestal chodit.

    Těším se na další díl. ;o)

      1. ja

        Re: bindParam, bindValue, apod.

        Nejsem. Jsem forenzní analytik a programátor. Citované hodnocení se přece odkazuje na článek jako celek, ne na samotnou techniku SQL injection.

        Od článku „Jdu hacknout váš server“ s úvodem jaký má bych čekal něco šťavnatějšího, nového a zajímavého. SQL injection jako primární útočný vektor je joke, viz dále. Navíc je to technika stará jako web samotný a omletá do zblbnutí. Proto je v této podobě článek 10 let pozadu. Neznalost jak funguje TOR; úsměvný návrh řešení magic_quotes; neznalost bindování; domněnka, že nějaký admin bude opravovat chybu v aplikaci… také přispívá k mým pochybnostem o autorově know-how.

        S SQL injection útočník prostě jen doufá, že programátor bude naprostý diletant, stejně jako provozovatel, který nikdy systém ani aplikaci nedal zauditovat ani neprojel žádným checkerem ani nerozdělil do patřičných separátních vrstev. Objevení takové chyby je triviální a v drtivé většině případů se ani po úspěšném útoku k ničemu nedostane. Jen „pouhý“ přístup k jinak nepřístupným datům vyžaduje několik dalších technických a designových podmínek („chyb“) ve volbě RDBMS, driveru, DB schématu a použitých funkcích, které preprocesují užvateský vstup.

        Většina případů (a ty high-profile všechny), které jste odkazem uvedl, neměly SQL injection jako primární vektor. Jde o jiné průniky do hlubších, méně chráněných, vrstev systémů, kde je již vyčíslitelná šance SQL injection uplatnit.

        Jestli žijete v přestavě, že třeba onen útok na Sony PSN proběhl tak, že někdo na front-endovém webu zadal ve svém FFku vychytralý dotaz do políčka Search a vyjely mu účty s hesly a čísly kreditek, tak jste z jiné planety vy sám.

        PS autorovi: Jak jsem ale napsal, nemyslím to zas až tak vážně. Jako zinscenovaná demonstrace principu na záměrně vadné aplikaci je to dobré. I kdyby jen pro zvýšení povědomí o problému u potencionálních programátorů, kteří si to přečtou.

        1. Radek Miček

          Re: bindParam, bindValue, apod.

          Jestli žijete v přestavě, že třeba onen útok na Sony PSN proběhl tak, že někdo na front-endovém webu zadal ve svém FFku vychytralý dotaz do políčka Search a vyjely mu účty s hesly a čísly kreditek, tak jste z jiné planety vy sám.

          Pokud vím, tak jsem neodkazoval na PSN hack, ale pouze na hack SonyPicters.com

          Většina případů (a ty high-profile všechny), které jste odkazem uvedl, neměly SQL injection jako primární vektor. Jde o jiné průniky do hlubších, méně chráněných, vrstev systémů, kde je již vyčíslitelná šance SQL injection uplatnit.

          Podle těch popisů, co odkazuje Wikipedie, to vypadá, že nemáte pravdu. Nebo máte jiné zdroje?

          1. ja

            Re: bindParam, bindValue, apod.

            Co odpovědět člověku, který se dohaduje na základě popisků v sekci referencí narychlo vygooglené stránky z Wikipedie s někým, koho daný obor léta živí a je mu i koníčkem, na otázku „Nebo máte jiné zdroje?“

            Myslím, že jsem své věcné argumenty k článku rozvedl dostatečně, takže se prosím neurazte, když se s vámi rozloučím. Začíná mi to připadat jako nikam nevedoucí flame diskuze. Svoje názory ani zkušenosti vám nevnucuji.

    1. fos4

      Re: bindParam, bindValue, apod.

      „..které může využívat třeba 10k aplikací zároveň s nulovou režií.“

      Nepřenáší se náhodou u bindování zvlášť dotaz a zvlášť data ? Pak je režie větší než v případě přípravy dotazu mimo db server.

      1. ja

        Re: bindParam, bindValue, apod.

        V citovaném scénáři se dotazy se nepřenáší vůbec, jsou předem naplánované přímo v DB enginu. Když máte update logiky a/nebo schéma DB, tak se nainstalovaných aplikací nemusíte ani dotknout. Pouze zupdatujete package (kolekce dotazů) nabindované v DB. Dobré řešení se tedy nepromítá pouze do rychlosti a bezpečnosti SQL, ale i ohromným úsporám času při vývoji a administraci.

        Na celém dotazu je zdaleka nejpomalejší vyhodnocení přístupového plánu – co ten dotaz vlastně chce, jak požadovaná data poskládat a hlavně jak to udělat co nejrychleji (je hromada metod přístupu k datům, kombinací indexů, kontroly referenční integrity, atd). I když máte „jen“ připravené univerzální SQL (prepare) – tedy ne jako package v DB, ale běžně remote z aplikace – tak engine při preparu naparsuje dotaz, připraví plán a veškeré volání query daného dotazu jsou čisté přístupy k datům. Díky této separaci je opakovaný dotaz o několik řádů rychlejší.

        Ve skutečnosti se „přenáší dotaz a parametry zvlášť“ ať voláte jak chcete. Příprava a vykonání dotazu jsou vždy dva kroky. Když prepare neuděláte vy, udělá ho aplikační driver za vás (jenže ne jednou, ale při každé invokaci). Vlastní žádost o data (ať s prázdnou nebo plnou množinou substitučních hodnot) půjde na server samostatně.

Napsat komentář

Přihlásit se

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: http://www.zdrojak.cz/?p=3604