Dotaz: Jak podstrcit SQl Dotaz?

[Jarko]

Ahoj, snazim se zabezpecit web a porad vsude ctu o nejakem sql injection, muze me prosim nekdo jednoduse vysvetli jak muzu podstrcit nejaky sql dotaz? Dyt je to absolutni nesmysl.. Jedina moznost me napada pres url ale to je absolutne primitivni to zabezpecit..

dekuji prosim za pomoc

Odpovědi

[Dejv]

Ahoj. Nesmysl to neni. Mrkni na wikipedii nebo zkus hledat na Rootu, pokud se nepletu, neco tam o tom sveho casu psali.

Dejv

[Jarko]

prolezl jsem trencin s trnaov a nic jsem nenasel, proto se ptam tady..

[Dejv]

Weby mest ti asi moc nepomuzou . Na Rootu jsem nasel tohle.

Dejv

[mich]

Nemůžu si pomoct: xkcd

[neaktivni]

Dokonalé ))))

[xkucf03]

+1

[msk]

SQL injection sa da zneuzit vcelku lahko, ked si programator danej aplikacie nedava pozor na to, akym sposobom konstruuje sql requesty.

Priklad:

Aplikacia ( napriklad webova ) ma okno na registraciu uzivatela. Tabulka je ( userid serial, username text, password text ). Vstupne parametre predpokladajme v premennych String user_name a String password:

String user_name = ...;
String password = ...;

// tak takto nie
Query  q1 = new Query ( "insert into users ( username, password ) values ( " + user_name + ", " + password + " );" );

// takto
PreparedQuery q2 = new PreparedQuery ( "insert into users ( username, password ) values ( ?,? );" );
q2.setString ( 1, user_name );
q2.setString ( 2, password );

Pokial bude v password nieco ako "foo ); drop from users; select ( 1", tak sa vykona:

insert into users ( username, foo );
drop from users;
select ( 1 );

... a mas problem

[kozzi]

ale ty predpokladas ze utocnik zna nazvy tabulek coz nemusi byt pravda. Ale ano je pravda ze pokud si nekdo sve aplikace nezabezpecuje proti tomuto primitibnimu utoku, tak je dost pravdepodobne ze jeho tabulka bude mit nazev users a polozky nejspis neco jako name, password, id, email ... .

[msk]

Nie, nepredpokladam. Posli v username nieco ako "1 ); drop table users; select 1" a v password "foo". Vyjdu z toho 3 prikazy:

insert into users ( username, password ) values ( 1 );
// na toto povie fail

drop table users;
// toto s radostou vykona


select 1foo);"
// a toto zase zfailuje, to ti uz ale nepomoze

[kozzi]

heh, ale opet si do policka napsalk nazev tabulky, coz zanmena ze predpokaldas

[msk]

Dobre, tak drop table pg_tables / pg_tablespace / pg_user / akakolvek systemova tabulka...

[xkucf03]

Proč by ty systémové tabulky zahazoval, když si z nich může vyselektovat názvy těch uživatelských?

[Tomas]

Rikat si "utocnik nezna nazvy tabulek, nemusim to zabezpecovat" - neni zrovna dobry pristup;))

 

Jinak nepovolene prihlaseni do jakehokoliv nezabezpeceneho systemu nemusis znat nazvy tabulek ani sloupcu.

napr.:

<tt>

SQL pro overeni hesla uzivatele (" SELECT user WHERE login = '"+login+"' AND passwd = '"+heslo+"';");

</tt>

pokud v promene heslo  mas hodnoty:

  ' OR '1'='1

nebo si zkouset vybrat uzivatele ktereho chces

  ' OR 1 OFFSET 25 LIMIT 1 --

tak se prihlasis bez znalosti uzivatelskeho hesla - a nemusis znat zadny nazev tabulky ani sloupce.

 

[Ash]

Oni tragédi co jsou schopní ukládat heslo v otevřeném tvaru si zaslouží aby se pak za trest museli trápit s takovýmito komplikacemi.

[alazar]

Jak to s tím souvisí??

[Ash]

Když heslo hashujete, tak můžete mít i legální heslo "' OR 1 OFFSET 25 LIMIT 1 --" bez toho že by vám to rozhodilo systém.

[joe]

Když zadané heslo hashujete před tím, než ho použijete v dotazu... jsi asi chtěl říct ;) Každopádně je to jedno, protože v tom dotazu je ještě login, že... Buď vstupy hlídáš, nebo nehlídáš, tečka.

[Ash]

Ano, ono překvapivě aby člověk heslo hashoval až poté, co ho použije v dotazu, na to je opět potřeba takový ten jemný, lamerský talent :)

[Filip Jirsák]

Já tedy klidně hashuju až v dotazu, protože hashuju až v uživatelské proceduře v databázi. Pak se nemusím starat o to, aby všechny aplikace používaly stejný algoritmus a stejnou sůl, protože tohle vše je až v DB. Ale zase používám Javovské PreparedStatement a PreparedCall, takže mi SQL injection nehrozí – hodnoty zadané uživatelem se tam zadávají jen jako hodnoty konkrétních parametrů, žádné skládání dotazu z jednotlivých částí.

[Ash]

Jistě, jen připomínám že jsem mluvil o ukládání hesla v otevřeném tvaru, což lze brát jako opak ukládání hashe, ať už je to hashování před vytvořením dotazu nebo hashování v db proceduře. Jistě se shodneme že je dobré, aby se otevřené heslo nikde moc dlouho netoulalo, ani neukládalo. Pokud je ošéfovaná komunikace server -> databáze tak samozřejmě nic proti procedurám v databázi :)

[Filip Jirsák]

Omlouvám se za nedorozumění, já jsem to chápal tak, že buď heslo do SQL příkazu vstupuje v otevřeném tvaru (a tedy může být zdrojem SQL injection), nebo do SQL příkazu vstupuje jako hash, a pak zdrojem SQL injection být nemůže.

Komunikace je ale buď zabezpečená, pak se může heslo toulat libovolně dlouho, nebo to bezpečná není, a pak se nemůže heslo nikde toulat ani jednu milisekundu. Uvažování „to bude rychle, toho si nikdo nevšimne“ do počítačové bezpečnosti nepatří.

[Ash]

Ano, už jen doplním že tím "nikde moc dlouho" jsem nechával prostor pro místa jako operační paměť, sběrnice a pod. Abych tak řekl, není nic tak zabezpečeného, aby to nemohlo být ještě zabezpečenější, když na to přijde :D

[xkucf03]

Pokud je ošéfovaná komunikace server -> databáze

Tak ta z principu ošéfovaná být musí, protože přes ni tečou všechna (i citlivá) data.

Jestli hashovat nebo ne, jsem se zabýval v blogu.

Hashovat mi přijde přirozenější až v DB (je to na jednom místě), ale není to až tak zásadní otázka.

BTW: četl už někdo tyhle zdrojáky? Ke změně hesla tam používám DB funkci, která ověří i to původní heslo -- ten systém by měl být odolný i proti jakkoli zkompromitované (a zpackané) porezentační vrstvě (PHP), ale rád bych, kdyby to po mě ještě někdo přečetl

[Ash]

Tak ta z principu ošéfovaná být musí, protože přes ni tečou všechna (i citlivá) data.

Mi připomíná ten ruskej vtip, jak maj Rusové půl metru velký včely, co jsou výkonné a produkujou hodně medu. "A jak se vám proboha vejdou do těch maličkých úlů???" No... no MUSÍ.

[xkucf03]

O tom to přece není. Heslo může být všeliaké i když nehashujeme, nebo to ani nemusí být heslo, ale třeba řetězec k vyhledání.

Jediné spolehlivé řešení je, neskládat SQL dotaz/příkaz, nelepit ho z kousků textu -- mít jeden odladěný dotaz s otazníky, za které se pak dosadí* proměnné (v Javě PreparedStatement, v PHP tohle umí PDO)

*) pomocí zvláštní funkce, ne nahrazením textu

[Ash]

Vizte zde, opakuji že tohle jsem vůbec neřešil, řešil jsem zda do databáze ukládat nebo neukládat heslo v plaintextu. Imho rozhodně neukládat. Jinak co se vstupů týče, osobně např. dbám na escapování uvozovek atd. atd.

[xkucf03]

co se vstupů týče, osobně např. dbám na escapování uvozovek atd. atd.

To znamená co? Že ty texty od uživatele escapuješ a pak je třeba uložíš do DB? IMHO je lepší pracovat s daty, tak* jak přišly od uživatele a do databáze ukládat čistá data, tedy bez jakéhokoli escapování. Důvody:

• escapování je závislé na způsobu využití (na formátu), zatímco text určený pro výstup do HTML můžu escapovat na entity &nbsp;, budu mít problém, pokud budu chtít tentýž text použít jinak (např. vysázet v LaTeXu)**
• do databáze mohou data přicházet z různých zdrojů, mohou být např. zadána ručně, nemáme žádnou záruku, že prošla naší escapovací funkcí → musíme být tedy k datům z databáze přirozeně nedůvěřiví a escapovat je znovu nebo kontrolovat.

*) mluvím teď o ošetření nebezpečných znaků (pro SQL, HTML), ne o kontrolách typu, že e-mail musí vyhovovat regulárnímu výrazu, nebo že text má nějakou maximální délku.
**) mám tu čest pracovat s jednou pěkně zfušovanou aplikací, která neumí UTF-8 a soudruhy z DDR nenapadlo nic lepšího, než ty znaky escapovat na HTML entity. Ono jim to hezky funguje když se text zobrazuje na webu, to by si toho člověk ani nevšiml, ale jakmile se ten text pošle elektronickou poštou (což se s e-maily běžně dělá) mimo ten systém, máme problém – příjemce vidí HTML entity tam, kde žádné HTML nemá, co dělat (např. předmět mailu).

[Ash]

Tušil jsem že když napíšu "atd" že někdo přijde s nějakou hloupostí. Data je samozřejmě žádoucí ukládat (tedy zařídit aby byla ve výsledku uložena) tak, jak přišla od uživatele, což v SQL příkazu kde jsou tato data ohraničena apostrofy lze zařídit již zmíněným escapováním případných apostrofů v datech. Tato data lze pak samozřejmě využít kdykoliv kdekoliv k všeobecné spokojenosti.

[Michal Kubeček]

Data je samozřejmě žádoucí ukládat (tedy zařídit aby byla ve výsledku uložena) tak, jak přišla od uživatele

S tím souhlasím…

což v SQL příkazu, kde jsou tato data ohraničena apostrofy, lze zařídit již zmíněným escapováním případných apostrofů v datech

…a s tímhle už ne. Data od uživatele především vůbec není vhodné vkládat přímo do SQL dotazu, protože právě tím si potenciálně zaděláváte na všechny problémy označované jako SQL injection. Pokud data od dotazu oddělíte, nemusíte escapovat nic a neriskujete, že jednou někde něco přehlédnete a vystavíte se tím útoku.

[Ash]

Data od uživatele především vůbec není vhodné vkládat přímo do SQL dotazu jistě, a pokud už to někdo dělá, je druhá nejlepší možnost je mít escapované jako například u hodnot přijatých z formulářů

[Michal Kubeček]

Jinak co se vstupů týče, osobně např. dbám na escapování uvozovek atd. atd.

A to je právě špatně, je to zbytečně komplikované a sebemenší chybička se může vymstít. Hodnoty parametrů prostě nemají v SQL dotazu co dělat. Je to jen historický relikt z dob, kdy PHP rozhraní pro MySQL neumělo pracovat s parametrizovanými dotazy. Ale i to už dost dlouho parametry oddělit umí (pro jiné databáze to šlo i dříve), takže není důvod si zbytečně přidělávat práci a navíc ještě zvyšovat riziko.

[Ash]

Je to jen historický relikt z dob, kdy PHP rozhraní pro MySQL neumělo pracovat s parametrizovanými dotazy. Jistě, ale i takové historické weby existují. U nového webu samozřejmě parametrické dotazy lze s výhodou použít. Ovšem vstupy je vhodné stejně hlídat, byť už ne pro riziko SQL injection.

[Martin Doucha]

Názvy tabulek a sloupců se dají ověřit správně sestaveným selectem. Když tabulka/sloupec neexistuje, select skončí s chybou a vyskočí internal server error. Když existuje, tak se stránka načte. A pokud je ten web opravdu hodně blbě napsaný, šlo by nechat si hlavičky všech tabulek vypsat.

[Tomas]

Vkladat se da pres jakykoliv uzivatelsky vstup, ktery se pak vklada do SQL dotazu - tozn. moznosti je spousta:

 - URL parametry

 - data ve formulari

 - http headery (cookies a jakekoliv dalsi)

 ... doporucuju si koupit nejakou knihu o bezpecnosti webovych aplikaci - SQL injection je jen jedna moznost utoku, ale existuje mnoho dalsich.

[Michal Kubeček]

Celé to ale předpokládá, že vstup zadaný (jakýmkoli způsobem) uživatelem bude použit jako součást SQL dotazu, což je samo o sobě naprosto zásadní chyba. Přitom dnes už i PHP rozhraní pro MySQL už (konečně) umožňuje se tomu vyhnout. Jenže autoři skriptů si (většinou) nechtějí "přidělávat práci" s bindováním parametrů a dál tvrdošíjně cpu uživatelské vstupy přímo do dotazu.

Takže SQL injection lze v drtivé většině případů velmi snadno a zcela univerzálně předejít a pokud to někdo odmítá udělat, protože "takhle to přeci psal vždycky", případně "takhle to přeci dělají všichni" nebo "takhle to dělá Franta Vomáčka ve své knize", je to jen jeho hloupost.

[fluxer]

Zdravím, pre všetkých SQLi nadšencov je tu Cheese Holes blog pre trénovanie Vašich zručností. Prvotné info je na webe hack4fun, kde nájtete aj linky na obe verzie Cheese. Enjoy

[chrono]

Má to niečo spoločné s Gruyere od Goole, alebo je podobnosť len čisto náhodná? :)

[chrono]

Goole malo byť samozrejme Google :)

[fluxer]

Úplná náhoda.