Nejběžnější bezpečnostní chyby ve webových aplikacích
Nálepky:
Smashing Magazine vydal seznam častých bezpečnostních chyb ve webových aplikacích. Seznam zahrnuje CSRF, XSS, clickjacking, SQL injection a další chyby, které se, ačkoli jsou notoricky známé, stále opakují…
A zrovna dnes vyšel článek o konkrétním zabezpečení aplikace, ve které to je obzvlášť důležité: Bezpečnostní opatření Admineru. Mimo jiné popisuje spolehlivé zabezpečení proti ClickJackingu a ne tu naprostou pitomost, kterou uvádí článek na Smashing Magazine.
Jak ten článek na Smashing Magazine čtu podrobněji, nacházím další perly:
1. Data se pro výstup ošetřují při uložení a ne až při výstupu.
2. Funkce get_nonce() používá neexistující proměnné. Navíc bez podrobnějšího popisu toho, jak se vygeneruje $salt je k ničemu. A v neposlední řadě doporučuje návrh způsobem Security by Obscurity.
3. Obrana vyžadující po uživateli, aby si zapnul JavaScript, opravdu není dobrý nápad.
4. Příklad útoku je zcela nesmyslný. PHP nedovoluje v jednom mysql_query poslat více příkazů.
Přesně tak, o mnoha zranitelnostech se tam zase nezmiňují….
Například PHP include a variable injection nebo jak to nazvat – příklad:
soubor login.php
<?php
if($_POST[„heslo“]==“tajne heslo“){
$prihlasen=“ano“;
}
if($prihlasen==“ano“){
echo „tajna sekce“;
}
?>
Co se ale stane když zadám login.php?prihlasen=ano ? :-)
Toto je klasický způsob útoku poté, co se dostanete ke kódu aplikace….
Pokud server nespravuje pitomec a nebo se nejedna o hodne starou a hodne deravou applikaci, nestane se nic.
register globals je defaultne vypnute uz od php 4.2.0 a ta vysla 22-Apr-2002, co je skoro 9 rokov. Mali by ste si oprasit svoje vedomosti ohladom php (pripadne ak vas kod u vas „funguje“, je na case porypat sa aj v configu php)
Kupodivu stále existují hostingy, kde je register_globals On.
1. Ono asi plati oboje, protoze ne vsechna data na vystupu pochazeji z databaze.
Neplatí oboje. Když data ukládám do databáze (odkudkoliv), tak je musím ošetřit pouze pro databázi (v případě vázání proměnných tedy nijak). Když data vypisuji do HTML, musím je ošetřit pro HTML (nejčastěji funkcí htmlspecialchars), ať už pochází odkudkoliv.
Nechci se toho článku nějak zastávat, ani nejsem odborník na bezpečnost, ale:
1. V článku je hned pod kódem odstavec vysvětlující, proč vstup ošetřuje už před uložením a také se zmiňuje o tom, jaké to má nevýhody. Můžeme s tím nesouhlasit, ale takto podané mi to nepřijde nějak skandální.
3. Koukal jsem se na Váš článek, kde píšete, že clickjacking řešíte pomocí hlavičky X-Frame-Options. Tuhle hlavičku ale pokud vím podporují jen nejnovější prohlížeče. Kolik je procent uživatelů používajících prohlížeč, který to podporuje? Asi se na to úplně spoléhat nedá, nebo ano?
1. Vysvětlením se snaží legitimizovat špatný postup, čímž to celé jen zhoršuje. Ošetřovat data pro HTML na vstupu prostě nejde, už jen proto, že jsou ošetřená data delší. Což může způsobit, že se do databáze uloží data oříznutá třeba uprostřed entity, což v extrému může způsobit až nezobrazení XHTML stránky. Navíc tím nutí všechny programátory psát výstup tak, aby data už neošetřoval. Protože to není pro případ „že by někdo zapomněl“ – ony se data podruhé už ošetřit nesmí, protože by to znamenalo vypsání HTML entit.
3. Uživatele používající staré nebezpečné verze prohlížečů chránit dost dobře nejde. Chtít po uživatelích zapnutý JavaScript není dobré ze dvou důvodů – jednak kvůli přístupnosti a jednak proto, že ti nejvíc opatrní uživatelé mají JavaScript vypnutý a selektivně si ho zapínají jen na stránkách, kterým oni sami věří (třeba pomocí extenze NoScript).
Což může způsobit, že se do databáze uloží data oříznutá třeba uprostřed entity
teda databázi která mi tiše ořízne data bych (už) nechtěl používat ani za prachy
Ještě ta procenta – podle zářijových statistik jsou spolehlivě chráněny asi 2/3 uživatelů.
asi 2/3? vis jak obrovske cislo tvori ta jedna tretina?! nazvat neco takoveho „spolehlivym resenim“ je opravdu perla…
Asi si nerozumíme. To řešení je spolehlivé z toho úhlu pohledu, že funguje všem zodpovědným uživatelům, kteří nepoužívají nebezpečný software. Není to řešení, které by přestalo fungovat proto, že si uživatelé někde něco vypnou třeba právě z důvodu lepší bezpečnosti (JavaScript).
zda mi bude fungovat zminovana hlavicka nema preci nic spolecneho s tim, jak jsem zodpovedny, ale s tim, jak mam aktualni prohlizec, pricemz aktualita software predevsim ve firmenim prostredi nebo u nezkusenych uzivatelu neni zrovna ruzova, na coz je potreba brat zretel a nenazyvat alternativni reseni rovnou za naprostou pitomost.
jinak Philip Tellis nikdy nebyl bezpecnostnim expertem u yahoo, ale radovym vyvojarem, takze ta narazka nize imho neni na miste…
Ale jistěže to souvisí se zodpovědností. Pokud uživatel nemá bezpečný prohlížeč, tak nesmí dělat věci, které v něm jsou nebezpečné. V případě ClickJackingu to znamená především to, že nebudu chodit na cizí stránky, pokud jsem přihlášen do nějaké aplikace. Ve firemním prostředí by se firma měla postarat o to, aby se to uživatelé dozvěděli, když už nechtějí nainstalovat nové prohlížeče.
Četl sis profil autora na Smashing? „As part of his job with the Paranoid group, he spends a lot of time worrying about Internet Security, and then doing something about it.“
ty to beres z pohledu, jak by to melo byt, ale realita je podstatne jina a prave tu by mela odrazet bezpecnostni politika.
kvuli te jedne vete jsi ho nazval bezpecnostnim expertem? tak to si ji dam do profilu take :)
Zase – neřekl bych ani popel, kdyby bylo uvedeno systémově správné řešení, k němu řečeno, že uživatelé bohužel stále používají nebezpečné prohlížeče a že pokud chceme ochránit i je, můžeme použít JavaScript. Ale uvést pouze řešení, které právě těm nejopatrnějším a nejzodpovědnějším uživatelům nebude fungovat, je chyba.
Článek jsem zatím nečetl, takže doufám, že nebudu úplně mimo, ale to že mysql_query() neumožňuje poslat více dotazů je sice dobré, nicméně není to jediná funkce, která umožňuje zasílat dotazy. Funkce pg_query() vícenásobné zaslání dotazu podporuje, takže aplikace nad PostgreSQL jsou v tomto ohledu náchylnější ke zranitelnosti.
When multiple statements are passed to the function, they are automatically executed as one transaction, unless there are explicit BEGIN/COMMIT commands included in the query string. However, using multiple transactions in one function call is not recommended.
Ale jistě. Pokud by příklad využíval
pg_query
nebo třebasqlite_query
bez využití návratové hodnoty, tak bych neřekl ani popel. Ale uvádět jako příklad kód, který nefunguje, je prostě chyba. To je akorát strašení, které pak všichni papouškují dál, dokud jim někdo nedokáže, že takhle ten příklad prostě nefunguje. A v ten okamžik si můžou říct „aha, tak ono vlastně žádné riziko nehrozí“ a je problém na světě.Navíc na SQL Injection existuje tolik hezkých a funkčních příkladů, že by opravdu nebylo těžké nějaký z nich uvést. Třeba získání všech dat z celé databáze kvůli neošetřené hodnotě LIMIT, na kterou ani ten jediný uvedený způsob obrany pomocí vázání proměnných nepomůže.
No jo, já to tušil, měl jsem si ten kus textu napřed přečíst :) Tak to nic.
Probůh, on to nepsal nějaký studentík, ale expert na bezpečnost z Yahoo!.
To víte, on je to hlavně „geek“ a ne odborník…