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

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

Skicka en kommentar