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

0 kommentarer

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 sina applikationer för dessa sårbarheter.

Sist gick jag igenom några testfall för autentisering, som är processen som identifierar din användare för systemet, och sessionshantering, dvs hur webbapplikationen håller reda på om du är inloggad i applikationen och eventuellt andra saker såsom innehållet i din varukorg. I det här inlägget kommer jag gå igenom auktorisering, vilket är processen för att kontrollera om användaren har behörighet att utföra de transaktioner han/hon gör. Jag kommer också beröra säkerhetstest av affärslogik i en webbapplikation.

Kategori

Ref. nummer

Testnamn

Sårbarhet

Authorization Testing

OWASP-AZ-001

Testing for Path Traversal

Path Traversal

OWASP-AZ-002

Testing for bypassing authorization schema

Bypassing authorization schema

OWASP-AZ-003

Testing for Privilege Escalation

Privilege Escalation

Testfall AZ-001

Nimda var en mask (självspridande virus) som 2001 skapade stora rubriker genom att utnyttja en directory traversal-sårbarhet i Microsofts webbserver IIS. Den har åtgärdats sedan länge (den fanns faktiskt en uppdatering ute flera månader innan Nimda gjorde sin debut). I testfall AZ-001 “Testing for Path Traversal” försöker man komma åt resurser i applikationen eller på servern som normalt inte går att komma åt, till exempel filer med konfigurationsinformation, lösenord eller källkod till applikationen. Det kan man göra genom att ändra på till exempel filparametrar till en sida som hanterar nedladdningar. Tänk dig att ”download.jsp” tar parametern ”file” som pekar på vilken fil som skall laddas ner, så ett anrop ser ut som så här: http://www.example.com/download.jsp?file=archive.zip. Vad skulle hända om man bytte ut ”archive.zip” till ”../archive.zip”? Får man ett felmeddelande att filen inte hittades är det stor risk att applikationen är sårbar för path traversal. Applikationen försöker förgäves ladda en fil ett steg högre upp i filträdet där det inte finns en fil som heter ”archive.zip” (”..” betyder närmast föregående katalog i de flesta operativsystem). När man väl har kommit så långt kan man börja försöka lista ut var någonstans man är i filträdet. Det kan man göra genom att försöka ladda ner en fil som man vet finns i det operativsystem servern kör, som till exempel ”C:\boot.ini” (Windows) eller ”/etc/hosts” (Linux och UNIX-system). När man har lyckats med det så har man listat ut var någonstans i filstrukturen man är och kan börja ladda ner valfria filer som applikationsservern har läsrättigheter till.

Testfall AZ-003

När man pratar om eskalering av behörigheter så testar man två saker:

  • vertikal eskalering: man försöker få högre rättigheter än vad man för tillfället har
  • horisontell eskalering: man försöker bli någon annan i systemet som har samma rättigheter som man redan har

Det är ganska enkelt att se varför en attackerare vill åstadkomma vertikal eskalering: som en användare försöker man bli administratör i systemet. Horisontell eskalering är lite svårare att sätta sig in i. Varför eskalering av behörigheter till samma nivå man redan har? Det blir lite klarare när man till exempel tänker på internetbanker. Om attackeraren (A) blir offret (O) så kan A, via Os konto, föra över pengar till sig själv eller till något annat konto som A har kontroll över.

Kategori

Ref. nummer

Testnamn

Sårbarhet

Business logic testing

OWASP-BL-001

Testing for business logic

Bypassable business logic

Testfall BL-001

När man testar affärslogiken så är man mer inne på traditionell testning än säkerhetstestning, men det är värt att nämna ändå. Vad man försöker göra är att kringgå de steg som är definierade i affärslogiken för systemet, till exempel om det är tänkt att man måste göra steg 1, 2 och 3 innan man får göra steg 4 i en process. Som attackerare så vill man testa ifall man kan gå direkt till steg 4, utan att passera 1-3.

Något annat som man kan testa är om systemet har funktionalitet för att skapa eller bevilja saker, till exempel för att bevilja en utläggsrapport. Som anställd (A) så kan man fylla i en utläggsrapport som måste godkännas av ansvarig (B) innan utlägget beviljas och pengar överförs. Om A kan få systemet att köra godkänningsprocessen som B skulle köra så kan A börja producera fiktiva utläggsrapporter och på så sätt stjäla pengar från företaget.

Det var allt för den här gången. I del 4 så kommer jag gå igenom testfall för datavalidering och belastningsattacker (denial of service, också känt som DoS).

/Michael Boman

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

0 kommentarer

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 förra blogginlägget pratade jag om insamlande av information (information gathering) och test av konfigurationshantering (configuration management testing). I detta inlägg tänkte jag gå igenom autentisering och sessionshantering.



Kategori


Ref. Nummer


Testnamn


Sårbarhet


Authentication Testing

OWASP-AT-001

Credentials transport over an encrypted channel

Credentials transport over an encrypted channel

OWASP-AT-002

Testing for user enumeration

User enumeration

OWASP-AT-003

Testing for Guessable (Dictionary) User Account

Guessable user account

OWASP-AT-004

Brute Force Testing

Credentials Brute forcing

OWASP-AT-005

Testing for bypassing authentication schema

Bypassing authentication schema

OWASP-AT-006

Testing for vulnerable remember password and pwd reset

Vulnerable remember password, weak pwd reset

OWASP-AT-007

Testing for Logout and Browser Cache Management

Logout function not properly implemented, browser cache weakness

OWASP-AT-008

Testing for CAPTCHA

Weak Captcha implementation

OWASP-AT-009

Testing Multiple Factors Authentication

Weak Multiple Factors Authentication

OWASP-AT-010

Testing for Race Conditions

Race Conditions Sårbarheter


Testfall AT-001

Autentisering är processen att identifiera en användare i systemet (dock nödvändigtvis inte till en specifik person), vanligtvis genom någon slags inloggningsmekanism. Vad som är viktigt att testa är att man inte kan komma över inloggningsuppgifterna på något enkelt sätt, som till exempel genom att sniffa nätverket. För att förhindra detta behöver man köra HTTPS (SSLv3 eller TLSv1, se föregående inlägg i denna serie). Själva inloggningen kan man göra på 3 olika sätt: Basic, Digest och HTML-formulär.

Basic autentisering teckenkodar användarnamn och lösenord i Base64, som är enkelt att koda tillbaka till vanlig text vilket inte är bra.

Digest autentisering krypterar användarnamn och lösenord, men är fortfarande sårbart för mannen-i-mitten (man-in-the-middle, MITM) attacker där en attackerare lurar användaren att kommunicera med attackeraren som i sin tur kommunicerar med den riktiga servern.

HTML-formulär-inloggning är det vanligaste sättet som man loggar in på webbsajter i dagsläget, där användaren fyller i sina inloggningsuppgifter på en webbsida. Detta gör att sajten kan utforma inloggningsformuläret så att det passar in på sajten, medan själva webbläsaren sköter basic och digest inloggningar (som inte kan modifieras på ett sådant sätt att de smälter in i webbsajten).

HTML-formulär kan ha brister så som:

  • Inloggningsuppgifterna skickas i klartext (okrypterat) till servern, vilket är svårt att upptäcka för användaren innan anropet görs. I basic och digest inloggning så ser man klart och tydligt ifall det är en inloggning mot HTTP eller HTTPS man är på väg att göra. Naturligtvis så bör basic och digest inloggning ske över en HTTPS-anslutning också.
  • Inloggningsuppgifterna skickas krypterat till servern från en okrypterad sida
  • Inloggningsuppgifterna skickas med en GET-fråga istället för en POST-fråga, vilket resulterar i att inloggningsgifterna sparas i webbläsaren och eventuellt också kan hamna på sajter som länkas från originalsajten genom HTTP-referer fältet.

En annan sak som jag måste ta upp när det gäller HTML-formulär-inloggning, och det är det där med att ha en hänglås ikon vid inloggningsfältet. En sådan bild har ingenting att göra med säkerheten av inloggningssystemet. Det är en bild, och skall inte förväxlas med hänglåsikonen i webbläsaren som indikerar att man kör HTTPS.

Testfall AT-002

Man bör också testa att systemet inte indikerar vad som är fel, om användarnamnet och/eller lösenord är fel. Samma felmeddelande skall presenteras för användaren oavsett om det är användarnamn eller lösenord som är fel. Detta testas genom att analysera skillnader mellan

  • giltigt användarnamn och lösenord
  • giltigt användarnamn med fel lösenord
  • ogiltigt användarnamn med valfritt lösenord

När du analyserar svaret så kontrollera svarskoder från HTTP-anropet samt innehållet och storlek på svarssidan. Även en skillnad på ett enda tecken gör att det går att köra en uttömmande sökning av giltiga användarnamn.

Testfall AT-008

CAPTCHA (“Completely Automated Public Turing test to tell Computers and Humans Apart”) används för att säkerställa att det är en människa och inte ett program som försöker utföra en transaktion, som till exempel skapa ett konto eller skicka in ett formulär. Detta beror på att det har satts i system att skapa och skicka in formulär per automatik, som till exempel e-post konton som sedan används för spam-utskick. Det hela går ut på att ett problem presenteras som är svårt för ett program att läsa och lösa, medan en människa löser det lätt, oftast i form av en bild med förvrängda bokstäver och siffror.

Problemet är att program har blivit bättre och bättre på att tolka sådana förvrängningar, och det finns flera öppen källkodsprogram som man kan ladda ner för uppgiften. Förutom att den genererade bilden kan vara lätt att tyda så kan det finnas andra sårbarheter så som väldigt få variationer av de förvrängda bilderna (till exempel att algoritmen inte genererar slumpade tecken utan har en begränsad mängd ord den förvränger), vilket kan resultera att man manuellt går igenom alla möjliga kombinationer och på så sätt lär programmet vad den skall svara. Ibland så lagras själva frågan som en parameter som skickas tillbaka till servers så att den vet vad du svarade på, vilket kan utnyttjas via återspelningsattacker, där attackeraren skickar in både fråga och svar på en bild som redan är löst, oavsett vad webbsajten faktiskt frågade efter.


Kategori


Ref. Nummer


Testnamn


Sårbarhet

Session Management

OWASP-SM-001

Testing for Session Management Schema

Bypassing Session Management Schema, Weak Session Token

OWASP-SM-002

Testing for Cookies attributes


Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity

OWASP-SM-003

Testing for Session Fixation

Session Fixation

OWASP-SM-004

Testing for Exposed Session Variables

Exposed sensitive session variables

OWASP-SM-005

Testing for CSRF

CSRF


Testfall SM-002 och allmänt om kakor

Sessionshantering är hur webbapplikationen håller reda på om du är inloggad i applikationen och eventuellt andra saker (till exempel innehållet i din varukorg). När HTTP-protokollet skapades såg man det som ett sätt för att hämta statiska sidor utan en massa logik, vilket resulterade i att HTTP-protokollet har ett minne som en guldfisk. Utan att lagra ett identifierande värde hos klienten som skickas med varje fråga så har applikationen inte någon som helst kunskap vad du gjorde i föregående transaktion. Detta identifierande värde brukar kallas sessions ID, och det lagras vanligtvis i en kaka (som får benämningen sessionskaka) i webbläsaren som i sin tur sparar ner den som en fil på din hårddisk. Sessions ID kan även skickas som en URL-parameter i adressfältet eller som ett gömt fält i ett HTML-formulär.

I förra blogg-inlägget nämnde jag Cross-Site Scripting, och hur man kunde stjäla sessionskakor med hjälp av JavaScript och hur det kunde förhindras genom att sätta ”HTTPOnly”-flaggan på kakorna. ”HTTPOnly” är en flagga som introducerades med Internet Explorer 6, och har blivit en defacto-standard trots att den inte är en W3C-standard. ”HTTPOnly”-flaggan indikerar för webbläsaren att skript språk skall nekas åtkomst till kakan. ”Secure”-flaggan indikerar för webbläsaren att kakan bara får skickas över HTTPS och inte i klartext över HTTP. Förutom ”HTTPOnly” och ”secure”-flaggor i flaggan så har kakor ett par andra fält.

”domain”-fältet indikerar vilken domän som kakan är giltig för, och kommer därmed skickas automatiskt med varje anrop till den domänen. Där är det viktigt att undersöka att domänen inte är för löst skriven. Om kakan har ”domain=omegapoint.se” så skickas den automatiskt till alla webbsajter som slutar med ”omegapoint.se”, till exempel ”http://omegapoint.se”, ”http://www.omegapoint.se” och ”http://securityblog.omegapoint.se”, medan ”domain=securityblog.omegapoint.se” skickas bara till websajten ”http://securityblog.omegapoint.se” och inte till ”http://www.omegapoint.se” eller ”http://omegapoint.se”.

”path” är ett annat fält som bör undersökas. ”path” berättar för webbläsaren att kakan skall enbart skickas med till en viss underkatalog på webbsajten, där ”path=/” betyder hela sajten medans ”path=/Home/sakerhetslosningar/” betyder att kakan skall bara skickas med ifall du besöker underkatalogen ”/Home/sakerhetslosningar/” på sajten.

Till sist så har kakor en giltighetstid som bestäms utav ”expires”-fältet i kakan. En kaka kan antingen vara giltig bara under den nuvarande sessionen, vilket betyder att kakan raderas när du stänger ner din webbläsare. Alternativt kan kakan även ha ett specifikt datum när den slutar vara giltig, och det är viktigt att undersöka att det datumet inte är satt för långt fram i tiden. När datumet har passerats så raderar webbläsaren kakan automatiskt. Förutom de standard fält och flaggor vi har precis gått igenom innehåller kakor data i form av ”variabelnamn=värde” som används utav webbapplikationen för att lagra data på webbläsaren.

Man kan inspektera vilka flaggor, fält och värden som är satta i kakorna med till exempel Firecookie, som är ett tilläggsprogram till webbläsaren Firefox.

Testfall SM-005

Nu över till den första riktiga attacken i denna genomgång av OWASP Testing Guide. Det finns en attack som liknar Cross-Site Scripting attacken (testfall DV-001, DV-002 och DV-003), som vi kommer att in på närmare i del 4 av denna serie, som kallas ”Cross Site Request Forgery” (som förkortas CSRF eller XSRF, testfall SM-005). Den har även kallats ”Session Riding”, vilket jag tycker är ett mer beskrivande namn på vad attacken gör.

CSRF går ut på att får offret automatiskt utföra en transaktion mot en webbapplikation genom att skapa en fråga som utförs automatiskt utav webbläsaren när den försöker rendera webbsidan. Tänk dig följande scenario:

Du sitter inloggad på din internetbank (https://www.dinbank.se/) för att föra över lite pengar till ditt e-handel konto för att köpa en pryl på nätet. Samtidigt surfar du runt i en annan flik (eller fönster) för information för den pryl du tänkte köpa, och du hamnar på ett forum som diskuterar den prylen du tänker köpa. På denna sida har någon lagt upp en bild, som skall laddas från ”https://www.dinbank.se/konto/overforing?tillkonto=1234567&summa=10000”, som faktiskt är den URL som anropas ifall du skulle överföra tio tusen kronor till konto 1234567. Webbläsaren vet inte, och kan inte veta, att det inte är en bild som hämtas när den anropar URLen, utan att den instruerar din internetbank att överföra pengar till något okänt konto.

Attackeraren kan inte själv skapa den här transaktionen utan att vara inloggad, men genom att få din webbläsare (som är inloggad) att utföra den så skapas den transaktionen och du har precis överfört tio tusen kronor till ett annat konto bara för att din webbläsare bara skulle ladda ner en bild. Svaret från transaktionen är naturligtvis inte en giltig bild och webbläsaren kanske renderar en ”trasig bild” ikon, men en sådan kan lätt gömmas genom att säga till webbläsaren att bilden är 1x1 pixel stor vilket får den trasiga bild ikonen se ut som en punkt. Vad som är viktigt att komma ihåg är att svaret på transaktionen bara går till offret och inte tillbaka till attackeraren, vilket betyder att attackeraren inte vet om transaktionen har utförts eller inte. Denna typ av attack har använts på internet för att till bland annat ta över hemma-routrar då de flesta inte bytt standardlösenordet på dem.

Det var allt för den här gången. I del 3 så kommer jag gå igenom testfall för auktorisering och hur man testar affärslogiken i webbapplikationer.

/Michael Boman

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

0 kommentarer

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