První krok

Nesmíte zapomenout na samozřejmé věci. Každé penetrační testování by mělo začít kontrolou portů. Rychlá kontrola programem nmap následovaná nástrojem pro kontrolu zranitelností např. Nessus. U webových serverů by se nemělo zapomenout ani na nástroj Nikto, který může ušetřit mnoho práce rutinních kontrol.

Nástroje

Před tím než začnete testovat, musíte si nachystat správné nástroje. Jeden takový již máte po ruce - internetový prohlížeč. Pokud používáte Firefoxu, můžete použít několik užitečných rozšíření, které ušetří spoustu času.

Podívejte se hlavně na tato rozšíření:

• Web Developer toolbar - praktický nástroj pro každého vývojáře webových aplikací. Na testy se bude hodit hlavně kvůli možnosti přímé editace webových formulářů (odstranění limitu na počet znaků nebo vyplnění zamknutých polí).
• Hackbar - nástroj pro dekódování Base64 kódování a znaků kódovaných do URL.
• SwitchProxy Tool - šikovný nástroj pro snadné přepínání proxy serverů, pokud se rozhodnete nějaké používat
• Add N Edit Cookies - editor cookies umožňuje přímou editaci údajů uložených v cookies.
• Tamper Data - podobně jako proxy server umožňuje odchytávat požadavky i odpovědi. A navíc je i modifikovat.

Těchto několik rozšíření Vám umožní rychle otestovat webovou aplikaci. Nicméně pro některé pokročilejší techniky je vhodný proxy server. Pravděpodobně tím nejlepším proxy serverem zdarma pro účely auditu je WebScarab.

Přípravy

Ještě než začnete, nastavte si prohlížeč tak, aby zobrazoval skrytá formulářová pole, komentáře a ignorovat znaková omezení vstupních polí. Stáčí k tomu několik kroků konfigurace přes Web Developer Toolbar:

1. V nabídce Options vyberte Persist Features. Další volby se uloží a zůstanou nastavené trvale i pro další navštívené stránky.
2. V nabidce Miscellaneous vyberte Show Hidden Elements a stejně tak i Show Comments.
3. V nabídce Forms vyberte Make Form Fields Writable a Remove Maximum Length. A možná můžete rovnou vybrat i Convert POST to GET nastavení, které se bude hodit později.

Jako rychlý test si zkuste projít stránky, které se chystáte testovat. Uvidíte žluté vykřičníky na místech, kde jsou komentáře. Aktuální verze Web Developer Toolbaru obsahuje chybu díky které se nemusí zobrazit všechna skrytá formulářová pole (lepší je použít proxy WebScarab, která je zviditelní a také je umožní editovat).

V nejhorším případě naleznete v komentářích heslo nebo název účtu. Potom je celý audit u konce, protože můžete snadno ukázat zranitelnost celého serveru.

Bezpečnostní audit

S prohlížečem a nainstalovanými nástroji jste plně ozbrojeni a můžete se pustit do auditu. Kroky popsané níže jsou v takovém pořadí, v jakém je pravděpodobně, že povedou nejrychleji k nějakým výsledkům.

robots.txt

Nebo také mapa zranitelností. Soubor robots.txt bývá často pochopen špatně. Tento soubor totiž neslouží k ochraně nebo skrývání obsahu. Používá se pouze pro způsobné vyhledávače, aby nedocházelo k indexaci obsahu, který nemá být indexován. Správný soubor robots.txt obsahuje adresáře s obrázky nebo dynamicky generovaný obsah, který nefunguje, pokud na něj přistupuje vyhledávací robot. Špatný soubor zobrazí i adresu pro administraci stránek, webové přístupové logy a podobně.

Pokud se podíváte na všechny adresy uvedené v robots.txt, uvidíte na čem jste. Narazíte-li na statistiky přístupů, podívejte se po administrační sekci webu. Pokud nenajdete očividně pojmenovaný adresář admin, hledejte takový adresář, kam přistupuje pouze několik IP adres.

K úspěchu Vám nyní může stačit i stránka, která je součástí administrace, ale nemá přístup chráněný jménem a heslem. A na každé stránce chráněné jménem a heslem zkuste několik kombinací jména a hesla, ale neztrácejte tím moc času, na test máte jen hodinku.

XSS

Ne každá XSS zranitelnost je jednoduše zneužitelná, nicméně tento typ útoku patří k těm nejrozšířenějším. Vyzkoušejte nějaký vstup a pokud narazíte na chybové hlášky, je pravděpodobné, že vstupy nejsou dostatečně ošetřeny. Zkuste vložit ">" jako vyhledávací řetězec a podívejte se na výsledek.

Pokud tento dotaz změní stránku nebo naruší formátování formuláře, pokračujte zadáním následujícího kódu:

"><script>alert("xss")</script>

I když neuvidíte zobrazené okno, zkuste najít zadaný kód ve stránce. Prozkoumejte, jak se aplikace chová k jednoduchým uvozovkám ', většina aplikací totiž ošetřuje pouze klasické uvozovky ("). Pokud se snažíte o narušení JavaScriptu, testujte pouze jednoduché uvozovky: '.

Během určené hodiny se snažíme o zjištění problémů, ne o jejich zneužití. Velmi častý problém je nedostatečné ošetření dat vložených v databázi. Stačí založit nový účet a použít > nebo podobný znak v názvu ulice nebo města. Tak se většinou dá získat cookie administrátora, který kontroluje objednávky či registrace.

SQL injection

V tomto případě je scénář velmi podobný předchozímu u XSS. Začněte vkládat jednoduché uvozovky do různých políček formuláře. Jako indikátor SQL injection uvidíte v odpovědi SQL error. Z něj se dá zjistit podstata problému. Některé stránky se snaží o skrývání databázových chyb, v tomto případě se pokuste domyslet korektní, ale špatný SQL dotaz. Například, když dostanete chybu při dotazu: stranka.html?id=1′, tak zkuste stranka.html?id=1%20or%201, stranka.html?id=1′%20or′1′=′1 nebo stranka.html?id=1-- a překontrolujte si, zda stále vidíte chyby. Pokud máte podezření na zranitelnost SQL injection, zkuste použít nástroj Paros. Kromě obvyklých uvozovek zkuste i dvě pomlčky (--), středník (;) nebo čárku (,).

Cookies a skrytá pole

Cookies a skrytá pole jsou další formou uživatelského vstupu. I když většina webových vývojářů se k nim takovýmto způsobem nechová a těmto datům plně důvěřuje. Pokud stále hledáte nějakou formu útoku, zkuste vložit jednoduché uvozovky a znaky z XSS. K tomu budete potřebovat rozšíření Add N Edit Cookies. Web Developer toolbar umožní editaci skrytých polí ve formulářích.

Sessions

Často naleznete vývojáře, kteří pro vývoj se sessions používají standardní nástroje - v tomto případě jsou většinou bezpečné. Na druhou stranu narazíte i na vývojáře, kteří se snaží používat podomácku vyrobené nástroje pro práci se sessions a tady máte šanci. Podívejte se na session ID, vypadá jako náhodně generovaný řetězec? Trošku si s ním pohrajte. Odstraňte nějaké znaky, nějaké přidejte. Opět zkuste přidat jednoduché uvozovky nebo XSS znaky. Je text odstraněn?

Pokud je session ID číselné, zkuste jej nahradit dalším číslem. Také zkuste zvýšit obě poslední dvě číslice o 1 (pokud je poslední číslice kontrolní součet). Není možné nějakým způsobem získat cizí session? A nakonec je možné, že se Vaše Session ID změní po přihlášení. V ideálním případě se vygeneruje nové session ID pro každou další požadovanou stránku. Webscarab může s analýzou sessoin ID pomoci, pokud se chcete zanořit hlouběji. Jednou z jeho výhod je další analýza požadavků vyměňovaných mezi prohlížečem a serverem (mezi tyto funkce patří i analýza session ID).

Google Hacking

Podívejte se na Google a zkuste si zjistit, co ví o celém webu. Můžete Google omezit přidáním operátoru site: (site:example.com) do vyhledávání. Zkuste hledat řetězce: sql, error, password nebo cvv2.

Hromadné stahování

Spusťte wget -m http://www.example.com/ a zkopírujte tak obraz celého webu. Nástroj wget vytvoří adresář s názvem serveru. Použijte grep pro nalezení chyb, komentářů nebo jiných chybových hlášek. Tento úkon lze dělat i přes Google, nicméně grep je podrobnější.

Uvědomte si, že stejně jako vyhledávač Google, tak i wget dbá na soubor robots.txt. V tomto bodě je již potřeba, abyste se seznámili podrobněji s testovanou aplikací. Google může pomoci při hledání výchozích umístění konfiguračních souborů (např. global.asa) nebo administrativních sekcí konkrétních webových aplikací.

Závěr

Tyto testy vyhledávají hlavně zjevné problémy a objeví většinou obecnější problémy. Zanedbávají další časté problémy jako například response-splitting nebo sekundární SQL injection. Stejně tak se příliš nezabývaly dalším využitím nalezených zranitelností. Zmíněné testy by měly sloužit spíše k pravidelnému testování. Stejně tak může sloužit jako studijní materiál programátorům webových aplikací. Nejlépe provádějte testování s vývojářem, aby si uvědomil nutnost ošetření vstupních dat.

Důkladné testování je lepší dělat přímo na zdrojovém kódu webové aplikace. Opět je vhodné, pokud bude vývojář u testování a bude mít možnost na testování spolupracovat. Se zdrojovým kódem je možné jednodušeji ověřit problém a odhadnout jeho dopad.

Při nalezení problémů v aplikaci by nemělo jít pouze o nápravu nalezených chyb. Stejně tak by se měla vyvinou strategie dalšího vývoje a definovat taková opatření, aby se jim v budoucnosti předcházelo. Pro každou webovou aplikaci je vhodné vytvořit sadu bezpečnostních funkcí, které se budou konzistentně používat v celé aplikaci.

The SANS Technology Institute - Web Application Auditing Over Lunch