Penetrační testování webových aplikací

Penetrační testování

Penetrační testování (anglicky Pentration Testing, nebo také Pentesting) je jeden z bezpečnostních procesů, který se pokouší o zlepšení celkové bezpečnosti testovaného aktiva (např. serveru). Penetrační testování může probíhat nezávisle, nebo se může jednat o část bezpečnostního procesu, který je součástí Software Development Life Cycle (SDLC). Účelem penetračního testu je pokus o získání přístupu k cílovému aktivu, bez požadovaného oprávnění – tedy pokusit se najít chybně implementované ochranné mechanismy, nebo potencionální bezpečnostní rizika dříve, než je někdo zneužije ke škodlivé činnosti. Aby se jednalo o penetrační test, nikoliv kybernetický útok, tester musí mít předem povolení od vlastníka cíleného aktiva. Jediným rozdílem mezi penetračním testem a reálným útokem je tedy povolení na cíl útočit.

V průběhu penetračního testu mohou být použity veškeré součásti IT infrastruktury, jako jsou aplikace, operační systémy, síťová zařízení, komunikační média a tak dále. To však neznamená, že se testování omezuje pouze na hardware a software, může zahrnovat i prvky psychologie, použité na pracovníky cílené společnosti, ve snaze získat nějaké cenné informace, které by testerovi pomohly k proniknutí do systému. Těmto prvkům útoků se také říká sociální inženýrství. Simulace reálného útoku je součástí penetračního testování, ale není to zdaleka jediná část. Tester svůj cíl analyzuje, vyhodnocuje potencionální hrozby a ty se následně snaží zneužít. Je očekáváno, že si tester v průběhu celého penetračního testu bude dělat důkladné poznámky, které vyústí ve výsledný report o stavu testovaného cíle. Je důležité si uvědomit, že i po kvalitně provedeném penetračním testu může cíl testování zůstat zranitelný. Je vcelku nepravděpodobné, že penetrační test odhalí všechny zranitelnosti. I kdyby se tak stalo, bezpečnost u software může být velmi proměnlivá – stále jsou objevovány nové zranitelnosti, jsou vydávány záplaty a nové verze, které s sebou mohou nést nové zranitelné prvky.

Terminologie

S okruhem penetračního testování je spojeno několik pojmů, které by bylo lepší si vyjasnit hned na začátku, aby se uprostřed textu neobjevovaly krkolomné vysvětlivky pojmů a aby se ustálily výrazy, které se budou v této práci používat.

Aktiva – Assets Pokud budeme hovořit o aktivech, jedná se o nějakou součást IT infrastruktury, která by měla být chráněna tak, aby s ní nikdo neoprávněný nemohl manipulovat. Nejčastěji se bude jednat o nějaké aplikace, data či zařízení.

Útok – Attack Útok na IT infrastrukturu za účelem získání přístupu k aktivům, vytvoření škody, či znemožnění správné funkčnosti služby.

Zranitelnost – Vulnerability Zranitelnost může být definována jako chyba, nebo slabina, s jejíž pomocí lze získat neoprávněný přístup k aktivům. Úspěšné zneužití zranitelnosti může vést k manipulaci s daty, které by neměly být dostupné.

Hrozba – Threat Hrozba představuje možné nebezpečí hrozící aktivům. Může se jednat o potencionální možnost útoku – tedy zneužití nějaké zranitelnosti.

Dopad – Impact Reprezentuje možný rozsah a typ škod na aktivech, ke kterým se útočníkovi podařilo získat přístup.

Riziko – Risk Existující hrozba představuje jisté riziko – tedy pravděpodobnost zneužití zranitelnosti. Riziko je také závislé na závažnosti této zranitelnosti. Vyhodnocení rizika pak může být definováno takto:

Riziko = Hrozba * Zranitelnost * Dopad

Exploit – Exploit Může se jednat o program, nebo sekvenci příkazů, která využívá určité zranitelnosti ke způsobení původně nezamýšlené činnosti – obvykle se jedná o ovládnutí systému, jinak nepovolenou instalaci software, či zvyšování oprávnění.

White Hat Někdy také nazýván Ethical Hacker. Jako tento typ hackera je často označován profesionál na poli IT bezpečnosti. Jedná se o člověka, zaměřujícího se na penetrační testování a další testy zajišťující bezpečnost v IT odvětví.

Black Hat Tento typ hackera je přesně to co si většina lidí pod slovem hacker představí. Jedná se o osobu, která zneužívá své znalosti k nelegální činnosti – útokům na servery, krádežím dat a podobně. V textu referován také jako útočník.

Gray Hat Tímto termínem je označován hacker, stojící na pomezí mezi white a black hat. Může to být například bezpečnostní specialista, který vystupuje jako white hat hacker, ale někdy porušuje etické zásady a principy – většinou však bez úmyslu škodit.

Blacklisting Jedná se o typ validace vstupu, kde se filtrují potencionálně nebezpečné znaky a známé útočné řetězce jako <script>.Obecně tato metoda validace není doporučena, protože se může na něco zapomenout a validace je tak nefunkční.

Whitelisting Uživatelem zadané vstupy se validují oproti očekávaným hodnotám (například regulárním výrazům). Hodnoty, které nesplňují podmínky whitelistu nejsou přijaty

Hodnocení zranitelností – Vulnerability Assessment Tento pojem bývá někdy zaměňován s penetračním testováním. Oba bezpečnostní procesy obsahují shromažďování informací, skenování a vyhodnocení nalezených zranitelností. A po tomto bodu se však rozcházejí – penetrační testování totiž obsahuje i fázi exploitování, kdy se snaží o reálnou kompromitaci systému, což součástí hodnocení zranitelností není.

Kategorie penetračního testování

Když je definován rozsah penetračního testu, definuje se i to, jakým způsobem se bude k testování přistupovat a co konkrétně se bude testovat. Podle možnosti přístupu jsou tu tři kategorie – Black Box, White Box a Gray Box, v závislosti na tom, co má test reprezentovat.

• Black Box – U Black Box penetračního testu je testerovi zděleno jen velmi málo informací o testovaném aktivu. V případě testování, kdy se má tester zaměřit na síťovou infrastrukturu testované společnosti, jedinou věcí, kterou bude tester na začátku testování vědět je rozsah IP adres, které má testovat. Pokud by se tedy jednalo o testování webové aplikace, tester opět dostane pouze adresu webu a žádné zdrojové kódy aplikace poskytnuty nebudou. Může se tak jednat o cílenou simulaci reálného útoku. Tento kategorie je velmi častá, jestliže se jedná o externí testování.

• White Box – White Box penetrační testování je přesným opakem Black Box kategorie. Testerovi jsou poskytnuty téměř všechny informace o testovaném cíli. To znamená, že v případě testování síťové infrastruktury jsou testerovi poskytnuty konkrétní adresy, operační systémy, na nich bežící služby s příslušnými verzemi a tak dále. U testování webové aplikace je poskytnut i samotný zdrojový kód, což umožňuje statickou i dynamickou analýzu zdrojového kódu. Tato kategorie je častá u interního penetračního testování.

• Gray Box – Jedná se penetrační testování, které stojí mezi Black Box a White Box testováním. Některé informace jsou testerovi poskytnuty, jiné zůstávají skryté. V případě testování webové aplikace tester dostane adresu webu a může dostat například jména uživatelských účtů. Tato kategorie testování může simulovat situaci, kdy uniknou určitá data na internet.

Typy penetračních testů

U penetračního testování musí být jasně specifikováno, co přesně se bude testovat a co už testu podléhat nebude. Tedy vytyčit nějaké hranice, které by tester neměl překročit. Je mnoho typů testování, avšak tyto jsou prováděny nejčastěji:

• Network Penetration Test V tomto typu penetračního testu se testuje infrastruktura počítačové sítě, neobsahuje-li zranitelnosti či potencionální bezpečnostní hrozby. Tento typ penetračního testu je možné dále rozdělit do dvou kategorií a to externí a interní testování. Externí – testerovi je poskytnut rozsah veřejných IP adres (popřípadě jedna adresa), které se budou testovat. Cíl testování je volně přístupný komukoliv z internetu. Interní – testerovi může být poskytnut přístup do firemní sítě přes VPN, nebo může testování probíhat přímo v místě určení, kde se tester bude připojovat do interní sítě testované společnosti například přes Wi-Fi.

• Web Application Penetration Test Dnes velmi běžné testování. Jak se rozšiřuje využití webových aplikací, které ukládají citlivá data uživatelů, je potřebné i jejich bezpečnostní testování. K tomu slouží právě tento typ penetračního testu, kdy tester může dostat pouze informace ve formě URL adresy webové aplikace v případě Black Box testu, nebo i zdrojové kódy aplikace a další informace ve formě White Box testu.

• Mobile Application Penetration Test Penetrační testování mobilních aplikací je jeden z novějších typů testů, avšak stejně důležitý jako jakýkoliv jiný. Mobilní zařízení se systémy Android, iOS, případně jinými jsou dnes často využívané jak ve firemním prostředí, tak pro osobní účely. Je tedy vhodné zajistit jak operačním systémům, tak i jejich aplikacím, pracujícím s citlivými daty, co nejlepší stupeň bezpečnosti, k čemuž může penetrační testování pozitivně přispět.

• Social Engineering Penetration Test Sociální inženýrství může být penetračním testem samo o sobě, nebo může být součástí jiného testování. V takovém případě se tester nesnaží zneužít slabin systému, ale jeho uživatelů, například pomocí útoku spear phishing

• Physical Penetration Test Asi nejméně častý způsob (ale stejně důležitý) penetračního testování, kdy je tester dotázán, aby se dostavil přímo do budovy testované společnosti. Hlavním cílem je otestovat fyzické bezpečnostní mechanizmy (zámky, senzory, kamery a jiné) a odhalit jejich slabá místa dříve, než tyto slabiny zneužije nějaká neautorizovaná osoba.

Standardy a metodologie

Pro potřeby bezpečnostního testování byly vytvořeny různé otevřené standardy a metodologie. Těchto standardů existuje celá řada, podílí se na nich jednotlivci, několika členné týmy či dokonce celé organizace. Od počtu osob se také odvíjí komplexnost jednotlivých standardů. V této sekci budou popsány jen některé z těch nejznámějších. Metodologie můžeme chápat jako definované sady pravidel a postupů, podle kterých by se měl celý proces testování řídit. Jedná se tedy o plán s praktickými návrhy a prokázanými praktikami, jejichž dodržováním je možné vyhodnotit bezpečnostní stav počítačové sítě, webové aplikace, serveru, nebo čehokoliv co podléhá bezpečnostnímu testování. Existuje několik organizací, které takovéto metodologie vyvíjejí a udržují. Všechny metodologie se od sebe navzájem v jistých bodech liší. Při jejich volbě je tedy potřeba přesně stanovit, co je od testování očekáváno, a následně si zvolit takovou metodologii, která bude stanovenému cíli nejlépe vyhovovat. Každé dobré penetrační testování by se mělo nějakou metodologií řídit. Poskytuje to značné výhody k pochopení a analýze jednotlivých zranitelností a obranných prostředků pro každou fázi testovacího procesu.

V této sekci je představeno několik dobře známých metodologií, u kterých budou vyzdviženy jejich klíčové vlastnosti a výhody použití, avšak k opravdu dobrému pochopení různých metodologií, je doporučeno nahlédnout do oficiálních dokumentací, které jsou dostupné na příslušných webových stránkách. Metodologie však nejsou jedinými standardy v této oblasti. Tak jako postup testování tak i samotné útoky a zranitelnosti, které se testují je nutné zařadit do určitého neměnného standardu. Nejznámějšími takovými standardy jsou projekty od společnosti Mitre, které se zabývají právě standardizací objevených zranitelností a útoků na ně. Další formou standardu, která určitě stojí za zmínění, jsou takové standardy, které umožňují vyhodnotit určitá rizika a závažnost nalezených zranitelností.

Information Systems Security Assessment Framework

ISSAF je často zmiňovaný strukturovaný rámec (framework), který kategorizuje testování bezpečnosti informačních systémů do několika oblastí, u kterých detailně specifikuje testovací kritéria. Rámec ISSAF je vytvořený a udržovaný neziskovou organizací Open Information Systems Security Group (OISSG), kde se rozhodli, neomezovat jejich materiály jakýmikoliv poplatky. Rámec ISSAF by měl být použit primárně pro testování bezpečnosti, ale může být využit i jako referenční materiál pro meetingy, konference a jiné potřeby v oblasti informační bezpečnosti. Informace v rámci ISSAF jsou organizovány do dobře definovaných testovacích kritérií, kde každé z nich bylo revidováno experty v dané oblasti. Mezi tato kritéria patří:

• popis kritérií pro testování, • cíle a záměry, • vstupní předpoklady pro provedení testu, • proces testování, • zobrazení očekávaných výsledků, • doporučené protiopatření, • reference a externí dokumenty.

Celkově je rámec velmi rozsáhlý a podrobný, protože se autoři snažili poskytnout co nejvíce informací. Hlavním důvodem je myšlenka, že je pro uživatele jednodušší materiál nevyužít, než jej sám vymýšlet. ISSAF metodologie pro penetrační testování je navrhnuta tak, aby umožňovala pokrýt všechny možné typy penetračního testování od začátku až ke konci testu. Testování se skládá ze tří hlavních fází dohromady o devíti krocích.

1. Plánování a Příprava 2. Testování 3. Reportování a úklid stop

První fáze popisuje kroky při výměně počátečních informací se zákazníkem, plánování a přípravu na testování. Kroky, ze kterých se skládá (druhá) testovací fáze jsou na obrázku 2. Třetí fáze popisuje vytváření reportu a úklid po ukončení testování. Pokud úklid není možné provést vzdáleně, je nutné o veškerých provedených změnách a přidaných souborech napsat do reportu, aby tyto změny mohly být opraveny příslušnými pracovníky.

Open-Source Security Testing Methodology Manual

OSSTMM poskytuje metodologii pro důkladné bezpečnostní testování, referované jako OSSTMM audit. Aktuální vydání je 3.0, to bylo zveřejněno v prosinci roku 2010. Pro přístup k novějšímu vydání je však zapotřebí prémiového účtu. Hlavní myšlenkou za tvorbou OSSTMM bylo poskytnout vědeckou metodologii pro přesnou charakteristiku operační bezpečnosti, skrze zkoumání a porovnávání výsledků testů v konzistentní a spolehlivé formě. A také poskytnutí příručky, podle které mohou bezpečnostní testeři a analytici uskutečnit certifikovaný OSSTMM audit. Manuál je možné použít na různé druhy bezpečnostního testování včetně penetračního testovaní, vyhodnocení zranitelností, či jiných. Neomezuje se pouze na jeden typ testovaného odvětví, je možné pomocí něj testovat fyzickou bezpečnost, síťovou infrastrukturu, nebo různé systémy či aplikace.

Metodologie udává určitou příručku, ve které jsou uvedeny body, které by měly být otestovány. Neudává však přesně způsob jejich kontroly (nástroje ani metody), to je přenecháno bezpečnostnímu testerovi. Na rozdíl od rámce ISSAF, nebo metodologie OWASP zde nejsou uvedené praktické příklady, nebo poukázání na konkrétní chyby, jsou zde uvedeny pouze oblasti testování. Metodologie určuje šest typů přístupu viz. obrázek 3. Přístupy se rozlišují pomocí dvou kriterií. První je počet informací, které má tester o aktivu k dispozici. A druhé je vědomí personálu, že bude testování probíhat.

Při použití OSSTMM pro testování je potřeba zaznamenávat co se testuje, jak se to testuje, co se podařilo díky testům najít a co se vůbec netestovalo. Důvodem celého zaznamenávání je psaní reportu, který udává přesné dotazy na průběh testu. Tento report je nazýván Security Test Audit Report (STAR).

Open Web Application Security Project

OWASP se od jiných metodologií (ISSAF, OSSTMM) liší hlavně tím, že se specializuje na testování webových aplikací. Účelem projektu OWASP je sesbírat co nejvíce testovacích technik, ty vysvětlit a udržovat jejich aktuální stav. OWASP Testing Guide je manuál, který obsahuje téměř vše, co je potřeba k otestování bezpečnosti webové aplikace. Je rozdělen do tří částí – The OWASP Testing Framework, Web Application Security Testing a Reporting. V první části je kladen důraz na zahrnutí bezpečnostního testování už v SDLC. Je doporučené testovat v každé fázi vývoje aplikace (define, design, develop, deploy, maintain). Což je jedna z dalších věcí, čím se OWASP liší od ostatních standardů. Ve druhé části je popsána metodologie pro penetrační testování. Testovací metodika OWASP je založena na Black Box přístupu k testování (ačkoliv s v dokumentaci objevují i případy, kdy se popisuje postup pro White Box a Gray Box přístupy). Tato metodologie se dělí na dvě hlavní části.

Fáze 1 – Pasivní mód V této fázi se tester snaží pochopit aplikační logiku testované aplikace. Používají se zde hlavně nástroje pro sběr informací (information gathering). Například může být použita HTTP proxy, přičemž tester může sledovat jak vypadají dané HTTP požadavky a odpovědi (requests and responses). Při dokončení této fáze testovaní, by měl tester chápat všechny přístupové body aplikace (HTTP hlavičky, parametry, cookies).

Fáze 2 – Aktivní mód V této fázi začíná penetrační testování podle OWASP metodologie s aktivním využitím různých nástrojů a technik, které zkouší odhalit známé zranitelnosti. Aktivní fáze se skládá z jedenácti podkategorií:

• určení cílů testování, • testování konfigurace a správy nasazení, • testování správy identity, • testování autentizace, • testování autorizace, • testování správy sezení, • testování validace vstupů, • testování řešení výjimek, • testování slabé kryptografie, • testování aplikační vrstvy, • testování na straně klienta.

Provedení testování je pouze polovinou z celkového procesu. V poslední části této dokumentace je popsáno, jak by se měl správně sepsat report o testování. OWASP mimo svůj Testing Guide nabízí i shrnutí TOP 10 [11], které se skládá z deseti zranitelností, vyhodnocených jako nejkritičtější v oblasti webových aplikací. Není to pouze list, který tyto zranitelnosti vyjmenovává, ale jedná se i o vysvětlení jak fungují, proč jsou do seznamu zařazené a jak je testovat, případně i opravit. Součástí projektu OWASP jsou i nástroje, vytvořené samotnou komunitou. To však neznamená, že by se měly používat pouze a právě tyto nástroje, což cílem OWASP projektu ani není. Odkazují se na velké množství jak už open-source tak komerčních nástrojů třetích stran.

Penetration Testing Execution Standard

Penetration Testing Execution Standard (PTES) je standard pro penetrační testování, skládající se ze sedmi hlavních částí. Ty pokrývají všechny důležité informace, týkající se penetračního testování – od zahájení komunikace se zákazníkem, přes sběr informací, až do vytváření reportu o celkovém průběhu testu. Tento standard je možné použít k libovolnému typu penetračního testu (testování síťové, aplikační,. . . ). Každá fáze je velmi dobře a detailně popsaná na oficiálních stránkách. Jednotlivé fáze standardu PTES jsou:

• interakce před začátkem testování, • shromažďování informací, • modelování hrozeb, • analýza zranitelností, • zneužití zranitelností, • po zneužití zranitelností, • reportování.

Tento standard udává vlastní plán, jak při testování postupovat, ale také obsahuje hodně referencí na jiné zdroje, jako třeba OWASP, pro případ testování webových aplikací.

Web Application Security Consortium – Threat Classification

„The Threat Classification je snahou klasifikovat slabiny a útoky, které mohou vést ke kompromitaci webových stránek, jejich dat, nebo uživatelů.” [27] Web Application Security Consortium – Threat Classification (WASC–TC) se stejně jako OWASP soustředí na oblast webových aplikací. Cílem tohoto projektu je společná snaha o zorganizování a vysvětlení zranitelností objevujících se u webových aplikací. Nejedná se přímo o metodologii, která vysvětluje jak postupovat při penetračním testování, ale jde spíše o referenční materiál, který se snaží vysvětlit terminologii, zranitelnosti, typy útoků a odkazuje čtenáře na další dostupné materiály. WASC–TC je zorganizován do tří různých pohledů:

Enumeration View – Tento pohled poskytuje přehled o nejčastějších útocích a zranitelnostech týkajících se webových aplikací. Každý z těchto útoků a zranitelností je samostatně rozebrán a společně s praktickým příkladem vysvětlen.

Development Phase View – Tento pohled byl vytvořen, aby poukázal, kde v SDLC je pravděpodobné, že se daná zranitelnost vyskytne. Jde tedy o snahu upozornit na určité fáze vývojového procesu, kde je mohou vznikat zranitelná místa v aplikaci. Jako fáze jsou zde uvedeny: návrh, implementace a nasazení. Návrh – Zranitelnosti se vyskytují, když nejsou splněny požadavky na zabezpečení aplikace v počátečních fázích vývoje. Implementace – Zranitelnosti se vyskytují z důvodu, že se nedodržují principy a praktiky bezpečného programování. Nasazení – Zranitelnosti mohou být výsledkem špatné konfigurace aplikace, popřípadě serveru, na který je aplikace nasazená.

Taxonomy Cross Reference View – Tento pohled obsahuje mapování zranitelností a útoků podle různých standardů. Každý z těchto standardů pro bezpečnost webových aplikací je jiný a vyhodnocuje zranitelnosti jinými způsoby, takže se jednotlivá hodnocení mohou lišit. Součástí tohoto mapování jsou: Mitre Common Weakness Enumeration (CWE), Mitre Common Attack Pattern Enumeration and Classification (CAPEC), SANS-CWE top 25 list, OWASP TOP 10 za roky 2010, 2007 a 2004.

Mitre Common Weakness Enumeration

Common Weakness Enumeration (CWE) [28] je komunitou vyvíjený formální seznam softwarových zranitelností v architektuře, návrhu, nebo zdrojovém kódu. Cílem CWE je vytvořit jednotný standard, který pomůže jednoznačně označit a identifikovat jednotlivé zranitelnosti. Díky tomuto standardu je možné se odkazovat na určité zranitelnosti pomocí unikátního CWE-ID. Jednotlivé CWE mají vždy stejnou strukturu popisu zranitelností, o kterých se pojednává. Nejdříve je vysvětleno co si pod názvem zranitelnosti představit – jedná se tedy o stručný slovní popis zranitelnosti. Dále jsou uvedeny CWE skupiny, do kterých zranitelnost patří, popřípadě podobné či související zranitelnosti. Následující části popisu obsahují informace o tom, kde se dané zranitelnosti mohou vyskytovat – u jakých technologií, jaké mohou být následky, pokud je zranitelnost zneužita. Nechybí ani praktické ukázky zranitelných zdrojových kódů (pokud je možné je uvést) a možné způsoby ochrany.

Mitre Common Vulnerabilities and Exposures

Common Vulnerabilities and Exposures (CVE) [29] je podobně jako CWE formální seznam softwarových zranitelností udržovaný společností Mitre. Položky CVE se skládají z identifikačního čísla (CVE-ID), popisu a alespoň jednoho veřejného odkazu. Na rozdíl od CWE se ale nejedná o obecný popis zranitelností, ale váže se na určitou technologii, produkt, či systém.

Mitre Common Attack Pattern Enumeration and Classification

Cílem Common Attack Pattern Enumeration and Classification (CAPEC) [30] je poskytnout veřejně dostupný katalog známých postupů útoků (attack pattern), spolu s komplexním schématem popisujícím související útoky. Postup útoku je prezentován jako abstraktní mechanismus, na kterém je popsáno a vysvětleno jak je útok na zranitelný systém či síť proveden. V každém CAPEC záznamu jsou definovány problémy, kterým útočník může čelit a s tím související doporučené metody, jak se reálnému útoku bránit. Projekt CAPEC pomáhá útoky kategorizovat smysluplným způsobem ve snaze poskytnout materiály, které mohou vývojářům pomoci pochopit způsob, jakým může být jejich systém napaden a jak se proti němu mohou efektivně bránit. Na rozdíl od standardů CVE a CWE se jedná o seznam nejběžnějších metod použitých při útocích na zranitelná místa, kdežto dva dříve zmiňované standardy popisují právě zranitelná místa, na které jsou útoky prováděny. Společné použití standardů CWE a CAPEC může poskytnout objasňující a pomocný materiál pro vývoj a úpravu vyvíjeného software.

Common Vulnerability Scoring System

Common Vulnerability Scoring System (CVSS) [31] je otevřený, volně dostupný standard, poskytující způsob pro posouzení závažnosti bezpečnostních zranitelností softwaru na základě jejich základních charakteristik. Výsledkem procesu je číselné skóre posuzované zranitelnosti, to pak může být překládáno do kvalitativní reprezentace. Použití CVSS přináší hned několik výhod jako je standardizované hodnocení zranitelnosti – tento systém hodnocení se dá využít na všech IT platformách od aplikací po celé operační systémy. Navíc díky využití tohoto standardu je jasně vidět jak se k výslednému hodnocení dospělo. Při porovnání jednotlivých CVSS skóre je pak možné nalézt rizika, která jsou prioritní. Skóre se počítá podle tří metrik – Base, Temporal, Environmental. Každá metrika se dále dělí na několik komponent, podle kterých se výsledná závažnost určuje.

• Base – tato metrika reprezentuje vnitřní charakteristiku zranitelnosti, které jsou neměnné v průběhu času a nejsou závislé na uživatelském prostředí. Dále se dělí na Exploitability a Impact metriky. Exploitability metriky zastupuje složitost a technické prostředky, které jsou nutné ke zneužití zranitelnosti. Impact metriky představují následky, které by mohly nastat v případě úspěšného zneužití zranitelnosti.

• Temporal – položky v těchto metrikách jsou reprezentovány charakteristiky zranitelnosti, které se mohou v čase měnit a přitom nezáleží na prostředí ve kterém se zranitelnost vyskytuje (operační systém, verze software). Záleží na tom, jestli pro danou zranitelnost existuje použitelný nástroj pro zneužití (exploitability) zranitelnosti, jsou-li vydané záplaty, které funkci takového nástroje znemožňují a podobné, v čase se měnící okolnosti.

• Environmental – tyto metriky jsou reprezentací charakteristik, které jsou unikátní v konkrétním uživatelském prostředí. Může se například jednat o zranitelnost v určitém operačním systému. Pokud tento operační systém není v daném prostředí používán, nebo je konfigurován jiným způsobem, než se uvádí v popisu zranitelnosti, je možné, že se zranitelnost na dané prostředí vůbec nemusí vztahovat. Mohou tedy existovat dvě společnosti, které čelí stejné zranitelnosti, ale protože každá z těchto společností využívá jiný hardware a software, finální skóre této metriky může být naprosto odlišné.

Pro použití kalkulátoru, jehož ukázka je na obrázku 4, existuje uživatelský manuál, který obsahuje dobře popsaný postup, podle jakých kritérií se zranitelnost vyhodnocuje. Finální skóre se dělí do několika kategorií dle závažnosti, jakou zranitelnost představuje – ty jsou uvedeny v tabulce 1.

Vyhodnocení standardů

V průběhu zpracování diplomové práce byly identifikovány tyto standardy:

Jak lze vidět v tabulce 2, standardů existuje hned několik. Některé se zabývají postupy při bezpečnostním testování, jiné zase identifikací a hodnocením zranitelností. V této chvíli jsou však podstatné ty, které určují postupy bezpečnostního testování. Všechny zmiňované testovací standardy popisují celé procesy bezpečnostního testu, které mohou být velice zdlouhavé, pokud by se měla striktně dodržovat testovací osnova. Je tak vcelku pochopitelné, že tyto standardy menšími firmami nemusejí být vhodným materiálem pro účely testování bezpečnosti. Všechny zmíněné standardy mají v oblasti penetračního testování své místo a každý vyniká v jiných podmínkách. Ale z důvodu jejich komplexnosti se příliš nehodí pro testování malých a jednoduchých projektů.

Výhody a nevýhody penetračního testování

Robustní ochrana aktiv může být udržována na dobré úrovni jen tak dlouho, dokud je na ni vyvíjen neustály tlak. Jedině tím se dá zaručit eliminace nových zranitelností a posunovat úroveň zabezpečení stále kupředu (nebo ji alespoň udržovat na stejné úrovni). Penetrační testování má řadu výhod, ale tak jako vše, má i jisté nevýhody. Je tedy na uváženou, jestli je penetrační testování to pravé, nebo je lepší zvolit nějakou jinou možnost, jak se zasloužit o zlepšení bezpečnosti aktivu. Zde je uvedeno několik pozitivních i negativních faktů, které penetrační testování provázejí.

Výhody

• Identifikace zranitelných míst. Jeden z hlavních důvodů, proč se penetrační testování provádí, je nalezení a opravit zranitelnosti aktiva.

• Ukázka reálného útoku. Umožňuje prozkoumat reálná rizika, která aktivům hrozí. Napomáhá získat lepší představu o jejich zabezpečení a efektivnosti obranných mechanismů.

• Může sloužit jako tréning pro IT oddělení. Vyhodnocení odolnosti pracovníků na sociální inženýrství a reakce schopnosti v případě bezpečnostních incidentů.

• Testování aktiva do hloubky. Tester se snaží chovat jako útočník, používá stejné nástroje a taktiky. Může tak najít i zranitelnosti, které automatizované nástroje neodhalí.

• Specifické rady k zabezpečení. Posledním krokem v penetračním testování je reporting, který by měl podávat konkrétní informace o konkrétních chybách. Na rozdíl od automatizovaných nástrojů, které jsou většinou schopny vygenerovat jen obecné tipy.

• Zachování dobrého jména společnosti. Představte si, že jste provozovatel e-shopu a objeví se zprávy o tom, že vaše servery byly napadeny hackery a uživatelská data unikla na internet. Pokud by se něco takového prokázalo, mělo by to na jméno společnosti devastující dopad.

• Prevence datových a finančních ztrát. Společnosti mají svůj byznys založený na práci s daty. Při průniku do webové aplikace mohou být data ukradena, popřípadě úplně ztracena, což může mít negativní dopad na fungování firmy.

Nevýhody

• Pokud testování není provedeno správně, může napáchat velké škody. Testy, které jsou špatně naplánovány, mohou například způsobit pád serveru, nechtěně vystavit citlivé informace veřejnosti, znehodnotit produkční data, nebo jiné nebezpečné záležitosti.

• Je nepravděpodobné, že penetrační test odhalí všechny zranitelnosti a bezpečnostní hrozby. V oblasti IT bezpečnosti je obrovské množství známých zranitelností a nové se objevují každou chvíli. Je tedy vcelku možné, že se na nějakou zapomene, nebo je testování zranitelnost zkrátka neodhalí.

• Kvalitní penetrační testování může být náročné – jak časově, tak finančně. Kvalifikovaných a důvěryhodných profesionálů v této oblasti je jen omezené množství, což se může projevit na ceně penetračního testu. A aby byl test kvalitní, i ti nejlepší testeři potřebují určitý čas na prozkoumání, vyhodnocení a otestování daného aktivu.

• Penetrační testování může dávat falešný pocit bezpečí. To že žádné zranitelnosti nebyly nalezeny, ještě neznamená, že neexistují, respektive, že se všechny nalezené zranitelnosti opravili, ještě neznamená, že neexistují další, nebo opravami nevznikly nové.

• Nerealistické testovací podmínky. Pokud je oddělení, které bude penetračním testem zasaženo, dopředu informováno o této skutečnosti, je mu tak umožněno dobře se na útok připravit, což může výsledné penetrační testování ovlivnit. V reálném případě však hacker zaútočí bez varování.

Penetrační testování webových aplikací

Tato kapitola se věnuje hlavně aktuálnímu stavu na poli bezpečnosti webových aplikací – jaké jsou nejčastější útoky a na jaké zranitelnosti se nejčastěji útočí. V kapitole 5 budou popsány vybrané zranitelnosti a ke každé z nich bude zmíněno několik nástrojů, které se dnes v tomto odvětví často používají.

Stav bezpečnosti na poli webových aplikací

Není vhodné spoléhat se pouze na OWASP TOP 10, SANS-CWE TOP 25, či jiný list zranitelností. Bylo nutné vytvořit vlastní přehled a mít tak kontrolu nad aktuálností dat. Proto došlo k vyhledání několika reportů různých společností, působících na poli počítačové bezpečnosti. Reporty sloužily jako zdroj informací o bezpečnostním stavu webových aplikacích. Cílem bylo získat reporty se statistikami z více zdrojů, aby se daly porovnat a vyhodnotit zranitelnosti, které se objevují nejčastěji a těmi se dále zabývat podrobněji po zbytek této práce. Každá společnost používá jinou metodologii pro získání dat, tak i pro hodnocení rizika daných zranitelností a také se všechny profesně soustředí na něco trochu jiného. Tato fakta je potřeba vzít na vědomí, protože zranitelnosti se svým pořadím v žebříčcích report od reportu liší (mezi společnostmi). Informace o společnostech a metodách použitých ke sběru dat pro jejich reporty lze vyčíst přímo v referovaných materiálech.

Symantec – Internet Security Threat Reports

V roce 2016 se počet útoků na webové aplikace snížil o třetinu oproti roku 2015. Nicméně útoky na webové stránky zůstávají i nadále velkým problémem. Každý den bylo průměrně detekováno kolem 229.000 útoků. Ke snížení počtu útoků sice došlo, ale kolem 76% skenovaných webových stránek stále obsahovalo zranitelnosti (obrázek 5) a u 9% z nich se objevily zranitelnosti kritické (obrázek 6).

Jako kritické zranitelnosti jsou brány ty, které při exploitování útočníkem mohou umožnit spuštění škodlivému kódu bez interakce uživatele, potenciálně mohou vyústit v krádež dat, nebo jinou kompromitaci stránek a jejich uživatelů.

V reportech z předešlých let se hodně diskutovalo o zranitelnostech týkajících se SSL/TLS, což je hlavně zásluha zranitelnosti Heartbleed u knihovny OpenSSL. V roce 2015 se také jednalo o velmi časté zranitelnosti, týkajících se protokolů SSL/TLS 3. Implementace SSL/TLS není jednorázový úkol. Organizace by měly být pro-aktivní co se jejich údržby týče. Aktualizace pro SSL/TLS knihovny jsou vydávány pravidelně, ale majitelé webových stránek je musejí stále instalovat. Protokoly SSL/TLS zůstávají centrálními prvky ochrany osobních údajů, autentizace a šifrování na internetu, ale pokud má jejich využití zůstat efektivní, je vyžadována neustálá údržba a ostražitost.

Positive Technologies

Tabulka 4 obsahuje srovnání různých typů útoku dle četnosti, které byly zaznamenány v prvních třech čtvrtletích roku 2017. Data vycházejí z reportů firmy Positive Technologies [34] [35] [36], ta data získala z aplikačních firewallů, které vyvíjejí.

Další srovnání v tabulce 5 pochází už z trochu širšího časového rozmezí a to z let 2014 až 2016. Opět se jedná o množstevní porovnání, tedy které zranitelnosti byly nejčastější. Nejedná se už o data získaná sběrem informací z aplikačních firewallů, ale naopak o data, která firma získala prováděním penetračních testů a různých bezpečnostních auditů. Testování probíhalo pomocí automatizovaných nástrojů tak i manuálního šetření, analýz zdrojových kódů a tak dále (Black, Gray i White Box metody penetračního testování).

V reportech jsou zranitelnosti řazeny do tří kategorií podle závažnosti: vysoká, střední, nízká. Odhad závažnosti byl určen dle Common Vulnerability Scoring System (CVSS v2). Útoky kategorizované vysokou závažností, které se objevovaly i v těchto tabulkách jsou: SQLi, XML External Entities (XXE) a Path Traversal. Z použitých reportů firmy Positive Technologies vyplývá, že je dnes asi největším problémem útok XSS. Nejen že zranitelnost na tento útok byla u testovaných webových aplikací nejčastější, útok XSS útočníci velmi často zařazují mezi své vektory útoků. Dalšími útoky, které dominují v horní polovině tabulky 4 jsou SQLi, Path Traversal, Local File Inclusion a OS Commanding. Všechny zmíněné útoky jsou klasifikovány jako útoky se střední, nebo vysokou závažností. Z tabulky 5 vyplývá, že na právě tyto útoky webové stránky většinou zranitelné nejsou – ale pokud by byly, je vcelku velké riziko, že by byly tímto útokem napadeny.

Acunetix

Firma Acunetix, která vyvíjí scanner zranitelností stejného jména, každým rokem vydává report, obsahující statistiky nejčastěji nalezených zranitelností i s hodnocením jejich závažnosti. Pro tento report, který zahrnuje období let 2016 – 2017, byla využita data z náhodně vybraných skenů 11 600 předplatitelů této služby. Report se převážně zabývá zranitelnostmi webových aplikací se střední, nebo vysokou závažností viz. tabulka 6.

U 50% skenovaných cílů, zahrnutých do tohoto reportu v intervalu let 2016 – 2017, byla objevena zranitelnosti XSS. Což jen potvrzuje fakt, že jsou v oblasti webových aplikací velké nedostatky co se týče bezpečnosti – jedná se totiž o jednu z dobře známých zranitelností, o které se ví mnoho let, ale objevuje se neustále a to s poměrně vysokou četností.

OWASP TOP 10

Cílem projektu OWASP TOP 10 je zvýšit povědomí o bezpečnosti webových aplikací, tak že vyhodnotí data o útocích za určité období a sestaví žebříček deseti nejkritičtějších zranitelností. Data zpracovávaná pro tento report byla poskytnuta více než 40 firmami, specializujících se na bezpečnost aplikací. Položky pro TOP 10 jsou prioritně vybrány podle počtu výskytů, složitosti zneužití, možnosti detekce a výslednému dopadu. Hodnocení jejich rizika je vyhodnoceno podle OWASP Risk Rating Methodology.

Jak je vidět na obrázku 7, který srovnává změny posledních dvou žebříčků, útoky typu Injection (SQLi, OS Commanding) jsou dlouhodobě považovány za jedny z nejnebezpečnějších. Avšak v průběhu let došlo k podstatným změnám. Výskyt některých zranitelností je zmírněn dnes používanými rámci, jako je tomu v případě CSRF, jiné jsou nahrazené nebezpečnějšími typy útoků a posunuty tak do pozadí. Dále se některé uvedené zranitelnosti spojují do jedné kategorie. Ačkoliv takový útok CSRF již není součástí aktuálního TOP 10 listu, neznamená že by se na něj mohlo zapomenout. Je to stále velmi nebezpečný útok, který by se měl testovat. Lze tedy vidět, že typy útoků Injection a XSS jsou stále aktuální hrozbou. Stejně jako špatná bezpečnostní konfigurace, návrh mechanismů pro autentizaci, správu sezení a jiné. Novinkami v seznamu pro rok 2017 jsou zranitelnosti XXE, nesprávná deserializace a nedostatečné logování a monitoring.

Vyhodnocení statistik

V průběhu let se objevují jistá období, kdy několik typů útoku figuruje nad ostatními, které zrovna nejsou tak časté, ale později se opět vrací. Je tedy důležité při vývoji webových aplikací nedbat pouze na nejaktuálnější trendy, ale poohlédnout se zpět v čase na zranitelnosti, které byly hojně zneužívány a s tímto vědomím také aplikace vyvíjet či testovat. Diplomová práce se však zaměřuje pouze na několik vybraných aktuálních záležitostí. Společnými prvky téměř ve všech zmíněných reportech jsou útoky typu SQLi a XSS. Tyto zranitelnosti jsou velmi rozšířené a nebezpečné, proto budou zahrnuty i v další části práce. Mimo jiné se jedná o zranitelnosti, které se útočníci pokoušejí zneužít hned mezi prvními, jak vyplývá z tabulky 4. Dalšími takovými zranitelnosti, které se útočníci velmi často snaží zneužít jsou Path Traversal, Local File Inclusion a OS Commanding (Command Injection). Všechny tyto zranitelnosti spadají do katagorie IIV. Důvodem, proč jsou útoky na validaci vstupů tak časté je nejspíš fakt, že se dají poměrně jednoduše automatizovat a testovat jednotlivé vstupy hned na několik zranitelností najednou. To mě vede k rozhodnutí, věnovat se po zbytek práce právě těmto útokům.

V tabulce 7 jsou vypsány útoky, které budou rozebrány a předvedeny v pozdějších kapitolách. Podle reportů firmy Positive Technologies [34] [35] [36] zastupují tyto typy útoků přibližně 70% celkového množství útoků na webové aplikace. Ačkoliv je tento výběr zaměřený na ty nejčastější útoky v posledních letech, je více než pravděpodobné, že útočníci budou do svého vektoru útoků zahrnovat mnohem více druhů útoků, než je možné pokrýt v rámci této práce. Což znamená, že i když testovaná aplikace bez problému odolá těmto útokům, neznamená to, že je naprosto v bezpečí.

Vybrané útoky a zranitelnosti

V této kapitole se nachází jen velmi stručný popis zranitelností a útoků, které byly vybrány pro další zpracování. Popis bude stručný, protože daná témata jsou velmi komplexní a jejich popis už i tak existuje v mnoha odkazovaných materiálech. Zde je pouze nastíněno, čím jsou zranitelnosti způsobeny a jakým způsobem na ně může být útočeno.

SQL Injection (SQLi)

Útok SQLi spočívá v injekci kódu do SQL dotazu. Tato injekce způsobí, že dotaz provede akci, ke které původně nebyl určen. Na SQLi může být náchylná jakákoliv webová aplikace, která využívá SQL databáze a neaplikovala proti tomuto útoku žádné ochranné mechanismy. Ačkoliv je SQLi jedna z nejstarších zranitelností, které se u webových aplikací vyskytují, je také jedna z nejnebezpečnějších. Využitím chyby v kódu zranitelném na SQLi se, za správných okolností, může útočníkovi povést obejít autentizační a autorizační mechanismy aplikace a získat tak přístup do databáze. Následně pak může útočník manipulovat s daty – přidávat, mazat, upravovat. Může dojít ke změně integrity dat a tudíž jejich znehodnocení. Dalším možným následkem je vykradení dat databáze, kdy si postupným dotazováním lze vyžádat všechna data (nebo jen specifikované tabulky). V některých případech se může útočníkovi povést proniknout až do systémové konzole, kde může provádět libovolné příkazy v závislosti na typu účtu, k jakému útočník získal přístup.

Druhy SQLi – SQLi útoky mohou být rozděleny do těchto tří skupin:

• In-band – Tento typ SQLi nastane, pokud je útočník schopen použít stejný komunikační kanál jak pro útok, tak pro získání výsledků (tedy webovou aplikaci). Útoky v této kategorii se dále mohou dělit na Error-based a Union-based SQLi.

– Error-based – Tato technika se odvíjí od chybových hlášení, které databáze zasílá jako reakci ke špatně zkonstruovaným dotazům. Využití tohoto typu útoku je možné pouze, pokud jsou chyby propagovány do samotné webové aplikace.

– Union-based – Tento typ SQLi využívá SQL operátoru UNION, kterým je možné získat více SELECT dotazů v jednom výsledku.

• Inferential (Blind) – V tomto typu SQLi neprobíhá žádný skutečný přenos výsledků skrze webovou aplikaci a útočník tedy nevidí výsledky na jím zadané vstupy. Je však schopen sestavit potřebné informace zasíláním speciálně připravených dotazů a pozorováním chovaní databázového serveru. Útoky v této kategorii se dále mohou dělit na Boolean-based a Time-based SQLi.

– Boolean-based – Tato technika závisí na zasílaní SQL dotazů, které by měly vracet TRUE, nebo FALSE výsledky. V závislosti na výsledku se pak obsah v odpovědi HTTP změní nebo zůstane stejný.

– Time-based – Tato technika spočívá ve využití databázových příkazů, jako je sleep ke zdržení odpovědi, čímž útočník může zjistit, vrací li zaslaný dotaz TRUE, nebo FALSE.

• Out-of-band – Pro výsledky dotazu je nutné použít jiný komunikační kanál, než jakým je proveden útok (například pomocí emailu, nebo HTTP dotazu). Tento typ SQLi je realizovatelný pouze v případě, že má databázový server povoleny funkce potřebné k odesílání dat.

Příklad – K tomu, aby šlo provést útok SQLi, musí útočník nalézt nějaké uživatelské vstupy, které při své funkci používají dotazy do SQL databáze. Ve webové aplikaci se může jednat například o funkci přihlášení. Informace o uživatelských účtech bývají uloženy v databázi a funkce pro jejich porovnání musí provést databázový dotaz, který může vypadat podobně, jako v tomto příkladu 1.

Příklad – K tomu, aby šlo provést útok SQLi, musí útočník nalézt nějaké uživatelské vstupy, které při své funkci používají dotazy do SQL databáze. Ve webové aplikaci se může jednat například o funkci přihlášení. Informace o uživatelských účtech bývají uloženy v databázi a funkce pro jejich porovnání musí provést databázový dotaz, který může vypadat podobně, jako v tomto příkladu 1.

Tento dotaz je reprezentací jednoduché autentizace uživatele. Pomocí jména účtu a hesla, ověřených oproti databázovému systému, kde by se v tabulkách měly nacházet stejné hodnoty jako ty co zadá uživatel, aby byla autentizace úspěšná. Pokud dotaz vrátí hodnotu, znamená to, že v databázi existuje uživatel se zadanými údaji a může být přihlášen do systému, v opačném případě bude přístup zamítnut. Pokud dotaz nepoužívá vázané proměnné a je do databáze zaslán bez jakýchkoliv ošetření, bude splňovat svou zamýšlenou funkcionalitu, ale také bude zranitelný na SQLi. Útočník tak může do parametrů odesílaných do databáze zkonstruovat takové řetězce znaků, které mu umožní provést akce dle jeho vlastního výběru. Může například vyplnit podobný vstup, jako je uvedený ve skriptu 1. S těmito hodnotami bude vstup stále syntakticky platný podle SQL databáze a dotaz proběhne úspěšně. Jakmile se dotaz odešle, je do aplikace vrácen i výsledek dotazu, což může znamenat úspěšnou autentizaci bez znalosti jména účtu a hesla. V takovémto případě je dokonce možné, že aplikace útočníka přihlásí pod prvním účtem, který je v databázi nalezen, což bývá často administrátorský účet.

Nástroje – Na testování webových aplikací proti útoku SQLi vzniklo mnoho nástrojů. Jedná se jak o nástroje, které se zaměřují pouze na tento útok, jako jsou například SQLmap [44] a SQLninja [45], tak o nástroje zabývající se větším množstvím útoků, kde SQLi je jen jedna část jejich zaměření. Takovými nástroji jsou třeba Nessus [46], w3af [47], nebo Arachni [48].

Cross Site Scripting (XSS)

XSS patří do typu útoků injekce kódu, kde je škodlivý kód vložen do jinak legitimní a důvěryhodné webové stránky (pokud nejde o stránku záměrně škodlivou). Chyby, které umožňují těmto útokům uspět, jsou vcelku rozšířené a mohou se vyskytnout všude, kde webová aplikace využívá vstup od uživatele, aniž by se provedla jakákoliv validace, či sanatizace. Jedná se o útok na straně uživatele, tedy internetového prohlížeče. Útočník může použít XSS útok k poslání nebezpečného skriptu k nic netušícímu uživateli (například skrze odkaz v emailu). Pokud se uživatel stane obětí útoku, jeho internetový prohlížeč spustí útočníkem podvržený skript. Prohlížeč přitom nemá jak poznat, že skript, který spouští je nedůvěryhodný a povolí mu přístup ke všem informacím, jako by byl legitimní součástí webové stránky. Nebezpečný obsah poslaný prohlížeči často bývá kód v jazyce JavaScriptu, ale může obsahovat také HTML, Flash, nebo jiné typy kódu, spustitelné internetovým prohlížečem.

Útok samotný může být použit k široké škále škodlivých činností, jako jsou krádeže sezení (session), šíření malware, poškození funkčnosti napadených stránek, může být použit i v kombinaci se sociálním inženýrstvím, které mohou útoku přidat na závažnosti. Útočníci často používají různé metody jak zakódovat nebezpečnou část odkazu (použitím Unicode), což způsobí, že odkaz na první pohled nevypadá tak podezřele. Existuje velké množství variant tohoto útoku, kde některé nepotřebují ani používat klíčové slovo script, či symboly větší / menší, které jsou použity pro označení začátku a konce skriptu. Z tohoto důvodu se nedá použít univerzální řešení, které by odfiltrovalo potřebné symboly, protože se dá opět jednoduše obejít. Místo toho by se měly vstupy validovat podle očekávaných hodnot, například regulárními výrazy.

Druhy XSS – Útok XSS se může vyskytovat v různých podobách a způsobovat různé problémy. Jeho základní rozdělení se ale řídí podle způsobu, jakým je útok doručen k napadenému uživateli – Stored a Reflected XSS. Dalším méně častým typem XSS útoku je DOM-based.

• Reflected – U tohoto typu XSS je škodlivý skript součástí dotazu, který je poslán webovému serveru a je reflektován zpět na uživatele takovým způsobem, že HTTP odpověď obsahuje tento skript z HTTP dotazu. Tímto se docílí jeho spuštění v prohlížeči uživatele. Použitím phishingu a jiných technik sociálního inženýrství, se útočník snaží uživatele nalákat, aby si zobrazil stránku, ke které byl podstrčen skript. Nejčastějším mechanismem, který se k doručení škodlivého skriptu používá, je vložení skriptu do parametru v URL adrese, ta je pak zveřejněna na internetu, popřípadě zasílána emailem. Pokud se uživatel nachytá, výsledkem je, že se skript odešle v dotazu na server a ten jej pošle zpět k uživateli jako součást stránky, která se spustí v uživatelově prohlížeči, včetně podvrženého skriptu. Jelikož skript u tohoto typu XSS není perzistentně uložen na serveru, k provedení útoku je potřeba jej doručit každému uživateli zvlášť.

• Stored – Také označované jako perzistentní XSS. Tento útok zahrnuje akci, kdy útočník do webové aplikace úspěšně vloží skript, který je v ní trvale uložen (například v databázi). Stránka je pak následujícím návštěvníkům zobrazována včetně útočníkem vloženého kódu. Typickými příklady, kde je útok mimořádně účinný, jsou internetové blogy, fóra, či komentářové sekce různých webových stránek.

• DOM-based – Tento XSS útok nastává, když je škodlivý skript spuštěn, jako výsledek úpravy DOM (Document Object Model) prostředí v prohlížeči uživatele. Tam je skript vložen do legitimní funkce zkonstruované vývojáři aplikace. Výsledkem je, že se kód na straně klienta spustí včetně vložené části kódu. HTTP odpověď samotné stránky se však nemění, ale klientská část kódu obsahuje a spouští dodatečně vloženou funkcionalitu díky modifikaci prostředí DOM. Tento útok překonává jakoukoliv ochranu na straně serveru a není možné jeho logování, protože se na server injektovaný kód vůbec nezasílá, což je podstatný rozdíl oproti Stored a Reflected typům XSS.

Příklad – V ukázkách a vůbec k samotné detekci zranitelnosti XSS bývá nejčastěji použit podobný skript, jako je v příkladu 2.

Jak už bylo zmíněno, někdy se používá i kódování, aby skript nebyl na první pohled čitelný a nebylo tak jasné co provádí. Méně zkušení uživatelé by se tak mohli snadno nachytat a myslet si, že se jedná o legitimní součást URL adresy. Adresa pak může vypadat podobně jako v příkladu 4, kde jedná se o dvě naprosto stejné URL adresy.

Nástroje – Stejně jako u SQLi, většina předních výrobců nástrojů pro bezpečnostní testování zařadila XSS mezi testované záležitosti. Tedy nástroji jako je Nessus, w3af, Arachni OWASP ZAP, Burp Suit  a jinými lze testovat i výskyt zranitelností typicky využívaných pro útok XSS.

OS Command Injection

OS command injection je technika útoku, jejíž cílem je spuštění libovolného příkazu v příkazové řádce operačního systému, hostujícího webovou aplikaci. Webová aplikace může být na tento útok zranitelná, pokud jsou předávána nějaká uživatelem zadávaná data do příkazů prováděných operačním systémem. Zranitelnost spočívá v nesprávné, nebo žádné validaci uživatelem poskytnutých dat. V tomto typu útoku, je-li úspěšný, získává útočník přístup do operačního systému, a to s oprávněními, pod kterými webová aplikace spouští příkazy, což může být v nejhorším případě i root / administrátor (podle typu OS). S možností spouštět libovolné příkazy operačního systému se útočník může pokusit stáhnout škodlivý software, snažit se o zvýšení uživatelských oprávnění, ukrást hesla k uživatelským účtům, nebo i napadnout jiná zařízení a mnoho jiného.

Druhy OS Command Injection – Podobně jako u útoku SQLi jsou to Error-based a Blind. Rozdělení se řídí pouze podle získání odpovědi od serveru.

• Error-based – Pokud útočník vloží systémový příkaz do vstupního parametru na webové stránce a výsledek se mu objeví v prohlížeči, značně to zjednoduší schopnost detekce, jeli webová stránka na tento útok zranitelná. Poskytnutý výstup může být také ve formě chybové hlášky, která je zapříčiněna pokusem o spuštění zadaného příkazu, což může opět útočníkovi pomoci při opravě a konstrukci dalších příkazů.

• Blind – Výsledky příkazu vloženého do vstupního parametru nejsou na stránce uživateli prezentovány a není tedy dostupná žádná odpověď, zda-li se útok podařil, nebo byl příkaz pouze špatně zadán. Útočník tedy musí použít jinou metodu získání odpovědi, že se mu příkaz podařilo spustit. Jednou z takových možností je například použít příkaz ping. Tímto příkazem lze poslat síťové pakety na zařízení, které má útočník pod kontrolou a díky sledování provozu lze zjistit, jestli se povedlo příkaz provést.

Příklad – Jak již bylo řečeno, riziko, které sebou přináší možnost tohoto útoku, je tvořeno využitím systémového příkazu s parametry dodanými uživatelem. V tomto příkladu 5 se může jednat o vzdálenou správu souborového systému na serveru, kdy funkce vypíše obsah zadané složky. Samozřejmě taková funkce by v žádném případě neměla být přístupná z internetu, zde je uvedena pouze pro ukázku funkcionality útoku.

Jelikož funkce opět nijak neošetřuje uživatelem zadané parametry, lze využít speciálního znaku – středníku, který označí příkaz za ukončený a za něj je možné psát další příkaz, což ovšem není zamýšlenou funkcionalitou. Jako u ostatních útoků typu IIV nelze jednoduše filtrovat znaky jako právě středník, protože může dojít k nahrazení středníku jinými znaky, a s využitím funkcionality kódování se středník opět podaří vložit. Výsledný příkaz v příkladu 5 pak provede výpis domovských adresářů a poté se spustí další, již vložený příkaz, který v tomto případě začne rekurzivně mazat celý disk systému – pokud se ovšem příkaz spouští pod uživatelem se zvýšenými oprávněními.

Nástroje – Pro testování zranitelnosti systému proti útoku OS Command Injection lze použít například tyto nástroje: Burp Suite, Nesssus, Arachni, nebo Commix.

Path Traversal

Útok Path Traversal (také známý jako Directory Traversal) spočívá v tom, že se útočník snaží získat přístup ke složkám a souborům, které jsou uloženy mimo kořenový adresář webové aplikace. Zranitelnost na tento útok vzniká v případě, že se pracuje s uživatelem zadaným vstupem, který se dále používá pro načítání souborů. Není-li uživatelský vstup řádně ošetřen předtím než se použije pro načítání souborů, útočník by mohl být schopen číst libovolné soubory na disku, včetně konfiguračních souborů (jak aplikace tak serveru) a zdrojového kódu aplikace. Avšak soubory, které může útočník takto číst jsou omezeny právy uživatele v operačním systému.

Druhy Path Traversal – Útok je možné rozdělit na dva typy – Relative a Absolute Path Traversal. Rozdělení je založeno na tom, jak je funkce načítání souboru implementována a zda-li omezuje útočníka na zadání relativní cesty k souboru, či může zadat i cestu absolutní.

• Relative Path Traversal – Soubor se načítá z předem zadaného adresáře. Útočník tedy používá speciální kombinace znaků jako jsou „..” a „/” (tečky a lomítka), aby se dostal z aktuálního adresáře a dále pak k souborům na serveru, které chce přečíst.

• Absolute Path Traversal – U tohoto typu útoku není předem zadaná cesta adresáře, ze kterého se soubor načítá. Útočník pak nemusí zadávat cestu od již zad

Příklad – Aplikace používá neověřený uživatelem zadaný vstup pro načítání obsahu textového souboru uloženého na serveru. Následující PHP kód 6 načítá textový soubor z předem zadaného adresáře a se zadanou příponou txt.

Pokud uživatelský vstup není ošetřen, jako je tomu v tomto případě, lze jednoduše několikrát zadat sekvencí znaků „../”, čímž útočník docílí možné změny cesty k souboru. Zbývá ještě problém s pevně zadanou příponou pro textový soubor, což se dá obejít tak, že se za celý řetězec přidá NUL byte (%00). Výsledný vstup pak způsobí, že zbytek textového řetězce za vloženým NUL bytem nebude ve výsledku vůbec přečten. U příkladu 7 pro Absolute Path Traversal je útok o poznání jednodušší, protože v aplikaci se počítá s tím, že bude zadána buďto absolutní cesta, nebo pouze název souboru v lokálním adresáři. Útočníkovi tak stačí zadat přímo absolutní cestu k souboru, bez přidávání jakýchkoliv dalších speciálních sekvencí znaků.

Nástroje – Path Traversal je možné testovat pomocí nástrojů již zmíněných u předešlých útoků, jakou jsou Nessus, w3af , Arachni, OWASP ZAP a Burp Suit . Dále existují nástroje, které jsou určeny přímo pro testování tohoto útoku, příklad je třeba DotDotPwn.

File Inclusion

Aplikace může být zranitelná na útoky typu File Inclusion, pokud se pracuje s uživatelskými vstupy, které jsou dále použity ve funkci, která do zdrojového kódu načítá soubor (například u jazyka PHP funkce include). Pokud se útočníkovi podaří na server nahrát vlastní spustitelný soubor, nebo do nějakého souboru zapisovat, je to velký problém. Podaří-li se takový soubor načíst, provede se i kód uvnitř souboru, a to dává útočníkovi možnost upravit funkcionalitu aplikace a dokonce i spouštět systémové příkazy. Uvedený scénář je jeden z nejhorších případů, který může nastat. Dochází tak k úniku dat, vzdálenému spuštění kódu, nebo kompromitace systému. To ale vyžaduje, aby měl útočník možnost nahrání vlastního souboru na server, nebo alespoň zápis do nějakého souboru, který může později i načíst. Pokud tohle kritérium není splněno, útok degraduje „pouze” na Path Traversal. Rozdílem mezi File Inclusion a Path Traversal je tedy vzdálené spuštění vlastního kódu na serveru.

Druhy File Inclusion – Rozdělení u útoku File Inclusion se řídí podle umístění nahrávaného souboru na Local File Inclusion (LFI) a na Remote File Inclusion (RFI).

• Local File Inclusion – LFI se může objevit, pokud se pracuje s neošetřeným uživatelským vstupem, za účelem vložení souboru do obsahu zdrojového kódu. Při LFI je přímo definovaná složka, ze které se soubor nahrává, proto není možné přímo do vstupu vložit soubor z externího zdroje. Nebo je nahrání externího souboru v aplikaci ošetřeno.

• Remote File Inlcusion – Jako RFI se označuje útok, kde je útočník schopen do běžící webové aplikace nahrát svůj vlastní soubor z externího zdroje. Může se například jednat o skript, který má útočník připravený na svém serveru, ten je nahrán do aplikace, přičemž je proveden. RFI je možné provést, pokud se uživatelský vstup řádně nekontroluje, v aplikaci není pevně nastavena lokace (složka), ze které se bude soubor načítat a není zakázané vkládání URL do parametrů (v případě PHP funkce allow_url_include a allow_url_fopen).

Příklad – V příkladu 8 se nachází ukázka zranitelného kódu ve webové aplikaci. V tomto případě se jedná o LFI, protože první část cesty k nahrávanému souboru je již zadaná v kódu aplikace. Útočník však stále může nahrávat soubory, které jsou umístěné na serveru. V tomto případě se dá použít například technika log poisoning, kdy je chyba vygenerována do logu a součástí této chyby je i skript. Napadený soubor logů je pak nahrán do aplikace což způsobí provedení skriptu, který je jeho součástí.

Nástroje – Vzhledem ke značné podobnosti s útokem Path Traversal 5.4, je možné použít k testování všechny nástroje uvedené u toho útoku i pro File Inclusion. Za zmínku stojí nástroj fimap [53], který je napsán speciálně na testování LFI/RFI.

Příprava testovacího prostředí a nástrojů

Cílem implementační práce je, vytvořit dva testovací nástroje pro demonstraci zranitelností, vybraných v kapitole 4.1.5. Prvním nástrojem by měla být webová aplikace, která bude tyto vybrané zranitelnosti obsahovat. Druhým nástrojem bude jednoduchý skenovací nástroj. Tento nástroj by měl být schopen danou webovou aplikaci otestovat a detekovat výskyt dříve řešených zranitelností. V kapitole 7 je pak popsána reimplementace zranitelných prvků aplikace. Takto opravená aplikace bude opět testována stejnými metodami. Výsledky obou testů budou porovnány.

Struktura kapitoly:

1. Volba použitých technologií – v této sekci jsou uvedeny statistiky, na jejichž základě byly zvoleny technologie použité při tvorbě webové aplikace. 2. Příprava virtuálního prostředí – testovací webová aplikace, na které probíhá veškeré testování běží ve virtuálním prostředí, zde je popsána příprava tohoto prostředí. 3. Testovací webové aplikace – v této části kapitoly jsou popsány jednotlivé stránky webové aplikace. 4. Testovací penetrační nástroj – zde je popsána funkce penetračního nástroje a možnosti s jakými může být spuštěn.

Výběr technologií pro webovou aplikaci

Výběr zranitelností a útoků, které jsou v diplomové práci zpracovávány je založen na statistikách, získaných v rámci průzkumu oblasti bezpečnosti webových aplikací. Stejně tak technologie pro implementaci testovacího prostředí bude podložen jistými statistikami. Výsledkem implementace by měla být malá až středně velká webová aplikace. Pro tato kritéria se asi nejlépe hodí využití technologií PHP, MySQL, Apache. Tato kombinace je dnes velmi populární. Při nasazení na operačním systému unixového typu, jako je na příklad linuxová distribuce Ubuntu (kterou zde využiji), lze dosáhnout řešení, a přitom se také vyhnout poplatkům spojeným s licencemi. To může být často i cílem menších společností, tedy důvodem zvolení a použití této kombinace technologií.

Programovací jazyk

Co se programovacích jazyků na straně serveru týká, tabulka 8 ukazuje, že u webových aplikací je největší zastoupení jazyka PHP. Ačkoliv ve firemním prostředí se často můžeme setkat s řešeními, založenými na technologiích ASP.NET a Java EE. Jazyk PHP na veřejné síti v počtu použití nemá konkurenci. Ostatní jazyky jako jsou Ruby, Python a jiné, jsou využívány oproti již zmíněným jazykům jen zřídka. Pro implementaci testovací webové aplikaci si tedy volím jazyk PHP.

Webový server

Tabulka 9 ukazuje dnes nejpopulárnější používané webové servery, kde aktuálně stále vítězí Apache. Webový server Nginx zažívá v poledních letech vcelku solidní vzrůst v počtu použití, ale Apache je stále ještě nejpoužívanějším, proto bude také použit i při implementaci této testovací aplikace.

Operační systém

Windows je dnes nejběžněji používaný operační systém pro notebooky a stolní počítače, co se serverové stránky týče, tam zase převládají systémy unixového typu. V tabulce 10 je ukázáno, že aktuálně dvě třetiny ze všech veřejně dostupných webových aplikací používá jako hostující systém nějaký operační systém unixového typu.

Databáze

Při porovnávání databázových systémů byl využit jiný zdroj než u předchozích výběrů. DB-Engines nesrovnává počty instalací databází, ani jejich využití pro určitá použití v IT odvětví – z toho důvodu lze tento zdroj vidět pouze jako ukazatel popularity různých databázových systémů. Zvolenou databází pro implementaci je MySQL, která je na žebříčku popularity umístěna jako druhá, hned za databází Oracle. MySQL je často používána v kombinaci s ostatními vybranými technologiemi. V rámci průzkumu bylo zjištěno, že se často používá v menších projektech.

Virtuální prostředí

K testovacím účelům bylo zapotřebí virtuální operační systém, který reprezentuje server hostující webovou aplikaci. K použití je zvolen virtualizační nástroj QEMU/KVM. Hostujícím operačním systémem pro virtuální server byla linuxová distribuce Fedora, proto instalace QEMU/KVM byl poměrně triviální úkol (viz. 10).

Testovací webová aplikace

Původně měla mít každá zranitelnost (viz. kapitola 5) vytvořenou jednu stránku, která obsahuje chybně implementovanou, zranitelnou funkci, ale nakonec má zranitelnost XSS stránky dvě – jednu pro typ Reflected a druhou pro Stored. Naopak zranitelnosti Path Traversal a File Inclusion sdílejí, vzhledem k jejich podobnosti, stránku jednu. Zranitelnosti SQL Injection a OS Command Injection už mají obě vyhrazené po jedné stránce. Implementace je provedena pomocí jazyka PHP (verze 7.1.16) v čisté podobě. Nebyly použity žádné rámce (frameworks), aby se daly ukázat čisté formy zranitelností, možnost jejich zneužití a také opravy. Určité rámce obsahují metody, které některé zranitelnosti eliminují. Ale takové metody mohou být přímo závislé na použitém rámci, který má implementované rozšiřující funkce a právě jejich použití napomáhá k ošetření dané zranitelnosti. Jiné rámce takové funkce mít nemusí, proto jsou zranitelnosti a následná obrana proti nim, předvedeny bez jakýchkoliv přidaných funkcionalit. Jelikož je cílem implementace demonstrace zranitelností, nejsou zde řešeny žádné programovací architektury či vzory. Celá aplikace je pak napsána v jednoduchém stylu, obsahujícím několik funkcionalit, které mohou být napadeny.

SQL Injection

Stránka pro SQL Injection (obrázek 8) reprezentuje listování v seznamu článků, kde je možné vyhledávání podle unikátního parametru. Články jsou uloženy v databázi odkud jsou i načítány. Stránka obsahuje formulář s jednou vstupní hodnotou pro vyhledávání podle názvu. Parametr je předán do podmínky dotazu, který poté do stánky načítá všechna nalezená data. V případě jakéhokoliv problému je chyba propagována přímo těla do stránky.

Reflected XSS

Stánka pro Reflected XSS je téměř stejná jako stránka pro SQL Injection 6.3. Jediným rozdílem je, že načítá obsah z jiné tabulky v databázi, aby se předešlo problémům při zobrazování obsahu, který by mohl být do jedné z těchto tabulek vložen.

Stored XSS

Pro potřeby demonstrace útoku Stored XSS, bylo potřeba ukládat obsah od uživatele do databáze. Jelikož v databázi již byly vytvořené tabulky pro články, byly použil podobné i pro tento příklad. Přes webový formulář bylo možné vkládat články do databáze, a ty se následně načítaly do téže stránky. Funkcionalita je obdobná jako u návštěvních knih, či komentářových sekcí stránek, které se běžně vyskytují na internetu.

OS Command Injection

Pro demonstraci útoku OS Command Injection bylo nutné, aby stránka používala nějaký systémový příkaz, který závisel na parametru, jež zadává uživatel stránky. Jako testovací příklad byla vytvořena stránka (obrázek 9), která umožňuje uživateli vytvářet soubory na serveru. Data tentokrát nejsou ukládána do databáze, ale přímo na souborový systém.

Path Traversal / File Inclusion

Stránka připravená pro útoky Path Traversal a File Inclusion zobrazuje článek, u kterého je možné změnit jazyk zobrazení. Tato funkcionalita je provedena pomocí PHP funkce include, která načítá obsah souboru, dle vybraného jazyka zobrazení. Aby bylo možné provést i útok File Inclusion, bylo nutné na serveru udělat dodatečné úpravy v konfiguraci souboru, který se stará o automatické generování log souborů pro webový server Apache, tak aby běžný uživatel mohl logy přečíst. V původní konfiguraci jsou soubory logů vytvářeny tak, aby je nemohli přečíst uživatelé, kteří k tomu nemají oprávnění. Uživatel, pod kterým webová aplikace běží taková oprávnění nemá. Důvodem za povolením čtení těchto souborů může být situace, kdy má webová aplikace nějakou formu administrátorské sekce, včetně monitorování stránek. Pak by bylo jedno z možných řešení jak tento monitoring provést, načítáním zmiňovaných logů do webové aplikace.

Testovací penetrační nástroj

Nástroj pro penetrační testování byl napsán v jazyce Python (verze 3.6.4). Jeden z hlavních důvodů volby tohoto jazyka je množství použitelných knihoven. Je tak možné poměrně rychle vytvořit funkční aplikaci a to v krátkém čase.

Funkce nástroje se dělí na dvě hlavní části. V té první si nástroj zjistí všechny dostupné stránky na testované webové aplikaci. Na jednotlivých stránkách se přitom vyhledávají i vstupní body ve formě HTML tagů form a následně input. Tato detekce probíhá zkoumáním zdrojového kódu stránek za pomocí knihovny scrapy. Všechna nalezená data se předávají do druhé fáze programu, která provádí testování. Pro každou zranitelnost je vytvořena vlastní třída, obsahující seznam útočných vstupů, které se zasílají do jednotlivých vstupních bodů. Třída dále obsahuje seznam očekávaných výstupů, které se ve stránce následně kontrolují. Pokud je očekávaný výstup nalezen, je vstupní bod označen jako zranitelný na provedený útok. Takto se cyklicky provede testování na všechny nalezené vstupní body.

stování na všechny nalezené vstupní body. Na obrázku 10 je zobrazena nápověda pro penetrační nástroj. Jak lze vidět, jedná se o vcelku přímočarý přístup, kde v podstatě stačí nástroji poskytnout URL adresu stránky, která bude testována. Nástroj pak pracuje sám automaticky, bez potřeby interakce, dokud se test nedokončí. Ostatní možnosti jsou volitelné a slouží k omezování nástroje. Pokud je zapotřebí otestovat pouze jednu URL adresu, aniž by nástroj hledal odkazy na další stránky, které by také testoval, je možné nástroj spustit v restricted režimu. Další možné omezení se týká simulace útoků. Pokud mám stránku, kterou chci otestovat jen na SQL Injection, je možné přidat omezení ve formě parametru attacks a argumentu, patřícímu příslušnému typu testování. Různé ukázky a kombinace použití nástroje jsou uvedeny ve výpisu 13.

Testování a oprava zranitelností

Tato kapitola je vyhrazena manuálnímu testování zranitelné webové aplikace. Každá zranitelnost má připravenou stránku, na které testování proběhne. Jedná se pouze o demonstraci útoku, proto zde nebude probíhat testování všech možných zranitelností pro všechny možné vstupní body ve webové aplikaci. Přístup k testu může být klasifikován jako Black Box, kde první fází bude předpoklad funkcionality testované stránky. Následně bude popsáno testování včetně chování aplikace na různé testovací vstupy. Po „odhalení“ zranitelnosti bude následovat i její oprava pro mou testovací aplikaci. Na konci každé podkapitoly budou doplněny i možnosti výskytu zranitelnosti a alternativní tipy zabezpečení aplikace. Všechny tipy, včetně referencí na dodatečné zdroje, jsem sepsal do samostatného dokumentu, který je součástí přiložených materiálů.

Struktura kapitoly:

1. Testování SQL Injection – Testování stánky probíhá pomocí union-based metody.

2. Testování Cross Site Scripting – Popsána bude pouze ukázka Reflected XSS, všechny použité metody a postupy by se daly replikovat i pro Stored XSS.

3. Testování OS Commang Injection – Zranitelnost je testována v error-based formě.

4. Testování Path Traversal a File Inclusion – Nejdříve bude popsán útok Path Traversal, na který bude navázán útokem LFI. Jelikož se jedná o podobné útoky a testování probíhá na stejné stránce, jsou zařazeny do jedné kapitoly.

5. Hromadný test – Na základě manuálních testů různých stránek vznikl nástroj pro automatickou detekci zranitelností, z jeho pomocí bude otestována jak zranitelná tak i zabezpečená testovací aplikace.

SQL Injection

Stránka pro SQL Injection obsahuje jeden vstupní bod, který je použit pro vyhledávání ve článcích, které jsou na stránce zobrazeny. Jsou-li data uložena a načítána z databáze, je vcelku možné, že v databázovém dotazu figuruje podmínka WHERE, kterou je redukován počet načtených článků, podle zadaného klíčového slova. Pokud je tohle tvrzení pravdivé a neprobíhá validace, ani sanatizace vstupů, je možné úspěšně provést útok SQL Injection. Prvními zasílanými vstupy, které jsem použil k otestování funkce formuláře jsou znaky ", ’ a %.

Při zadání znaku uvozovky, stránka nevrátila žádné výsledky, ani chyby (viz. obrázek 11). Ale při zadání znaku procenta, byly zobrazeny všechny články, jako by k žádnému vyhledávání nedošlo (viz. obrázek 11), což potvrzuje, že filtrování článků probíhá v databázovém dotazu v podmínce WHERE. Za pomocí dříve zmíněných znaků v kombinaci se všemi možnými znaky, které se v databázích používají pro komentáře, lze zjistit, nejen že je aplikace zranitelná na útok SQL Injection, ale také, že se jedná o databázový systém MySQL, nebo MariaDB. Pomocí dalšího zkoumání, které probíhá ve formě UNION SELECT tabulky INFORMATION_SCHEMA, lze získat informace o všech tabulkách v databázi. Je tak možné bez problému číst veškerý obsah databáze pomocí podobných dotazů, jako je zobrazen na obrázku 12.

Část zdrojového kódu zranitelné stránky je zobrazena ve výpisu 14, kde jde jasně vidět, v čem je problém. Vstup od uživatele je přímo předán databázovému dotazu, což znamená, že je kdokoliv schopen pozměnit původní funkci dotazu.

Možný výskyt zranitelnosti:

• Předpokladem je práce s relační databází, používající jazyk SQL. • Databázové dotazy jsou tvořeny na základě uživatelem zadanými daty, bez jakékoliv kontroly. • Dynamicky tvořené SQL dotazy. To platí jak pro programovací jazyk aplikace, tak pro databázové procedury.

Možnosti obrany:

• Preferovanou možností je použití parametrizovaných dotazů (Prepared Statement), pokaždé, kdy do SQL dotazu vstupují data poskytnutá uživatelem aplikace. • Použití uložených procedur v databázi. Pokud jsou implementovány správně, mají uložené procedury stejný efekt jako Prepared Statemens (použití parametrizovaných dotazů uvnitř procedur). • Pozitivní validace vstupů – whitelisting. • Escapování všech uživatelských vstupů (mělo by být použito jen v případě, kdy není možné použít jiné metody obrany).

Cross Site Scripting

Stránka obsahuje seznam článků, ve kterých je možné vyhledávat podle názvu článku. V případě XSS nezáleží na tom, odkud jsou data načítána. Co ale podstatné je, že při odeslání formuláře se zadaným vstupem pro vyhledávaní se ten samý textový řetězec znovu objeví na stránce. Pokud aplikace neošetřuje speciální znaky používané pro HTML, je dost možné, že bude útok XSS proveditelný. Klasickým testovacím vstupem, jako je na obrázku 13, bylo ověřeno, že je aplikace zranitelná na útok XSS.

V programovacím jazyce PHP existuje funkce htmlspecialchars, která dokáže vcelku efektivně aplikaci i její uživatele ochránit před útoky XSS. Největším problémem, který se vyskytuje v souvislosti s použitím této funkce, je nutnost každý vstup i výstup webové aplikace ošetřit. Zapomene-li se na jediný, je to vše co stačí proto, aby zranitelnost mohla ve stránce existovat. Ve své aplikaci jsem pomocí již zmíněné funkce ošetřil všechny vstupy do webové aplikace stejným způsobem jako je v příkladu 17

Možnosti obrany:

• Escapování všech dat vstupujících do webové aplikace. • Vyvarovat se vkládání uživatelem poskytnutých dat do atributů HTML elementů. • Pozitivní validace vstupů – whitelisting. • Některé template engines mohou pomoci s ochranou aplikace proti XSS

OS Command Injection

Stránka poskytuje uživateli formulář pro vytváření souborů na serveru. Tato funkcionalita může být dosažena jak funkcemi programovacího jazyka, tak za pomocí systémového příkazu. Jednáli se o případ, kdy je použita varianta se systémovým příkazem a vstup není řádně ošetřen, je možné provést pokus o vložení dodatečného příkazu. Pomocí speciálních znaků & a ; lze otestovat, zda se jedná o volání systémového příkazu. Tyto znaky jsou používány k ukončení příkazu, za který je pak možné přidat další příkaz. Z pozorování funkce formuláře lze zjistit, že aplikace přidává na konec řetězce vlastní příponu souboru, ve formě txt, aby nebylo možné vytvářet spustitelné soubory (například PHP skript). Dochází-li ke spojování textových řetězců a jedná se skutečně o systémový příkaz, pokud se přidá středník za konec jména, měl by se soubor vytvořit bez přípony txt, čímž je možné vytvořit soubor jakéhokoliv typu – což se také stalo. Je tedy potvrzeno, že vstup je zranitelný na útok OS Command Injection.

Pokud je aplikaci zaslán vstup ve formátu středník – příkaz – středník, mělo by dojít ke spuštění dodatečného příkazu uvnitř funkce. Na obrázku 14 je ukázka, co se stane, když se mezi středníky zadá příkaz id. Je zjištěno, že příkazy jsou prováděny pod uživatelem www-data, jehož uživatelskými oprávněními jsou omezeny všechny příkazy odeslané na server.

Možný výskyt zranitelnosti:

• Použití systémového příkazu, který je závislý na vstupu od uživatele.

Možnosti obrany:

• Použít jinou metodu, která umožní dosáhnout stejné funkcionality i bez volání systémového příkazu. • Nedovolit uživateli přímý vstup do systémového příkazu. • Pozitivní validace vstupů – whitelisting. • Escapování všech uživatelských vstupů (mělo by být použito jen v případě, kdy se není možné použít jiné metody obrany).

Path Traversal a File Inclusion

Ve stránce je zobrazen článek, u kterého existuje možnost změnit jazyk zobrazení. Článek se musí načítat z nějakého zdroje – může se jednat například o databázi, nebo soubor. Za předpokladu, že jako úložiště je použit soubor, který se celý načítá do stránky, mohlo by dojít k manipulaci cesty cílovému souboru. Místo článku v jiném jazyce by mohlo dojít k pokusu o načtení úplně jiného souboru uloženého na serveru. Při zadání absolutní cesty souboru /etc/passwd je vypsána chyba, což může znamenat, že aplikace používá jiný způsob načítání obsahu, je proti tomuto útoku ošetřena, nebo je dopředu zadána nějaká cesta (například složka). Dalším pokusem je zadání relativní cesty k souboru. Pokud se dostatečně mnohokrát přesunu do rodičovského adresáře a poté zadám cestu k souboru, soubor se vypíše jako na obrázku 16

Je možné do stránky načítat soubory na serveru což je samo o sobě dost nebezpečné. Co by bylo ještě nebezpečnější, kdyby se stránky podařilo načítat obsah, který serveru zaslán. Toho by šlo dosáhnout, pokud bych měl přístup ke čtení některého z logů hostujícího serveru webové aplikace. Pokusem o načtení několika známých lokací, kde se běžně logy vyskytují, se podařilo načíst soubor /var/log/apache2/access.log (obrázek 17). V takovémto případě je možné provést útok LFI. Součástí přiložených materiálů je pak předvedena i technika log poisoning, díky které je možné do logu zapsat vlastní kód a ten pak načíst do obsahu stránky.

Možný výskyt zranitelnosti:

• Při práci se soubory, nebo složkami se pracuje s daty zadanými uživatelem aplikace. • Neohraničené cesty k načítaným souborům. • File Inclusion – čitelné log soubory. • File Inclusion – možnost nahrání externího souboru na server.

Možnosti obrany:

• Nepovolit uživateli přímou manipulaci s funkcí, která pracuje se soubory (složkami). • Použít předem nastavených podmínek pro načítání souborů, jestliže je volba souboru přenechána uživateli. • Ohraničení cesty k načítanému souboru. • Pozitivní validace vstupů – whitelisting. • Na systémech unixového typu je možné použít chroot jail, který dokáže zabránit v listování složek, za nově definovaným kořenovým adresářem. • Je-li to možné, zakázat stránce načítat soubory z externích zdrojů (například v PHP allow_url_fopen, allow_url_include).

Testování pomocí vytvořeného nástroje

V penetračním nástroji je zakomponováno mnoho testovacích vstupů, včetně těch, které byly použity pro manuální testování aplikace v rámci této kapitoly. Obrázky 18 a 19 jsou srovnáním výsledků testování pomocí penetračního nástroje. Jak je vidět, ve zranitelné aplikaci byly dle očekávání objeveny všechny zranitelnosti nejméně jednou. Oproti tomu v opravené aplikaci již nebyl nalezen žádný zranitelný vstup. V přiložených materiálech se nachází reporty vygenerované nástrojem pro penetrační testování Arachni, který v opravené aplikaci také žádné z řešených zranitelností nedetekoval.

Obecná doporučení pro vývoj webových aplikací

Tato doporučení nejsou vázána na žádnou platformu ani technologii. Jsou to obecné rady, které mohou pomoci s oblastí bezpečnosti při vývoji webových aplikací. Ačkoliv je tato práce zaměřena hlavně na zranitelnosti IIV, zejména pět určitých útoků, které je využívají. Jsou zde uvedeny i rady týkající se jiných problémů. Aby aplikace mohla být považována za opravdu bezpečnou, nestačí pouze vzít v úvahu následujících několik bodů. Je potřeba provádět neustálé revize zdrojových kódů, pravidelné testování aplikace, kontrolu verzí použitého software a mnoho dalšího. Jak už bylo nejednou řečeno, bezpečnost není záležitost, která se jednou aplikuje a trvá navždy.

• Správná validace (sanitizace) vstupů

Nikdy nepracovat s uživatelským vstupem v jeho původní podobě. Pokud se pracuje s databází, použít Prepared Statements. Jsou-li data zobrazována na webových stránkách, je potřeba použít escapování. Uživatelem zadaná data vstupují do funkcí – filtrování podle kontextu, validace, whitelisting. V několika předešlých kapitolách byla řešena právě tato problematika – nesprávně validované vstupy. Ve většině případů je lepší použít whitelisting než blacklisting. Explicitně se určí, jaké znaky mohou data obsahovat, nebo v jakém mají být formátu. S dobře rozmyšleným regulárním výrazem se výrazně sníží možnosti útoku. Pokud však nemůže být v daném kontextu použit whitelist, je dobré použít alespoň validaci pomocí blacklistu. Blacklisting může být dobrá ochrana, ale hlavní problém u této metody je, že je snadné na něco zapomenout.

• Zabezpečit autentizační a autorizační mechanismy

Pokud je to možné, je vhodné použít více faktorovou autentizaci. Ta může zamezit přihlášení pod uživatelským účtem, jehož přihlašovací údaje byly ukradeny. Implementace mechanismu, který kontroluje slabá hesla (v hesle je zakomponované přihlašovací jméno, použití pouze písmen / číslic, kontrola oproti slovníku známých, slabých hesel). Limitovat pokusy o přihlášení – zamezí se tak brute force a slovníkovým útokům. Ukládání hesel a citlivých údajů pomocí dostatečně silných kryptografických mechanismů (PBKDF2 + SHA-256 s dostatečným počtem iterací). Logování neúspěšné autentizace. V případě velkého množství neúspěšných pokusů o přihlášení zablokovat účet a kontaktovat majitele. Bezpečná správa sezení. Session ID vždy generuje server, mělo by být dostatečně dlouhé s vysokou entropií, bezpečně uložené a označeno jako nevalidní po odhlášení uživatele, nebo dlouhé neaktivitě.

• Zbytečné vyzrazování informací

Chybové hlášení nikdy nepropagovat do webové aplikace. Pro účely ladění a vývoje programu je užitečné mít přehled o jeho chování, s čímž souvisí různé výstupy, které si vývojář nechává vypisovat. Pro tyto účely je však dobré použít mechanismus, který dokáže globálně vypnout a zapnout ladicí výpisy. V jiném případě je lepší využít konzole či log soubory. Předejde se tak problému, že se na některý z výpisů do webových stránek zapomene, což pak útočníkům vyzrazuje dodatečné informace o aplikaci. Nastavit server tak, aby o sobě nevyzrazoval zbytečně moc informací (aplikační server, programovací jazyk, verze software, atd.).

• Aktualizace software

V každém novém produktu se časem objeví nějaká bezpečností chyba, které se dá zneužít a musí být opravena. Na administrátorech serverů je, aby udržovali svůj software co možná nejaktuálnější.

• Monitorování a logování

Monitorování podezřelých aktivit může odhalit blížící se útok. Logování nepovolených vstupů může pomoci s analýzou zranitelnosti v případě úspěšného útoku.

• Princip nejnižšího oprávnění

Každý účet a modul by měl mít přístup pouze k informacím a zdrojům, které potřebuje ke své funkcionalitě. V případě úspěšného zneužití zranitelnosti se tímto opatřením může snížit dopad škod na minimum.