Názory k článku Na podceňovanou hrozbu SQL injection doplácí i řada českých webů

> Je důležité si uvědomit i to, že SQL injection nemá nic společného s jazykem, ve kterém je webová aplikace napsaná

Tak s tymto by som dost nesuhlasil aj ked dovody nie su technicke, ale socialne.
Vsetci Javovsky programatori uz od zakladnych tutorialov vedia, ze SQL string sa nema vyskladavat z textov co zadava uzivatel, ale maju pouzivat PreparedStatement, teda posielat parametre do SQL. Dokonca niektore nastroje na staticku kontrolu kodu na tuto chybu upozornuju ( FindBugs ) .

Pravdupovediac, rovnako sa to da osetrit v PHP alebo ASP, ale z mne neznamych dovodov na to tie lamy kaslu.

V čempak že to je napsané to Z1.CZ (s ukázkovou SQL injection)? Aha, vona to byla Java :)

Ra100 tym chcel povedat, ze vyukove materialy nabadaju k pouzitiu prepared statementov. Pokial je vsak programator nedosledny a lenivy, tak to moze pisat v com chce a nikto mu nezabrani to napisat nespravnym sposobom.

Takze vlastne SQL Injection nema nic spolecneho s jazykem, ve kterem je stranka napsana :)

To je stejné, jako se hádat, zda memory (resource) leaky souvisejí s jazykem. Některé jazyky to dělají snazší a některé těžší, ale možné je to ve všech.

Taky bych to takhle videl. Dalsi vec je take to, ze kdyz uz nekdo programuje neco v jave, jedna se zpravidla o vetsi vec, ve ktere uz se pouzivaji objektove-relacni mapovaci frameworky jako je ibatis nebo hibernate, kde se pouzivaji prepared statementy, jak psal kolega prede mnou.

No, výukové materiály k ASP taky dlouhé roky nabádaji k použití něčeho, co stejně nikdo pořádně nepoužívá :)

A myslis, ze vyukove materialy k ASP.NET ci PHP nenabadaji ke stejne veci? Proste, co to tvrdis, je nesmysl :)

Ono je tezke potkat dokumentaci k SQL API v libovolnym jazyku, kde by k tomu nenabadali;)

Vetsinou jeste uvednou priklad jak se to nema delat, aby zduraznili mozny bezpecnostni problem, ale jak je vedit spousta "programatoru" tu dokumentaci necte a nema ani tuseni ze neco takovyho hrozi.

A neni to jen SQL-injection ale bezpecnostim otazkam vubec spousta lidi nevenuje pozornost, a podle toho ty weby vypadaj.

treba tu dokumentaci ctou :-).
ale takovym tim zpusobem "sakra, jak se pouzivaji ty parametry? ... tady nekde byl priklad!" ;-)

Nj vecny problem lamerskych programatoru. Kdyby vsichni dusledne pouzivali orm misto na kolene skladanych sql stringu tak problem sql injection neexistuje.

prosímvás, nepřebrat cokoliv přímo z parametrů je stejná zásada jako nepokládat holou ruku na rozpálený kamna. toto je zásada kterou jsem se velmi záhy naučil před dávnými lety při psaní cgi v shellu - to je aspoň prasárna ;-) - a platí pro všechno programování v čemkoliv a čehokoliv. pokud toto někdo nedodržuje, neumí programovat.

Kontrola vstupních dat se musí provádět vždy a u každého programu Pro programátora by měla být naprostou samozřejmostí . Vzpomínám si, že u některých programů představovala validace dat i více než 50% práce. (To ještě nebyly k mání regulární výrazy). Bohužel - pokud si autor tuto práci ušetří, zákazník to včas nezjistí. A to je ten problém.

Je to šmejd a podvod na zákazníka - asi jako švestková povidla s jablečnou dření nebo špekáčky se sójou. (Tedy něco, co je dnes naprosto běžné - bohužel).

Zvykáme si, že za levný peníz je pouze náhražka - nebo-li předražený šmejd. Nedivme se, že to proniká i do této profese.

Tak tak.

Jistě že PreparedStatement je řešení, ale také ne vždy, protože už jsem viděl mnoho DB, kde se spouštěly "stored procedures" s parametrama, ve kterých pak následně byl exec(SQL) nebo sp_execute nebo něco takováho a script na konci stejně injektovaný script spustil, takže pro javu platí stejně jako pro cokoliv ostatního.

Jinak v .NET je DLINQ, v rámci kterého toto opravdu nelze přejít, ale to zase nelze použít vždy.

Proč vytvářet zbytečnou aféru? Trocha toho XSS nebo SQL Injection nikoho ještě nezabila..

Haha, tak toto muze napsat jen uplny jelito. Podivejte se nekdy na pravidelne opravovane security chyby v prohlizecich. Jsou tam i lahudky typu kradeni hesel z password manageru a podobne. A toto vsechno muze utocny skript pouzit.

mas pravdu.
prosim Te, pochlub se tu posli mi nejaky linky na weby co jsi delal ;)

www.google.com

panecku, ted jsi mi to nandal, wow!

ktery vyraz ze mam googlit? "Mirek (neregistrovaný)"?

Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala.

První odstavec je velice nepěkné paušalizování. Záleží na architektuře a na samotné aplikaci. Na mých stránkách může kdokoliv použít SQL injection, ale v ničem mu to nepomůže. Dokonce se může k databázi připojit přímo přes SQL a dělat si tam co chce a číst co chce. A čímpak to? V databázi je sice nosný uživatel (a několik utilities účtů), ale každý uživatel se tam připojuje přes svůj vlastní účet, ke kterému se nastavují práva. Při registraci přes web se pomocí pečlivě ošetřeného (a miniaturního) mechanismu založí přímo databázový uživatel s defaultním profilem a veškeré zabezpečení pak přebírá tento DB server - a že to umí výborně.

Zde popsaná SQL injection je nebezpečná pouze ve chvíli, kdy se webové logika připojuje do databáze pod privilegovaným uživatelem a autor veškeré ošetření přesouvá právě na tuto webovou logiku. Právě tato webová logika a důvěřivý DB server jsou náchylné k útoku.

Ve zkratce: SQL injection je typ útoku, kterému se dá bránit buďto pečlivým vytvářením aplikace, nebo zvolit takovou architekturu, u které SQL injection nemá smysl.

U podnikových aplikací a zabezpečených intranetových řešení je volena obvykle druhá metoda. Bohužel není rozumně použitelná s "low end" technologiemi jako bývalo MySQL (dnes už to zvládá, ale programátoři už mají zažité vzory chování, které s tím nepracují) a rovněž není rozumně použitelná s "low end" hardwarem (pokud chci mít v databázi tisíce uživatelů, už to samo bude obrovskou zátěží pro HW). V každém případě nesouhlasím s paušalizováním "SQL Injection je vždy problém".

a kdyz aplikace bezi pod vlastnim uctem, tak jako utocnik neziska pristup k "uctum" registrovanych uzivatelu te aplikace? nebo nemuze zmenit obsah stranky tak, ze dojde k presmerovani na jiny web? rad bych ty vase weby videl ;)

Webová aplikace neběží pod plnohodnotným vlastním účtem. Nemá k tomu důvod. Serverové procesy běží na serveru a klientské procesy buď běží pod konkrétním uživatelem, nebo běží jen pod účtem, který je striktně read only. Problém nastane až ve chvíli, kdy chci anonymní přístup pro zápis. Ale ani ten není neřešitelný.

Ja bych rekl, ze problem nastane hlavne v okamziku, kdy se k vasi aplikaci bude chtit v osm rano najednou pripojit tisic uzivatelu a vy budete pro kazdy request navazovat nove db spojeni.

Nebo tam mate nejake hyper-inteligentni pooly databazovych spojeni? :-) Vase reseni me zajima, ale zatim mam pocit, ze jde pouzit maximalne pro redakcni system o deseti klientech (plus minus).

No, s ORACLE-m to jde. Muzes poolovat pripojeni a pri tom davat pokazdy jiny prava.

Ja osobne si ale myslim, ze tohle neni nejdulezitejsi zabezpeceni. Napriklad pri loginu se asi tezko muzes pripojit sam za sebe, kdyz se jeste nevi kdo to bude.

Tez kdyz jsou miliony uzivatelu (treba google), tak nevim jestli to db zvlada.

Navic to predpoklada moznost urcovat prava pro pristup k jednotlivym radkum i sloupcum (nejpis to nejak pres views pujde).

Imho je takovy pristup hruby a slozity. Neresite problem zabezpeceni aplikace, ale presouvate jej na podsystem databaze. Vysledkem takoveho reseni je nutnost slozitejsiho technickeho reseni. Nevim jak jste prisel na to, ze se takto resi podnikove aplikace, ale ja takto nevidel realizovano zatim jeste nic.

Mno tak jestli si myslite, ze neni problem aby neanonymni identitu pouzival anonymni uzivatel tak opravdu bezpecnsoti nerozumite, tudiz zbytek vaseho vylevu je o nicem.

Můžete být prosím přesnější? Rád se dozvím, jak se bez znalosti uživatelského jména a hesla dokážete přihlásit k databázi. Moc by mi pomohl třebas fragment programu v Javě. Představte si, že vám na nějaké IP adrese jede třebas Oracle 9i, víte všechny detaily, ale neznáte žádná hesla. A teď jak se dostanete dovnitř?

"Na mých stránkách může kdokoliv použít SQL injection, ale v ničem mu to nepomůže. Dokonce se může k databázi připojit přímo přes SQL a dělat si tam co chce a číst co chce."

Takze najednou tohle neplati? ;-)

Rovnez vase zadost je usmevna. Predstava k uspesnemu utoku nestaci. Kazda konkretni aplikace ma sve chyby a sve uzivatele... ;-)

Teď se ztrácím.

1. Každý uživatel se musí přihlásit k databázi. Buďto pomocí SQL klienta (jen hypotetická možnost, DB server si povídá jen s několika málo IP adresami) nebo prostřednictvím webové aplikace. V každém případě zadané přihlašovací údaje slouží k přihlášení k DB serveru. Tedy ne že by se webová aplikace přihlásila sama jako superuser a pak ověřovala údaje.

2. Jakmile jste přihlášení pomoci SQL klienta, můžete si spustit co chcete. Nastavení práv v DB ohlídá na co přístup máte a na co nikoliv. Stejně tak jakmile se přihlásíte přes webovou aplikaci, můžete pomocí SQL injection (nedělám si iluze, že by naše webová aplikace byla 100% bullet proof) spoštět taky prakticky jakékoliv SQL příkazy. Ale opět vás ohlídá nastavení práv v DB serveru.

Jak to tak po sobě čtu, možná už vím kde je zakopán pes. Výrazem "dělat si tam co chce a číst co chce" jsem mínil "pokusit se dělat si tam co chce a číst co chce, ale DB server mu dovolí jen to, na co má práva". Jinak řečeno, propašování SQL příkazu až na server nepředstavuje žádné vážné bezpečnostní riziko, protože vás vždy bude kontrolovat samotný DB server, který to umí mnohem lépe než webová aplikace.

Každopádně se vzdalujeme od toho, co jsem napadal - tvrdím (v rozporu s autorem článku), že prolomení webového rozhraní skrze SQL injection nemusí znamenat prolomení bezpečnosti celé aplikace.

Nepochybuji o tom, že SQL injection je praktický problém s dopadem na každého z nás. Kdybych měl však připodobnit tento článek k něčemu, co bude možná více srozumitelné, přirovnal bych webovou aplikaci k shellu, pomocí kterého uživatelé spouští své příkazy. Tento shell běží obvykle pod rootem. Článek tvrdí, že proto by autoři shellu měli ošetřovat jaké příkazy dovolí spustit a bránili se vynalézavosti uživatelů. A já mu oponuji tím, že dalším řešením je, aby ten shell vůbec neběžel s rootovskými právy.

> A já mu oponuji tím, že dalším řešením je,
> aby ten shell vůbec neběžel s rootovskými právy.

No, autor to v tom článku dost jasně píše :) Ale pokud vám Karle dělá radost že můžete oponovat, tak vám to budiž přáno :)

Záleží na úhlu pohledu. Já jsem dnes možná poněkud podrážděný a proto ten článek vidím spíše jako konstatování, že SQL injection je vždy problém, hromady příkladů a ukázek jak ho zneužít a teprve v posledním odstavci zmíněno, že existuje metoda návrhu, která může efekt SQL injection eliminovat bez toho, že by byl eliminován samotný SQL injection, ale i ta je zmíněna jen jako něco "navíc" místo aby byla uvedena jako základ a obecně spolehlivější cesta než snaha ošetřit každý jeden vstup (byť je to cesta dražší).

I když jsem se možná jen nechal nachytat na novinářské pravidlo "první odstavec musí šokovat i kdyby měl trochu lhát, v článku to pak uveďte na pravou míru, ale ne na tolik, abyste popřel první odstavec".

Nechci se vas nejak dotknout, ale zda se mi, ze to vidite jaksi no ... laicky. Sql injection sam o sobe je problem, ale je to problem spatne napsanych aplikaci. Rozhodne k jeho naprave neni potreba investovat spoustu usili k oprave kazdeho jednoho vstupu jak pisete, jen pristup do databaze musi byt psan urcitym zpusobem, tak aby k danemu problemu nedoslo. A co se tyce zabezpeceni databaze, tak to je (mela by byt) samozrejma vec, ale nedela se primarne kvuli odstraneni utoku sql injection, ale jako jeden z prvku beznecnosti aplikace. Napriklad v clanku zminene pravo pouze pro spousteni procedur, nebo zvlast connection pool pro uzivatele prohlizejici si web a pro ty pracujici v redakcnim systemu a podobne.
Zkratka receno bezpecnost je treba vnimat komplexne, ne jen z pohledu jednoho systemu.

Tak to je samozřejmě nesmysl.

> Na mých stránkách může kdokoliv použít SQL injection, ale v ničem mu to nepomůže

To totiž znamená, že nelze do formuláře vložit třeba apostrof (nelze zadat příjmení O'Connor), aby to nezpůsobilo chybu. Na úrovni práv sice ošetříte, že nedojde ke škodě, ale nic to nemění na tom, že aplikace není plně funkční.

Přiznám se, že tady jsem se trochu ztratil. Například Conn O'Shea v databázi registrovaný je.

Možná jsem se nevyjádřil zcela přesně, ale při přihlašování do aplikace neprovádí servlet žádné:
SELECT 1 FROM bbip_users_tab WHERE userid = :user_id_ AND password = :password_
Provádí se:
Connection con = DriverManager.getConnection( "jdbc:myDriver:wombat", pUserId, pPassword);

Tady vám SQL injection s přihlášením nepomůže.

Dále, jakmile se přihlásíte, máte jen taková práva, jaká vám byla přiřazena. Pokud nejste zrovna administrátor, máte jen práva read na někokolik málo view a vidíte pár procedur a funkcí. Zkrátka i když se přihlásíte přímo do databáze přes SQL klienta, nenapácháte žádné zásadní škody. Proto je mi celkem jedno, pokud vám webové rozhraní umožní vložit prakticky libovolný SQL příkaz. Naše aplikace mají zabezpečený datový model pomocí prostředků DB serveru. A s ohledem na to, kolik úsilí do těchto technologií investují přední dodavatelé produkčních DB serverů, nebudeme jediní.

Chápu, že je důležité udržovat i webové rozhraní v nějakém rozumně bezpečném stavu, ale trvám si na tom, že to není jediná možnost a vlastně to není ani zrovna dvakrát spolehlivá možnost.

Takze nakonec uznavate autorem navrhovane reseni ke konci clanku. Pouzivat maximalne stored procedury, minimalizaci prav a aplikacni rozhrani by melo filtrovat vstupy :-)

Ano :-)

S prvním odstavcem hrubě nesouhlasím (ne, SQL injection není vždy problém).

S dalšími kromě posledního plně souhlasím.

S posledním odstavcem pak souhlasím až na to, že bych slovo "navíc" nahradil slovem "nebo".

Jestli jsem to pochopil spravne, na navrhujete pouzivat stored procedury v co nejvetsi mire?
Ja mam pocit, ze pro robustnost navrhu je dobre nemit rozhazenou aplikacni logiku v databazi i v aplikaci, blbe se to spravuje a udruzuje.

flame: db my mela byt dobra v poskytovani dat, aplikace v praci s nimi a nemichat. Tj. treba autorizaci resit na urovni aplikace, nikoli databaze...

Taky nechápu tu část o vložených procedůrách v SQL.

Proč preferují výkonný kód v SQL, místo v PHP, či čemkoliv jiném.

Podle mě to bude nepřehledné (jak píšeš kód na dvou místech, i když někdy se to může hodit...).

Ale hlavně nechápu, jak to může zvýšit bezpečnost, například zvýšit odolnost oproti SQL Injections.

Stored procedury jsem nikdy nepoužíval, může mi to někdo vysvětlit, nějak jednoduše nejlépe?

Já si totiž myslím, že je to blbost.

Jasně, omezení práv beru.

Omezení vstupů beru, a sám je důsledně dělám.

Ale jaký je rozdíl, jestli, když špatně ošetřím vstup pak s tím kódem něco udělám s SQL přes PHP a nebo přes vloženou proceduru přímo v SQL?

Možná jsem váš první komentář nepochopil správně.

Problém SQL injection chápu jako vadu při vytváření SQL příkazů. Řešením je tuto vadu ostranit, nikoliv ošetřovat její důsledky. Ve článku je třeba uveden příklad, kdy lze server "napadnout" hledáním výrazu: ' or 1=1. To je zcela regulérní výraz, který skutečně může někdo hledat. Aplikace jej proto musí korektně vložit do SQL, třeba tak, že před apostrof vloží lomítko nebo jej zdvojí - prostě jak si to konkrétní databáze žádá.

Váš komentář mi naopak vyzněl tak, že není třeba řetězec korektně vložit do SQL, protože stejně nelze získat citlivá data.

Jak pravil Linus: "Kecat umí každý - ukaž mi kód".

Až sem hodíš odkaz na ten tvůj superweb, tak se má smysl bavit. Zatím se tu jen chvástáš, že jsi naprostý bůh.

Nezbývá než si uvědomit, že kdyby tvé řešení skutečně fungovalo, už bys
a) dávno byl v balíku jako konzultant nějaké megafirmy
b) pořádal školení, jak to dělat, a všichni by to po tobě kopírovali.

To je řešení dostatečné pouze v případě, že žádný z uživatelů nemá právo žádného zápisu. Jakmile může cokoliv zapisovat, pak je kontrola dat nutností. Zvláště, jde-li o architekturu s tenkým klientem ve formě webového prohlížeče. Není přece problém vsunout do textového řetězce skript nebo odkaz kamkoliv. Pak se provede při čtení na straně uživatele a váš server tomu nezabrání.

Osobně nevím, proč by měl mít uživatel právo posílat jakýkoliv SQL příkaz a dokonce proč by měl mít nějaké právo přístupu do databáze. Databázový server je služba aplikaci, nikoliv uživateli. SQL slouží ke komunikaci mezi aplikací a databází, nikoliv mezi uživatelem a databází. Uživatel nechť má přístup do aplikace a vše se pak musí dít pod její kontrolou.(Pochopitelně běží na serveru). Netvrdím, že je to jediný možný či vhodný model - ale mě se páčí nejvíce.

První odstavec je velice nepěkné paušalizování. Záleží na architektuře a na samotné aplikaci.

S tím se dá souhlasit. Ne každá chyba v aplikaci je zneužitelná a od toho jsou penetrační testy, aby se ukázalo, jestli ty chyby zneužít jdou nebo nejdou.

SQL injection je typ útoku, kterému se dá bránit buďto pečlivým vytvářením aplikace, nebo zvolit takovou architekturu, u které SQL injection nemá smysl.

No, v principu mate pravdu, ale je třeba mít na paměti, že dnes už každá databáze má prostředky pro čtení souborů na disku, případně i pro spouštění kódu. SQL injection nemusí být jen o tom, že něco uložím nebo vyčtu z databáze.

A není radno zapomínat, že injection útoky platí i na další používané technologie - ldap, xpath, ...

Klaus.cz byl reportován krátce po jeho prvním zvolení prezdentem. SQL injection tam je, ale je to fixnuté a tak, že to využít nejde.

Ale trochu osvěty na todle téma nemůže nikdy škodit.

Když se z jednoho jazyka lepí jíný, tak je holt třeba eskejpovat citlivé znaky.

Tady lze doporučit - používejte kvalitní databázový layer (pro PHP třeba dibi ;) a nemusíte se SQL injection vůbec bát. Obrovská výhoda této (až nepochopitelně rozšířené) chyby je ta, že se dá vyřešit na velmi nízké úrovni a pak už na ní není třeba myslet.

Jistě jistě ono taky stačí používat nativní PDO, ne nějaké vaše obskurní třídy.

Samozřejmě spoustě lidí stačí obyčejné PDO. Ale kdo chce něco navíc, používá dibi. V současné době ten nejúúúžasnější databázový layer! Tak to prostě je. S tím nic nenaděláte :-))

A kto chce nieco naviac, pouziva Javu a hibernate (.net+nhibernate).
Este nejake stupidne argumenty ?

Kdyz nekdo pouziva hruzu jako MS OLE DB a MS Jet DB, tak necht trpi.

Tade je to samé prgoš, samé ekjaltion a podobně. A žádná samohana.
Teda chlapí, a co ta SKJŮeL injektse udělá s Lotus Domino Serverem.

Teda to by mne Meďánku náš zajímalo.
Ha ha ha.

Nazdar.

p.s.
kolik jazyků znáš, tolikráte jsi programátorem.
Досвидания
Bye, bye

Vubec nic pac to neni SQL databaze ;-)

Cest praci, siudruzi..bohuzel nechapu o cem je rec...

"Pokud vládnete jazykem SQL, tak začínáte tušit, jak velká je tohle zrada (a malér)" a i v dalších příkladech (xp_cmdshell)

To první není SQL, ale T-SQL, a jedná se o příklady konkrétně pro MS SQL Server, takže je trochu zavádějící to za "SQL" označovat, protože SQL jsou především normy napříč db, a ne jen jedno řešení od MS, ne

Ano. Ostatní tu jenom dělají machry, ale skutek utek.