Přejít k navigační liště

Zdroják » Zprávičky » Nejběžnější bezpečnostní chyby ve webových aplikacích

Nejběžnější bezpečnostní chyby ve webových aplikacích

Zprávičky Různé

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í…

Komentáře

Subscribe
Upozornit na
guest
23 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Jakub Vrána

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.

Jakub Vrána

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ů.

Johny

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[„hes­lo“]==“tajne heslo“){
$prihlasen=“ano“;
}

if($prihlasen==“a­no“){
echo „tajna sekce“;
}
?>

Co se ale stane když zadám login.php?prih­lasen=ano ? :-)
Toto je klasický způsob útoku poté, co se dostanete ke kódu aplikace….

neron

Pokud server nespravuje pitomec a nebo se nejedna o hodne starou a hodne deravou applikaci, nestane se nic.

ach

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)

Johny

Kupodivu stále existují hostingy, kde je register_globals On.

neron

1. Ono asi plati oboje, protoze ne vsechna data na vystupu pochazeji z databaze.

Jakub Vrána

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.

karf

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?

Jakub Vrána

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).

jos

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

Jakub Vrána

Ještě ta procenta – podle zářijových statistik jsou spolehlivě chráněny asi 2/3 uživatelů.

Emkei

asi 2/3? vis jak obrovske cislo tvori ta jedna tretina?! nazvat neco takoveho „spolehlivym resenim“ je opravdu perla…

Jakub Vrána

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).

Emkei

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…

Jakub Vrána

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.“

Emkei

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 :)

Jakub Vrána

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.

drevolution

Č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.

Jakub Vrána

Ale jistě. Pokud by příklad využíval pg_query nebo třeba sqlite_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.

drevolution

No jo, já to tušil, měl jsem si ten kus textu napřed přečíst :) Tak to nic.

Jakub Vrána

Probůh, on to nepsal nějaký studentík, ale expert na bezpečnost z Yahoo!.

LamiCZ

To víte, on je to hlavně „geek“ a ne odborník…

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.