Hlavní navigace

Vlákno názorů k článku Na podceňovanou hrozbu SQL injection doplácí i řada českých webů od luky - a kdyz aplikace bezi pod vlastnim uctem, tak...

  • Článek je starý, nové názory již nelze přidávat.
  • 10. 6. 2008 12:05

    luky (neregistrovaný)
    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 ;)
  • 10. 6. 2008 13:19

    Zdenek (neregistrovaný)
    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.
  • 10. 6. 2008 17:00

    mazanek (neregistrovaný)
    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...
  • 10. 6. 2008 20:13

    hisaak (neregistrovaný)
    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).
  • 10. 6. 2008 23:35

    Miloš (neregistrovaný)
    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.
  • 10. 6. 2008 23:38

    Jaromír Adámek
    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?
  • 11. 6. 2008 0:14

    Maaartin (neregistrovaný)
    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).
  • 11. 6. 2008 4:11

    David Grudl (neregistrovaný)
    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.
  • 11. 6. 2008 10:03

    anonymní
    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, ...

  • 12. 6. 2008 0:34

    polygon (neregistrovaný)
    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.
  • 12. 6. 2008 0:55

    polygon (neregistrovaný)
    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.
  • 10. 6. 2008 14:18

    Zdenek (neregistrovaný)
    "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... ;-)
  • 10. 6. 2008 15:29

    Daniel Dočekal
    > 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 :)
  • 10. 6. 2008 21:51

    Pavel D. (neregistrovaný)
    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.
  • 10. 6. 2008 13:48

    David Grudl (neregistrovaný)
    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í.
  • 10. 6. 2008 11:39

    Karel (neregistrovaný)
    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".
  • 10. 6. 2008 14:04

    Karel (neregistrovaný)
    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ý.
  • 10. 6. 2008 14:10

    Karel (neregistrovaný)
    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ř?
  • 10. 6. 2008 14:43

    Zdenek (neregistrovaný)
    Takze nakonec uznavate autorem navrhovane reseni ke konci clanku. Pouzivat maximalne stored procedury, minimalizaci prav a aplikacni rozhrani by melo filtrovat vstupy :-)
  • 10. 6. 2008 15:23

    Karel (neregistrovaný)
    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.
  • 10. 6. 2008 15:26

    Karel (neregistrovaný)
    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".
  • 10. 6. 2008 15:39

    Karel (neregistrovaný)
    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".
  • 10. 6. 2008 14:28

    Karel (neregistrovaný)
    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.