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.
Pro Ministerstvo zdravotnictví jsme pomohli připravit krizový web o koronaviru, který se stal jedním z hlavních informačních kanálů pro všechny občany. Článek popisuje, jak jsme web upravili, aby zvládl tak velký nápor.
V tomto díle začneme psát naši ukázkovou aplikaci. Povedeme Vás od úplného začátku až po finální deployment do produkce. V průběhu si ukážeme využití všech hlavních vlastností IMA.js a jak vytvořit často používané prvky webových aplikací.
Existuje několik možností, jak ověřit platnost certifikátu, pojďme si některé ukázat.
To ještě funguje?
Tohle mohlo fungovat před 10 lety, ale kdo by dneska v době ORM psal SQL dotazy ručně?
Re: To ještě funguje?
8-)
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.
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.
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ší).
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 ;-)
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.
Re: To ještě funguje?
V PHP manuálu je o SQL injection kapitola. Navíc na potřebu ošetření upozorňují i jednotlivé stránky:
Re: To ještě funguje?
Dík za doplnění, kapitola je fajn, snažil jsem se v rychlosti najít, kde je na ní odkaz a ani na http://php.net/manual/en/mysql.examples-basic.php a ani na http://php.net/manual/en/function.mysql-query.php jsem ho nenašel, ale možná jsem se přehlédl. To byl můj point, chybí mi zmínka u těch úplně základních příkladů.
should be je podle mě poměrně málo zavazující ;-)
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…
Re: To ještě funguje?
Raw dotazy pouzivam, hlavne tam, kde je potreba ho hodne optimalizovat.
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.
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í.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.
Havij
Havij je lehce zavirovaný :D
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 zavolatmysql_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_PREPARESje 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_PREPARESvypněte. Pro MySQL je potřeba vypnout, direktivuPDO::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.
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:
$db->prepare("SELECT ... WHERE id = $_GET[id]").ORDER BY ?.IN (?)neboVALUES (?).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).
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 ;-)
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í.
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.
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.
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?
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.
Re: Jak se *opravdu* bránit?
Vypínat
PDO::MYSQL_ATTR_DIRECT_QUERYnení třeba, od PHP 5.3.6 lze nastavit kódování při připojení pomocí parametrucharsetv DSN. ObdobněPDO::ATTR_EMULATE_PREPARES.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_QUERYje opravdu defaultně vyplé, díky za doplnění.Re: Jak se *opravdu* bránit?
PDO::MYSQL_ATTR_DIRECT_QUERYje 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í DSNmysql:host=localhost;charset=utf8.Re: Jak se *opravdu* bránit?
V rychlosti jsem se do defaultního nastavení
PDO::MYSQL_ATTR_DIRECT_QUERYzamotal, 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ě.
Re: Jak se *opravdu* bránit?
Aby se data správně ošetřovala, tak se musí
charsetuvé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).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.
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í?
Re: Dotaz na autora
Ale to neni špatnej nápad. Nechceš pak o tom napsat článek?
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]
Re: Dotaz na autora
A co zapnout magic quotes?
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.
Re: Dotaz na autora
Zdroják používá MySQL, a proto v komentářích nelze použít některé znaky jako například
Re: Dotaz na autora
wtf, proc pouzivas jako nick neci jmeno ?
Re: Dotaz na autora
WTF? To psal David Grudl a jmenuje se tak (viděl jsem to u něj v občance).
Re: Dotaz na autora
Nebyl to David Grundl?
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.
Re: Dotaz na autora
:D jsi asi jedinej, komu to nedoslo
ú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.
Re: úroveň vysokoškolského vzdělání
Kdyby jsi tu hlášku na BitBucketu dočetl do konce, tak bys zjistil, že se zdrojáky jenom přesunuly jinam ;-) https://github.com/igorkulman/ModularCMS
Re: úroveň vysokoškolského vzdělání
Náhodně jsem kouknul na jeden zdroják a hle, co jsem tam našel:
db
asi bych všechny ty (internety a databáze) zrušil..
a když ne, tak radši použijte ….. nebo (dibi / notorm) :)
Jak píše SQL autor
Např. https://github.com/igorkulman/ModularCMS/blob/master/src/page.AdminGallery.php
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 ;)
Re:
Co z toho vyplývá, že někdo před šesti (?) lety psal děsný kód?
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 ;-)
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.
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***
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.
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.
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.
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.
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?
Re:
Pri psani diplomove prace.
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?
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.
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í.
Re:
Shodneme se jedine na tom, ze dokud clanek nebude updatovan, ani takove veci znat nemusim.
Re:
Ja si tech autoru budu vazit az to v clanku doplni/opravi na zaklade pripominek ve zde smazanych prispevcich (good luck)
Re:
To mi zní jako nějaký nesmysl. Autorů si přeci nemusíte vážit. Proč byste měl? A proč vlastně chcete?
Re:
Reagoval jsem na vase: „Ja si autoru vazim i s jejich chybami“
Re:
Samozrejme, ze nemusim, omlouvam se, ze jsem se spletl v uvaze a mylne se domnival, ze to zde ma mit uroven.
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“ :)
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.
Re:
Souhlas.
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…
Re:
Viz má odpověď vedle.
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.
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.