Níže nabízím překlad z Home > Stable > 4-Web Application Security Testing > 04-Authentication Testing > Testing for Bypassing Authentication Schema.
Shrnutí
V počítačové bezpečnosti je autentizace proces pokusu o ověření digitální identity odesílatele komunikace. Běžným příkladem takového procesu je přihlašovací proces. Testování autentizačního schématu znamená pochopení toho, jak autentizační proces funguje, a využití těchto informací k obejití autentizačního mechanismu.
Zatímco většina aplikací vyžaduje autentizaci pro získání přístupu k soukromým informacím nebo provádění úkolů, ne každá autentizační metoda je schopna poskytnout dostatečnou bezpečnost. Nedbalost, neznalost nebo jednoduché podcenění bezpečnostních hrozeb často vede k autentizačním schématům, která mohou být obejita prostým přeskočením přihlašovací stránky a přímým vyvoláním interní stránky, která by měla být přístupná pouze po provedení autentizace.
Navíc je často možné obejít autentizační opatření manipulací s požadavky a oklamáním aplikace, aby si myslela, že uživatel je již autentizován. To lze provést buď úpravou daného parametru v URL, manipulací s formulářem nebo podvržením relací.
Problémy související s autentizačním schématem mohou být nalezeny v různých fázích životního cyklu softwaru (SDLC), jako jsou fáze návrhu, vývoje a nasazení:
- Ve fázi návrhu mohou chyby zahrnovat nesprávné definování částí aplikace, které mají být chráněny, volbu nepoužití silných šifrovacích protokolů pro zabezpečení přenosu přihlašovacích údajů a mnoho dalších.
- Ve fázi vývoje mohou chyby zahrnovat nesprávnou implementaci funkcí ověřování vstupů nebo nedodržení osvědčených bezpečnostních postupů pro konkrétní jazyk.
- Ve fázi nasazení aplikace mohou být problémy během nastavení aplikace (instalační a konfigurační činnosti) kvůli nedostatku potřebných technických dovedností nebo nedostatku dobré dokumentace.
Cíle testu
- Zajistit, aby byla autentizace aplikována na všechny služby, které ji vyžadují.
Jak testovat
Black-Box Testing
Existuje několik metod, jak obejít autentizační schéma, které používá webová aplikace:
- Přímý požadavek na stránku (vynucené procházení)
- Úprava parametrů
- Předvídání ID relace
- Injekce SQL
Přímý požadavek na stránku (vynucené procházení)
Pokud webová aplikace implementuje řízení přístupu pouze na přihlašovací stránce, autentizační schéma může být obejito. Například, pokud uživatel přímo požádá o jinou stránku prostřednictvím vynuceného procházení, tato stránka nemusí zkontrolovat přihlašovací údaje uživatele před udělením přístupu. Pokuste se přímo přistoupit k chráněné stránce prostřednictvím adresního řádku ve vašem prohlížeči a otestovat tuto metodu.Přímý požadavek na chráněnou stránku
Obrázek 4.4.4-1: Přímý požadavek na chráněnou stránku.
Úprava parametru
Dalším problémem souvisejícím s návrhem autentizace je, když aplikace ověřuje úspěšné přihlášení na základě hodnoty pevně stanovených parametrů. Uživatel může upravit tyto parametry, aby získal přístup do chráněných oblastí, aniž by poskytl platné přihlašovací údaje. V následujícím příkladu je parametr „authenticated“ změněn na hodnotu „yes“, což uživateli umožňuje získat přístup. V tomto příkladu je parametr v URL, ale proxy server by mohl být také použit k úpravě parametru, zejména když jsou parametry odesílány jako prvky formuláře v požadavku POST nebo když jsou parametry uloženy v cookie.
http://www.site.com/page.asp?authenticated=no
raven@blackbox /home $nc www.site.com 80
GET /page.asp?authenticated=yes HTTP/1.0
HTTP/1.1 200 OK
Date: Sat, 11 Nov 2006 10:22:44 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
</HEAD><BODY>
<H1>You Are Authenticated</H1>
</BODY></HTML>
Predikce ID relace
Mnoho webových aplikací spravuje autentizaci pomocí identifikátorů relace (session IDs). Proto, pokud je generování ID relace předvídatelné, mohl by škodlivý uživatel najít platné ID relace a získat neoprávněný přístup k aplikaci, přičemž by se vydával za dříve autentizovaného uživatele.
Na následujícím obrázku se hodnoty uvnitř cookies zvyšují lineárně, takže by pro útočníka mohlo být snadné uhodnout platné ID relace.
Na následujícím obrázku se hodnoty uvnitř cookies mění pouze částečně, takže je možné omezit útok hrubou silou na definovaná pole uvedená níže.
SQL Injection (autentizace pomocí HTML formuláře)
SQL Injection je široce známá technika útoku. Tato část nebude popisovat tuto techniku podrobně, protože v této příručce je několik částí, které vysvětlují injekční techniky mimo rámec této sekce.
Následující obrázek ukazuje, že pomocí jednoduchého SQL injection útoku je někdy možné obejít autentizační formulář.
Gray-Box Testing
Pokud útočník byl schopen získat zdrojový kód aplikace využitím dříve objevené zranitelnosti (např. přesměrování adresáře) nebo z webového úložiště (Open Source aplikace), mohlo by být možné provést sofistikovanější útoky proti implementaci autentizačního procesu.
V následujícím příkladu (PHPBB 2.0.13 – Zranitelnost obejití autentizace), na řádku 5 funkce unserialize() zpracovává uživatelem dodanou cookie a nastavuje hodnoty uvnitř pole $row. Na řádku 10 je hash hesla uživatele uložený v databázi backendu porovnán s tím dodaným.
if (isset($HTTP_COOKIE_VARS[$cookiename . '_sid']) {
$sessiondata = isset($HTTP_COOKIE_VARS[$cookiename . '_data']) ? unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : array();
$sessionmethod = SESSION_METHOD_COOKIE;
}
if(md5($password) == $row['user_password'] && $row['user_active']) {
$autologin = (isset($HTTP_POST_VARS['autologin'])) ? TRUE : 0;
}V PHP, porovnání mezi řetězcovou hodnotou a boolean hodnotou (1 a TRUE) je vždy TRUE, takže dodáním následujícího řetězce (důležitá část je b:1) do funkce unserialize(), je možné obejít kontrolu autentizace:
a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}
Nástroje
Odkazy
- Whitepapers
- Mark Roxberry: „PHPBB 2.0.13 vulnerability“
- David Endler: „Session ID Brute Force Exploitation and Prediction“