Jak na bezpečnostní testy

Bezpečnostní test je typem funkčního testu, který má za úkol odhalit možné slabiny testovaného systému proti útoku hackerem, a tím snížit pravděpodobnost a úspěšnost napadení. Podobně jako u jiných typů funkčních testů, i tady rozeznáváme fáze test analýzy, test designu, test exekuce a vyhodnocení testu.
Bezpečnostní testy by měl připravit a vykonat specialista na tento typ testů, nicméně ve fázi test analýzy bude nutně potřebovat pomoc od test analytika, znalého funkcí testovaného systému.


Před začátkem bezpečnostního testu je nutné informovat všechny dotčené strany o začátků testů, případně si od nich vyžádat i písemný souhlas (třeba pokud děláte v rámci testu i reverse engineering aplikace, autoři kódu mohou od vás požadovat nějakou písemnou záruku, že informace nezneužijete a po skončení testů veškeré získané informace smažete).
Výjimkou může být situace, pokud v rámci bezpečnostního testu zkoušíte i nějakou formu sociálního inženýrství (jak "odolní" jsou uživatelé systému - jestli třeba prozradí své heslo na základě smyšleného e-mailu od "administrátorů") - tehdy můžete některé skupiny z informování  o připravovaném testu vynechat.

Nyní rozeberu jednotlivé fáze podrobněji:

1. Test analýza

Úkolem v této fázi je identifikovat motivaci útočníka (co získá, když nějakým způsobem "hackne" aplikaci) a motivaci zákazníka (jak bude poškozen, pokud útočník provede v systému "nepřípustné" akce), abyste dostali seznam rizik, které musíte podchytit.

U hackera jsou to nejčastěji tyto důvody:

• osobní prospěch (podvodné transakce, získání přístupu k neautorizovaným informacím, falšování identity, ovládnutí cizího počítače, pomsta bývalému zaměstnavateli...)
• získání citlivých informací pro třetí stranu (jména, rodná čísla, adresy, telefony, čísla kreditních karet, průmyslová špionáž...)
• znefunkčnění systému pro jiné zákazníky (pro osobní uspokojení hackera, konkurenční boj...)

Zákazník se může obávat například:

• úniku citlivých informací
• finančních podvodů (např. hacker si je schopen objednat z eshopu produkt za uměle sníženou cenu a zákazník je tudíž poškozen)
• manipulace s účty jiných uživatelů (hacker se přihlásí do elektronického bankovnictví jako jiný uživatel a vybílí mu účet...)
• poškození dobrého jména firmy (kupříkladu nahrazení firemní webové prezentace stránkami hackera)
• zneužití systému zaměstnanci

Čím přesněji identifikujete rizika, tím lépe můžete zaměřit testy bezpečnosti na jednotlivé funkční části systému (a nebudete plýtvat energií na málo rizikové věci).

V této fázi může dokonce vyplynout, že nemá smysl plýtvat penězi na bezpečnostní test, pokud je riziko napadení nízké, nelze způsobit velkou škodu, nebo se dá systém rychle a snadno vrátit do původní podoby (pravidelně zálohované statické HTML stránky atd.)

Pokud máte seznam rizik, měl by analytik znalý funkčnosti systému začít spolupracovat s odborníkem na bezpečnostní testy, aby společně identifikovali možné "nebezpečné objekty" ať již přímo v aplikaci, nebo v síťové infrastruktuře - případně v lidských zdrojích používajících danou aplikaci.
Třeba když víte, že rizikem je získání neautorizovaných informací, soustředíte se na autentizaci a autorizaci uživatele (login formulář, přístup na chráněné stránky, "obejití" logiky aplikace přes URL parametry, vymámení hesla od uživatelů atd.).

Výstupem fáze test analýzy by měl být tedy přesný seznam rizik a rizikových objektů, které budou předmětem bezpečnostního testu.
Seznam si dejte schválit (kvůli rozsahu testování - a tudíž i objemu práce a k tomu určených financí).

2. Test design

V rámci test analýzy jste získali seznam rizikových objektů a rizik, ve fázi test designu budete hledat způsoby, jak konkrétní riziko na konkrétním objektu naplnit (třeba pokud máte nějaký webový formulář a jde vám o získání cookies příhlášených uživatelů, zkusíte na jednotlivých polích formuláře cross-site scripting).
Test design by měl dělat bezpečnostní odborník. Pokud ho nemáte, zaměřte se alespoň na "školácké bezpečnostní chyby". Mezi obecně nejnebezpečnější místa v aplikacích patří vstupy od uživatelů a vstupní body cizích systémů (URL, webové služby...), takže největší pozor si dejte na:

1. validaci polí na formulářích - přes 90% průniků do aplikací je způsobeno tím, že se nevalidují hodnoty v polích; pak lze do polí zadávat třeba javascriptový kód, SQL kód, (nepovolené) HTML tagy, příliš velké hodnoty parametrů (přetečení proměnných), nenumerické znaky do numerických polí... Obzvlášť si dejte pozor, pokud je validace na webové stránce zajištěna skriptem na straně klienta - tuto kontrolu lze snadno obejít a pokud parametry nevaliduje i server, problém je na světě.
2. manipulaci s parametry posílanými na server (ať již v POST datech, v URL nebo XML požadavcích webové služby) - pokud se třeba posílá pro konkrétního přihlášeného uživatele request na https://mujserver.orderProduct?userid=32&product =33 a vy URL změníte na https://mujserver.orderProduct?userid=33&product =33 a produkt se vloží na objednávku uživatele s ID 33, je to špatně (stejně tak si v tomto případě můžete pohrát s SQL injection do jednotlivých parametrů; obecně je z hlediska bezpečnosti nevhodné pojmenovávat parametry v dotazech tak, že se dá snadno "odhadnout" jejich význam).
3. přílišnou nápovědu hackerovi ve viditelném kódu nebo v aplikaci (třeba ve zdrojovém kódu webstránky jsou zapomenuté "programátorské" komentáře k jednotlivým funkcím, nebo při přihlašovacím dialogu vám systém řekne, jestli máte špatně login, nebo jen heslo místo univerzální hlášky "máte špatný login nebo heslo")
4. slabé zabezpečení přístupu (možnost použít expirované certifikáty, slabá hesla, viditelné nezakryptované heslo v požadavku na server při autentizaci...)

3. Test exekuce

Test exekuci by až na nějaké snadné a podrobně popsané scénáře ("vlož text xxxx do pole yyyy") měl vykonávat bezpečnostní tester. Veškeré akce by měly být logovány - ať již systémově, nebo ručně testerem, aby případné úspěšné průniky ("objednání produktu za cenu 0 Kč") mohly být v systému identifikovány a po ukončení testu opraveny/smazány, obzvlášť pokud je test vykonáván na produkčním prostředí. Pro některé typy průniků se dají s výhodou použít různé nástroje (třeba Acunetix Web Security Scanner, IBM Rational AppScan, HP WebInspect...)


4. Vyhodnocení testu

Ve vyhodnocení testu byste měli uvést aspoň tyto výstupy:

1. shrnutí, co jste testovali (rizika + objekty)
2. jaké potenciální bezpečnostní rizika jste objevili, co nejpřesněji popsané (i s důkazy - třeba screenshoty, hodně to "zabírá" na manažment, když vidí problém na vlastní oči)
3. doporučení, jak snížit jednotlivá nalezená bezpečnostní rizika

To by bylo v kostce o základech bezpečnostních testů všechno. Pokud se chcete s bezpečnostními testy seznámit podrobněji, můžete se podívat třeba na OWASP, nebo si zkusit hackování v praxi na http://www.hackthissite.org/. Z knížek mohu doporučit výbornou How to break software , pokud máte radši výuková videa, koukněte na přednášku How to break web software.