Ing. Jan Mittner 3.11.2011. 1. Autentizace 2. Pluginy 3. Autorizace 4. Útoky 2.

Prezentace na téma: "Ing. Jan Mittner 3.11.2011. 1. Autentizace 2. Pluginy 3. Autorizace 4. Útoky 2."— Transkript prezentace:

1 Ing. Jan Mittner 3.11.2011

2 1. Autentizace 2. Pluginy 3. Autorizace 4. Útoky 2

3  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 http://framework.zend.com/manual/en/zend.auth.html 3

4  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. 4

5  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 rainbow tables:  útok využívající již předpočítaných tabulek „hash – heslo“  http://www.phpguru.cz/clanky/soleni-hesel http://www.phpguru.cz/clanky/soleni-hesel 5

6  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 http://devzone.zend.com/article/3372 6

7  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 http://framework.zend.com/manual/en/zend.acl.html  lze to řešit i jinak (jako Zend_Controller_Action_Helper) 7

8  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://framework.zend.com/manual/en/zend.view.scripts.html#zend.view.scripts.escaping  http://cs.wikipedia.org/wiki/Cross-site_scripting http://cs.wikipedia.org/wiki/Cross-site_scripting 8

9  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.d b.adapter.quoting.quote http://framework.zend.com/manual/en/zend.db.adapter.html#zend.d b.adapter.quoting.quote  http://framework.zend.com/manual/en/zend.db.statement.html http://framework.zend.com/manual/en/zend.db.statement.html  http://cs.wikipedia.org/wiki/SQL_injection http://cs.wikipedia.org/wiki/SQL_injection 9

10  cross-site request forgery (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 autentifikaci cookies 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í hash token nebo captcha ochranu  http://framework.zend.com/manual/en/zend.form.standardElements.html#zend.form.standardEle ments.hash http://framework.zend.com/manual/en/zend.form.standardElements.html#zend.form.standardEle ments.hash  http://framework.zend.com/manual/en/zend.captcha.html http://framework.zend.com/manual/en/zend.captcha.html  http://php.vrana.cz/cross-site-request-forgery.php http://php.vrana.cz/cross-site-request-forgery.php 10

11  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

12  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

13  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ů 13