Obsah
1
Testování zabezpečení webových aplikací Bakalářská práce
Vedoucí práce: Ing. Michael Štencl
Michal Vetr
Obsah
2
Rád bych na tomto místě poděkoval vedoucímu práce Ing. Michaelu Štenclovi, za cenné rady, konzultace a čas, které mi věnoval.
Obsah
3
Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně s použitím literatury a podkladů, které jsou uvedeny v práci. V Brně dne 20. května 2010
________________________
Obsah
4
Abstrakt Vetr, Michal. Web application security testing. Bachelor thesis. Brno, 2010. This bachelor thesis describes a comparison of selected techniques and applications designed to break web applications. Comparison focuses on basic testing in several areas. The work also includes designing applications for security testing. Keywords Web applications, PHP, MySQL, HTTP, testing, XSS, session theft, SQL injection, PHP Injection.
Abstrakt Vetr, Michal. Testování zabezpečení webových aplikací. Bakalářská práce. Brno, 2010. Tato bakalářská práce se zabývá popisem a porovnáním vybraných metod a aplikaci určených k prolomení webových aplikací. Porovnání je zaměřeno na základní testování v několika oblastech. Součástí práce je i navržení aplikace pro testování zabezpečení. Klíčová slova Webové aplikace, PHP, MySQL,HTTP, testování, XSS, krádež relace, SQL Injection, PHP Injection.
Obsah
5
Obsah 1 Úvod a cíl práce............................................................................................................6 1.1 Úvod........................................................................................................................6 1.2 Cíl práce...................................................................................................................7 2 Způsoby napadení webových aplikací ......................................................................8 2.1 HTTP.......................................................................................................................8 2.2 Soubory cookie........................................................................................................9 2.3 Relace....................................................................................................................10 2.4 Krádež relace.........................................................................................................11 2.5 Cross-site scripting................................................................................................11 2.6 SQL Injection........................................................................................................13 2.7 PHP Injection.........................................................................................................14 3 Bezpečnost webových aplikací..................................................................................16 3.1 Powerfuzzer...........................................................................................................16 3.2 WebScarab.............................................................................................................17 3.3 Selenium................................................................................................................18 3.4 Nikto 2...................................................................................................................19 3.5 Acunetix Web Vulnerability Scanner....................................................................20 4 Návrh vlastní aplikace...............................................................................................22 4.1 Princip funkce Crawleru........................................................................................22 4.2 Princip funkce Testeru...........................................................................................23 4.3 Princim funkce Kontroloru....................................................................................24 4.4 Kontrola Nikto2.....................................................................................................24 4.5 Ohrožení................................................................................................................24 5 Diskuze a závěr..........................................................................................................25 5.1 Diskuze .................................................................................................................25 5.2 Závěr......................................................................................................................25 Literatura.....................................................................................................................26 Přílohy...........................................................................................................................27
Diskuze a závěr
6
1 Úvod a cíl práce 1.1
Úvod
Tato práce se zabývá problematikou zabezpečení webových aplikací. Ze současného pohledu by se dala přirovnat k disciplíně, která by již v dnešní době měla být součásti tvorby jakékoliv webové aplikace, kde je požadován zpětný dialog s uživatelem. Pokud si tento fakt uvědomíme, zjistíme, že tvorba webových aplikací není nijak jednoduchá a že se jedná o poměrně složitý proces. Naprogramovat aplikaci dle zadání zákazníka a zajistit požadovanou funkčnost je věc jedna. Zabezpečit ji tak, aby odolala na nejrůznější druhy útoku, je úkol podstatně náročnější. Samotný jazyk HTML dokáže pouze na základě HTTP požadavku stránky pouze interpretovat webovému prohlížeči, tento postup dnes odpovídá statickým stránkám. Chceme-li nad stránkami provádět složitější operace, potřebujeme do webového místa začlenit některý ze skriptovacích jazyků, který z nich tvoří dynamickou aplikaci. Pro psaní takového kódu se dnes používají nástroje jako Java, PHP, PERL, ASP/VBScript a řada dalších. Právě díky nim jsme v dnešní době schopni nakoupit zboží v pohodlí svého domova, zkontrolovat stav svého účtu nebo rezervovat si nejbližší let do naši oblíbené destinace. Když už je aplikace schopná poskytnout nám tyto služby, je zřejmé že musí uchovávat obrovské množství dat, jako jsou podrobné údaje objednávek s nimi souvisí údaje o různém druhu zboží, které prostřednictvím aplikace nabízeno a tímto způsobem by se dalo pokračovat. Dat je tedy mnoho a je třeba nad nimi udržovat určitou logiku, než aby se bezhlavě ukládala do souboru a později se pomocí řízeni aplikace z těchto umístění vyvolávala. Pro tyto účely vznikly tzv. databázové systémy, díky nim a použití SQL jazyka se práce s daty stala řízená, kontrolovatelná a mnohem pohodlnější. V dnešní době existuje celá řada komerčních i open-source variant, které můžeme pro naší práci využít. Výběr aplikačních nástrojů pro realizaci webových aplikací je dnes velice široký. Pro programátora vyvstává otázka v jakém jazyce svoji aplikaci napsat, je jich nepřeberné množství a každý z nich má nějaké výhody, na druhou stranu se v nich mohou objevit nuance na které by jsme si měli pozor. Stejná situace panuje na poli databázových systémů, asi nejznámější představitele jsou Oracle, PostgreSQL a MySQL. Jedná se o relační databázové systémy, takže každý z nich respektuje stejné
Diskuze a závěr
7
pravidla pro tvorbu databáze. Mimo relační databáze se začínají objevovat systémy, které jsou tzv. dokumentově orientované nebo NoSQL, takové systémy neakceptuji relační model ve vysoké normální formě, nýbrž se jedná o poměrně nestrukturované shluky dat s plochou strukturou. Pokud si dáme všechny tyto technologie dohromady dostaneme minimální potřebný základ pro dnešní webové aplikace. Zde je dobré si uvědomit, že každá mince má dvě strany. Díky těmto technologiím získáváme kvalitní prostředky, pomocí nichž jsme schopni realizovat naše projekty, ale také při neopatrné nebo nepromýšlené manipulaci s nimi mohou mít důsledky našeho počínaní přímo fatální dopad. Ve většině případů, a však tento problém nemají za vinu použité prostředky, nýbrž sám tvůrce aplikace, tyto dopady jsou povětšinou výsledkem nedokonalé znalosti, nepochopením nebo leností.
1.2
Cíl práce
Cílem této práce je navrhnout webové prostředí pro testování zabezpečení webových aplikací realizovaných v PHP a MySQL. S tímto cílem souvisí nutnost vytvořit přehled dostupných metod, kterými jsou aplikace nejčastěji napadány a přehled nástrojů pro testování zabezpečení využívajících těchto metod k prolomení.
Diskuze a závěr
8
2 Způsoby napadení webových aplikací Webové aplikace již několik let zaznamenávají neutuchající rozvoj a zájem. S postupným rozvojem byly nasazovány různé technologie, které větší či menší měrou ovlivňují vzhled nebo funkčnost aplikace. Nesmí nás tedy zarazit, že se prostředky těchto aplikací staly prostředky promýšlených a zákeřných útoků. Při tom mnohdy, aby jsme těmto problémům předešly stačí pouze aby měl tvůrce aplikace kvalitní znalosti těchto základních prostředků.
2.1
HTTP
Protokol HTTP je základním kamenem internetu jak jej známe dnes, právě díky němu zaznamenal takový rozvoj. Při tom se lze domnívat, že tato obliba vznikla právě díky jeho jednoduchosti. Pokud je z webového prohlížeče zaslán požadavek na zobrazení kódu některé stránky, připojí se ke vzdálenému serveru uvedenému v adrese URL. Jakmile se naváže spojení TCP zašle prohlížeč požadavek HTTP, kterým si vyžádá od serveru soubor dokumentu. Webový prohlížeč zašle obsah stránky a spojení uzavře. Díky tomu , že je protokol řádkový a bezstavový se v komunikaci může vyskytnout několik ideálních případu pro manipulaci s požadavky, které jsou serveru posílány. V protokolu HTTP existuje několik druhu požadavků, z toho nejdůležitější jsou GET a POST. Metoda GET je asi nejpoužívanější vůbec, její použití je nejčastější v případech chceme-li nahrát některou webovou stránku ze strany serveru. Již při zadaní nazvu stránky do URL řádku prohlížeče se použije požadavek typu GET. Důležitější je že případné data, která je potřeba předat k dalšímu zpracování, jsou posílána jako parametry v URL řádku prohlížeče. Nejčastější použití metody Post je v případě odesílaní formulářů na webu, způsob předání dat je podobný jako u metody GET, ačkoliv parametry se nezobrazují přímo v URL řádku, nýbrž jsou předávána v těle požadavku. Další rozdíl spočívá v opakovaném odesílání dat, u metody GET lze data opakovaně odesílat, např. při zmáčknutí klávesy zpět, při placení účtu by jsme mohli zaplatit dvakrát a proto použití teto metody v tomto kontextu není zrovna moc vhodné. Metoda POST toto nedovolí a vybídne uživatele o potvrzení takovéto akce.
Diskuze a závěr
9
Z těchto příčin vyplývá jednoduché pravidlo: Pokud naší akci chceme vyvolat nějakou akci na serveru, jako je třeba změna souboru v adresářové struktuře nebo zapsaní dat do databáze, měli by jsme vždy používat metodu POST.(Huseby, 2006) Řádkovou orientaci si protokol http vypůjčil od protokolu telnet, vzhledem k tomuto faktu dnes lze vzužít k připojeni na webový server program telnet. Pro takový způsob komunikace nepotřebujeme zvláštní vybaveni stačí nám pouze zadat do konzole unixového systému:
telnet www.seznam.cz 80 Jakmile se zdaří připojení stačí už pouze napsat základní řádky http požadavku:
GET / HTTP/1.1 Host: www.seznam.cz Server seznam.cz nám ochotně odpoví hlavičkami následovanými kořenovým dokumentem HTML. Na místo použití programu telnetu lze napsat program, který se dá lehce nastavit a bude tuto činnost vykonávat automaticky. Těchto programů je na internetu dostupná spousta. Některé lze používat jako webové služby a pouze vypisují dotaz a odpověď serveru, nebo se může jednat o programy které fungují jako prostředník mezi webovým prohlížečem a serverem. Takové programy umožňují měnit parametry požadavku, před tím než jsou odeslány serveru. Pokud vezmeme v potaz tento fakt, musíme přijmout další pravidlo pro tvorbu webových aplikací: Z hlediska serveru neexistuje bezpečný klient. (Huseby, 2006)
2.2
Soubory cookie
Problematika souboru cookie, opět přímo souvisí s bezstavovostí HTTP protokolu, díky ní nikdy neexistuje žádná kontinuita mezi jednotlivými požadavky klienta. Po splnění požadavku server i klient zapomenou, že spolu kdy mluvily. S postupně rostoucí potřebou autentizace se hodilo, aby si server stav mezi jednotlivými požadavky pamatoval aspoň po nějaký čas. Pomocí cookie server, žádá klienta aby si pamatoval krátkou informaci. V následující komunikaci pak klient v každém požadavku tuto informaci zasílá. K zasílaní souborů cookie se přímo používají hlavičky http, pro
Diskuze a závěr
10
nastavení souboru server použije hlavičku SET-Cookie, samotná hlavička tohoto požadavku může vypadat následovně:
Set-Cookie: Gtestss =QDniaqAu9AT2aW5sPf7; Path=/; Expires=Tue, 27 Oct 2015 10:00:59 GMT Takováto hlavička obsahuje soubor s názvem Gtestss a hodnotou, kterému je nastavena zakódovaná hodnota, následuje cesta kam se má soubor zasílat a čas kdy bude soubor zneplatněn. Nejdůležitější je asi hodnota Gtestss neboť klient nemá žádné tušení co by mohla tato metoda znamenat, slepě ji pouze posílá zpět. Programátoři většinou s cookie většinou přímo nepracují, používají ke své tvorbě nějaké API, to ale neznamená že je ke své práci nepoužívá server. Pokud klient zakáže svoje cookie, je pravděpodobně že se mu na většině serveru nepodaří autorizace, neboť ti většinou používají k implementaci relací.
2.3
Relace
Relace je kolekce proměnných, která dohromady tvoří stav[1]. Tyto proměnné na serveru sami o sobě ještě netvoří plnohodnotnou relaci. Nejdůležitějším prvkem je (session ID) tedy identifikátor relace. Tyto údaje je zapotřebí nějakým způsobem dopravit ke klientovi a asociovat je s ním. To lze realizovat hned několika způsoby, předáním v URL pomocí metody GET. Toto řešení ale nebývá moc šťastné, neboť tím naservírujeme SID přímo pod nos potencionálního útočníka. Pohodlnějším způsobem předaní je uložit jej do souboru cookie. V jazyce PHP jsou relace velmi dobře implementovány a práce s nimi je po určitém nastudování docela jednoduchá. Pomocí funkce session_start() lze jednoduše relaci inicializovat, naopak session_destroy() odstraní všechna data relace. K super globálním proměnným se lze dostat pomoci $_SESSION['promenna']. Nutno podotknout, že to jestli se bude SID ukládat do URL nebo souboru cookie, záleží na nastavení serveru. Je-li povoleno na straně klienta zaznamenávání do souboru cookie, aplikace se sama rozhodne je-li třeba předávat identifikátor relace metodou GET. I přes vkládání identifikátoru není nás aplikace nemůže zcela ochránit před krádeží relace.
Diskuze a závěr
2.4
11
Krádež relace
Drtivá většina dnešních aplikací používá k identifikaci uživatele, právě prostředek vytvoření relace. Uživatel vstoupí na stránku s webovým formulářem a je vybídnut k zadání svého uživatelského jména a hesla, po té je ve většině případů vytvořena relace a zaslána první odpověď s nastavením cookie souboru v kterém je zapsán identifikátor relace. Nyní je velice důležité, aby se identifikátor žádným způsobem nedostal do rukou útočníka. Tem má k dispozici hned několik způsobů jak se ho zmocnit. Nejprimitivnějším způsobem je SID uhodnout, spočítat si jej, zkusit metodu pokus omyl. Velice zajímavý příklad, který se dal v minulosti zpozorovat bylo, že si útočník naprogramoval funkci na odesílaní cookies do oblíbeného rozšíření webového prohlížeče a umístil jej jako vylepšenou verzi na stránky těchto rozšíření. Funkce sama reagovala pouze na jednu webovou aplikaci, kterou chtěl útočník napadnout, a po přihlášení do této aplikace zasílala na adresu útočníka přímo hlavičky s nastavenými cookies. Tímto způsobem se bez sebemenších problému dostal k identifikátoru několika procent lidí, kteří používaly tento prohlížeč v kombinaci s jeho upraveným rozšířením. Nevyjdou-li tyto pokusy, nebo útočník není až tak zdatný programátor může se pokusit relaci ukradnout pomocí asi nejpoužívanější metody útoku cross-site scripting.
2.5
Cross-site scripting
Cross-site scripting je metoda narušení WWW stránek využitím bezpečnostních chyb ve skriptech (především neošetřené vstupy). Útočník díky těmto chybám v zabezpečení webové aplikace dokáže do stránek podstrčit svůj vlastní javascriptový kód, což může využít buď pouze k poškození vzhledu stránky, jejímu znefunkčnění anebo dokonce k získávání citlivých údajů návštěvníků stránek, obcházení bezpečnostních prvků aplikace a phishingu. (Tichý,2008) Ačkoliv se problematice cros-site scriptingu věnujě nepřeberné množství publikací, je zranitelnost pomocí této metody i nadále jednou z nejčastějších chyb při psaní webových aplikací. Udělat chybu v aplikaci je při tom velice jednoduché, stačí když se utočníkovy podaří do napadené stránky vložit vlastní HTML kód, který je následně zobrazen v prohlížeči. Příklad takové bezpečnostní díry může nastat v následujícím případě:
Diskuze a závěr
12
Priklad XSS utoku Priklad stranky obsahujicí xss chybu
Stránka se v prohlížeči zobrazí, tak že na první pohled vypadá úplně neškodně.
Obr. 1
Jednoduchá aplikace zranitelná pomoci XSS
Pokud vložíme do URL řádku prohlížeče za koncovku souboru xss.php řetězec ? id=
Takto vypada uspesny xss utok
. Vypíše se v prohlížeči řetězec naformátovaný jako nadpis první úrovně.
Diskuze a závěr
Obr. 2
13
Stránka s injectovaným html řetězcem
Tento typ útoku se označuje jako lokální nebo DOM based. Nejlépe jej lze využít na stránkách kde je neošetřený přenesení proměnné z URL adresy. Non-persistentí druh útoku je postaven na podobném způsobu úpravy URL, v tom je ale umístěný škodlivý javascriptový kód, který po provedení požadavku změní obsah stránky a ten je poslezé zobrazen uživateli. S persistentním útokem se můžeme nejčastěji setkat v diskuzních fórech, návštěvních knihách, komentářích k článkům, prostě všude tam kde uživatel nějakým způsobem může vložit natrvalo nějaký vstup. Pokud tento vstup není na serveru dostatečně kontrolován může dojít ke vložení nebezpečného scriptu. Největší nebezpečí tohoto útoku spočívá v tom, že se script spustí všem uživatelům kteří si stránku s daným příspěvek prohlíží.
2.6
SQL Injection
Drtivá většina dynamicky generovaných webových aplikací používá pro uchování, odeslaní a zpětné vyvolání dat jeden nebo více subsystémů. Mezi těmito subsystémy, jako jsou třeba operační systém, dokumenty XML, knihovny nebo i prohlížeče používané uživateli, je databázový systém založený na jazyku SQL. Komunikace s uživatelem probíhá pomocí vytváření řetězců, které mohou obsahovat nějaké řídící informace a data. Subsystém obsahuje parser, který tyto data znak po znaku dekóduje a v závislosti na tom co parser přečte se provede nějaká akce. Pojem a popis problému s názvem SQL Injection se poprvé objevil v článku od Raina Foresta Puppyho v časopise Phrack Magazine v roce 1998[1]. Pomocí využítí této bezpečnostní díry je utočník schopen měnit či zadávat dotazy, které jsou odesílány do databáze. Manipulace se vstupními daty je přímo umožněna prostřednictvím formulářů nebo jiných vstupů, které se ve webové aplikaci mohou
Diskuze a závěr
14
vyskytovat. Pokud jsou tyto vstupy neošetřeny, útočník dokáže podvrhnout vstupní data a tím měnit výsledek celého dotazu. Díky takovému počínaní je schopen dostat se k údajům, které by jsme za normálních okolnosti chtěli držet v tajnosti, nebo vymazat databázi či tabulku.
2.7
PHP Injection
Tento způsob napadení se týká aplikací, které nemají ošetřenou inkluzi jiných stránek. Programátor si vytvoří nejčastěji jednu šablonovou stránku index.php do které později pomocí klauzule include vkládá obsahy jiných sekcí webu. Tento postup mu ušetří psaní záhlaví, patičky menu a jiných náležitostí, které jsou pro většinu stránek v jeho aplikaci stejné. V případě že programátor použil neošetřenou klauzuli include, vypadá URL adresa v prohližeči následovně:
http://www.mojestránka.cz/index.php?page=news.php Někde do volného místa stránky index.php je vložená stránka news.php, prakticky se z pohledu interpretru PHP provede zdrojový kód index.php a následovně kód stránky news.php. Podobně jako u Cross-site scriptingu k napadnutí této stránky stačí pozměnit URL řádek například následovně:
http://www.mojestránka.cz/index.php? page=http://www.seznam.cz Pokud se objeví na stránce titulní stránka seznamu.cz chyba existuje. Této chyb může útočník využít tak, že si napíše jednoduchý script:
Tento soubor umístí jako script.txt na některý freehostingový webový server. Nyní už pouze stačí upravit URL řádek napadané aplikace:
Diskuze a závěr
15
http://www.mojestránka.cz/index.php? page=http://utok.wz.cz/script.txt Takže se zobrazí kompletní zdrojový kód indexu.php. Tímto způsobem je útočník schopen se prokousat až třeba ke scriptu, který navazuje spojení s databázovým serverem.
Diskuze a závěr
16
3 Bezpečnost webových aplikací Výčet způsobů útoků v předešlé kapitole není konečný, existují i další způsoby jak nějakou aplikaci nabourat. Avšak techniky popsané výše by měli být základním kamenem každé aplikace testující bezpečnost webových aplikací. Tyto programy bývají buť volně dostupné, tvořeny skupinkami nadšených vývojářů, nebo jsou nabízené společnostmi, které se vývojem testovacího software zabývají. Tyto aplikace jsou v následující kapitole probrány a také je popsána jejich funkčnost.
3.1
Powerfuzzer
Program napsaný v pythonu, dostupný jako open-source a založený na mnoha dalších open-source fuzzerech. Informace sbírá z mnoha bezpečnostních zdrojů a webových stránek. Je schopný projít stránku a identifikovat vstupy, dále identifikovat běžná webová slabá místa (XSS, SQL injection). Podporuje https. Komerční verze je dostupná jako online služba.(Softwaregateset, 2010)
Obr. 3
Výsledek testu programu Powerfuzzer
Po spuštění programu se vytvoří dialogové okno, Velká textová část vypisuje uživateli informace o tom co program právě provádí. Pod textovou částí se nacházejí různé formulářové pole díky nimž se dá průběh testu ovlivňovat. Takto je uživatel
Diskuze a závěr
17
schopný programu předat nastavení proxy serveru, podvrhnout cookie soubor nebo zadat uživatelské jméno nebo heslo. Nejdůležitější je pole Target URL, slouží pro vložení URL adresy aplikace, jenž se má otestovat. Po stisknutí tlačítka „Scan” program začne mapovat přiloženou adresu URL, po té je provedena zkouška útoku XSS a SQL injection. Po dokončení testu se zobrazí okno informující uživatele o nalezených chybách.
3.2
WebScarab
WebScarab je framework pro analyzu aplikaci, které komunikují za použití protokolu HTTP a HTTPS. Je napsaný v Javě, a tedy portovatelný na mnoho platforem. WebScarab má několik operačních módu, implementovaných počtem pluginů. V nejběžnějším použití, WebScarab operuje jako záchytný proxy, který umožňuje operátorovy vidět a modifikovat požadavky vytvořené prohlížečem před tím než jsou odeslány na server, a k zobrazeni a modifikaci odpovědi vrácené ze serveru předtím než jsou obdržené prohlížečem.(OWASP, 2010)
Obr. 4
Filtrování komunikace pomoci programu WebScarab
Po stažení a rozbalení archivu se, je třeba nastavit webový prohlížeč, aby používal spojení pomoci proxy serveru. Jako parametr serveru vyhovuje localhost a port 8008. Po potvrzeni a spuštění WebScarabu již veškerá komunikace probíhá prostřednictvím
Diskuze a závěr
18
aplikace. Pokud chceme editovat požadavky a odpovědi stačí na záložce Intercept zatrhnout Intercept requests. Nyní již máme nad celou komunikaci kontrolu. Po zadaní adresy nám v průběhu komunikace vyskakuji okna umožňující editaci jednotlivých kriterii požadavků.
3.3
Selenium
Framework pro testování webových aplikací napsaný v Pythonu a dostupný jako rozšíření webového prohlížeče firefox. . Framework otevře v prohlížeč, DOMu zasílá události a emuluje chování uživatele. Každá akce provedená při nahrávaní pomocí frameworku je zobrazena v tabulce hlavního okna. Na záložce 'source' lze prohlížet zdrojový kód testu ve formatu HTML.(Selenium HQ, 2010)
Obr. 5
Test case přihlašovacího rozhraní s pokusem o sql injection
Pomocí nabídky Options - Format lze zobrazení zdrojového kódu testu měnit do několika programovacích jazyků např. Java, C#, Python, Perl i PHP. Selenium nám takto umožňuje vytvářet case testy, kterými můžeme zkoušet funkčnost aplikace nebo je aplikovat jako pokus o její prolomení. Tento kód je posléze připraven k použití s rozšířením Selenium Core, které běží jako HTTP proxy a díky němuž lze, podobně jako u programu WebScarab, jednotlivé testy spouštět na různých prohlížečích.
Diskuze a závěr
3.4
19
Nikto 2
Nikto je Open Source (GPL) web server scanner, dostupný pro GNU/Linux, který provádí všeobecný test proti webovému serveru. Test obsahuje množství případu prolomení včetně 6100 potencionálně nebezpečných souborů/CGI, kontroluje neaktualizované verze programového vybavení serveru a verze se specifickým problémem. Dále se zaměřuje na konfigurační problémy jako je přítomnost několika index souboru, nastavení HTTP serveru a snaží se identifikovat instalované webové služby a software. Jeho použitelnost zvyšuje fakt, že položky a pluginy jsou často updatované. Není navržený jako moc neviditelný nástroj. Otestuje web server v co možná nejrychlejším čase a je poměrně viditelný v log souborech.(Cirt.net,2010) Program není vybaven GUI rozhraním, po rozbalení archivu se stačí přemístit do složky programu a spustit příkaz:
./nikto.pl -host http://nazev.proverovaneho.serveru:80 Tímto způsobem lze spustit test serveru na požadovaném portu, ten zobrazí kompletní informace o serveru, jako jsou třeba ip adresa, nainstalované konfigurace, nastavení apache aj. Na příkladu zobrazeném v obrázku je začátek výpisu demonstrován. Zajímavý úkazem povolené metody HTTP, kde je upozornění na metodu TRACE, které by se dalo využít při typu útoku Cross-site Tracing (XST). Dále upozorňuje na starší verze programů zajišťující šifrovaní ssl vrstvy. Následně se pustí do procházení adresářové struktury daného umístění, při nalezení podezřelého scriptu upozorní na možnost útoku pomocí metody Cross-site scripting, HTML injection nebo SQL injeciton.
Diskuze a závěr
Obr. 6
20
Výstup programu Nikto2
Program Nikto dvě je komplexní nástroj na prověření celého webového umístění. To že je volně ke stažení je jeho velkou výhodou i možné riziko. Potencionální útočník díky jeho použití je schopný zjistit poměrně hodné informaci o místě kam by se chtěl vlámat. I když na počátku bylo zmíněno, že je jeho přítomnost jednoduše zjistitelná v různých log souborech, pomocí parametru -evasion+ jej lze spustit v módu kdy je schopný uniknout intrusion detection systému. Čímž by se administrátor nemusel vůbec o jeho přítomnosti.
3.5
Acunetix Web Vulnerability Scanner
Komerční program společnosti Acunetix, je dostupný ve free verzi na stránkách výrobce pro operační systém Windows. V placené verzi dokáže automaticky zkontrolovat webovou aplikaci na slabiny jakými jsou SQL Injection, cross-site scripting, arbitární tvorbu/mazání souborů, slabou silu hesel na přihlašovacích stránkách. Ve free verzi nabízí pouze scan pro zjištění cross-site scripting slabosti. A pro spuštění je nutnost nainstalovaní Microsoft SQL serveru 2005, v souvislosti s touto závislostí je schopný vytvářet podrobné reporty jednotlivých scanu.
Diskuze a závěr
Obr. 7
21
Výsledek scanu programu Acunetxi Web Vulnerability Scanner
Demonstrace probíhala na free verzi programu, ten nám tedy podal informace pouze o zranitelnosti xss. Program má velice komplexní grafické rozhraní. Po stisknuti tlačítka 'New Scan' se zobrazí průvodce nastavení scanovaní, lze vybrat z několika různých typu. Scanování jednotlivé aplikace, z listu webových aplikací nebo rozsah ip adress. Pří výběru Scan signle website, stačí zadat URL, testované aplikace. V dalším dialogu se již zobrazí informace kompletní informace o serveru, jak tomu bylo případě programu Nikto2. Následují Crawling options a Scan options, zde lze vybrat z několik různých modů, kterými se má scan provést. Po nastavení požadovaných atributů se spustí scan, nad jehož průběhem má uživatel realný přehled. Po ukončení scanu se zobrazí výsledky s informacemi o variantách provedených útoků. V záznamovém listu lze procházet, na kterém scriptu byl útok proveden a do jaké hodnoty byl škodlivý řetězec podsunut. V postraním okně jsou podrobné informace o http hlavičkách tzn. v jaké hlavičce byl script podsunut a jaká byla odpověď serveru.
Diskuze a závěr
22
4 Návrh vlastní aplikace Vyčet aplikací dostupných či nabízených komerčními firmami není konečný, tyto aplikace byly vybrány s ohledem na druh prováděných testování. Kromě toho, že jsou všechny vytvořené pro nedestruktivní testování webových aplikací, jejich použití se vztahuje na desktopové prostředí. Program společností Acunetix nabízí komplexní řešení v případě zakoupení plné verze, Nikto2 zase dokáže na problém pouze poukázat, Powerfuzzer zase zkoumá problémy spojené s XSS nebo SQL injection. V současné době se tedy lze jen zřídka setkat s aplikací, která by byla schopná poskytnout základní informace o bezpečnostním stavu jeho aplikace. Pokud již takovou aplikaci najde, je vázán na instalaci na určitou platformu, nebo mu nejsou poskytnuté dostatečné informace o stavu bezpečnosti. Vývojář sám by neměl být nucen se rozhodovat mezi různými operačními systémy, zda bude užívat Windows, Linux čí Macintosh. Vývojář by měl vyvíjet. Situace je ulehčená i tím, že pokud se jedná o vývojáře webové aplikace, je jeho primárním zájmem, to co se zobrazí ve webovém prohlížeči. Tento fakt je přímo závislý na běhovém prostředí serveru a podíváme-li se na nabídku současných hostingových poskytovatelů dostaneme se k závěrů, že většina nabízí služby hyper textového procesoru PHP a databázového systém MySQL. Proto by bylo logické navrhnout vývojáři aplikaci, kterou by si mohl portovat kamkoliv sebou a rozuměl by jejímu kódu. Aplikace navržená v rámci této práce se snaží v co možná největší míře tyto požadavky splnit a proto využívá služby těchto systémů. Jedná se o webový bezpečnostní systém využívajících poznatků získaných studiem výše zmiňovaných bezpečnostních programů. Pro kontrolu běhového prostředí webového místa bylo využito programu Nikto2, o cílené prověření bezpečnosti vyvíjené aplikace se stará algoritmus fungující na principu Crawlera.
4.1
Princip funkce Crawleru
Crawler je script, který se připojí na na webovou stránku specifikovanou uživatelem. Po připojení hledá na stránce přítomnost tagu
