Jediný co mě na prepared statements vadí je jejich naprosto nepoužitelná syntaxe.
Mně tedy připadají mnohem přehlednější, než slepování řetězců. Ale to je věc názorů – nicméně pokud se rozhoduju mezi přehledností a bezpečností, musí – zvlášť v případě, kdy jde o něco důležitého, třeba o peníze – vyhrát bezpečnost.
Nevím proč by se měla syntaxe dotazů měnit.
Nejde o změnu syntaxe, ale o změnu v parsování věcí, které třeba ve standardu nejsou jasně řečené, případně v parsování příkazů, které jsou v rozporu se standardem.
Jiné jazyky používají taky escapování a dodnes to nikomu nevadilo. XML, JSON, prakticky každý formát používá escapy. Proč to vadí u MySQL?
Odborníkům na bezpečnost to samozřejmě vadí odjakživa. Ono nejde jen o samotné escapování, ale o to, jak je složité a jaké má varianty. V XML je velmi jednoduché a jasně definované, chybnou syntaxi parsery rovnou odmítnou – takže ten problém, že dva parsery stejný vstup rozparsují jinak, prakticky neexistuje. Úplně jiné je to třeba u HTML, kde se různé parsery chovají i záměrně jinak – třeba podmíněné komentáře v MSIE. No a MySQL je někde uprostřed, rozparsuje i dost nestandardní dotazy, a to samozřejmě otevírá možnost, že
real_escape něco vyhodnotí jako „v pohodě, jsme uvnitř hodnoty“, ale parser MySQL to vyhodnotí jako součást SQL příkazu.
Máte nějaký reálný útok zkrz real_escape?
Nemám. Ale „umíme to lépe zabezpečit“ si rozhodně nespojuju s „víme o té hrozbě a umíme to snadno opravit, ale Googlem jsme nenašli informace o žádném reálném zneužití, tak budeme doufat, že to nikdo nezneužije zrovna proti nám“. Nevýhoda tohohle přístupu je také v tom, že to nikdo samozřejmě nebude zkoušet proti nějaké demoverzi, protože to není úplně snadné a motivace žádná. Až bude možné skrze ten web ukrást pár milionů, motivace bude výrazně vyšší a třeba se najde někdo, kdo si zjistí vámi používané verze MySQL a PHP, ty parsery si porovná a zjistí, jestli nějaká obskurní posloupnost znaků ten parser v PHP nezmate.
Každopádně zabezpečení by mělo předcházet známým hrozbám, ne jenom těm, které už někdo v praxi provedl a Google o tom něco najde. Nechcete být přece tím příkladem praktického zneužití, který Google jako první zaindexuje.
Když takhle přistupujete k SQL injection, jak asi přistupujete k jiným bezpečnostním hrozbám?
S prepared statement samozřejmě umím, ale přišlo mi to... pomalejší... komplikovanější.
Mně to připadá jednodušší, není důvod, aby to bylo pomalejší – naopak při dobré implementaci a podpoře serveru to bude rychlejší, protože serveru nemusí parsovat každý dotaz znova, ale jenom sáhne do cache pro již dříve zpracovaný dotaz, který u sebe má rovnou i prováděcí plán.