Tato stránka se Vám pokusí nastínit nejčastější rizika webových aplikací (řazeno od nejzávažnějších), který vyšly z analýz dle OWASP pro rok 2013.

1. Injection (SQL, OS, LDAP, XML...)

   Jedná se o bezpečnostní mezeru, kdy jsou aplikací zpracovávána data (ať už od uživatele, různých importů apod.), u kterých nedochází ke kontrole jejich validity. Útočník tak může získat přístup k datům, na která nemá oprávnění nebo dokonce přístup k celé databázi, nad níž může provádět libovolné operace. Útočník by si mohl vypsat z databáze např. seznam všech registrovaných uživatelů, včetně jejich osobních údajů, což jsou velmi citlivé informace, které je třeba patřičně chránit.

2. Broken Authentication and Session Management

   Správa a přihlašování uživatelů je velmi důležitá oblast, která se dotýká všech aplikací, do nichž se přihlašují uživatelé, ať už registrovaní z internetu, či administrátoři za účelem správy systému nebo obsahu. Do této oblasti můžeme zahrnout přihlašování uživatelů, změnu hesla, získání zapomenutého hesla, funkci pamatování hesla, zamykání účtů, aktulizaci osobních údajů uživatele apod. Je důležité mít v aplikaci všechny tyto akce a kroky řádně navržené a bezpečně implementované. Pokud v některém kroku útočník objeví chybu, může se stát, že si tzv. přivlastní identitu uživatele. To znamená, že se bude moci přihlásit jako uživatel, kterému byla identita zcizena, aniž by znal uživatelské jméno nebo heslo daného uživatele. Navíc se o tom uživatel ani administrátor nemusí dozvědět.

3. Cross-Site Scripting (XSS)

   Díky této zranitelnosti dokáže útočník vložit do stránky nebezpečný kód, poškodit zobrazovanou stránku nebo v horším případě vylákat z uživatele jeho přihlašovací údaje do aplikace. To může útočník provést např. tím, že na stránce zobrazí uživateli falešné přihlašovací okno, které místo přihlášení uživatele zašle jeho přihlašovací údaje přímo útočníkovi. Je proto důležité, aby Vaše aplikace důsledně ověřovala veškerý vstup od uživatele a limitovala tak tento typ útoku.

4. Insecure Direct Object References

   Určitě máte ve Vaší aplikaci různé úrovně oprávnění uživatelů, např. registrovaného uživatele, který má omezené funkce a práva a administrátora, který má přístup ke správě celé aplikace. Je důležité, aby aplikace striktně rozlišovala úroveň oprávnění přihlášeného uživatele a ověřovala tuto úroveň při přístupu ke konkrétním datům. Přihlášený uživatel se např. nachází na stránce, která má URL http://<domena_aplikace>/uzivatel/6542 a zobrazuje Vaše osobní data. Co se stane, když na konec URL zadáte místo čísla 6542 číslo 6541? Může se klidně stát, že se dostanete na stránku s osobními údaji uživatele, který byl do systému registrován před Vámi nebo dokonce budete jeho osobní údaje moci změnit. To se stane v případě, když aplikace nebude striktně ověřovat úroveň oprávnění přihlášeného uživatele vůči datům, které se chystá uživatel zobrazit.

5. Security Misconfiguration

   Tyto zranitelnosti se týkají špatného nastavení systému, neaktualizovaného SW a mohou se objevit jak na úrovni aplikace samotné tak na úrovni prostředí, ve kterém je aplikace provozována (služby provozovatele aplikace, hosting). Jste si jisti, že se ve Vaší aplikaci nenachází účet s uživatelským jménem „test” a heslem „Heslo123”? V aplikacích se často při jejím vývojí nachází testovací účty s jednoduchými přihlašovacími údaji nebo funkce, které slouží jako testovací a ověřovací při vývoji aplikace. Často se však stává, že při nasazení aplikace do ostrého provozu nejsou tyto testovací účty a funkce z aplikace odstraněny a poskytují tak útočníkovi snadný způsob průniku do aplikace. V oblasti infrastruktury se může jednat o nezměněné výchozí přihlašovací údaje k administrátorským účtům, síťovým prkvům apod. V různých zařízeních pak zůstávají účty jako je uživatelské jméno „admin” nebo „root” a heslo „admin”. Schválně - kolikrát už jste se setkali s tím, že někdo má na svém domacím routeru/NAS přihlašovací jméno a heslo nastavené výrobcem?

6. Sensitive Data Exposure

   Pokud Vaše aplikace uchováva citlivá data uživatelů, jako např. čísla platebních karet, smluv apod., je prakticky povinnost používat k přenosu dat šifrovaný kanál. U webových aplikací se jedná o použití SSL (https protokolu), které zajistí, že přenášená data nelze útočníkem odposlechnout. Pokud aplikace nepoužívá šifrování, pak je snadné např. při přihlašování uživatele zachytit jeho uživatelské jméno a heslo a získat tak přístup do aplikace. Dnešní trend je všude být online a tak se uživatelé do aplikací přihlašují např. z různých wifi sítí, u kterých ani netuší, kdo je provozuje a tedy kdo může sledovat jejich pohyb na internetu a přenášená data.
   Další důležitou věcí je správné uchovávání citlivých údajů uživatelů, např. jejich hesel. Uživatelé často používají stejná hesla do různých systémů a aplikací. V případě napadení Vaší aplikace by tak útočník mohl získat hesla i do jiných systémů uživatele. Je proto důležité hesla uživatelů v aplikaci vůbec neukládat a namísto toho ukládat jejich tzv. otisk (hash). Avšak někdy i to nemusí stačit. Výkon počítačů se neustále zvyšuje a tak dnes není problém prolomit šifrování, které ještě nedávno bylo dostačující. Pokud provozujete starší aplikaci, je velmi pravděpodobné, že nevyhovuje dnešním bezpečnostním standardům a měla by být podrobena penetračním testům.

7. Missing Function Level Access Control

   Tato bezpečnostní mezera umožňuje útočníkovi vykonat akce, na které by jinak potřeboval patřičnou úroveň oprávnění. Administrátor má v aplikaci např. tlačítko zakládající nového uživatele. Po stisknutí tlačítka aplikace na server zašle požadavek na adresu http://<domena_aplikace>/zalozUzivatele a připojí k požadavku (POST) uživatelské jméno, heslo nového uživatele a roli uživatele (např. admin). Co se však stane, pokud aplikace neověří, zda má přihlášený uživatel právo přidávání uživatelů? Nového uživatele bude moci založit i útočník, který může být v systému přihlášen jako registrovaný uživatel nebo dokonce nemusí být přihlášený vůbec a získá tak neoprávněný přístup do aplikace.

8. Cross-Site Request Forgery (CSRF)

   CSRF útok probíhá tak, že útočník donutí uživatele vykonat požadovanou akci. Často se tak stává zasláním odkazu např. v emailu, který budí dojem, že ho zaslal administrátor a požaduje např. kliknutí na odkaz, aby se ověřila aktivita účtu uživatele apod. Zaslaný odkaz je však předem vykonstruovaný tak, aby provedl akci, kterou útočník požaduje. Uživateli se po kliknutí na odkaz otevře internetový prohlížeč, který danou akci vykoná. Uživatel se mohl do aplikace přihlásit ještě před otevřením emailu nebo používá funkci Zapamatovat heslo a je tedy v době vykonání akce útočníka v aplikaci přihlášený.  Má tedy přístup k datům a funkcím, které patří pouze jemu. Útočník si tak může nechat citlivá data zaslat k sobě na server nebo změnit údaje uživatele apod.

9. Using Components with Known Vulnerabilities

   Téměř nikdo dnes nevytváří celou aplikaci od základů sám, ale používá ve své aplikaci různé knihovny, frameworky, či celé opensource systémy apod. Mnoho vývojářů se však nestará o to, jakou verzi do aplikace nasadí a vystačí si s tím, že komponenta funguje. Problém však nastane ve chvíli, kdy se v komponěntě, kterou aplikace používá, objeví bezpečnostní chyba. Tyto chyby bývají zveřejněny a popsány, takže pro útočníka není problém takovou chybu zneužít.

10. Unvalidated Redirects and Forwards

    Aplikace často používají přesměrování uživatele např. do nějaké své sekce nebo jiné stránky. Pokud je přesměrování provedeno na základě parametru v URL, např. http://<domena_aplikace>/?redir=admin.example.com, měla by aplikace prověřit cíl přesměrování a tyto cíle omezit pouze na vybrané a žádoucí. V opačném případě může útočník podstrčit uživateli odkaz, který ho přesměrovává na jeho podvodný web, který může vypadat stejně jako původní aplikace a uživatel tak nemusí na první pohled nic poznat. Po přihlášení uživatele pak útočník získává jeho přístupové údaje.