VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra technických studií Obor Aplikovaná informatika. Analýza bezpečnosti webových stránek veřejné správy v kraji

Transkript

1 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra technických studií Obor Aplikovaná informatika Analýza bezpečnosti webových stránek veřejné správy v kraji bakalářská práce Autor: Filip Svoboda Vedoucí práce: Ing. Dominik Marek Jihlava 2016

2

3 Abstrakt Tato práce je zaměřena na penetrační testování webových stránek veřejné správy v Kraji Vysočina. První část slouží jako úvod do problematiky penetračního testování. Věnuje se popisu používaných technik, nejčastějších zranitelností na webových stránkách a metodik pro penetrační testování. Ve druhé, praktické části práce je provedena analýza bezpečnosti webových aplikací podle čtyřfázové metodiky, kterou definoval Národní institut standardů a technologie USA. Testování je zaměřeno na 10 nejzávažnějších zranitelností, jak je definuje příručka OWASP Top 10. V poslední kapitole jsou shrnuty výsledky testů s doporučeními, jak rizika omezit. Klíčová slova Bezpečnost webových aplikací, penetrační testování, OWASP Top 10, Nessus, Burp Suite, sqlmap Abstract This thesis is focused on penetration testing of websites of public administration in Vysočina region. The first part is an introduction to penetration testing. It describes the used techniques, penetration testing methodologies and the most critical web application security risks and vulnerabilities. The second, practical part describes security analysis performed on base of four-phase methodology defined by The National Institute of Standards and Technology. The testing focuses on 10 most critical vulnerabilities as defined in OWASP Top 10 document. The last part summarizes testing results with recommendations how to prevent them. Keywords Web application security, penetration testing, OWASP Top 10, Nessus, Burp Suite, sqlmap

4 Prohlašuji, že předložená bakalářská práce je původní a zpracoval jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též AZ ). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne... Podpis

5 Poděkování Na tomto místě bych rád poděkoval svému vedoucímu práce Ing. Dominiku Markovi za poskytnutí tématu a možnost vytvářet ho pod jeho vedením.

6 Obsah 1 Úvod a motivace Problematika testování bezpečnosti webových aplikací Penetrační test Typy penetračních testů Podle pozice útočníka Podle způsobu provedení Podle úrovně znalostí o testovaném systému Metodiky penetračního testování OSSTMM OWASP web application security testing methodology NIST Technical Guide to Information Security Testing and Assessment Plánování Průzkum Útok Report OWASP Top OWASP Top A1 Injection A2 Broken Authentication and Session Management A3 Cross-Site Scripting (XSS) A4 Insecure Direct Object References A5 Security Misconfiguration A6 Sensitive Data Exposure A7 Missing Function Level Access Control A8 Cross-Site request Forgery (CSRF)... 23

7 4.1.9 A9 Using Known Vulnerable Components A10 Unvalidated Redirects and Forwards Penetrační testování vybraných webových aplikací Plánování Informace o testovaných aplikacích Popis a výběr použitých nástrojů Průzkum Útok A1 Injection A2 Broken Authentication and Session Management A3 Cross-Site Scripting (XSS) A4 Insecure Direct Object References A5 Security Misconfiguration A6 Sensitive Data Exposure A7 Missing Function Level Access Control A8 Cross-Site Request Forgery (CSRF) A9 Using Known Vulnerable Components A10 Unvalidated Redirects and Forwards Report edotace Informační systém Krajského úřadu Kraje Vysočina eambulance emedocs Rowanet Závěr Seznam použité literatury Seznam obrázků... 55

8 Seznam použitých zkratek Přílohy A - Report z penetračního testování... 57

9 1 Úvod a motivace V roce 2015 bylo k internetu připojeno 43 % světové populace a toto číslo neustále roste. [1] S nárůstem využití internetu se pojí i větší množství zpracovávaných a přenášených dat a zvyšuje se i množství kyber-útočníků, kteří mají o citlivá data zájem. Podle studie 2015 Cost of Data Breach Study [2] byla v roce 2015 výše finanční ztráty, způsobené únikem informací 3,79 mil. USD, což je o 23 % vice, než v roce Cena za jeden odcizený dokument se vyšplhala v průměru na 154 USD. Z uvedených statistik je patrné, že útoků na firemní sítě a webové aplikace bude nadále přibývat a je nutné se jim bránit. V roce 2015 vstoupil v účinnost zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti) [3], který mimo jiné, ukládá provozovatelům určitých webových aplikací a informačních systémů povinnost zabezpečit data. V rámci mé bakalářské práce se mi naskytla možnost provést bezpečnostní analýzu několika webových stránek veřejné správy v Kraji Vysočina. Seznámení se s problematikou a výstup z této bezpečnostní analýzy pro mě bude jistě velkým přínosem. Práce je rozdělena na dvě části. První část je teoretická a popisuje obecná pravidla a postupy, které se používají pro otestování zabezpečení webových aplikací, a obsahuje přehled nejčastějších chyb, které se ve webových aplikacích objevují. Ve druhé časti práce je prakticky provedena bezpečnostní analýza popsaných webových zranitelností a výstupem je zpráva pro Krajský úřad o provedeném testování. 9

10 2 Problematika testování bezpečnosti webových aplikací Následující teoretická část si klade za cíl seznámit čtenáře s problematikou penetračního testování a s důležitými pojmy, jejichž znalost je nutná pro pochopení části praktické. 2.1 Penetrační test Jedná se o testování IT infrastruktury, ve kterém se simuluje skutečný útok, za účelem nalezení co nejvíce zranitelných míst, které by mohly být použity útočníkem k proniknutí do aplikace, systému, nebo sítě. Výsledkem penetračního testu je pak zpráva, jež obsahuje všechny nalezené zranitelnosti a také doporučení pro jejich nápravu. [4] Před samotným penetračním testem je nutné získat úplný souhlas s našimi aktivitami od všech stran, které může test nějak zasáhnout. [5] 2.2 Typy penetračních testů Penetrační testy se dají rozdělit do několika základních kategorií. Podle toho, kde se nachází útočník, jaké má znalosti o testovaném systému a dle způsobu provedení. [6] Podle pozice útočníka Interní Externí Externí testy jsou prováděny z vnější sítě, typicky internetu a zaměřují se na kontrolu tzv. demilitarizované zóny 1 (DMZ), firewallů nebo směrovačů Interní testy simulují útok z vnitřní sítě, do které se útočník může dostat buď fyzicky nebo prolomením vnější ochrany, např. firewallu, špatně zabezpečeného webového serveru apod. [7] 1 Demilitarizovaná zóna je podsíť, ve které jsou umístěny služby přístupné z internetu, ale je oddělena od zbytku interní sítě. 10

11 2.2.2 Podle způsobu provedení Manuální testy Manuální testy provádí tester ručně. Takové testy jsou velmi specifické a vytvořené na míru testované aplikaci. To umožňuje detailně se zaměřit na určité místo aplikace a řádně ho otestovat. Nevýhodou manuálních testů je velká časová a znalostní náročnost. Tester musí mít detailní přehled o různých zranitelnostech a vědět jak jednotlivé zranitelnosti zneužít proti konkrétnímu druhu aplikace, kterou testuje. [6] Automatizované testy Automatizované testy jsou rychlé a dají se snadno reprodukovat. Používají se zde skenery zranitelností, které jsou vyvíjeny profesionály v této oblasti. Můžeme použít několik nástrojů, které mají široké možnosti konfigurace, ale přesto tyto nástroje nemusí nalézt všechna zranitelná místa, nebo je naopak může chybně identifikovat. [6] Semiautomatické testy Semiautomatické testy kombinují manuální a automatické testy. Tento typ testu kombinuje výhody obou výše zmíněných metod, kdy například nejprve identifikujeme potenciálně zranitelná místa automatickým skenerem a na ta místa poté útočíme. [6] Podle úrovně znalostí o testovaném systému Black-box testy Black-box test napodobuje přístup skutečného útočníka, který nemá žádné informace o vnitřní struktuře aplikace a zná pouze vstupy a výstupy. Aplikace tedy pro testera představuje tzv. černou skříňku. [6] White-box testy Při tomto typu testu má tester k dispozici kompletní zdrojové kódy a zná její vnitřní strukturu. Při testování pak tester nemusí zkoušet mnoho různých útoků, ale zjistí z kódu, jak je dané místo zabezpečeno a dle toho volí další postup. 11

12 Výhodou tohoto přístupu je rychlejší a lepší pochopení zranitelných míst aplikace. Naopak nevýhodou je nutná znalost programovacího jazyka, ve kterém je aplikace napsána a z toho plyne i větší cenová náročnost. [6] Grey-box testy Grey-Box testy stojí mezi dvěma předchozími a snaží se maximálně využít jejich výhod. Tester má přístup pouze k některým informacím o aplikaci, např. architektuře, způsobu nakládání s daty, ověřování uživatelů apod. a při testech se je snaží využít. [8] 3 Metodiky penetračního testování Zatímco samotné testování vyžaduje určitou kreativitu testera, přístup k testování by měl být jasně definovaný a konzistentní. Metodiky testování popisují, jaké jednotlivé kroky je vhodné dodržet, avšak neměly by testera omezovat v jeho intuici a kreativitě. [9] Základní struktura jednotlivých metodik je vždy stejná, ale různé zdroje uvádějí upravené metodiky dle vlastních zkušeností. 3.1 OSSTMM The Open Source Security Testing Methodology Manual (OSSTMM) je otevřená metodika, která popisuje kroky, jež je nutné dodržet během testování. OSSTMM rozděluje penetrační testování na 6 oblastí: síťové zabezpečení, bezpečnost informací, fyzické zabezpečení, zabezpečená komunikace, zabezpečení bezdrátových sítí a sociální inženýrství. Každá sekce obsahuje moduly zaměřené na konkrétní oblast testování a jsou v nich popsané jednotlivé testovací kroky. Množství použitých modulů se může měnit v závislosti na požadavcích. [10] Projekt zastřešuje a vydává nezisková organizace Institute for Security and Open Methodologies (ISECOM), která se zaměřuje na rozšiřování povědomí o počítačové bezpečnosti a výzkum v oblasti zabezpečení. [11] 12

13 3.2 OWASP web application security testing methodology The Open Web Application Security Project (OWASP) je nezisková organizace a komunita zabývající se bezpečností webových aplikací. Cílem OWASP je zdarma poskytovat jednotlivcům i organizacím informace a nástroje, které pomohou zvýšit jejich bezpečnost na internetu. Organizaci jde především o sdílení informací v komunitě a zakládá si na své nezávislosti, proto nepoužívá a nedoporučuje žádné komerční produkty nebo služby. Vydala také několik významných dokumentů. Jedním z nich je OWASP Top 10, který shromažďuje 10 nejkritičtějších zranitelností webových aplikací, popisuje, jak fungují a jak jim předejít. Detailněji je rozebrán v další kapitole. [12] Neméně důležitým dokumentem je OWASP testing guide. Ten detailně popisuje jednotlivé zranitelnosti a jak je otestovat. Je zde definována OWASP web application security testing methodology. Metodika je založena na principu black-box testování a je rozdělena na 2 fáze. První fáze se nazývá pasivní režim a je zaměřená na pochopení logiky aplikace, jaké má funkce a jak s ní lze komunikovat apod. Druhá fáze se nazývá aktivní režim a dále se rozděluje na 11 podkategorií. Tyto podkategorie obsahují celkem 91 jednotlivých testů, které se věnují jednotlivým zranitelnostem a popisují jak je testovat. [13] 3.3 NIST Technical Guide to Information Security Testing and Assessment Další model pro penetrační testování, jehož název je Technical guide to Information Security Testing and Assessment pochází od Národního institutu standardů a technologií USA (NIST). Tato příručka popisuje metodiku sestávající ze 4 fází. Na obrázku 3-1 je zobrazeno, jak na sebe jednotlivé fáze navazují. 13

14 Obrázek 3-1: Čtyřfázová metodika dle NIST (Zdroj: [14]) Plánování V této fázi se na základě obecných zadání definuje rozsah testu, určí se detailnější a prioritní cíle, které se budou testovat, většinou totiž není možné otestovat úplně vše na 100 %. [14] Průzkum Ve fázi průzkumu je potřeba zjistit o testované aplikaci co nejvíce informací. V závislosti na typu testu (black box, grey box, white box) se liší informace, které potřebujeme znát. Typicky zjišťujeme např. použitý programovací jazyk, Framework, webový server a operační systém na kterém běží. [14] Útok V této fázi probíhá skenování testované aplikace, testování zabezpečení a pokusy o prolomení bezpečnostních mechanismů. Hlavním cílem útoku může být např. získání přihlašovacích údajů, eskalace uživatelských práv, přihlášení do aplikace bez validních přihlašovacích údajů nebo získání citlivých informací. [14] Report Jak je patrné z obrázku 1, fáze reportu probíhá souběžně s ostatními. Během fáze průzkumu a útoku jsou jednotlivé zprávy z útoku hlášeny správci nebo majiteli dané aplikace. Finálním výstupem celého testu je dokument, obsahující popis nalezených zranitelností, hodnocení jejich závažnosti a doporučení pro jejich odstranění. [14] 14

15 4 OWASP Top 10 OWASP Top 10 je dokument vydaný organizací OWASP (The Open Web Application Security Project), který popisuje 10 nejvýznamnějších zranitelností, vyskytujících se ve webových aplikacích a zároveň způsob, jak jim předejít. Cílem tohoto projektu je zvýšit povědomí o bezpečnosti webových aplikací a poučit vývojáře, designéry i manažery o důsledcích bezpečnostních slabin aplikací. Poprvé byl OWASP Top 10 vydán v roce 2004 a další verze poté vycházely po 3 letech. Nejnovější verze, ze které vychází tato práce je z roku Žebříček u každé zranitelnosti hodnotí a popisuje pět jejích atributů, a to jak technický, tak i následný obchodní dopad na postiženou společnost. [15] Obrázek 4-1: Schematické zobrazení cesty útoku (Zdroj: [15]) Průvodci hrozby Termín průvodci hrozby označuje jednotlivce nebo skupiny, které můžou zranitelnost nějakým způsobem zneužít a ohrozit tak společnost. Tyto skupiny a jednotlivci mohou být rozděleni následovně: Bez určení cíle: Mezi tyto průvodce hrozby patří počítačové viry, červy, trojské koně a logické bomby. Zaměstnanci: Pracovníci, dodavatelé, provozní personál nebo bezpečnostní služba, kteří jsou naštvaní na společnost. Organizovaný zločin: Zločinci se zaměřují na informace, které pro ně mají hodnotu, jako jsou bankovní účty, kreditní karty nebo duševní vlastnictví, které se dá zpeněžit. Zločinci často využívají vnitřní pracovníky, aby jim pomohli proniknout do společnosti. 15

16 Společnosti: Konkurenční společnosti nebo i jejich partneři. Člověk neúmyslně: Nehody, neopatrnost. Člověk úmyslně: Vnitřní pracovníci nebo vnější útočníci. Přírodní pohromy: Například záplavy, požár, úder blesku, pád meteoritu, zemětřesení. [16] Vektor útoku Vektor útoku je cesta nebo způsob, který může útočník použít k průniku do systému. Mnoho z nich využívá známá slabá místa aplikací, některé zneužívají i lidský faktor, který je často nejslabším článkem systému. [17] Bezpečnostní slabiny Bezpečnostní slabina je díra nebo slabina v zabezpečení aplikace, která může vzniknout už v době návrh nebo při implementaci a útočník ji pak může zneužít pro poškození zainteresovaných stran v aplikaci. Těmi jsou jak majitelé a provozovatelé aplikace, tak i její uživatelé a ostatní subjekty, které na danou aplikaci spoléhají. [18] Technické dopady Technický dopad popisuje dopad na systém v případě úspěšného útoku. Jedná se například o ohrožení důvěryhodnosti, integrity a dostupnosti systému. [19] Obchodní dopady Obchodní dopad udává, jaký dopad bude mít úspěšný útok na společnost z obchodního hlediska. Obecně se jedná o ztrátu financí, reputace, zákazníků. [20] 4.1 OWASP Top V této kapitole je popsáno 10 nejkritičtějších zranitelností webových aplikací roku 2013 tak, jak je uvádí OWASP Top 10 z roku A1 Injection A2 Broken Authentication and Session Management A3 Cross-Site Scripting (XSS) A4 Insecure Direct Object References 16

17 A5 Security Misconfiguration A6 Sensitive Data Exposure A7 Missing Function Level Access Control A8 Cross-Site Request Forgery (CSRF) A9 Using Known Vulnerable Components A10 Unvalidated Redirects and Forwards A1 Injection K chybám tohoto typu, jakými jsou např. SQL a LDAP injection, dochází, když jsou nedůvěryhodná data poslána přímo do interpretru jako součást příkazu nebo dotazu. Útočník tak může v interpretru vykonat vlastní kód a přistupovat tak k datům bez řádné autorizace. [15] SQL injection SQL injection je metoda, kdy útočník vloží vlastní kód SQL dotazu do vstupu na webové stránce (formulář, URL adresa, HTTP hlavička). Pokud vstupy na webové stránce nejsou správně ošetřeny, útočníkův kód se předá databázovému (DBMS) a ten ho vykoná. Při úspěšné injekci může útočník číst a modifikovat databázová data, provádět administrátorské operace s databází (jako je vypnutí DBMS), zobrazit obsah souboru ve filesystému DBMS a v některých případech spouštět příkazy operačního systému. [21] Průvodci hrozby Útočníkem může být kdokoliv, kdo má možnost posílat do systému nedůvěryhodná data, včetně externích a interních uživatelů a administrátorů. Vektor útoku Útočník odesílá textové příkazy, které zneužívají syntaxi cílového interpretru. Vektorem útoku může být téměř každý zdroj dat, včetně interních zdrojů. Bezpečnostní slabiny Chyby typu injection se objevují velmi často v zastaralém kódu, který se stále používá. Dají se nalézt v SQL, LDAP, Xpath nebo NoSQL dotazech, příkazech operačního sytému, XML parserech, SMTP hlavičkách, argumentech programu, atd. Zranitelnost se 17

18 dá snadno odhalit prozkoumáním zdrojového kódu, ale poměrně obtížně se zjišťuje testováním aplikace. S tím v dnešní době mohou pomoci automatizované nástroje a skenery. Technické dopady Injekce může vést ke ztrátě dat, narušení integrity, nebo až k úplnému převzetí kontroly nad serverem. Obchodní dopady Musíme brát v úvahu obchodní hodnotu dat, která mohou být ohrožena (upravena, vymazána) A2 Broken Authentication and Session Management Aplikační funkce spojené s autentizací a správou relací často nejsou implementovány správně, což útočníkům umožňuje kompromitovat hesla, klíče nebo tokeny relací, nebo jinak zneužít chyby k vydávání se za jiného uživatele. [15] Průvodci hrozby Zde je potřeba brát v úvahu anonymní externí útočníky i uživatele s vlastními účty, kteří mohou ukrást účty jiných uživatelů. Vektor útoku Útočník využívá trhlin v autentizaci nebo v použitých funkcích pro správu relace (např. nechráněná hesla, identifikátory relace) k tomu, aby se vydával za jiného uživatele. Bezpečnostní slabiny Vývojáři často vytváří vlastní schéma pro ověření uživatele a správu relace. Navrhnout bezpečné řešení není triviální záležitostí, a proto vlastní pokusy často vedou k chybám v oblastech, jako jsou odhlášení uživatele, správa hesel, zapamatování přihlášeného uživatele, bezpečnostní otázky, aktualizace profilu, atd. Hledání takových zranitelností může být obtížné, pokud je implementace unikátní. 18

19 Technické dopady Může být ohroženo mnoho, nebo dokonce všechny účty na serveru. Útočník může provádět vše, co skutečný majitel účtu. Častým cílem jsou administrátorské a jinak privilegované účty. Obchodní dopady Je třeba uvážit, jakou hodnotu mají dotčená data a informace a také obchodní dopad případného zveřejnění zranitelnosti A3 Cross-Site Scripting (XSS) Chyby typu XSS se vyskytují, když aplikace posílá nedůvěryhodná data přímo do internetového prohlížeče uživatele bez řádného ověření nebo ošetření. Chyba umožňuje útočníkovi spouštět skripty v prohlížeči oběti a tak např. ukrást relaci uživatele, pozměnit webové stránky, nebo přesměrovat uživatele na nebezpečné stránky. [15] Průvodci hrozby Útočníkem může být kdokoliv, kdo má možnost posílat do systému nedůvěryhodná data, včetně externích a interních uživatelů a administrátorů. Vektor útoku Útočník posílá textové skripty, které exploitují interpretr v prohlížeči. Vektorem útoku může být téměř každý zdroj dat, včetně interních zdrojů, jako jsou data uložená v databázi. Bezpečnostní slabiny XSS je nejrozšířenější bezpečnostní chyba objevující se ve webových aplikacích. K XSS chybě může dojít, pokud aplikace umožňuje uživatelům přidat na stránku obsah, který pak bez kontroly zobrazuje dalším uživatelům. XSS se dělí do 3 základních kategorií: perzistentní kód je v aplikaci uložen neperzistentní kód je vložen v URL adrese 19

20 DOM based XSS škodlivý kód je vložen pomocí manipulace s DOMem 2 stránky Technické dopady Útočník může ukrást relaci uživatele, změnit vzhled stránek, vkládat škodlivý obsah, přesměrovat uživatele, atd. Obchodní dopady Je potřeba zvážit hodnotu postiženého systému a dat, které zpracovává. Také je třeba brát v úvahu, jaký dopad může mít zveřejnění zranitelnosti A4 Insecure Direct Object References Nezabezpečený odkaz na objekt se objevuje, pokud aplikace umožňuje přistoupit k objektu na základě vstupu od uživatele nebo např. parametru v URL adrese. Uživatel pak může snadno takový parametr změnit a získat neoprávněný přístup k datům. [15] Průvodci hrozby Zde je třeba si uvědomit, jaké typy uživatelů používají daný systém a zda by někteří z nich neměli mít přístup pouze částečný přístup k některým datům. Vektor útoku Útočník, který je uživatelem systému, změní hodnotu parametru, který odkazuje na objekt, ke kterému by neměl mít přístup. Bezpečnostní slabiny Aplikace často používají k vygenerování stránky skutečný klíč nebo název nějakého objektu a ne vždy ověřují, zda je uživatel oprávněn k cílovému objektu přistupovat. Technické dopady Taková chyba může zpřístupnit všechna data, která na která se dá odkázat parametrem. Pokud jsou klíče předvídatelné, útočník může snadno získat přístup ke všem takovým datům. 2 Document Object Model je rozhraní, které popisuje obsah a strukturu HTML dokumentu v podobě stromu [22] 20

21 Obchodní dopady Je třeba vzít v úvahu obchodní hodnotu vystavených dat a také dopad odhalení zranitelnosti veřejnosti A5 Security Misconfiguration Zabezpečení aplikace vyžaduje řádnou konfiguraci použitých nástrojů, frameworků, aplikačních serverů, webových serverů a databázových serverů. Výchozí hodnoty v nastavení často nejsou bezpečné, a proto by měly být správně nakonfigurovány a udržovány. [15] Průvodci hrozby Zde je potřeba brát v úvahu anonymní externí útočníky i uživatele s vlastními účty, kteří se mohou pokusit kompromitovat systém. Vektor útoku Útočník může získat přístup do systému použitím výchozích přihlašovacích údajů, zneužitím nepoužívaných stránek, neopravených chyb nebo nechráněnými adresáři a soubory. Bezpečnostní slabiny K chybě může dojít na každé úrovni aplikace, jako jsou platforma, webový server, databáze, framework a vlastní kód. Vývojáři a systémoví administrátoři musí pracovat společně na správné konfiguraci systému. Technické dopady Chyby tohoto typu poskytují útočníkovi přístup k některým systémovým souborům nebo funkcím. Obchodní dopady Systém může být zcela kompromitován bez vědomí správce. Data mohou být ukradena nebo postupně měněna a náklady spojené s obnovou se mohou být značné. 21

22 4.1.6 A6 Sensitive Data Exposure Tato zranitelnost se objevuje, když aplikace nesprávně uchovává citlivá data, jako např. bankovní údaje, hesla, rodná čísla, zdravotní záznamy a jiné osobní údaje. Data tohoto typu vyžadují zvláštní ochranu, jako je šifrování dat nebo řízení přístupu k zálohám. [15] Průvodci hrozby Je třeba vzít v úvahu všechny, kdo mají přístup k citlivým datům a jejich případným zálohám. Jedná se o uložená data, ale i o přenášená data a data uložená v prohlížečích uživatelů. Vektor útoku Útočník většinou neprolomí přímo šifrování, ale zaměří se například na krádež šifrovacích klíčů nebo nešifrovaných dat. Bezpečnostní slabiny Tato zranitelnost se vyskytuje v případě, kdy nejsou citlivá data šifrována nebo jsou použity slabé šifrovací klíče a algoritmy. Technické dopady Chyba často kompromituje všechna data, která by měla být chráněna. Typicky osobní údaje, kreditní karty, atd. Obchodní dopady Je potřeba zvážit obchodní hodnotu odcizených dat a dopad na důvěryhodnost A7 Missing Function Level Access Control Většina webových aplikací řeší úroveň přístupu k dané funkci tím, že danou funkci nezobrazí neoprávněnému uživateli. Každá dostupná funkce musí mít ověřovat přístupová práva i na serveru. Jestliže požadavek odeslaný na server není řádně ověřen, může toho útočník zneužít a používat tak administrátorské funkce. [15] 22

23 Průvodci hrozby Kdokoliv, s přístupem k síti, ve které aplikace běží, jí může poslat požadavek. Je třeba zvážit, zda může anonymní uživatel používat dané funkce. Vektor útoku Útočník, který je autorizovaným uživatelem aplikace, změní URL adresu a v případě nedostatečné kontroly oprávnění může využít funkci, na kterou adresa odkazuje. Bezpečnostní slabiny Někdy je úroveň přístupu k funkcím špatně nakonfigurována a vývojáři zapomenou kontrolu implementovat. Technické dopady Zranitelnost umožňuje útočníkovi neoprávněný přístup k funkcím. Administrační funkce jsou hlavním cílem takových útoků. Obchodní dopady Je nutné zvážit hodnotu dostupných funkcí a dat, se kterými pracují. Také je třeba brát v úvahu dopad na reputaci v případě zveřejnění chyby A8 Cross-Site request Forgery (CSRF) CSRF útok přiměje prohlížeč uživatele, přihlášeného ke zranitelné stránce, k odeslání podvrženého HTTP požadavku. K takovému požadavku jsou automaticky připojeny session cookies 3, hlavičky a jiné ověřovací informace oběti. Pro zranitelnou aplikaci se pak takový požadavek tváří jako regulérní akce uživatele. [15] Průvodci hrozby Kdokoliv, kdo může podstrčit obsah do prohlížeče uživatele a donutit je tak odeslat požadavek na stránku. 3 Session cookies jsou soubory, obsahující identifikátor relace uživatele 23

24 Vektor útoku Útočník vytvoří podvržený HTTP požadavek a různými podvodnými metodami ho odešle z prohlížeče oběti. Útok uspěje, pokud je uživatel ke zranitelné aplikaci přihlášen. Bezpečnostní slabiny CSRF využívá toho, že prohlížeč automaticky odesílá některé identifikační údaje, např. cookies. Útočník tak může generovat požadavky, které jsou k nerozeznání od oprávněných. Technické dopady Útočník může oběť přimět, aby provedla operaci, ke které má přístup, jako např. změnit údaje na účtu, nakupovat, odhlásit nebo přihlásit uživatele. Obchodní dopady Je třeba zvážit hodnotu dotčených dat a funkcí. Zranitelnost může mít také velký dopad na pověst A9 Using Known Vulnerable Components Používané komponenty, jako jsou knihovny, frameworky a jiné softwarové moduly jsou většinou na severu spouštěny se všemi právy. V případě exploitace 4 zranitelné komponenty může takový útok vést k vážné ztrátě dat nebo ovládnutí serveru útočníkem. Aplikace, používající komponenty, se známými zranitelnostmi mohou oslabit aplikační obranu a umožnit řadu možných útoků. [15] Průvodci hrozby Některé zranitelné komponenty mohou být identifikovány a zneužity za pomoci automatizovaných nástrojů, což značně rozšiřuje skupinu možných útočníků. Vektor útoku Útočník odhalí zranitelnou komponentu automatickými nástroji nebo manuální analýzou a tu poté zneužije. 4 Zneužití zranitelnosti ve webové aplikaci nebo programu. 24

25 Bezpečnostní slabiny Mnoho aplikací má tyto nedostatky, protože spousta vývojářů používá starší verze knihoven. Vývojáři někdy ani nevědí, jaké všechny komponenty aplikace používá, a závislosti mezi komponentami situaci ještě zhoršují. Technické dopady Mohou se vyskytovat jakékoliv zranitelnosti, jako jsou XSS, injection, atd. Dopad na aplikaci se tak pohybuje od minimálního až po úplné převzetí kontroly nad systémem. Obchodní dopady Je třeba zvážit, jaká dopad může mít každá zranitelnost na postiženou společnost A10 Unvalidated Redirects and Forwards Webová aplikace často přesměrovávají uživatele na jiné stránky a používají nedůvěryhodné údaje k určení cílové stránky. Bez řádného ověření může útočník přesměrovat oběť na podvodnou nebo jinak nebezpečnou stránku nebo použít předávané údaje k neoprávněnému přístupu na stránky. Průvodci hrozby Bereme v úvahu každého, kdo může přimět uživatele odeslat požadavek dané aplikaci. Vektor útoku Útočník vytvoří odkaz na neověřené přesměrování a přiměje uživatele, aby na něj kliknul. Takový odkaz vypadá, že vede na důvěryhodnou stránku a tak uživatel nemusí poznat rozdíl. Bezpečnostní slabiny Webové aplikace často přesměrovávají uživatele jinam a někdy je cílová adresa uvedena v neošetřeném parametru, který umožní útočníkovi cílovou adresu podvrhnout. 25

26 Technické dopady Chyba může vést k instalaci malwaru 5, nebo odhalení uživatelského hesla a jiných informací. Obchodní dopady V případě úspěšného útoku je možné ztratit důvěru uživatelů a je tedy třeba se zamyslet nad její hodnotou. 5 Penetrační testování vybraných webových aplikací V této kapitole je popsán průběh samotného penetračního testování vybraných webových aplikací. Test byl proveden podle metodiky definované v Technical guide to Information Security Testing and Assessment od NIST, která byla popsána v kapitole 3.3. V první části kapitoly je popsán plán testu a jeho cíle. Je zde zahrnut i výběr vhodných nástrojů, použitých pro testování. V další části je popsána fáze útoku a analýza zranitelností pro webovou aplikaci edotace. V kapitole Report jsou popsány nalezené zranitelnosti pro jednotlivé webové aplikace a doporučení pro jejich odstranění. 5.1 Plánování V rámci penetračních testů budou otestovány následující aplikace: Informační systém Krajského úřadu Kraje Vysočina eambulance kraje Vysočina edotace kraje Vysočina emedocs Rowanet Analýza všech aplikací bude provedena jako white-box testy z pozice vnějšího útočníka prostřednictvím sítě internet. Z hlediska míry automatizace budou testy probíhat poloautomatizovaně za použití nástrojů popsaných dále. Aplikace budou testovány na 10 nejrozšířenějších zranitelností, popsaných v dokumentu OWASP Top Označení pro škodlivý počítačový program. 26

27 5.1.1 Informace o testovaných aplikacích Informační systém Krajského úřadu Kraje Vysočina ( Tento informační systém se podle určujících kritérií [23] řadí mezi významné informační systémy 6, na něž jsou podle zákona o kybernetické bezpečnosti [3] kladeny větší bezpečnostní požadavky a z toho důvodu mu byla v mém testu věnována největší pozornost. eambulance kraje Vysočina ( eambulance slouží jako rozcestník ke službám v krajském zdravotnickém systému, které lze obsluhovat prostřednictvím internetu. Uživatelé se tam mohou objednat do ambulancí krajských nemocnic apod. edotace kraje Vysočina ( Aplikace edotace slouží k zobrazení všech dostupných dotací a pro jejich elektronické vyřizování. emedocs ( Informační stránka projektu emedocs (Exchange Medical Documets System), který buduje a rozšiřuje komunikační strukturu pro bezpečnou a důvěryhodnou výměnu zdravotnické dokumentace mezi zdravotnickými zařízeními v rámci zdravotnického systému České Republiky. Rowanet ( Tato aplikace slouží jako informační stránka o projektu ROWANet, který má na starost páteřní optickou datovou síť veřejné správy v kraji Vysočina Popis a výběr použitých nástrojů Pro celkový sken různých zranitelností jsem vybíral z 2 dostupných komerčních nástrojů: Rapid7 Nexpose a Tenable Nessus. Oba nástroje nabízejí širokou škálu možností a nastavení pro bezpečnostní analýzu a oba je možno zdarma vyzkoušet. V mých testech jsem se rozhodl použít Nessus, protože má menší hardwarové nároky 6 Významný informační systém má zásadní význam pro fungování veřejné správy 27

28 a celkově mi přišel rychlejší. V případě, že by bylo potřeba pokračovat v testech po uplynutí zkušební doby také Nessus vychází cenově výhodněji. Pro důkladnější testování některých zranitelností budou použity specializované nástroje na daný problém. Pro otestování SQL injection bude použit SQL map, který podporuje testy velkého množství útoků pro různé databázové systémy. K odhalení XSS zranitelností bude použit doplněk do prohlížeče HackBar, který usnadňuje vkládání různě kódovaných příkazů na stránku, dále bude použit nástroj XSSer, který automaticky hledá a testuje zranitelnosti typu XSS. K dalším detekcím bude použit nástroj Burp Suite, který funguje jako lokální proxy server, přes který probíhá komunikace s webovou aplikací. To nám umožňuje monitorovat a upravovat zasílané HTTP požadavky. Mimo to má Burp Suite další nástroje pro zmapování struktury aplikace, opakované zasílání požadavků s různými parametry a placená verze obsahuje automatický skener zranitelností. 5.2 Průzkum V této fázi je potřeba zjistit o aplikaci co nejvíce informací a udělat si tak přehled, jaké typy zranitelností se mohou vyskytnout a kde je hledat. Adresářová struktura aplikace Pro zjištění adresářové struktury aplikace jsem používal nástroj Burp Suit, konkrétně tedy jeho modul Spider, který slouží právě k tomuto účelu. 28

29 Obrázek 5-1: Výstup skenování aplikace nástrojem Burp Suite (Zdroj: autor) Na obrázku 5-1 vidíme soubory a adresáře, které dokázal Burp Suite najít, zároveň vidíme, jaké požadavky byly odesílány k jejich detekci. Z adresářové struktury si můžeme udělat poměrně dobrou představu o tom, jak aplikace funguje, jaká data kde odesílá, s jakými parametry pracuje apod. Automatický sken zranitelností a identifikace použitých technologií Dalším krokem je spuštění automatické detekce zranitelností. K tomuto účelu použiji nástroj Nessus, nastavený pro testování webových aplikací. V nástroji lze nastavit, jestli chceme provést rychlý, nebo důkladný test. Zde byl použit méně důkladný test, který poskytuje dobrý náhled na zranitelná místa v aplikaci v přiměřené době. 29

30 Obrázek 5-2: Zranitelnosti identifikované nástrojem Nessus (Zdroj: autor) 30

31 Na obrázku 5-2 je vidět, že skener detekoval několik zranitelností a rozdělil je podle závažnosti. Mimo to ale skener detekoval i jiné důležité informace: Webový server: Apache, verze PHP verze Útok Ve fázi útoku je třeba prověřit nálezy ze skeneru, který jsme použili v předchozí fázi a otestovat další citlivá místa aplikace A1 Injection U analýzy zranitelnosti typu injection je třeba nejprve identifikovat všechny vstupy aplikace. K tomu se dá dobře využít výstup z nástroje Burp Suite, který byl použit ve fázi průzkumu a kromě adresářové struktury zaznamenal i všechny HTTP požadavky i s jejich parametry. Penetrační tester tak může na základě zkušeností a intuice vybrat, které parametry je vhodné dále testovat. Obrázek 5-3: HTTP požadavky testované na SQL injection (Zdroj: autor) 31

32 Na obrázku 5-3 jsou zvýrazněny požadavky, které jsem se rozhodl postoupit dalšímu testování nástrojem SQLmap. Jako první byl otestován požadavek na URL který metodou GET přebírá parametry akce a val zadané přímo v URL adrese. Nástroj SQLmap byl spuštěn příkazem: sqlmap -u " --time-sec 10 b kde přepínač -time-sec nastavuje dobu čekání pří detekci injection podle doby odezvy, -b určuje, že SQLmap při úspěšné injekci zjistí pouze uvítací zprávu DBMS a podle ní určí, o který typ databázového systému se jedná. První provedený test dopadl neúspěšně a nebyla nalezena žádná zranitelnost. Stejně tak dopadl druhý test, na URL Dále byl testován požadavek na URL s POST parametry sub a hledej, který slouží k vyhledávání na stránkách edotací. Nástroj SQLmap byl v tomhle případě upraven do tvaru: sqlmap -u " -- data="sub=hledej&hledej=test" -b --time-sec 10 -p hledej kde přepínač -p určuje, které parametry se mají testovat. Obrázek 5-4: Výstup nástroje SQLmap po nalezení SQL injection (Zdroj: autor) Z obrázku 5-4 je patrné, že útok byl tentokrát úspěšný a detekoval zranitelnost SQL injection typu stacked queries, cože je typ útoku, kdy se za korektní SQL dotaz vloží další, který se vykoná také. Zranitelnost byla odhalena metodou tzv. blind SQL 32

33 injection, která spočívá v použití SQL funkce pro pozastavení běhu a porovnává se doba trvání dotazu. Tohoto typu testu se využívá v případech, kdy na stránce, ani v kódu, není žádný viditelný výstup, odtud tedy blind injection (naslepo). Zranitelnost lze vyzkoušet přímo na stránce, zadáním testovacího payloadu 7 do pole pro vyhledávání. Obrázek 5-5: Ověření blind SQL injection pomocí Tamper Data (Zdroj: autor) A2 Broken Authentication and Session Management Testovaná webová aplikace pří návštěvě nastavuje v prohlížeči cookies, obsahující tokeny relace. Pro analýzu náhodnosti těchto tokenů se dá využít modul sequencer nástroje Burp Suite. Nejprve je nutné nalézt požadavek, který do cookies ukládá hodnotu session id a předat ho sequenceru. Ten začne generovat velké množství požadavků a zachytávat tokeny. Poté Burp Suite předloží analýzu náhodnosti tokenů, analýzu na úrovni znaků a na úrovni bitů. 7 Část zprávy (požadavku), která obsahuje útočný kód 33

34 Obrázek 5-6: Analýza náhodnosti tokenů relace (Zdroj: autor) Graf na obrázku 5-6 znázorňuje náhodnost znaků na jednotlivých místech tokenu. Analýza byla provedena na základě 9177 tokenů. Z grafu nejsou patrné žádné anomálie, které by umožňovali útočníkovi odhadnout alespoň část tokenu A3 Cross-Site Scripting (XSS) Při testování zranitelností XSS je třeba identifikovat všechny vstupy, kde lze zadat škodlivý kód. Vstupy mohou být formulářové prvky na stránce, ale i parametry v HTTP požadavcích. Jako první test byl spuštěn nástroj XSSer, který automaticky prošel cílovou adresu a útočil na všechny identifikované vstupy. Program neodhalil žádné zranitelnosti. Na webu se nachází vyhledávací pole, které bylo podrobeno ručnímu testování. Bylo zjištěno, že po vyhledání výrazu se tento po odeslání promítne do parametru value daného formulářového prvku. 34

35 Obrázek 5-7: Zdrojový kód formuláře pro vyhledávání (Zdroj: autor) Ze zdrojového kódu stránky je vidět, že pro injektáž javascriptového kódu je nutné nejprve se dostat mimo kontext elementu input a poté až vložit samotný script. Testováním bylo zjištěno, že po zadání hledaného výrazu, např. "><script>alert(document.cookie);</script> dojde k vykonání scriptu. Pole pro vyhledávání tedy obsahuje zranitelnost XSS. Obrázek 5-8: Zneužití vyhledávacího pole pomocí XSS (zdroj: autor) Při použití nástroje Nessus byla odhalena veřejně dostupná stránka 8, na které je použita funkce phpinfo(). Tato funkce vypisuje na stránku informace o konfiguraci PHP na serveru, použitých modulech, operačním systému, cestách, kde se nachází konfigurační soubory, atd. Stránka sama nesděluje žádné kritické informace, ovšem některé z uvedených údajů se dají využít v jiných typech útoků. Z odhalené stránky je možné vyčíst, že na serveru je použito PHP ve verzi PHP interpretr ve verzích obsahuje ve funkci phpinfo() zranitelnost typu XSS 9. Za použití testovacího payloadu info.php?a[]=<script>alert(/xss/);</script>

36 lze pak jednoduše ověřit, že stránka je skutečně zranitelná. Obrázek 5-9: XSS zranitelnost ve funkci phpinfo (Zdroj: autor) A4 Insecure Direct Object References Zde musíme otestovat, zda v aplikaci existuje parametr, jehož změnou by bylo možné získat přístup neoprávněný přístup k datům. V aplikaci byla identifikována adresa pro ukládání souborů na základě jeho id: Změnami hodnoty parametru id bylo staženo několik souborů. Tyto soubory obsahovaly veřejně dostupné informace, přístupné i z webové stránky samotné. Zranitelnost tohoto typu zde nebyla objevena A5 Security Misconfiguration Při hledání zranitelností tohoto typu je vhodné pokusit se nalézt konfigurační stránku aplikace (serveru), nebo jiné, kde vyzkoušíme, zda nejsou ponechány výchozí přihlašovací údaje. Bylo zjištěno, že při zadání adresy server odpovídá stavovým kódem 403 Forbidden. Na požadovaném místě se tedy 36

37 zřejmě nachází nějaký konfigurační soubor, ke kterému nám ale webový server neumožňuje přistoupit. Analýzou nebylo zjištěno žádné chybné nastavení webového serveru nebo aplikace A6 Sensitive Data Exposure Při testování této chyby je třeba zmapovat všechny odkazy a ujistit se, že nevedou na citlivá data. Taková data se mohou vyskytovat i v podobě komentářů ve zdrojových kódech, mohou být předávána jako parametry HTTP požadavku, ukládána v cookies apod. K průzkumu zde byl použit Burp Suite, ve kterém jsme odhalili volně dostupné adresáře download/ a download/edotace/ Obrázek 5-10: Adresářový výpis volně dostupného adresáře (Zdroj: autor) 37

38 Po bližším prozkoumání nalezených dokumentů nebyla odhalena žádná citlivá data a adresář je zřejmě volně dostupný záměrně A7 Missing Function Level Access Control V testované webové aplikaci nelze bez přihlášení identifikovat žádné administrátorské funkce. Protože nemáme přístup k žádnému účtu, nebylo možné otestovat, zda jsou použité funkce dostatečně ošetřeny proti zneužití neautorizovaným uživatelem A8 Cross-Site Request Forgery (CSRF) V aplikaci byla bez přihlášení identifikována jedna akce, která by měla být chráněna proti zneužití metodou CSRF. Po provedení pokusu o přihlášení byl odeslaný HTTP požadavek zachycen nástrojem Burp Suite. Obrázek 5-11: HTTP požadavek, odesílaný po přihlášení (Zdroj: autor) Ze zachyceného požadavku můžeme vyčíst, že odesílá parametry jméno, heslo a submit. Neobsahuje tedy žádný token, který by formulář ochránil před neoprávněným odesláním A9 Using Known Vulnerable Components Pohledem do zdrojového kódu lze identifikovat použitý redakční systém Vismo5. Po provedení neplatného pokusu o přihlášení na adrese lze z chybové hlášky vyčíst, že pro autentizace je použit serverový modul mod_auth_sspi ve verzi

39 Použitím internetového vyhledávače a prohledáním databáze zranitelností Exploit Database 10 nebyly nalezeny žádné veřejně dostupné zranitelnosti a exploity pro tyto použité komponenty. Skener zranitelností Nessus, který byl použit ve fázi průzkumu identifikoval webový server Apache ve verzi a zároveň podal hlášení o tom, že tato verze obsahuje chybu HTTP Server Byte Range DoS, která zneužívá nedostatečné kontroly při použití HTTP hlavičky Range. Tato hlavička se používá např. pro stahování velkých souborů, které by se celé nevešly do jednoho požadavku. Parametr range pak udává, kterou část souboru od serveru požadujeme. Chyba spočívá v použití velkého množství rozsahů, webový server tak vytvoří velké množství kopií daného souboru a může zahltit celou paměť a vytížit procesor. Takový útok může vést až k odepření služby (DoS). [24] A10 Unvalidated Redirects and Forwards Prvním krokem při hledání zranitelností tohoto typu, je identifikace každého místa aplikace, kde dochází k přesměrování. Aplikace mlže uživatele přesměrovat na jinou stránku několika způsoby: [25] Server odpoví stavovým kódem 3xx a uvedenou hlavičkou Location, která specifikuje cíl přesměrování Odpověď serveru obsahuje hlavičku Refresh se zadanou cílovou adresou HTML tag <meta> může být použit pro simulaci HTTP hlavičky a nastavovat parametry Location a Refresh Přesměrování může být docíleno použitím javascriptu Dalším krokem je procházení webu a kontrola požadavků provedených na aktuální stránce skrz lokální proxy (např. Burp Suite). Pokud stránka obsahuje přesměrování, je třeba identifikovat, zda cílová adresa může být ovlivněna uživatelem. V aplikaci nebyla nalezena žádná přesměrování. 5.4 Report V této kapitole jsou popsány výsledky penetračního testování pro 5 testovaných webových aplikací. Ke každé zranitelnosti uvedeno doporučení k nápravě

40 5.4.1 edotace Test: Injection Cíl: Otestovat aplikaci na odolnost proti SQL injection. Zjištění: Aplikace obsahovala zranitelnost SQL injection. Zranitelná místa: o Vyhledávací formulář, nacházející se na úvodní stránce. Doporučení k nápravě: Pro vykonávání SQL dotazu využívat prepared statements, které definují strukturu dotazu a dosazené hodnoty samotný dotaz nemohou ovlivnit. Test: Session Management Cíl: Otestovat, zda jsou generované session tokeny dostatečně náhodné. Zjištění: Použitá funkce pro generování session tokenů splňuje požadavky a není možné token odhadnout. Zranitelná místa: - Doporučení k nápravě: - Test: Cross-Site Scripting (XSS) Cíl: Otestovat aplikaci na odolnost proti XSS. Zjištění: Aplikace obsahovala zranitelnosti typu XSS. Zranitelná místa: o Vyhledávací formulář, nacházející se na úvodní stránce. o Funkce phpinfo() na adrese Doporučení k nápravě: o Ošetřit vstup vyhledávacího pole převedením speciálních znaků na entity, např. použitím PHP funkce htmlspecialchars(). o Odstranit stránku využívající funkci phpinfo() a updatovat PHP na novější verzi Test: Insecure Direct Object References Cíl: Zjistit, zda uživatel může přistupovat k informacím, ke kterým by neměl. 40

41 Zjištění: Všechny privátní soubory jsou chráněny proti neoprávněnému přístupu. Zranitelná místa: - Doporučení k nápravě: - Test: Security Misconfiguration Cíl: Otestovat aplikaci a použité komponenty, jestli jsou správně nastaveny. Zjištění: Nebyla odhalena žádná chybná nastavení nebo nebezpečné výchozí hodnoty. Zranitelná místa: - Doporučení k nápravě: - Test: Sensitive Data Exposure Cíl: Otestovat, jestli se útočník může dostat k citlivým datům v aplikaci. Zjištění: Aplikace neumožňuje přístup k citlivým datům. Zranitelná místa: - Doporučení k nápravě: - Test: Missing Function Level Access Control Cíl: Otestovat ochranu aplikačních funkcí před neoprávněným přístupem. Zjištění: V aplikaci nebyly identifikovány žádné zneužitelné funkce. Zranitelná místa: - Doporučení k nápravě: - Test: Cross-Site Request Forgery (CSRF) Cíl: Otestovat aplikaci na odolnost proti CSRF. Zjištění: Aplikace byla náchylná na útok typu CSRF. Zranitelná místa: o Formulář pro přihlášení Doporučení k nápravě: Při odeslání formuláře připojit k požadavku náhodně generovaný token. Test: Using Known Vulnerable Components 41

42 Cíl: Otestovat aplikaci na veřejně známé a dostupné chyby. Zjištění: Aplikace obsahovala zranitelnost typu DoS. Zranitelná místa: o Použitá verze webového serveru Apache. Doporučení k nápravě: Aktualizovat Apache na novější verzi. Test: Unvalidated Redirects and Forwards Cíl: Otestovat aplikaci na přítomnost neošetřených přesměrování. Zjištění: Aplikace neobsahuje žádná zranitelná místa pro útok tohoto typu. Zranitelná místa: - Doporučení k nápravě: Informační systém Krajského úřadu Kraje Vysočina Test: Injection Cíl: Otestovat aplikaci na odolnost proti SQL injection. Zjištění: V aplikaci nebyla nalezena žádná chyba typu SQL injection. Zranitelná místa: - Doporučení k nápravě: - Test: Session Management Cíl: Otestovat, zda jsou generované session tokeny dostatečně náhodné. Zjištění: Použitá funkce pro generování session tokenů splňuje požadavky a není možné token odhadnout. Zranitelná místa: - Doporučení k nápravě: - Test: Cross-Site Scripting (XSS) Cíl: Otestovat aplikaci na odolnost proti XSS. Zjištění: V aplikaci nebyly odhaleny žádné zranitelnosti typu XSS. Zranitelná místa: - Doporučení k nápravě: - 42

43 Test: Insecure Direct Object References Cíl: Zjistit, zda uživatel může přistupovat k informacím, ke kterým by neměl. Zjištění: Všechny privátní soubory jsou chráněny proti neoprávněnému přístupu. Zranitelná místa: - Doporučení k nápravě: - Test: Security Misconfiguration Cíl: Otestovat aplikaci a použité komponenty, jestli jsou správně nastaveny. Zjištění: Nebyla odhalena žádná chybná nastavení nebo nebezpečné výchozí hodnoty. Zranitelná místa: - Doporučení k nápravě: - Test: Sensitive Data Exposure Cíl: Otestovat, jestli se útočník může dostat k citlivým datům v aplikaci. Zjištění: Aplikace neumožňuje přístup k citlivým datům. Zranitelná místa: - Doporučení k nápravě: - Test: Missing Function Level Access Control Cíl: Otestovat ochranu aplikačních funkcí před neoprávněným přístupem. Zjištění: V aplikaci nebyly identifikovány žádné zneužitelné funkce. Zranitelná místa: - Doporučení k nápravě: - Test: Cross-Site Request Forgery (CSRF) Cíl: Otestovat aplikaci na odolnost proti CSRF. Zjištění: Aplikace nebyla náchylná na útok CSRF. Zranitelná místa: - Doporučení k nápravě: - 43

44 Test: Using Known Vulnerable Components Cíl: Otestovat aplikaci na veřejně známé a dostupné chyby. Zjištění: Aplikace neobsahovala žádné zranitelné komponenty. Zranitelná místa: - Doporučení k nápravě: - Test: Unvalidated Redirects and Forwards Cíl: Otestovat aplikaci na přítomnost neošetřených přesměrování. Zjištění: Aplikace obsahovala přesměrování, které přebírá cílovou adresu z URL adresy. Zranitelná místa: o Formulář pro přihlášení, dostupný z přebírá z URL parametr ReturnUrl Doporučení k nápravě: Kontrolovat cílovou adresu proti seznamu povolených adres nebo domén eambulance Test: Injection Cíl: Otestovat aplikaci na odolnost proti SQL injection. Zjištění: V aplikaci nebyla nalezena žádná chyba typu SQL injection. Zranitelná místa: - Doporučení k nápravě: - Test: Session Management Cíl: Otestovat, zda jsou generované session tokeny dostatečně náhodné. Zjištění: Použitá funkce pro generování session tokenů splňuje požadavky a není možné token odhadnout. Zranitelná místa: - Doporučení k nápravě: - Test: Cross-Site Scripting (XSS) Cíl: Otestovat aplikaci na odolnost proti XSS. 44