Genomgång av OWASP Testing Guide (del 1 av 5)

OWASP (Open Web Application Security Project) har en testguide (OWASP Testing Guide, finns gratis på webben och i tryckt form till självkostnadspris) som innehåller 66 tester i 10 olika kategorier. I denna serie av blogginlägg kommer jag att gå igenom dessa 66 tester, vilka sårbarheter de testar och varför det är viktigt att testa dina applikationer för dessa sårbarheter.

I det här blogginlägget så kommer jag gå igenom insamlande av information (information gathering) och test av konfigurationshantering (configuration management testing).

Kategori	Ref.nummer	Testnamn	Sårbarhet
Information Gathering	OWASP-IG-001	Spiders, Robots and Crawlers -	N.A.
	OWASP-IG-002	Search Engine Discovery/Reconnaissance	N.A.
	OWASP-IG-003	Identify application entry points	N.A.
	OWASP-IG-004	Testing for Web Application Fingerprint	N.A.
	OWASP-IG-005	Application Discovery	N.A.
	OWASP-IG-006	Analysis of Error Codes	Information Disclosure

Testfall IG-002

När det kommer till ”Information Gathering”-kategorin så är det inte några sårbarheter per se, utan hur man kan få reda på information om applikationen för att senare kunna attackera systemet med större precision. En källa man kan vända sig till för att få mer information om systemet är Google och andra sökmotorer (om systemet är publikt tillgängligt). Denna teknik kallas allmänt ”Google hacking”.

Google är en mycket kraftfull sökmotor, mycket mer kraftfull än vad man normalt använder den till. Man kan till exempel söka efter publika MS Office-dokument (Word, Excel, PowerPoint etc.) eller sårbara versioner av diverse webbapplikationer genom att använda inurl, intitle, filetype, site och andra nyckelord i sin Google sökning. Det är ett ganska tråkigt och tidskrävande arbete, men som tur är finns det automatiserade verktyg för detta. Ett exempel på ett sådant verktyg är SiteDigger från Foundstone.

För mer information om Google hacking kan du läsa boken Google Hacking (ISBN: 1597491764, skriven av Petko Petkov, Roelof Temmingh och Johnny Long) samt besöka webbsajten Google Hacking Database.

Testfall IG-006

Något mer som är viktigt att testa i denna kategori är IG-006 (analys av felkoder). Felkoder kan vara mycket behjälpliga för någon som försöker ta sig in i systemet, men är inte speciellt beskrivande för en vanlig användare. En stack trace (en hierarkisk spårning av funktionsanrop som används vid avlusning) och andra felkoder bör loggas till en fil och slutanvändaren skall bara få ett referensnummer som kan leda till just det felmeddelandet som genererades. Som penetrationstestare har jag många gånger fått mycket beskrivande felmeddelanden som har hjälpt mig att ta mig in i systemet.

Kategori	Ref.nummer	Testnamn	Sårbarhet
Configuration Management Testing	OWASP-CM-001	SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity)	SSL Weakness
	OWASP-CM-002	DB Listener Testing	DB Listener weak
	OWASP-CM-003	Infrastructure Configuration Management Testing	Infrastructure Configuration management weakness
	OWASP-CM-004	Application Configuration Management Testing	Application Configuration management weakness
	OWASP-CM-005	Testing for File Extensions Handling	File extensions handling
	OWASP-CM-006	Old, backup and unreferenced files	Old, backup and unreferenced files
	OWASP-CM-007	Infrastructure and Application Admin Interfaces	Access to Admin interfaces
	OWASP-CM-008	Testing for HTTP Methods and XST	HTTP Methods enabled, XST permitted, HTTP Verb

Testfall CM-001

Oftast när man tänker på säkerhet på webben så tänker man SSL, men bara för att man har SSL på sin server betyder det inte att det är säkert. För det första så hindrar inte SSL mig att attackera systemet i fråga, utan det skyddar mot avlyssning och manipulation. För det andra så har SSL haft sina brister genom åren i form av vad som i dagsläget anses vara för korta nycklar och osäker kryptering och nyckelutbyte. I dagsläget så är 128-bitar nyckellängd med protokollen SSLv3 eller TLSv1 ett minimum. För att testa detta kan man använda verktyg som OpenSSL (med kommandoklienten), Nessus (från Tenable) och SSLDigger (från Foundstone). Förutom SSL-/TLS-typ och nyckellängd bör man även undersöka giltighetstid, utfärdare och för vilken server certifikatet gäller. Detaljer för detta står beskrivet i CM-001 i OWASP Testing Guide.

Testfall CM-008

I del 4 av denna serie kommer vi gå igenom Cross-Site Scripting (också känt som XSS; testfall DV-001, DV-002 och DV-003) som bland annat kan användas för att stjäla sessionskakor, som i sin tur kan skyddas genom att sätta ”HTTPOnly”-flaggan på kakan (testfall SM-002 som beskrivs närmare i nästa blogginlägg). Man kan gå förbi detta skydd genom att skapa ett TRACE-anrop till servern. TRACE är ett HTTP-anrop för debugging som returnerar det man skickar in. TRACE-anropen inkluderar kakor oavsett om de har HTTPOnly satt eller inte vilket resulterar i att kakorna blir tillgängliga via svaret från servern som man kan komma åt med bland annat JavaScript. Det är som tur är ganska enkelt att testa om HTTP-servern stödjer TRACE. Man kan skicka frågan ”OPTIONS / HTTP/1.0” till webbservern och undersöka om svaret innehåller TRACE, alternativt skapar man en TRACE-fråga till webbservern och kollar om den gick igenom.

Detta var en kort genomgång av de två första kategorierna i OWASP Testing Guide. I nästa blogginlägg i denna serie så kommer vi gå igenom autentisering och sessionshantering.

/Michael Boman