Komentáře k článku

SQL Injection pre každého

V dnešnej dobe plnej webových frameworkov, databázových knižníc a ORM by som tak trochu čakal, že webov náchylných na SQL Injection už nebude veľmi veľa. Opak je však pravdou a zaútočiť na tieto weby pomocou SQL Injection už môže naozaj ktokoľvek, stačí mu len vhodný nástroj a trochu trpezlivosti.

Zpět na článek

70 komentářů k článku SQL Injection pre každého:

  1. bubla

    To ještě funguje?
    Tohle mohlo fungovat před 10 lety, ale kdo by dneska v době ORM psal SQL dotazy ručně?

    1. Filip Procházka

      Re: To ještě funguje?
      Ano, funguje. I v tento moment na světe najdeš několik lidí, kteří se právě učí programovat. A je dost velká šance, že ORM nepoužití, a dokonce nepoužijí ani prepared statements, ale prostě si poskládají SQLko ze stringu a parametrů requestu.

      To je prostě realita. Nikdo nezačne s programováním a není lusknutím prstů naprosto dokonalý programátor co nedělá chyby.

      1. filip.jirsak

        Re: To ještě funguje?
        Pokud někdo začíná s programováním, měl by se z alespoň podprůměrného článku dozvědět, že poskládání SQL příkazu z textových částí a parametrů požadavku je to nejhorší, co může udělat. Nikdo není lusknutím prstů dokonalým programátorem. Ale dokonalým programátorem se nestane ani čtením článků, které ho naučí, jak to dělat špatně – právě naopak.

        1. Filip Procházka

          Re: To ještě funguje?
          No a jak jako začátečník poznáš, že to je špatně, když ani nevíš, že SQL Injection existuje? A nic si nenalhávejme, který začátečník by tohle mohl tušit?

          Problém je, že na googlu najdeš tisíce článků psaných před >10 lety a nebo jinými začítečníky (což je mnohdy ještě horší).

          1. Michal Špaček

            Re: To ještě funguje?
            Začátečník se o SQL Injection může dozvědět třeba v oficiální dokumentaci, často hned rovnou někde na začátku. Např. kapitola Basic module usage pro psycopg2 to rovnou obsahuje a zmiňuje se o SQL Injection. Ve světe PHP to zatím není běžné. Má to jen jeden problém – tiše předpokládám, že začátečníci oficiální dokumentaci čtou ;-)

            1. VladaHejda

              Re: To ještě funguje?
              několik? na světě je tisíce začátečníků kteří píšou s tim co FUNGUJE a bezpečnost je nezajímá protože „proč by měl zrovna jejich web někdo napadat“. Pro ně je tenhle článěk důležitej.

    2. jlk

      Re: To ještě funguje?
      Já, já, já. Když člověk vidí, co z toho ORM leze, tak si rve vlasy a běží pro tekutý dusík, aby to to server vydržel. Na menší projekty ORM používám, ale jakmile začne hrozit, že bude DB výrazné užší hrdlo, je to podle mě o hubu…

    3. Jinaq

      Re: To ještě funguje?
      Raw dotazy pouzivam, hlavne tam, kde je potreba ho hodne optimalizovat.

    4. OndrejMirtes

      Re: To ještě funguje?
      I v době ORM lze SQL dotazy psát ručně a dokonce to i vřele doporučuji. V případě Doctrine se používá jazyk DQL, který se překládá na velmi podobné SQL a pokud něco neumí, dá se to do něj doimplementovat.

  2. filip.jirsak

    proč se vydávají takovéhle nesmysly?
    Proč takovýhle nesmyslný článek vyšel na Zdrojáku? To nejdůležitější – jak se bránit – je napsáno ve třech větách, a navíc je to celé špatně. Kontrola vstupních dat SQL injection nezabrání (i validní vstupní data mohou vést na SQL injection), mysql_real_escape_string() není funkce pro kontrolu vstupních dat a jako obrana před SQL injection je to to nejhorší možné řešení.

    1. David Adamczyk

      Re: proč se vydávají takovéhle nesmysly?
      Od toho je tady diskuze aby fundovani odbornici vse uvedli na pravou miru. Kdyz si chci precist neco o bezpecnosti webovych aplikaci zacnu nejprve napr. na webu OWASP a potom googlim dalsi podstatne veci. IMHO by clanku neuskodilo par relevantnich odkazu na danou problematiku. Myslim ze bezpecnost webovych aplikaci nekonci jen u SQL Injection (o kterem je napsano uz 1234 tisic clanku), fandim autorovi a snad v budoucnu napise i o necem novejsim.

  3. Michal Špaček

    Jak se *opravdu* bránit?
    Pokud se chcete proto SQL Injection opravdu bránit, tak sice můžete použít mysql_real_escape_string(), ale je předtím potřeba zavolat mysql_set_charset(), jinak je pořád možné provést SQL Injection. Volání mysql_query('SET CHARSET ...') apod. nestačí, správnou znakovou sadu pro escapování musí znát i klient, kterému se to řekně práve pomocí mysql_set_charset() – stačí to zavolat jednou po připojení.

    Nicméně je rok 2014, mysql rozšíření (a funkce jako mysql_real_escape_string()) používejte už jen u velmi starých projektů, pro nové a novější věci použijte prepared statements, které v PHP jsou dostupné třeba díky rozšíření PDO, např.

    $result = $db->prepare('SELECT ... FROM ... WHERE id = ?')->execute($_GET['id']);

    Do SQL dotazu tedy žádné proměnné nedávejte a „připojujte“ je tam pomocí otazníku a proměnnou poté předejte do metody execute().

    PHP standardně používá emulované prepared statements, direktiva PDO::ATTR_EMULATE_PREPARES je defaultně zapnutá (můžete si to ověřit ve zdrojovém kódu PHP), takže rychlost je naprosto stejná, jako když si „slepíte“ dotaz sami. PDO také data správně oescapuje a pak pošle jeden dotaz do databáze, jen s PDO je to pohodlnější a hůře se zapomíná na správné ošetření.

    Díky tomu, že defaultně PDO escapuje, tak je stále náchylné na SQL Injection, pokud se pro MySQL nastaví špatná znaková sada, ale to už se rovná takové menší sabotáži, je potřeba ten kód napsat opravdu dost nešikovně a musíte vědět jak na to. Pokud chcete opravdovou ochranu proti SQL Injection, tak PDO::ATTR_EMULATE_PREPARES vypněte. Pro MySQL je potřeba vypnout, direktivu PDO::MYSQL_ATTR_DIRECT_QUERY.

    Pozor také na to, že napadání cizích webů vás může dostat do problémů, děcka, doma to raději nezkoušejte.

    Pokud by vás zajímalo, proč je MD5 špatně a jak hesla správně ukládat, tak se podívejte na moji prezentaci o ukládání hesel. Jak konkrétně jsme to implementovali na jednom webu ukazuji v přednášce o zlepšení zabezpečení Slevomatu.

    1. Jakub Vrána

      Re: Jak se *opravdu* bránit?
      Používat prepared statements jako obranu proti SQL injection bych srovnal s použitím MD5 pro ukládání hesel. Dříve se to doporučovalo a s jistými „ale“ to jde dělat i dnes, ale má to řadu nevýhod:

      1. Nic mi nezabrání napsat $db->prepare("SELECT ... WHERE id = $_GET[id]").
      2. Není podporovaná práce se sloupci, např. ORDER BY ?.
      3. Není podporovaná práce se seznamy, např. IN (?) nebo VALUES (?).
      4. Krkolomně se pracuje i s hodnotou NULL.

      Nejde jen o to, že jsou tyto obraty nepohodlné. Jde o to, že když programátoři tyto nedostatky řeší, tak v kódu často nasekají bezpečnostní chyby.

      Řešením je používat knihovnu vyšší úrovně, která těmito nedostatky netrpí, spolu s linterem, který zabrání prvnímu problému. Tato knihovna vevnitř může klidně používat prepared statements, ale většinou k tomu není důvod. Dobrou ukázkou je knihovna libphutil, její funkce qsprintf a související linter. Existují samozřejmě i jiná řešení, např. dibi nebo NotORM, které to řeší zase trochu jinak (a nemají linter).

      1. Michal Špaček

        Re: Jak se *opravdu* bránit?
        Hlavní důvod proč jsem ten komentář napsal bylo, aby lidé nelepili proměnné do SQL dotazů. Možná jsem měl místo prepared statements použít termín vázání proměnných, může v tom být rozdíl, záleží na úhlu pohledu.

        Ono defaultně ani prepared statements v PHP nepoužívají prepared statements v db serveru, použití některých knihoven, které mají pohodlnější API je samozřejmě ještě lepší, souhlasím.

        Srovnání s MD5 je trochu nešikovné. Když se použijí prepared statements tak jak mají a vývojář si je vědom omezení, tak to aplikaci proti SQL Injection chrání. Správně použít MD5 na ukládání hesel ani snad nejde ;-)

        1. Jakub Vrána

          Re: Jak se *opravdu* bránit?
          Odrazovat od lepení dotazů je stejně chvályhodné jako odrazovat od ukládání hesel v plaintextu. Ale doporučit vázání proměnných je jako poradit MD5 na hesla. Srovnatelné to podle mě v klidu je. Když doporučím ukládat md5($password . $login) a budu vyžadovat dvanáctiznaká hesla s velkou entropií, tak se dostanu zhruba na úroveň vázání proměnných. Bude to jakž takž bezpečné, ale má to pořád zásadní problémy.

          Srovnání vem čert. Jde o to, že vázání proměnných jako dostatečnou obranu proti SQL injection samo o sobě použít nejde. Prepared statements v PDO jsou omezené tím, že musí zůstat kompatibilní se serverovou implementací.

          1. Michal Špaček

            Re: Jak se *opravdu* bránit?
            Vázáním proměnných jsem myslel API, které odděluje proměnné od samotného dotazu, jako protiklad lepení proměnných přímo do dotazu. Tedy i to, co používá dibi, NotORM a další. Možná to není nejšťastnější pojmenování, ale nevím jak tomu říkat, možná stačilo použít „nelepte proměnné do dotazu a posílejte je v jiných parametrech“.

            Na srovnání s MD5 se neshodneme, ale to asi nevadí :-)

            S tím, že prepared statements nejsou pro práci moc pohodlné, viz tebou ukázané příklady, a vývojáři mohou (ale nemusí) dynamickým sestavováním dotazu snížit zabezpečení, s tím souhlasím.

            1. Jakub Vrána

              Re: Jak se *opravdu* bránit?
              Já bych se prostě dnes zdráhal někomu samotné PDO doporučit. Můj podrobnější článek na toto téma vyšel i tady na Zdrojáku.

              1. Michal Špaček

                Re: Jak se *opravdu* bránit?
                Asi bude lepší říkat „Místo ext/mysql použijte PDO, ale některé věci se v něm dělají nepohodlně, takže až si je tam budete dodělávat, tak si tam zranitelnost zase můžete zatáhnout. Použijte tedy raději něco, co má pohodlnější API, jako např. …“ Souhlas?

                1. Jakub Vrána

                  Re: Jak se *opravdu* bránit?
                  Na tom se neshodneme. Důležité je použít knihovnu, která řeší pokud možno všechno správně. Co používá vevnitř, je druhořadé. PDO takovou knihovnou určitě není, ale vevnitř použitá být může a nemusí. Např. libphutil podporuje ext/mysql a ext/mysqli.

    2. Jakub Vrána

      Re: Jak se *opravdu* bránit?
      Vypínat PDO::MYSQL_ATTR_DIRECT_QUERY není třeba, od PHP 5.3.6 lze nastavit kódování při připojení pomocí parametru charset v DSN. Obdobně PDO::ATTR_EMULATE_PREPARES.

      1. Michal Špaček

        Re: Jak se *opravdu* bránit?
        Pro PDO většinou není potřeba nastavovat charset, dokonce právě díky špatně nastavenému charsetu a některým znakovým sadám je SQL Injection v PDO (s defaultně zapnutými emulovanými prepared statements) možné provést.

        PDO::MYSQL_ATTR_DIRECT_QUERY je opravdu defaultně vyplé, díky za doplnění.

        1. Jakub Vrána

          Re: Jak se *opravdu* bránit?
          PDO::MYSQL_ATTR_DIRECT_QUERY je defaultně zapnuté: mysql_driver.c#L590. Není potřeba vypínat, protože emulované prepared statements (které jsou obvykle skoro dvakrát rychlejší) jsou bezpečné, pokud je správně nastavené kódování. Kódování nastavené v DSN se od PHP 5.3.6 respektuje: mysql_driver.c#L729. To, co píšeš, platilo v PHP < 5.3.6, navíc jen v situaci, kdy server měl defaultně nastavené nějaké exotické kódování jako Shift JIS (což nemívá). Dnes už jde o zbytečné strašení lidí a lepší je popsat, jak správně kódování nastavit. Např. pomocí DSN mysql:host=localhost;charset=utf8.

          1. Michal Špaček

            Re: Jak se *opravdu* bránit?
            V rychlosti jsem se do defaultního nastavení PDO::MYSQL_ATTR_DIRECT_QUERY zamotal, omlouvám se. Ten řádek to ukazuje zcela jasně, dík.

            Tady je dump tabulky a kód v PHP, kterým jde udělat SQL Injection i v PHP 5.5 (testováno na Windows, PHP 5.5.9), používá databázi ve znakové sadě GBK a nastavuje ji špatně, ačkoliv takto nějak podobně se to běžně dříve dělalo. Na druhou stranu, nevím, co dnes frčí v Číně. Na znakové sadě nastavené na serveru nezáleží, testováno s character-set-server=utf8.

            Dump a zdrojáky na https://github.com/spaze/emulated-prepare-statements – kde je problém a jak ho vyřešit je naznačeno přímo ve zdrojovém kódu.

            Lidi samozřejmě strašit nechci a sorry, jestli jsem tím někoho vystrašil. Pokud se nastaví znaková sada správně, tak jsou emulované prepared statements v pohodě.

            1. Jakub Vrána

              Re: Jak se *opravdu* bránit?
              Aby se data správně ošetřovala, tak se musí charset uvést v DSN. To celkem jasně uvádím a tobě to tam chybí, navíc i na řádku s navrženou opravou (zřejmě jen překlep). To je potřeba lidem vtloukat do hlavy, naopak o emulaci prepared statements kvůli bezpečnosti vědět ani nemusí (ale zase se to hodí kvůli výkonnosti).

              1. Michal Špaček

                Re: Jak se *opravdu* bránit?
                Dík za upozornění, byl to opravdu jen překlep. Když už někde vysvětluju prepared statements, tak existenci emulated prepared statements nerad tajím a je jedno, jestli se jedná o bezpečnost nebo výkonnost. Emulované prepared statements mohou být rychlejší, ale také nemusí, záleží na použitém RDBMS a aplikaci, ale to už se dostáváme od SQL Injection trochu někam jinam, nemá cenu v tom pokračovat.

  4. DavidGrudl

    Dotaz na autora
    Děkuji za super článek. Upravil jsem své weby, aby byly odolné proti SQL injection pomocí doporučené sanitizace, takže ze všech řetězců, které ukládám do databáze, odstraňuji uvozovky. Funguje to perfektně. Ale narazil jsem na nepříjemný problém. Potřeboval bych totiž uložit do databáze článek, který obsahuje PHP kód, ve kterém jsou uvozovky použité :-(

    Chtěl jsem se proto zeptat, zda je vůbec možné do databáze ukládat řetězce obsahující uvozovky? Všiml jsem si, že v některých článcích zde na Zdrojáku se uvozovky vyskytují. Používá Zdroják databázi? Nebo existuje nějaký trik, jak lze toto omezení obejít a do databáze uvozovky uložit?

    Napadlo mě převést uvozovky na HTML entity. Je to správné řešení?

    1. HonzaMarek

      Re: Dotaz na autora
      Ale to neni špatnej nápad. Nechceš pak o tom napsat článek?

    2. JakubKohout

      Re: Dotaz na autora
      [trolling]
      V takovem pripade je vhodne pouzit funkci addslashes na vstupu a na vystupu pomoci str_replace provest prevod zpet

      mysql_insert("INSERT INTO tabulka VALUES(NULL, ".addslashes($text_clanku).")");

      Na vystupu potom muzes jednodusse udelat
      list($text) = mysql_fetch_array(mysql_query("SELECT obsah FROM tabulka"));
      $text = str_replace('\"', '"', $text);

      [/trolling]

        1. JakubKohout

          Re: Dotaz na autora
          samozrejme pokud to na webhostingu umi takhle zapojit tak je lepsi pouzit magic_quotes. Je s tim pak min prace.
          Treba muj oblibenej webzdarma.cz to umi, proto taky nic jineho nepouzivam.

    3. Jan Prachař

      Re: Dotaz na autora
      Zdroják používá MySQL, a proto v komentářích nelze použít některé znaky jako například

      1. Martin Hassman

        Re: Dotaz na autora

        WTF? To psal David Grudl a jmenuje se tak (viděl jsem to u něj v občance).

        1. karel

          Re: Dotaz na autora
          hmm clovek ktery napise databazovi layer se bude ptat na takovou kravinu ? to jako fakt ? Protoze takovym dotazem by zdiskreditoval veskerou svou praci do ted.

  5. Martin Prokeš

    úroveň vysokoškolského vzdělání
    A tohle je prosím absolovent „softvérového inžinierstva na Univerzite Karlovej v Prahe“. Smutné :(

    Nedalo mi to a na http://is.cuni.cz/IS-139.html jsem našel autorovu bakalářskou práci na téma ModularCMS (co by to taky bylo za PHP programátora, kdyby si nenapsal vlastní CMS, že. Práce samozřejmě začíná přehledem shitových cizích CMS). Škoda že zdrojáky jsou již smazané (viz http://www.kulman.sk/content/modularcms ) mohli jsme se zasmát ještě víc.

      1. Chobot

        Re: úroveň vysokoškolského vzdělání
        Náhodně jsem kouknul na jeden zdroják a hle, co jsem tam našel:

        $alias = $db->getCell("SELECT id FROM content WHERE alias='{$_POST["alias"]}'");
        
  6. thecnology

    db
    asi bych všechny ty (internety a databáze) zrušil..
    a když ne, tak radši použijte ….. nebo (dibi / notorm) :)

  7. Lamicz
    $db->query("UPDATE gallery_albums SET title='{$_POST["title"]}', text='{$_POST["text"]}' WHERE id='{$id}' AND lang='{$r["lang"]}'
    

    BTW „ty kódy“ jsou teda celkově děs co jsem se tak díval. Jako sám taky nepíšu zrovna nic úžasného, ale alespoň nepíšu na Zdroják. Autorovi bych vzkázal, že na toto téma jsou tu povolanější – ono to PHPko je dost známý jazyk ;)

    1. David Grudl

      Re:
      Co z toho vyplývá, že někdo před šesti (?) lety psal děsný kód?

      1. Chobot

        Re:
        1) V tom jeho repozitáři vidím poslední změny „2 years ago“

        2) Jestliže se někdo poučil o SQL injection a prozřel natolik, že o tom začne psát edukativní články na servery pro vývojáře, tak si snad zamete před vlastním prahem, ne? To znamená:

        a) buď ty zdrojáky opravit (ideální řešení)

        b) nebo je stáhnout, aby nikoho nevedly špatným směrem (např. čtenáře, který se tam nějak prokliká)

        c) nebo tam aspoň dát velkou ceduli: TAKHLE SE TO NEDĚLÁ a prohlásit to za odstrašující případ.

        BTW: já začínal s PHP dříve než autor a už tehdy jsem se dočetl o SQL injection a odzačátku důsledně používal parametrizované dotazy, místo abych lepil stringy a $_POST parametry ;-)

        1. Martin Hassman

          Jedná se o klasický FUD na autora článku. Pokud to není z předchozí věty jasné, tak další příspěvky budu mazat.

          1. v2kt0r

            Re:
            Teď ještě co má Fear-Uncertainty-Doubt společného s předchozím příspěvkem a autorem článku? ***ZBYTEK KOMENTÁŘE BYL MODEROVÁN***

            1. Martin Hassman

              Re:

              Počítám, že chápete, jaký je rozdíl mezi slušným dotazem a pokusem o urážku, proto nebudu dále vysvětlovat, proč byl váš komentář moderován.

              Co se týče vašeho dotazu, tak narozdíl od ostatních diskutujících tu Chobot nejen v tomhle, ale i ve smazaném komentáři, neřeší chyby v článku, ale snaží se cíleně poškodit osobu autora jako takovou a to přesně v souladu s principy FUDu, šířením informací, které mají vyvolat pochybnosti o autorově osobě jako takové (všechna ta tři písmenka jdou na tohle aplikovat), navíc demagogickým způsobem. Já si vážím si našich autorů a to včetně jejich chyb a jsem přesvědčen, že něco takového sem (a nejen sem) nepatří. Nevím, zda mě, Viktore, pochopíte, ale o vysvětlení jsem se alespoň pokusil.

              1. dword

                Re:
                To, ze si to berete osobne, je vas problem. Autor poukazoval na nezodpovednost mistnich autoru, kteri se tvari jako mentori dane problematiky, pricemz siri jen dalsi spatne navyky (vytloukani klinu klinem). Cele to pusobi jako kdyby clanek musel byt vydan v urcity cas. Uznavam ze vase taktika je hodne dobra – svest to na FUD, nicmene na mne osobne napriklad neplati.

                1. Martin Hassman

                  Re:

                  Osobně neosobně, je fajn označovat urážku urážkou a snahu ublížít snahou ublížít – říká se to mu pravda.

                  A je rozdíl mezi komentováním obsahu článku (což nakonec pomůže oněm začátečníkům, kteří si článek přečtou a takové komentáře sem patří) a mezi snahou poškodit osobnost autora navíc za irelevantní věci – např. za to jaký napsal před lety kód do projektu za diplomovou práci. Jsem přesvědčen, že FUD je správné označení. Ale hlavu máme každý svoji, nechť se všichni rozhodnou podle sebe.

                  1. dword

                    Re:
                    Naopak, napsanim diplomove prace opet tvorite obsah dostupny verejnosti a jako autor tyto dusledky budete nest cely zivot. Srovnani vidim jako naprosto relevantni. Z vasich slov mi vyplyva, ze vam to bylo jedno i tehdy, i dnes.

                    1. Martin Hassman

                      Re:

                      To ale není v rozporu s tím, za čím stojím.

                      BTW co znamená „Z vasich slov mi vyplyva, ze vam to bylo jedno i tehdy, i dnes?“ Tomu nerozumím. Kdy tehdy mi to bylo jedno?

                        1. Martin Hassman

                          Re:

                          Stále nerozumím, vypadá to na pořádný zmatek. Ze kterých mých slov „vyplývá, že mi to bylo jedno i tehdy, i dnes?“ Jak s tímhle souvisí má diplomová práce?

                          1. dword

                            Re:
                            Vase diplomova prace nijak, jde o pristup s jakym tvorite verejne dostupne zdroje informaci. Preferujete smazani podnetnych komentaru pred zpetnou vazbou autorovi a nasledne korekci (kompromis by byl zmoderovat prispevek se zachovanim podnetnych veci namisto oznaceni jako FUD a cau). Tvrdim, ze to je nezodpovedne. Ze kterych slov to vyplyva neni dulezite, kdyz muj postoj stejne nikdy neprijmete.

                            1. Martin Hassman

                              Re:

                              Shodneme se alespoň na tom, že veškeré vaše obviňování mé osoby se skládá z vašich osobních projekcí a dojmů a o mě a o mých skutečných postojích nevíte prakticky nic?

                              Třeba ono „Preferujete smazani podnetnych komentaru pred zpetnou vazbou autorovi“ je jeden z mnoha nesmyslů, na kterých tahle debata stojí.

                              1. dword

                                Re:
                                Shodneme se jedine na tom, ze dokud clanek nebude updatovan, ani takove veci znat nemusim.

              2. dword

                Re:
                Ja si tech autoru budu vazit az to v clanku doplni/opravi na zaklade pripominek ve zde smazanych prispevcich (good luck)

                1. Martin Hassman

                  Re:

                  To mi zní jako nějaký nesmysl. Autorů si přeci nemusíte vážit. Proč byste měl? A proč vlastně chcete?

                  1. dword

                    Re:
                    Samozrejme, ze nemusim, omlouvam se, ze jsem se spletl v uvaze a mylne se domnival, ze to zde ma mit uroven.

  8. Marek Sirkovský

    FUD
    Tak jediné co jsem se z celého článku a celé diskuze dozvěděl, je že existuje zkratka FUD :)
    Možná mi to připadá naivní a moc obecné, protože už je to pár let, co jsem řešil takové „základní“ věci jako sql injection, ale možná pro začínající programátory, to má smysl.
    Ale ten konec je dle mě trošku odfláknutý. Autor to mohl více rozvést, více se rozepsat a dát více odkazů apod…
    Takhle to vypadá, jen jako odškrtnutá fajfka „v červenci vydat článek na zdrojáku“ :)

  9. Marek Sirkovský

    Místo diskuzí o autorovi, FUD, jeho hříchu z mládí, nemůže někdo ten článek spravit? Nebo aspoň stáhnout z webu, dokud se nespraví? Balastu je na internetu dost, tak ho netřeba přidávat a tohle reputaci Zdrojaku nepřidá.
    Narážím hlavně na Havij a na tu problematickou sanitizaci.

    1. PJ

      Re:
      Souhlas.

      nemůže někdo ten článek spravit?

      Obávám se, že přístup do redakčního systému má jen Martin Hassman. A už mu to psalo několik lidí a pořád se k tomu nemá. Ani neodpověděl, jestli prověřoval zavirovanost toho Havij a další věci…

    2. Martin Hassman

      Re:

      Upozornění k Havai jsem přidal, opatření proti SQL injection jsou velmi slušným způsobem diskutované v komentářích, které patří k článku a čtenáři snad dostatečně pomůžou.

  10. karel

    clanek na urovni seminarky prvaku stredni skoly
    obsah clanku jen ukzauje to ze nejak dosly napady na clanky, pridana hodnota informaci v clanku je 1% a to ze jsem se dovedel o programku na testovani, mimochodem firefox ma na to pluginy co zvladnou i jine testy nez jen injection a je to free.

Zdroj: https://www.zdrojak.cz/?p=12831