4IT445 – Bezpečnost

Ing. Jan Mittner 4IT445 – Bezpečnost

Osnova • Autentizace • Pluginy • Autorizace • Útoky

Autentizace • proces ověření identity • v Zendu řešíme skrze komponentu Zend_Auth • zajišťuje ověření identity oproti datovému zdroji identit • využívá rozšiřitelné adaptéry implementující jednotné rozhraní • databázové rozhraní • HTTP autentifikace • LDAP • OpenID • atd. • http://framework.zend.com/manual/en/zend.auth.html

Hash hesla • hesla do databáze neukládáme v otevřeném formátu, ale pouze jejich hash, tzn. jednosměrně zakódovaný řetězec znaků dle vybrané hashovací funkce • hash by nemělo být možné hrubou silou v rozumném čase dekódovat zpět na heslo • útočník ani administrátor pak z databáze, resp. jiného datového zdroje, nebudou schopni hesla dešifrovat • nejčastější hashovací funkce – MD5, SHA (SHA-1, SHA-2) atd.

Solení hesel • hash se nevytváří pouze ze samotného hesla, ale ze spojení hesla s libovolným řetězcem =solí • sůl by měla být pro každého uživatele individuální • může jít o náhodně vygenerovaný řetězec uložený u každého uživatele v databázi nebo jednoduše např. pouze login uživatele • vhodné zkombinovat i s další statickou solí definovanou pouze v rámci aplikace mimo databázi • solení hesel zajišťuje především obranu proti rainbowtables: • útok využívající již předpočítaných tabulek „hash – heslo“ • http://www.phpguru.cz/clanky/soleni-hesel

Pluginy • objekty neinvazivně rozšiřující funkcionalitu stávající aplikace • pluginy mohou nabývat různých typů dle svého účelu • action / view helpery, formulářová rozšíření (filtry, validátory, dekorátory), pluginy front-controlleru atd. • pluginy front-controlleru ovlivňují chování aplikace jako celku a váží se na jednotlivé události během životního cyklu zpracování požadavku klienta • vychází z objektu Zend_Controller_Plugin_Abstract, který definuje metody pro jednotlivé události: • preDispatch() – spouští se před zpracováním konkrétní akce • postDispatch() – spouští se po zpracování konkrétní akce • atd. • http://devzone.zend.com/article/3372

Autorizace • udělení přístupu k funkcím a informacím na základě oprávnění ověřené identity • v Zendu řešíme skrze komponentu Zend_Acl • vychází z obecného modelu access control list, který definuje seznam určující kdo nebo co má povolení přistupovat k objektu a jaké operace s ním může provádět • pracuje s pojmy • zdroj – objekt, u něhož je kontrolován přístup • role – objekt, který může požadovat zdroj • role může mít přístup ke zdroji jako celku, resp. pouze k vybraným akcím pro práci se zdrojem • role mohou tvořit hierarchický strom dědičnosti oprávnění • nad vytvořeným ACL modelem je následně možné klást dotazy, zda má uživatel disponující danými rolemi práva k provádění akcí nad vybranými zdroji • http://framework.zend.com/manual/en/zend.acl.html • lze to řešit i jinak (jako Zend_Controller_Action_Helper)

Útok – XSS • cross-site scripting (XSS) je hackerská metoda využívající bezpečnostních děr ve skriptech • zpravidla se týká neošetřených klientských vstupů a výstupů, čili útočník může do aplikace nahrát vlastní škodlivý kód • 3 typy: • lokální • z URL se do javascriptu stránky vkládají neošetřené vstupy na straně klienta • útočník tak může snadno vytvořit vlastní URL, do vstupů včlení škodlivý kód a URL bude distribuovat dál • nepersistentní • obdobné jako lokální typ s rozdílem, že neošetřený vstup se vkládá do stránky na straně serveru • persistentní • podobné jako nepersistentní typ s rozdílem, že škodlivý kód se uloží do databáze, čili následně není nutné vstoupit na stránku skrze upravenou URL • obrana v Zendu – hlídat uživatelské vstupy a používat escapování výstupů • http://framework.zend.com/manual/en/zend.view.scripts.html#zend.view.scripts.escaping • http://cs.wikipedia.org/wiki/Cross-site_scripting

Útok – SQL injection • SQL injection je hackerská metoda zajišťující „vsunutí“ vlastního SQL do prováděného dotazu na straně serveru • metoda využívá neošetřených vstupů a umožňuje útočníkovi získat data z databáze, resp. jejich podobu upravit • obrana v Zendu – hlídat uživatelské vstupy a používat quotování vstupů a vázání proměnných do SQL dotazů • http://framework.zend.com/manual/en/zend.db.adapter.html#zend.db.adapter.quoting.quote • http://framework.zend.com/manual/en/zend.db.statement.html • http://cs.wikipedia.org/wiki/SQL_injection

Útok – CSRF • cross-siterequestforgery(CSRF) je hackerská metoda zajišťující spuštění akcí ve vybrané aplikaci uživatelem nevědomě skrze jinou napadenou aplikaci • útok je nejsnazší realizovat proti aplikacím, které využívají při autentifikacicookies a jejichž funkční strukturu útočník zná • útočník pak může do jiné aplikace přidat např. tag obrázku s URL vybrané akce v cílové aplikaci (např. mazání / editace dat apod.) • následně uživatele přiměje na napadenou stránku vstoupit, a pokud ten je současně přihlášen v cílové aplikaci, tak se nevědomky provedou akce, které mohou způsobit nevratné změny • obrana v Zendu – ve formulářích využívat autorizační hashtoken nebo captcha ochranu • http://framework.zend.com/manual/en/zend.form.standardElements.html#zend.form.standardElements.hash • http://framework.zend.com/manual/en/zend.captcha.html • http://php.vrana.cz/cross-site-request-forgery.php

Útok – replay attack • typ man-in-the-middle útoku • typicky problém u přihlašovacích formulářů, které nejdou přes https • navíc se heslo přenáší v otevřené podobě • řešení: challenge-response přihlašování • ve formuláři je jednorázový náhodný token • spolu s tímto tokenem se na straně klienta spočítá hash a zasílá se místo hesla • server vezme token a zahashuje jej společně s heslem uživatele uloženým v db (resp. s hashí hesla) • výsledek porovná a pokud sedí, je vše ok • výhody: • heslo se nepřenáší v otevřené podobě (nemusí být https) • není možné se přihlásit opakovaně odposlechnutým požadavkem

Útok – přístup k citlivým souborům • citlivé soubory musejí být vždy umístěny mimo document root nebo alespoň odpovídajícím způsobem zabezpečeny proti přístupu • např. application.ini obsahuje hesla • přípona .ini je ale standardně webserverem vracena jako textový dokument • řešení: .htaccess soubor se zakázáním přístupu

Úkoly • doplňte do aplikace dalšího administrátora • zakomponujte do autentifikace solení hesel • doplňte do administrace další akci (např. změna pořadí produktů) a ošetřete ji vhodným oprávněním • aplikujte na dříve vytvořenou komponentu článků vhodná administrátorská oprávnění • pro zájemce:vytvořte vlastní autentifikační adaptér pro čtení identit ze souboru vycházející ze Zend_Auth_Adapter_Interface • pro zájemce: zkuste nasimulovat některý z představených bezpečnostních problémů

4IT445 – Bezpečnost