Ing. Jan Mittner

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

 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.  3

 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

 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“  5

 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.  6

 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   lze to řešit i jinak (jako Zend_Controller_Action_Helper) 7

 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ů   8

 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ů  b.adapter.quoting.quote b.adapter.quoting.quote   9

 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  ments.hash ments.hash  

 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

 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

 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