Genomgång av OWASP Testing Guide (del 2 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 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

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

Skicka en kommentar