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

1. 

   bubla 18.7.2014 ve 00:30

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

   Martin Hassman 18.7.2014 ve 01:49

   Re: To ještě funguje?

   8-)
2. 

   Filip Procházka 18.7.2014 v 03:14

   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 18.7.2014 v 09:15

   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 18.7.2014 ve 20:30

   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 18.7.2014 ve 20:46

   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 18.7.2014 ve 21:16

   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. 

   Jakub Vrána 18.7.2014 ve 21:31

   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:

   mysql_query Data inside the query should be properly escaped.

   mysqli_query Data inside the query should be properly escaped.

   PDO::query Data inside the query should be properly escaped.
1. 

   Michal Špaček 18.7.2014 ve 22:15

   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í ;-)
3. 

   jlk 18.7.2014 ve 14:45

   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…
4. 

   Jinaq 18.7.2014 ve 18:16

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

   OndrejMirtes 18.7.2014 ve 21:03

   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 18.7.2014 v 09:12

   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 18.7.2014 v 09:29

   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. 

   GraslT 18.7.2014 v 09:53

   Havij
   Havij je lehce zavirovaný :D
4. 

   Michal Špaček 18.7.2014 ve 18:58

   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 18.7.2014 ve 22:12

   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 18.7.2014 ve 22:26

   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 18.7.2014 ve 23:14

   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 19.7.2014 ve 01:47

   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 19.7.2014 v 02:19

   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 19.7.2014 v 02:45

   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 19.7.2014 v 03:27

   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 18.7.2014 ve 22:12

   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 18.7.2014 ve 22:32

   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 18.7.2014 ve 23:04

   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 19.7.2014 v 02:33

   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 19.7.2014 v 03:22

   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 21.7.2014 ve 15:06

   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.
5. 

   DavidGrudl 18.7.2014 ve 20:13

   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 18.7.2014 ve 20:52

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

   JakubKohout 18.7.2014 ve 20:52

   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. 

   OndrejMirtes 18.7.2014 ve 21:00

   Re: Dotaz na autora
   A co zapnout magic quotes?
1. 

   JakubKohout 18.7.2014 ve 21:09

   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ř 18.7.2014 ve 23:11

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

   karel 22.7.2014 ve 01:28

   Re: Dotaz na autora
   wtf, proc pouzivas jako nick neci jmeno ?
1. 

   Martin Hassman 22.7.2014 ve 14:26

   Re: Dotaz na autora

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

   T3RMiX 22.7.2014 ve 19:19

   Re: Dotaz na autora
   Nebyl to David Grundl?
2. 

   karel 23.7.2014 v 09:09

   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.
1. 

   Kolemjdouci 23.7.2014 v 10:21

   Re: Dotaz na autora
   :D jsi asi jedinej, komu to nedoslo
6. 

   Martin Prokeš 18.7.2014 ve 21:35

   ú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. 

   arron 20.7.2014 v 02:35

   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
1. 

   Chobot 20.7.2014 ve 22:33

   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"]}'");
   
7. 

   thecnology 18.7.2014 ve 22:32

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

   Lamicz 21.7.2014 v 08:36

   Jak píše SQL autor
   Např. https://github.com/igorkulman/ModularCMS/blob/master/src/page.AdminGallery.php

   $album_id = $db->getCell("SELECT album_id FROM gallery_fotos WHERE id = '{$_POST["id"]}'");
   
9. 

   Lamicz 21.7.2014 v 08:48

   $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 21.7.2014 v 11:15

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

   Chobot 21.7.2014 ve 16:25

   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 21.7.2014 ve 16:34

   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 22.7.2014 ve 00:30

   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 22.7.2014 ve 14:23

   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 22.7.2014 ve 15:15

   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 22.7.2014 ve 16:19

   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 22.7.2014 ve 17:39

   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 22.7.2014 ve 17:47

   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. 

   dword 22.7.2014 ve 17:54

   Re:
   Pri psani diplomove prace.
1. 

   Martin Hassman 22.7.2014 ve 18:01

   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 22.7.2014 ve 18:12

   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 22.7.2014 ve 18:27

   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 22.7.2014 ve 19:47

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

   dword 22.7.2014 ve 17:46

   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 22.7.2014 ve 17:58

   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 22.7.2014 ve 18:01

   Re:
   Reagoval jsem na vase: „Ja si autoru vazim i s jejich chybami“
2. 

   dword 22.7.2014 ve 18:03

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

    Marek Sirkovský 21.7.2014 ve 21:37

    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“ :)
11. 

    Marek Sirkovský 23.7.2014 v 07:57

    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 23.7.2014 v 08:35

   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…
1. 

   Martin Hassman 23.7.2014 v 11:58

   Re:

   Viz má odpověď vedle.
2. 

   Martin Hassman 23.7.2014 v 11:58

   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.
12. 

    karel 23.7.2014 v 09:21

    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.