Názory k článku
Roste počet útoků typu SQL Injection

Také tomu moc nerozumím. Když chci dovolit uživateli zadávat data/dotazovat se na ně přes SQL příkazy, tak používám parametry. Zda někdo nepoužije bezpečný přístup je jen jeho neznalost, ale potom by se neměl divit důsledkům s tím spojeným.
Jenže on je ten internet tak lákavý, a ten zvolený jazyk (každý si může doplnit jaký chce, neb předpokládám, že všechny umožńují programovat bezpečně) tak jednoduchý a stránky s ním mám vytvořeny během pár minut. To že by dotyčný mohl mít i jiné znalosti než jen HTML/JS/CSS, ale zřejmě už neví a možná ani nechce slyšet, protože by jej to stálo více úsilý, námahy a času.
Díky
--J.

... a ty parametry se predavaji treba pres URL a bez kontroly se strci do sql dotazu - problem je ze jako parametr utocnik pouzije SQL ;)

takze vzdy kontrolovat jake parametry dostavam!

Tak ono celkem staci ty parametry pouzit skutecne jako parametry a ne z nich trapne skladat nejaky sql prikaz - nevim jestli to podporuje php, ale normalni jazyky to maji celkem standardne. Pak ten kod vypada (v ilustracnim pseudo jazyku :-)) treba takhle:

query.sql.text = "update users set name = :name where id = nejakeJehoId";
query.params["name"] = coMiZadalUzivatel;
query.execute;

pak je mi uplne jedno, jestli jako jmeno uzivatel zadal "'I AM BIG HACKER; delete from users" nebo cokoliv jineho, protoze se tim akorat nastavi to pole v db, ale neprovede se to jako vlastni sql prikaz. Takhle se daji jednoduse i ukladat binarni data

PHP na to má podporu v mysqli extension

Stejne radeji pouzivam vlastni tridu, ktera ma parametry jako :nazev a pak zere pole parametru.. jsem to videl jeste za dob Delphi :) Tu malou rezii co to potrebuje kvuli bezpecnosti obetuji.. nejake zvyseni vykonu by pak prineslo prepsani tech SQL retezcu s parametry na konstantni casti+ volani mysql_escape, coz neni problem udelat strojove,ze.. Ukazka:

    // smazani zaznamu o prislusnem pocitaci
    if ($DB->exec( "DELETE FROM `Host` WHERE id=:id", array('id'=>$id) )) {

    }

Rozřšíření pro některé databáze to umožňují, dokonce s ještě pohodlnější syntaxí:

  $rslt = ibase_query($tr, 'update USERS set NAME=? where ID=?', $name, $id);
  // nebo (lepší když se používá stejný dotaz víckrát s různými parametry)
  $qry = ibase_prepare($tr, 'update USERS set NAME=? where ID=?');
  $rslt = ibase_execute($qry, $name, $id);

Takto naivne jsem se vypekl nedavno, kdyz jsem myslel, ze to vse mam "zadarmo" v JDBC.... zkuste zadat do textoveho formulare apostrof (klasicky, zakladni) a pak to nastavte via setString()... ocekavejte krasnou vyjimku, ale az po execute...:-)

Chcel by som sa spytat tu znalych ci sa podobnym utokom neda predist ked sa pouziva nieco ako hibernate a pod... tam o SQL clovek ani nevie (ak teda neznasilnuje O/R technologie) a aj neznaly programator sa vyhne podobnym problemom...

Pri používaní Hibernate sa dá týmto útokom predísť, pretože to transparentne vnútorne používa práve vyššie spomínané parametrizované SQL dotazy. Umožňuje síce používať aj priame natívne SQL dotazy a tam by už mal človek vedieť, čo robí.

Předpokládám, že každý programátor, hodný toho jména, bedlivě kontroluje veškeré parametry od uživatele, takže takový pokus nemůže mít šanci. A tam kde projde, nechť si to autor zodpoví. Proto to nepokládám za nic moc nebezpečného. (Alespoň se oddělí zrno od plev). I když je fakt, že ten nárůst pokusů taky o něčem vypovídá ...

Vypovida o tom, ze kazdy druhy pubertacek si koupi za par stovek z brigosky knihu o PHP a hned je z nej velkej mistr programator a hned patla weby na zakazky, a pak to takhle vypada

(php nemam rad, preferuji javu, ale i to debilni php ma prostredky, jimiz lze predchazet rizikum, a vetsinou je to jen o inteligenci tvurce, viz prispevky vyse)

Kdyby si aspon koupili knihu. Nebo ji, nedejboze, precetli...