Genomgång av OWASP Testing Guide (del 4 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 auktorisering, vilket är processen för att kolla ifall du har rätt att utföra de transaktionerna du anropar, och hur man testar affärslogiken i en webbapplikation. I detta inlägg tänkte jag gå igenom datavalidering och överlastningsattacker.

Kategori
Ref. Nummer
Testnamn
Sårbarhet






Data Validation Testing
OWASP-DV-001
Testing for Reflected Cross Site Scripting
Reflected XSS
OWASP-DV-002
Testing for Stored Cross Site Scripting
Stored XSS
OWASP-DV-003
Testing for DOM based Cross Site Scripting
DOM XSS
OWASP-DV-004
Testing for Cross Site Flashing
Cross Site Flashing
OWASP-DV-005
SQL Injection
SQL Injection
OWASP-DV-006
LDAP Injection
LDAP Injection
OWASP-DV-007
ORM Injection
ORM Injection
OWASP-DV-008
XML Injection
XML Injection
OWASP-DV-009
SSI Injection
SSI Injection
OWASP-DV-010
XPath Injection
XPath Injection
OWASP-DV-011
IMAP/SMTP Injection
IMAP/SMTP Injection
OWASP-DV-012
Code Injection
Code Injection
OWASP-DV-013
OS Commanding
OS Commanding
OWASP-DV-014
Buffer overflow
Buffer overflow
OWASP-DV-015
Incubated Sårbarheter Testing
Incubated Sårbarheter
OWASP-DV-016
Testing for HTTP  Splitting/Smuggling

HTTP Splitting, Smuggling
Datavalidering är det område där det brukar oftast gå fel, så det är värt att lägga lite extra krut på dessa tester. Det är också under datavalidering som de två högsta problemen under OWASP Top 10 ligger (diverse Injection sårbarheter samt Cross Site Scripting (XSS)). Det underliggande problemet är att indata tolkas som kod, antingen i webbläsaren eller på servern.

Testfall DV-001, DV-002 och DV-003 
Cross Site Scripting (XSS) är en sårbarhet som uppstår när man låter inmatad data tolkas som kod som körs i webbläsaren (oftast JavaScript, men andra skript språk som webbläsaren kan tolka är också applicerbara). Cross Site Scripting har ett par varianter:
  • Typ 1 (reflekterad): Data som skickas med anropet visar (reflekteras) på den resulterande sidan. Sökfält är överrepresenterade i denna typ av sårbarheter.
  • Typ 2 (lagrad): Data som skickas med anropet lagras på servern som senare visar den för användaren. Denna typ av sårbarhet brukar vara överrepresenterad i alla typer av kommentarsfält.
  • Typ 0 (DOM): DOM-baserad XSS har mycket gemensamt med Typ 1 (reflekterad), fast man attackerar webbläsarens DOM-träd istället. 
Man kan även utföra attacker på Flash-objekt på liknande sätt, då oftast genom att skicka attack data till Flash-objektet.

När man testar för XSS-sårbarheter så brukar man skicka in ett litet JavaScript:

<script>alert(”XSS”);</script>

Som skapar en alert-dialog med ordet ”XSS” i sig. Tyvärr är det så att systemägare/systemansvarig tror att det är det som är problemet (att kunna skapa en massa alert-dialoger). Detta är dock inte det enda som en attackerare kan göra, utan en attackerare kan köra valfri kod i JavaScript i användarens webbläsare. För att få en idé vad sådana skript kan åstadkomma kan man titta på BeEF (browser exploitation framework) som man kan ladda ner gratis på http://www.bindshell.net/tools/beef/. Jag planerar att skriva en artikel om just BeEF vid ett senare tillfälle.

Testfall DV-005 
När det kommer till injection-attacker så är SQL-injection den mest kända. SQL-injection är en attack där indata tolkas som SQL-kod i databasen. Låt oss ta en titt på lite SQL-kod i en applikation, i detta fall inloggningsfunktionen i Insecure Web Application (IWA) som vi använder i våra utbildningar:

sql = "SELECT * FROM users WHERE user = '" + user + "' AND password = '" + password + "'"; 

där den röda texten är indata från användaren. Detta uttryck läses som: Välj alla rader från tabellen “users” där användarnamnet är vad som skickades in från formuläret och lösenordet är vad som skickades in från formuläret.

Om man som attackerare matar in följande indata:

user = 'OR 1=1 --
password = blabla 


Så får man följande SQL-uttryck:

SELECT * FROM users WHERE user = '' OR 1=1 --' AND password = 'blabla

“--“ är ett kommentarstecken i SQL, vilket betyder att allt efter ”--” ignoreras. Detta resulterar då i följande SQL-uttryck:

SELECT * FROM users WHERE user = '' OR 1=1 

Vilket läses som: Välj alla rader från tabellen “users” där användarnamnet är tomt eller 1=1 (dvs. sant). Detta resulterar att databasen ger applikationen alla fält i tabellen, och applikationen använder det första som brukar vara administratörs-kontot. Voilá, instant admin access.

SQL-injektioner kan till exempel användas för att komma förbi inloggningskrav, som exemplet ovan; för att ladda ner databasen; för att skapa, modifiera eller ta bort data ur databasen samt i vissa fall ta kontroll över databasservern (via så kallade Stored Procedures).

Kategori
Ref. Nummer
Testnamn
Sårbarhet


Denial of Service Testing
OWASP-DS-001
Testing for SQL Wildcard Attacks
SQL Wildcard Sårbarheter
OWASP-DS-002
Locking Customer Accounts
Locking Customer Accounts
OWASP-DS-003
Testing for DoS Buffer Overflows
Buffer Overflows
OWASP-DS-004
User Specified Object Allocation
User Specified Object Allocation
OWASP-DS-005
User Input as a Loop Counter
User Input as a Loop Counter
OWASP-DS-006
Writing User Provided Data to Disk
Writing User Provided Data to Disk
OWASP-DS-007
Failure to Release Resources
Failure to Release Resources
OWASP-DS-008
Storing too Much Data in Session
Storing too Much Data in Session
Belastningsattacker finns i två varianter: bandbreddsattacker och applikationsattacker. Jag kommer inte gå igenom bandbreddsattacker, där man skickar så mycket data eller förfrågningar till servern så att den inte har några lediga resurser kvar till legitima användare. I korta drag så är det en ”störst internetuppkoppling vinner” tävling, och det finns inget som applikationen man testar kan göra något åt utan man måste kolla på infrastrukturer runt omkring.

Testfall DS-001 
SQL-injection attacker kan även användas för att skapa belastningsattacker. SQL har stöd för jokertecken, och vissa kan kräva mycket systemresurser för att analysera. Ett exempel på sådana jokertecken är "[]","[^]","_" och "%". Om man matar in teststrängen _[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£amp;N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_ så kan man få en SQL-fråga som normalt returnerar på mindre än en sekund ta 6 sekunder eller mer, och skickar man flera sådana så kan man allokera alla SQL-kopplingar som applikationen har till databasen, vilket resulterar i att legitima användare inte får några databasresurser för att köra applikationen.

Testfall DS-002 
Om applikationen låser konton efter ett antal försök så kan en attackerare låsa alla konton i applikationen (om attackeraren vet vilka de är genom testfall AT-002), vilket hindrar legitima användare från att logga in och använda systemet. Så här har vi ett litet problem: Om man blockerar testfall AT-002 och AT-004 så kan man skapa en belastningsattack av typen DS-002. Vilket som är farligast måste bedömas från applikation till applikation, det finns inte något bra sätt att hantera detta som fungerar i alla tillfällen.

Det var allt för den här gången. I nästa och sista delen av den här artikelserien så kommer jag gå igenom testfall för webbtjänster (Webservice) och AJAX-specifika attacker.

/Michael Boman

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

Skicka en kommentar