Názory k článku Testování verzí CMS: 50 000 zastaralých instalací systémů WordPress a Joomla

Kdyz tohle je prave ten ekosystem a zaroven distribuce kodu. Viz nedavna zprava o tom, ze byl prodavan primo malware plugin pro WP. Nebo dokonce zprava par mesicu zpet o tom kolik pluginu ma zasadni diry(XSS/SQL-I).

Tohle v modulu/sablone pro Drupal na drupal.org proste nenajdes. Uz protoze drtiva vetsina tech pouzivanych prochazi pri kazdem release auditem security teamu.

I moduly pro Drupal mají dost svých problémů: https://www.drupal.org/security/contrib

To že někdo prodá své rozšíření někomu dalšímu a ten do něj dá malware bohužel není příliš šokující věc a děje se běžně - u rozšíření do prohlížečů, mobilních aplikací. To že určitá část pluginů v repozitáři obsahuje chyby je sice smutné, ale normální - povětšinou se jedná o staré pluginy, které téměř nikdo nepoužívá - pokud si někdo jen tak nainstaluje plugin, který nebyl 3 roky aktualizován (a takové ani nejde jednoduše běžným způsobem vyhledat v repozitáři) a používá ho 5 uživatelů, tak se samozřejmě vystavuje určitému riziku (které bohužel běžný uživatel nedokáže vyhodnotit). Také by bylo fér podotknout, že většina chyb jsou authenticated XSS, kdy admin může zaútočit sám na sebe - netvrdím, že to není problém, ale tento chyb nalezneme ve spoustě custom made administracích mnoha systémů, vývojáři jsou často jednoduše líní.

Tohle urcite nikdo netvrdi. Jen jde o mnozstvi kritickych chyb. Za 10 let u drupalu jsem potkal weby hacknute jen dvema zpusoby utoku - drupalgeddon(zdra­vime na Panamu :-) ) a pak neco co bylo v CKEDitoru.

Naproti tomu mame clanek u ktereho debatujeme.
Naproti tomu mame logy webovych serveru - zkuste se tam mrknout co boty laka :-)
Naprosti tomu mame zkusenosti kdy u me stacilo jednou se nechat ukecat a dat ten WP na server. Za tyden sel do hajzlu protoze jsem na to nemel nervy. Oproti tomu desitky Drupal webu v zasade neudrzovanych a krom vyse zmineneho drupalgedonu (a drive utoky pres nesifrovana ulozena hesla v totalcmd zakaznika) nikdy nic.

Boty samozřejmě láká systém, který je více rozšířený. Vzhledem k tomu, že WP webů je mnohonásobně více než Drupalů (https://trends.builtwith.com/cms), tak samozřejmě budou více zkoušet WP a budou rovnou zkoušet desítky známých zranitelností, které jsou většinou už dávno opravené.

Ano, moduly Drupalu problemy maji, ale mrkni jake problemy. Drtiva vetsina tech "problemu" je limitovana podminkou ve smyslu "uzivatel ma pravo administrovat XY". To je dost rozdil oproti vetsine chyb v pluginech/sablonach WP kde je to spis dane navrhem aplikace a ekosystemem kolem.

Bylo by to jaksi na dlouhou debatu, ale myslim, ze to je prave ten "ekosystem".

Především je třeba rozlišovat chyby v jádře WP a chyby v doplňcích, které dělá kde kdo. Linuxový kernel má také spousty svých chyb, které se stále opakují a jejich dopady jsou mnohem závažnější:

http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
- pro srovnání http://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor_id=2337

To že někdo udělá XSS nebo SQLi není podle mě záležitost jazyka - poslat formulářové políčko rovnou do DB lze všude. SQLi ASP.NET aplikaci jsem naposledy nalezl minulý týden, XSS v Java EE web aplikaci taktéž.

Pro pořádek, nerad bych se pouštěl do nějakých brutálních hádek - na všech vašich argumentech je trocha pravdy, snažím se jen názory zkreslené do negativna dorovnávat svými názory zkreslenými do pozitivna.

Především je třeba rozlišovat chyby v jádře WP a chyby v doplňcích, které dělá kde kdo.
Oni to snad útočníci rozlišují? To, že je to chyba „jen“ v doplňku vám nějak pomůže, když ten doplněk máte nainstalovaný? Vždyť kvůli tomu množství doplňků se právě WordPress používá. Zároveň když vybíráte doplněk, nemáte moc šanci zjistit, zda bude bezpečný. Je pravda, že chyba v doplňku neohrožuje každou instalaci WP, ale je víceméně věcí náhody, zda ta chyb ovlivní i vaši instalaci.

Linuxový kernel má také spousty svých chyb, které se stále opakují a jejich dopady jsou mnohem závažnější
Kolik měl Linuxový kernel v roce 2017 vzdáleně zneužitelných chyb? Chyby, které se v linuxovém kernelu opakují, jsou typické pro C aplikace – a většinu z nich byste v PHP aplikaci vyrobil velmi těžko. To je ten vliv programovacího jazyka a prostředí, o kterém jsem psal.

To že někdo udělá XSS nebo SQLi není podle mě záležitost jazyka - poslat formulářové políčko rovnou do DB lze všude.
Samozřejmě, že to jde všude, to ale není podstatné. Podstatné je, jak se to dělá typicky, co najdete v návodech atd. Typický příklad dotazu do databáze, který najdete prakticky v každém návodu k PHP, je tohle:

$mysqli->query("SELECT actor_id, first_name, last_name FROM actor WHERE actor_id = $aid");

nebo případně:

mysql_query("SELECT actor_id, first_name, last_name FROM actor WHERE actor_id = $aid")

Takže začnete s kódem náchylným na SQL injection, a pak, pokud vůbec zjistíte, že něco takového existuje a že je potřeba se tím zabývat, to můžete začít zalepovat.

V Pythonu ten samý případ vypadá takhle:

select_stmt = "SELECT * FROM employees WHERE emp_no = %(emp_no)s"
cursor.execute(select_stmt, { 'emp_no': 2 })

Ano, programátorovi to nebrání poskládat SELECT rovnou s vloženou hodnotou, ale v dokumentaci to vidí rovnou takhle, rovnou vidí ten druhý parametr funkce execute() – a poskládat ten SQL dotaz jako řetězec by vlastně bylo komplikovanější.

To samé v Javě:

PreparedStatement ps = con.prepareStatement("SELECT * FROM employees WHERE emp_no = ?");
ps.setInt(1, 2);
ResultSet rs = ps.executeQuery();

PHP také umí prepared statements a bindování proměnných, ale rozhodně to není mainstream a když to zmíníte před nějakým PHPčkařem, pokud o tom vůbec ví, začne vyjmenovávat, že to může být pomalejší a kdesi cosi.

Nemyslím si, že by mé argumenty byly zkreslené do negativna – to, že je PHP zaměřené na rychlé prototypování (dnešní terminologií) je základní vlastnost toho jazyka, je dobře, že takový jazyk existuje, ale je potřeba vědět, že to je dvousečná zbraň.

Zrovna to nepoužívání bindovaných proměnných v MySQL dotazech přitom jde jednoznačně za týmem kolem PHP – dalo by se to pochopit před deseti roky, ale ne v roce 2017. V oficiální dokumentaci PHP v příkladu použití pořád najdete jen query() a žádné prepare(), v Quick start guide jsou prepared statements stále až jako další kapitola po executing statements s query(), a ještě je to označené jako speciální varianta pro efektivní provádění opakovaných dotazů. Kolik let ještě bude trvat, než se změní přístup autorů, než se to změní v oficiální dokumentaci, a pak než to postupně probublá do různých návodů,příruček, učebnic a blogů? Mimochodem, i ten WordPress stále používá query() …

A jak mohou autoři WP za to, že si tam někdo hodí nějaký zmaštěný plugin? Resp. v souvislosti s tím textem, jak tomu mají autoři WP zabránit, když pak kdejaký neznalec přijde s "Chyba ve WP", což je titulková návnada ... ?
Uživateli WP je celkem jedno, zda za to může Franta nebo Pepa – pro něj je problém to, že má děravou instalaci WordPressu. Ale když se na to ptáte – autoři WP za to mohou tím, že neposkytují autorům pluginů prostředí, které by je vedlo k psaní bezpečného kódu.

Ostatně to samé se ti s pluginy třetích stran jde naprasit i v Javě, sice jsi hezky použil preparedStatement, ale i v Javě jde do databáze poslat i normální dotaz jako string do kterého vlepíš proměné přímo z GETu, žádný preparedStatement tam vynucený není .... jenom se to v Javě často používá - jo je to super, ale znova: vynucené jazykem to není
Tak ještě jednou. Nejde o to, co jde nebo nejde, jde o to, co se používá, co je běžné, co najdete v dokumentaci a návodech. Nic o vynucení jazykem jsem nepsal.

to že kdekdo zmastí tutoriály na nejjednodušší a v podstatě nebezpečný kód není chyba php
Chyba PHP je, že takový zmaštěný tutoriál s v podstatě nebezpečným kódem je oficiální dokumentace PHP.

když už jsme sklouzli k obvinění php
No, obvinění PHP. Ono k tomuhle PHP původně nebylo určeno. Původní chyba byla na straně těch, kteří ho začali na takovýhle software používat. Na druhou stranu, PHP už se takhle používá dost dlouho, PHP na to reaguje přidáváním jazykových konstrukcí, ale z pohledu bezpečnosti toho dělá jen velmi málo. Takže viníků je několik – což možná bude součást problému, že je za to vlastně zodpovědný kde kdo, takže ve výsledku nikdo.

Jenomže prepared statements skutečně mají nějakou režii navíc
To je irelevantní! Tady jde o bezpečnost, tu není možné obětovat za jakési hypotetické minimální zvýšení výkonu. Zvlášť když řádově víc, než co ušetříte nepoužitím prepared statements, propálíte někde jinde (ať už ve vlastním programu, nebo tím, že používáte interpretovaný jazyk volaný přes CGI).

S query není problém
Je to problém, ani v té Javě by nemělo statement bez parametrů existovat. Ani to nemusí být implementované pomocí prepared statements, ale když už to někdo mermomocí chce implementovat pomocí escapování parametrů, má to být přímo součástí knihovny. Vždyť spouštět SQL příkaz s vloženými hodnotami bez jejich escapování nedává žádný smysl, pokud tedy nechcete záměrně vytvořit SQL injection, tak k čemu je taková funkce v knihovně?

problém je ten, že většina lidí, resp. programátorů, ani netuší, že by měli nějaké vstupy ošetřovat
Ne, problém je jazyk a knihovna, která nutí programátory dělat něco tak nesmyslného jako „ošetřovat vstupy“ kvůli bezpečnosti. Vstupy se ošetřují z hlediska logiky aplikace, např. že věk nemůže být záporný. Ale z hlediska bezpečnosti je to nesmysl – problém není v tom vstupu, ale v tom, že pro knihovnu existuje něco jako „nebezpečný vstup“. Když chci uložit nějaký text do databáze, mám ten text předat knihovní funkci a ta ho má tak jak je uložit do databáze – ne že se musím starat o to, jestli je pro tu knihovnu bezpečný.

to je vyložená neznalost, která jednoznačně ukazuje že se tenčlověk neorientuje v totálních základech web. bezp.
To nejsou základy webové bezpečnosti, to jsou základy nebezpečnosti jednoho konkrétního jazyka a jeho standardní knihovny.

Asi bude trvat dlouho než ti dojde, že autoři nemohou udělat takový systém, aby tam nešlo napráskat chyby když někdo přidá vlastní kód.
Nechápu, proč oslovujete mne, a pak polemizujete s vlastním výmyslem, který já jsme nikdy nenapsal. Opakovaně jsem výslovně napsal, že nejde o to, co je teoreticky možné, ale o to, k čemu daný jazyk a platforma spíš navádí a čemu spíš brání. Z vašeho komentáře plyne, že podle vás jsou všechny programovací jazyky a platformy stejné a liší se jenom syntaxí. Jenomže tak to není. Třeba běžný kód v C bude podstatně náchylnější k buffer overflow chybám než běžný kód v PHP. Což neznamená, že nejde vyrobit buffer overflow i v PHP, ani to neznamená, že se má všude používat PHP místo C.

A mimochodem, udělat systém, ve kterém bude obtížné ve vlastním kódu udělat některé chyby, je možné – příkladem takového systému je např. PHP, ve kterém je obtížné udělat některé chyby, které byste mohl udělat ve stejném kódu napsaném v C.

Kdybys o WP a pluginech skutečně něco věděl, tak by ti bylo známo, že kompletní API od WP existuje
To je v rozporu s něčím, co jsem napsal?

ale hromada pluginů jej nepoužívá a implementuje své po svém
To provozovatelům těch napadených webů nějak pomůže?

Ten tvůj návod je k mysqli a s mysqli se prostě jinak nepracuje.
Což je právě chyba.

používám když dělám interně nějaké prototypování které se pak smaže nebo přepíše
Jak jsem psal, tohle je vhodný způsob použití. Bohužel ale jiní toto často používají v produkčních systémech.

Problém nastává, když si to někdo vygooglí a vůbec ne nezamyslí nad nějakou bezpečností nebo se neobtěžuje nastudovat API systému, pro který dělá.
Takoví lidé ale evidentně WP pluginy píšou, a je to záměr. A pak je tu pořád ten problém, že to v té dokumentaci není popsané jako bezpečnostní riziko, a že tam ty nebezpečné funkce vůbec jsou uváděné jako primární řešení, místo aby primární byly ty bezpečné funkce a tyhle nebezpečné byly v nějaké advanced sekci pro programátory, kteří dobře vědí, co dělají.

Výkon prepared statements není irelevantní.
Je irelevantní. Pokud předčasná optimalizace jenom stojí čas programátora, je to sice hloupost, ale neškodná. Pokud způsobí bezpečnostní problém, je to vážná chyba. To, že někdo dělá předčasné optimalizace v prototypu, je jeho chyba – měl by si zjistit, k čemu prototyp slouží.

Někdo to holt nezkousne a v rukách amatéra to může být pohroma.
Což je u PHP, což je platforma pro amatéry, docela problém.

A ani není pravda že tě vstup nezajímá a má to řešit knihovna, protože neexistuje jenom SQLInjection a ukládání do databáze.
Já jsem nepsal, že to má řešit knihovna. Nemá se to řešit vůbec, pokud ten vstup není něco potenciálně nebezpečného jako třeba cesta k souboru nebo kód. Ale obyčejný text není nic, co by mělo být nebezpečné a mělo se to nějak speciálně ošetřovat.

No, mám z tvého výkonu pocit, že tam kde se použijí knihovny a java, tak není problém. Ono to tak ale ve skutečnosti není, že?
Ne, ve skutečnosti to tak není, je to jen váš ničím nepodložený pocit.

A já ti opakovaně píšu, že i když tomu platforma "spíš" brání, tak nikdo nezbrání tomu, aby tam někdo napráskal chyby
A píšete to proč? Je to nějak důležité? Podle vás platí, že nemá smysl zabránit 10 %, 50 % nebo 90 % chyb, protože když nemůžu zabránit 100 % chyb, nemám dělat nic? Mají se v autech přestat používat airbagy, bezpečnostní pásy nebo ABS, protože když to nezabrání všem nehodám, nemá se to používat vůbec?

do WP často dělají pluginy amatéři a pak to tak vypadá
Právě proto, že to dělají amatéři, je dobré dát jim do rukou takový nástroj, se kterým mohou pracovat i amatéři. Ne něco, kde jim napíšete „takhle se to dělá a takhle to bude fungovat“, a oni si mají někde úplně jinde zjistit, že takhle se to vlastně vůbec dělat nemá.

Není, jenom se v C a v PHP dají z nedbalosti práskat jiné chyby. Ne že v jednom ano, v jednom ne.
Chápete rozdíl ve významu slov „obtížné“ a „nemožné“? Když napíšu, že je něco „obtížné“, myslím tím, že je to „obtížné“, takže je zbytečné vyvracet tvrzení, že je to „nemožné“.

Jenže ta funkce je dost používaná.
Budu se opakovat, ale to je právě ta chyba.

Mimochodem to je tvou selectivní slepotou, ale i v tom tvém příkladu v dokkumentaci je "MySQLi extension basic examples". A jelikož si klasický amatér, včetně tebe (nebo možná spíš až taková hvězda), nepřečte poznámky v kódu tak nezjistí že:
"...Let's make it
// default to 1, and cast it to an integer as to avoid SQL injection
// and/or related security problems. Handling all of this goes beyond
// the scope of this simple example...."
Vždyť jsem to psal. Autoři PHP považují kód s SQL injection za základ, a zabránění SQL injection a bezpečnost jsou teprve věci pro pokročilé, které nemusí znát každý programátor. A aplikace podle toho vypadají, SQL injection je běžná věc, a zabezpečení je něco navíc. Mně tenhle přístup připadá zvrácený.

do WP často dělají pluginy amatéři
Jak je vidět, tak PHP evidentně pro amatéry není. Viz. běžní pisatelé pluginů . . . . .
Už jste si rozmyslel, jak to tedy je?

Každý vstup do aplikace a každý výstup je potenciálně nebezpečný. Některý více, některý méně. U webů to platí dvojnásob.
Nevím, proč by to mělo u webů platit dvojnásob. Naopak u webů platí, pokud vynecháme upload souborů, že každý vstup je text. Co je na textu nebezpečného? On se vám někdy text v aplikaci třeba sám od sebe spustil? Na textu nic nebezpečného není, nebezpečná je jeho interpretace. A funkce pro uložení textu do databáze nemá text nijak interpretovat, má text vzít tak jak je a bez jakékoli změny ho uložit do databáze. Na tom není nic komplikovaného, a pokud s tím programy na nějaké platformě mají notoricky problém, je to problém té platformy.

A ona by to měla řešit nějaká knihovna, protože obecně platí, že programátor při použití knihovních funkcí méně zapomíná udělat nějaký jeden krok z několika.
Ano. A proto má mít funkce ve standardní knihovně pro volání SQL příkazů přímo podporu pro předávání hodnot parametrů. Protože to potřebuje prakticky každá aplikace pracující s databází a používá se to ve spoustě příkazů, takže nedává žádný smysl, aby si to každý programátor řešil znova sám. Zvlášť když na tom závisí bezpečnost aplikace. Zejména když stejně musí existovat varianta bez množiny parametrů nebo s prázdnou množinou, protože některé SQL příkazy parametry nemají – takže pokud někdo má potřebu vyřešit si předávání parametrů sám, nic mu v tom nebrání a prostě si ten dotaz poskládá sám a použije tu bezparametrickou variantu funkce. Negativa takového řešení neexistují žádná.

Nedavno jsem videl prednasku na ktere prednasejici pomerne presvedcive tvrdil*, ze statements v PHP jiz rezii nemaji protoze i "obycejna" query se pripravi jako statement a pak se poslou prazdne argumenty.

* ja tomu verim, ale nejsem ochoten to vydavat za svoje tvrzeni protoze jsem to uvnitr nezkoumal

PDO je v PHP v roce 2017 naprosty standard. Asi nepotkavas programatory, ale zacatecniky. Proc bych to vlastne mel delat jinak? Krom toho zrovna v tom Drupalu celou query stavim objektove takze udelat dnes v Drupalu sql injection pri pouziti API neni uplne easy. A jsme mozna zpatky u toho rozdilu proc jej povazuji oproti WP za etalon bezpecneho SW.
A jestli nekdo dnes pouzije navod z roku 2005 tak si nemyslim, ze je to uplne vina jazyka.

Jinak ano, taky bych byl pro totalni vyhozeni starych mysql funkci z celeho jazyka. PHP7 bylo k tomuto dobra sance, ale evidentne nekdo na to nemel gule.

Hele takhle, nerikam, ze je to vsespasne, ale pouzit nejakou objektovou knihovnu pro pristup k DB (tedy nepsat primo query) a k tomu slusny sablonovaci system (treba Twig) a drtiva vetsina problemu je vyresena. To, ze neco takove WP neumi do sebe dostat neni otazka jazyka. Nerikam, ze to dela aplikaci bezpecnou samo o sobe, ale vymyslet tam pak nejaky XSS/SQL-i je pomerne slozitejsi.

Já ale nikde netvrdím, že je to s PHP neřešitelné. Samozřejmě, že to řešit jde, ať už prostředky standardní knihovny, nebo nějakou nadstavbou. Problém je, že to není standard – pokud i dnes někdo bude zjišťovat, jak v PHP zavolat dotaz nad MySQL, s největší pravděpodobností narazí (v lepším případě) na mysqli_query().

To také není úplně pravda. WP má WP_Query pro přístup k většině datům bez SQL příkazů (je pravda, že výsledné SQL dotazy jsou často dost hrozné, ale umí to i cachovat, takže se to trochu kompenzuje). Dále má svou vrstvu wpdb, která samozřejmě umí prepared statements (což je oficiálně doporučovaný postup) a metody pro vkládání/updaty data automaticky escapují. Pak je zde samozřejmě metoda query(), která vykoná dotaz jak leží - zde spoléhá na pisatele, aby si ho ošetřil (a když si není jistý jak, je zde funkce esc_sql, která to zařídí). Pokud někdo chce používat Twig, tak samozřejmě také může: https://github.com/timber/timber.

To také není úplně pravda.
Vždyť sám píšete:

Pak je zde samozřejmě metoda query()
Vida, takže přeci jen to pravda je.

která vykoná dotaz jak leží - zde spoléhá na pisatele, aby si ho ošetřil
Proč? K čemu je taková funkce dobrá? Kdyby ta funkce jako druhý parametr brala pole parametrů, radši to programátor použije, než by hodnoty vkládal do dotazu ručně. A programátora, který to nezná, by to nejspíš aspoň trklo, že se to takhle dá použít. A pokud by někdo opravdu potřeboval hodnoty do dotazu vložit ručně, pořád by měl možnost to udělat a pole parametrů předat prázdné. Pořád by tu byl prostor pro chyby, ale aspoň by to k těm chybám programátora nenavádělo.

je zde funkce esc_sql, která to zařídí
Tyhle funkce, které „to zařídí“, jsou snad ještě větší zlo. Escapování parametrů je špatné samo o sobě, a když se k tomu ještě přidá funkce, která „to zařídí“ a programátor netuší, co a proč vlastně dělá, je to na nejlepší cestě, aby někde něco oescapoval dvakrát, pak to zjistí, escapování odstraní a vyrobí tím SQL injection, a ještě si bude pamatovat, že to příště nemá používat, protože „to nefungovalo“.

Reagoval jsem na "nemá objektovou knihovnu pro pristup k DB (tedy nepsat primo query) a k tomu slusny sablonovaci system (treba Twig)" - mohu přistupovat k DB přes objekty WP_Query, mohu používat knihovnu, která přidává abstraktní vrstvu, který spousty věcí ošetří, mohu používat Twig, když chci.

Možnost zavolání dotazu přímo mají snad všechny systémy. Proč je v Javě Statement, když mám používat PreparedStatement?

Reagoval jsem na "nemá objektovou knihovnu pro pristup k DB (tedy nepsat primo query) a k tomu slusny sablonovaci system (treba Twig)"
Aha. Jenže to nikdo před vámi nenapsal.

mohu … když chci
To je právě ten problém, že nejprve musíte vědět, že něco takového chcete. Zrovna mezi vývojáři pluginů do CMS se dá čekat spousta těch, kteří normálně neprogramují, a jenom potřebují přidat nějakou funkci do CMS.

Možnost zavolání dotazu přímo mají snad všechny systémy.
Samozřejmě. Jsou i zcela legitimní dotazy, které nemají žádné parametry. Abyste tomu zabránil, musel byste mít přímo v jazyce podporu pro textové konstanty, jejichž typ by byl odlišný od dynamicky vytvářených řetězců. Ale jak už jsem tu mnohokrát napsal, nejde o to, že něco jde – podstatné je, co se v daném prostředí považuje za běžný postup, na co narazíte v návodech a tutoriálech.

Proč je v Javě Statement, když mám používat PreparedStatement?
Jak už jsem psal, považuju za chybu, že statement nemá rovnou jako druhý parametr mapu parametrů s tím, že by JDBC driver povinně musel umět binding parametrů. Na druhou stranu, nevím o tom, že by se někde v oficiální dokumentaci Javy vyskytovalo skládání SQL příkazu z parametrů, Statement, PreparedStatement a CallableStatement jsou v oficiální dokumentaci uváděny dohromady s tím, že Statement je určeno pro jednoduché SQL příkazy bez parametrů a pro statické dotazy, zatímco PreparedStatement pro dotazy s parametry. V žádných návodech se nemotá hlava programátorům nějakým escapováním parametrů, a metoda pro escapování parametrů byla přidána až v Javě 9 (vyšla před pár dny) – asi aby se nestýskalo PHP programátorům, kteří přejdou na Javu.

Je celá řada SQL příkazů, které např. nemají prováděcí plán, a tudíž nemají parametry a tudíž je nesmysl, aby se pro ně používalo API pro prepared statements.

Tady s Filipem nesouhlasím - je nesmysl, aby za problémy mohlo PHPko PHP je víc na ráně: pořád se používá v drtivé většině webů, díky minimálním vstupním nákladům je používaný v low cost projektech, kdy a kde jsou pro velkou část vývojářů bezpečnost, věci kolem výkonosti, kvality kódu nepodstatný detaily, které jdou mimo ně, nebo které se jim při té ceně nevyplatí řešit.

Problémy se znalostma programátorů jsou všude - pokud se firmy nejsou úplně low cost, tak a) jejich problémy jsou méně viditelné, b) sem tam si zaplatí školení, případně odborně zdatnější (a povětšinou výrazně dražší) programátory, c) někdy mají specialisty na bezpečnost.

Java nebo Python se low costu neprosadí - na to už potřebujete technicky zdatnější programátory - a ti nejsou pro low cost zaplatitelní. Pokud PHP používají proškolení a technicky zdatní vývojáři, tak problémy jsou obdobné jako jiné dynamické jazyky.

Pavel Stěhule: To přece ale vůbec neznamená, že není možné dát low cost programátorům do ruky nástroj, který je povede k bezpečnému použití. Právě naopak, oni takový nástroj potřebují nejvíc. Není potřeba používat speciální API pro prepared statements – úplně stačí metoda execute() nebo query(), která bude mít jako první parametr text se zástupnými znaky a jako druhý volitelný parametr mapu nebo seznam hodnot parametrů. Nezáleží na konkrétní implementaci, jde o to, že když programátor bude chtít do SQL příkazu vložit parametry, bude mít správnou funkci hned po ruce a nebude zbytečně vymýšlet vylomeniny.

V PDO je o jednu instrukci navíc - musí se volat PREPARE - což má taky svůj smysl (může se umístit mimo cyklus). Navíc, díky dynamice PHPka to jde jednoduše zawrapovat.

Jádro pudla je v tom, že programátoři (ti, kteří dělají chyby o kterých se tady bavíme) jen matně tuší, co to je SQL injection a pravděpodobně vůbec nebudou tušit, co to je prepared statement. Takže i kdyby ve funkci query bylo možné použít parametry, tak je nepoužijí, bo nebudou tušit proč.

Třeba ještě s v ADO ve VB byl opruz používat prepared statements, a to se o PHP vůbec říct nedá.

Podle mne pokud by ti programátoři v dokumentaci nebo v okolním kódu viděli třeba tohle:

$mysqli->execute("INSERT INTO CountryLanguage VALUES (?, ?, ?, ?)", $code, $language, $official, $percent);

budou to používat.

Mohlo by to být více zdůrazněné, ale když si teď listuji dokumentací k PDO i k mysqli, tak všechny příkazy s parametrizací dělají přes prepare. Takže pokud si dá člověk trochu víc práce a prolítne dvě html stránky místo jedné, tak na všech adekvátních příkazech najde PREPARE. Je fakt, že některé příklady v dokumentaci ke query jsou asi spíš na škodu.

Tady ještě může hrát roli MySQL - pokud se použijí prepared statements, tak se použije binární protokol a budete dostávat typová, kdežto, když defaultní textový protokol vrací jenom texty, jestli jsem to pochopil. Takže výsledek (metadata) může být jiný pokud použijete nebo nepoužijete parametry.

Já tedy v dokumenatci MySQLi vidím něco úplně jiného. Když vezmu stránky postupně podle obsahu, první stránka, kde se objevují parametrizované dotazy, je Executing statements . Parametry INSERT u jsou tam přímo součástí příkazu, což v reálné aplikaci nedává vůbec žádný smysl – a vše je tam pomocí query, o prepare na té stránce není jediná zmínka. Evidentně i autoři PHP považují prepare za něco speciálního, co se nepoužívá pro běžné vykonávání příkazů. Následuje kapitola Prepared Statements, kde se hned v druhé větě píše, že se to používá pro opakované opakované vykonávání stejných příkazů z důvodu vysoké efektivity. Pokud to čte začátečník, správně si řekne, že optimalizace zatím není nic pro něj, stejně bude zatím používat jen jednoduché příkazy. Následuje kapitola o uložených procedurách, kde jsou všechny parametry opět natvrdo součástí SQL příkazu. prepare je tam uvedené jednou – bez parametrů. Následuje několik dalších kapitol s query a parametry, které jsou natvrdo v SQL příkazu, takže příklady, které nemají nic společného s reálnými aplikacemi – a pokud se jimi někdo inspiruje, logicky dospěje k tomu, že ty konstantní parametry akorát nahradí odkazem na proměnnou. Přitom jinak jsou ty příklady vzorové, všude se testují návratové kódy – tak, jak by ten kód měl vypadat v reálné aplikaci. Kapitoly o instalaci a podobné asi můžeme přeskočit, následuje už dříve odkazovaná stránka MySQLi extension basic examples, kde o prepare opět není ani zmínka, naopak se obsah proměnné vkládá přímo do SQL příkazu. Přitom tohle je ta stránka, odkud začne každý, kdo jenom rychle potřebuje vědět, jak se volají dotazy do databáze. A většina programátorů u téhle stránky taky skončí, protože podle ní napíšou svůj kód, vyzkouší, kód jim vrátí správná data, a tím to pro ně končí, nebudou mít důvod číst něco dalšího – vždyť jim to přece funguje. Zpět k tomu příkladu – na začátku v komentáři sice je zmínka o SQL injection a že se kvůli tomu přetypovává na int, ale kdo ten komentář bude číst? A i když si ho někdo přečte – „Handling all of this goes beyond the scope of this simple example.“ Takže SQL injection a bezpečnost je něco pro pokročilé, začátečníci o tom nepotřebují vědět nic. Když pak někdo tenhle příklad vezme, akorát místo čísla bude potřebovat použít jako parametr text, hned má přímo ukázkový kód s SQL injection – aniž by vůbec tušil, že je něco špatně.

Autoři PHP zjevně považují prepared statements za něco pokročilého, co si najde ten, koho to opravdu zajímá. Zároveň PHP neumí bindování proměnných jinak, než s prepared statements. PHP zkrátka programátorům doporučuje nástroj, který je (zbytečně) náchylný k SQL injection, a navíc tuhle vážnou bezpečnostní hrozbu odbude poznámkou pro zasvěcené, místo aby tam byl výrazný červený nápis s vykřičníky, že takhle se to dělat nemůže. Tohle prostě je problém platformy PHP a vysvětluje to, proč je tolik PHP aplikací napadnutelných přes SQL injection.

Interní implementace prepared statements v MySQL v tom nemusí hrát žádnou roli, parametrizované dotazy s bindováním proměnných není vůbec nutné implementovat přes prepared statements – klidně může dvouparametrická funkce query() interně pomocí escapování skládat parametry do textového dotazu. Sice považuju escapování za hack, ale pořád je to milionkrát bezpečnější, když to ta funkce bude dělat takhle, než nechávat to na tom, jestli programátor vůbec tuší něco o SQL injection a vzpomene si, že to má nějak řešit.

// úplně stačí metoda execute() nebo query(), která bude mít jako první parametr text se zástupnými znaky a jako druhý volitelný parametr mapu nebo seznam hodnot parametrů.

Tohle je naprosto naivní představa
$db->query("select * from users where password = $_POST['passwor­d']", array());

tak takhle nejak si predstavujes zabezpeceni proti amaterovi/zaca­tecnikovi?

Tohle je naprosto naivní představa
Klidně vám to napíšu počtvrté, že když někdo v příkladech v dokumentaci uvidí použití s parametry, tak pak sám napíše

$db->query("select * from users where password = ?", array($_POST['password']));

– protože je to jednodušší a přehlednější. Že se pořád najde někdo, kdo mermomocí ten kód bude muset napsat špatně, tomu se zabránit nedá, ale jde o to, co se používá normálně.

naivni predstava. totalni novacek neznaly zakladnich bezpecnostnich pravidel tam stejne mrskne sql tak jak si ho nekde precetl.

Pokud by to byl takový hňup, že by ani nevěděl, že musí v SQL napsat podmínky, co chce vlastně vybrat, tak to vůbec nevadí. Za prvé by mu zkopírované SQL vůbec nefungovalo, protože by tam měl názvy tabulek a sloupců, které by neměl ve své databázi, za druhé by v tom zkopírovaném SQL nebyly žádné vložené parametry, takže žádný prostor pro SQL injection.