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