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