OWASP Top 8

Vi hade en diskussion häromdagen där vi gick igenom sårbarheterna (eller är det attackerna?) i OWASP Top Ten. Jag har ju vissa tvivel till den nya utgåvans inriktning men idag gäller det en nytt irritationsmoment. Vän av ordning som man är (skriver ilskna insändare o s v) så trivs jag när saker är distinkta och inte överlappar. OWASP Top Ten lider av vissa problem kring i detta avseende. OWASP Top Ten borde kanske egentligen vara OWASP Top Eight.
  1. Injection
  2. Cross-Site Scripting (XSS)
  3. Broken Authentication and Session Management
  4. Insecure Direct Object References
  5. Cross-Site Request Forgery (CSRF)
  6. Security Misconfiguration
  7. Insecure Cryptographic Storage
  8. Failure to Restrict URL Access
  9. Insufficient Transport Layer Protection
  10. Unvalidated Redirects and Forwards
Den första strykningen är enkel att förklara. Cross-site scripting (XSS) är egentligen en form av injection precis som LDAP injection, SQL injection, command injection eller Xpath injection. Vi skulle med gott samvete kunna prata om XSS som HTML injection med browsern som interpreter. Att Javascript tolkas av (förenklat sett) samma tolk förändrar ingenting. Se följande två beskrivningar från OWASP Top Ten 2010:

A1 Injection flaws
Attacker sends simple text-based attacks that exploit the syntax of the targeted interpreter. Almost any source of data can be an injection vector, including internal sources.

A2 Cross-site scripting
Attacker sends text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.

Den andra strykningen är lite mer subtil. Failure to restrict URL access och insecure direct object reference är båda problem med brister i authorization (vem har tillgång till vad) vilket är en del av paraplyet access control.  I första fallet (A4) avses tillgång till "objekt" och i andra fallet (A8) till "sidor". Förutsatt att sidor visar objekt, hur drar vi den gränsen? Behöver vi dra en gräns? Dessutom, är en sida ett "systemobjekt"? Är en fil ett systemobjekt? Beskrivningarna från 2010-versionen:

A4 Insecure direct object reference
Attacker, who is an authorized system user, simply changes a parameter value that directly refers to a system object to another object the user isn’t authorized for. Is access granted?

A8 Failure to restrict URL access
Attacker, who is an authorized system user, simply changes the URL to a privileged page. Is access granted? Anonymous users could access private pages that aren’t protected.

Hur en applikation gör för att visa sidor, om de lagras som objekt eller inte o s v, är till stor del upp till utvecklaren och ramverket. Oavsett om syntaxen i en sidas URL:er är

http://www.example.com/apage?object=myobject
http://www.example.com/apage?object=notmyobject


eller

http://www.example.com/mypage
http://www.example.com/notmypage


eller

http://www.example.com/show?page=mypage
http://www.example.com/show?page=notmypage


handlar det om samma problem. Vem har tillgång till vad.

Den bästa anledningen till att separera "vanlig" injection och HTML injection (XSS) i vanliga diskussioner är att den förra är en attack mot applikationen medan den senare i regel är en attack mot andra användare. Även detta resonemang haltar dock lite; att sno administratörens cookie via XSS och använda den för att autentisera sig mot applikationen, är det verkligen en attack mot administratören?

Hårklyverier kanske.

--
Stefan Pettersson


OWASP Top Ten 2010

OWASP:s flaggskepp Top Ten har kommit ut i en ny version och det har skett några mindre förändringar. Malicious file execution och information leakage har fått kliva av och istället ge plats för security misconfiguration samt unvalidated redirects and forwards.

Det är dock en sak som OWASP vill framhäva särskilt; att årets lista handlar om risk. Metoden som används är löst baserad på OWASP Risk Rating Methodology. Jag har inte ägnat sådär jättemycket tid att titta på metoden tyvärr men med anledning av tidigare inlägg och kommentarer på bloggen så är jag väl mer eller mindre tvungen framöver. Sammanfattningsvis är jag dock skeptisk till huruvida det är värt att göra riskbedömningar för tio sårbarheter/attacker utan sammanhang...


P g a att jag har lite dåligt med tid; lösryckta tankar och funderingar:
  • Det huvudsakliga värdet i OWASP Top Ten ligger i att man har samlat de tio vanligaste och farligaste från en bunt generella sårbarheter/attacker i ett dokument och att detta dokument är väldigt välkänt.
  • Man borde separera persistant och reflected cross-site scripting p g a den jordskredsstora skillnaden i läskighet de har.
  • Är det någon i Top Ten-projektet som jobbar med att sälja bläckpatroner eller?
  • Notera att svenska OWASP-kapitlet finns med i listan med acknowledgements. Det var värt en lång och bitvis hetsig kväll med många viljor på Omegapoint. Jag är lite oklar över hur vår feedback användes dock.

--

Stefan Pettersson


Allt du vill veta om CAPTCHA

Du har säkert sett sådana här när du har registrerat ett konto på någon webbsida:


Programmen som hanterar dessa bilder kallas CAPTCHA och som du säkert misstänkt så finns de där som en säkerhetsfunktion. Vad skyddar de mot och hur bra fungerar de?


Bakgrund
CAPTCHA står för Completely Automated Public Turing test to tell Computers and Humans Apart. Det handlar alltså om att kunna skilja på människor och datorer, eller egentligen, om möjligheten för en människa att bevisa att hon inte är en dator.

Behovet finns eftersom Internet har många resurser som kan missbrukas genom automatisering. En angripare skulle t ex kunna skriva ett program som under några timmar registrerar 20 000 mailkonton på Spray och sedan skickar ett tiotal mail var; ett enkelt och relativt oskyldigt sätt att slussa ut en kvarts miljon spammail. Ett annat klassiskt exempel är en omröstning som hölls på Slashdot 1999 om vilken skola som hade den bästa utbildningen i datavetenskap. Efter att studenter på Carnegie Mellon hade skrivit ett program för att rösta automatiskt ryckte snart studenter från MIT in och det urartade i en tävling om vem som skrev det mest effektiva röstprogrammet. Carnegie och MIT fick strax över 20 000 röster var medan trean fick knappt 1000.

Den formella definitionen är att en CAPTCHA är ett program som kan generera och bedöma tester som (1) de flesta människor kan klara av men (2) dagens datorer inte klarar. Det populäraste testet har visat sig vara att kunna läsa deformerad text, något som datorer generellt har svårt för medan människor är väldigt duktiga på. Definitionen på en CAPTCHA lämnar dock testets typ öppet.

Däremot, om man följer direktiven för en CAPTCHA strängt så ska programmets beståndsdelar vara öppna (Public Turing test). Dels för att följa Kerckhoffs princip men också för att en välkommen bieffekt är att forskning runt artificell intelligens drar nytta av kapprustningen kring CAPTCHA-program. I den här texten använder jag alltså termen något oansvarigt.

Som vanligt inom säkerhet så är inte CAPTCHA en fullständig lösning på problemet. Implementeringar är fyllda av fällor.


Svagheter och attacker
Det första man behöver övertyga sig om är hur en lyckad attack ser ut. En CAPTCHA-knäckare behöver inte vara perfekt; en angripare kan t ex nöja sig med att, i genomsnitt, var tionde försök är korrekt. Detta leder direkt till att test med en väldigt begränsat mängd möjliga svar kan betraktas som svaga. Se till exempel metoden Spray använder för att kontrollera användare som glömt sitt lösenord.


Hos Spray är ett av ett litet antal (här fem stycken) möjliga svar rätt. En 20-procentig hit rate genom blint gissande är fullt godtagbart för en angripare.  (Sprays implementering lider av flera problem men det lämnas som en övning för läsaren.)

En annan faktor än (lite slarvigt) lösningsrymden är (lite slarvigt) problemrymden. Hur många bilder har Spray i databasen? Är det möjligt att ladda ner alla och identifiera dem en gång och sedan utnyttja kunskapen för att lösa alla framtida? Om databasen innehåller 200 bilder är det något jag skulle kunna ägna några timmar åt. Om databasen innehåller 3,4 miljoner bilder är jag inte riktigt lika sugen.

Det här knyter an i text-CAPTCHA-metoden. Standardattacken är att använda OCR-program (Optical Character Recognition) för att tolka bilden som text. Om de textsträngar som testet använder är riktiga ord från t ex engelska så minskar antalet möjliga gissningar radikalt. Om OCR-programmet analyserar en bild, hittar en text och tolkar den som BRNANA men samtidigt meddelar att den är osäker på den andra bokstaven är det förstås ett enkelt steg att kontrollera med en ordlista innan gissning. Sannolikt kommer det att visa sig att BANANA har det kortaste avståndet till BRNANA.

Ytterligare en uppenbar svaghet är algoritmer som inte utnyttjar slumptal. Om de deformationer som används för att förvränga texten alltid är samma har angripare möjlighet att hitta andra deformationer som inverterar effekten. (Det här beror förstås på att data inte förloras vid vissa deformationer, något som somliga har fått lära sig den hårda vägen.)

En mindre uppenbar svaghet i text-CAPTCHA-bilder är när enskilda bokstäver är enkla att separera från varandra. Jämför t ex Googles nuvarande CAPTCHA med en av de tidigaste exemplen; EZ-Gimpy nedan. Om bokstäverna kan anlyseras var för sig förenklas attacker rejält.


Redan under CAPTCHAs barndom fruktade man att människor skulle utnyttjas för att lösa testerna. En farhåga man hade var att porrsidor skulle sättas upp där besökare fick lösa en CAPTCHA varje gång de ville se ett gäng bilder. De test som besökarna löste genererades inte av porrservern utan skulle då tas från Hotmails användarregistrering så att porrsurfare, ovetandes, registrerade mailkonton. De goda nyheterna är att det här aldrig blev ett riktigt problem, åtminstone inte vad man vet. De dåliga nyheterna är istället att CAPTCHA-knäckare rekryterades i låglöneländer. Det finns tyvärr inte så mycket information om hur utbredd metoden är.

Förutom detta finns det förstås flera exempel på program avsedda för att knäcka CAPTCHA-tester.


Andra problem
Det är inte det här inläggets fokus men det är viktigt att påpeka; CAPTCHA-tester må vara svåra för dagens datorer att lösa men de är också svåra för en ansenlig del människor. En arbetsgrupp på W3C släppte en rapport på ämnet för fem år sedan; Inaccessibility of CAPTCHA:

A common method of limiting access to services made available over the Web is visual verification of a bitmapped image. This presents a major problem to users who are blind, have low vision, or have a learning disability such as dyslexia.  This document examines a number of potential solutions that allow systems to test for human users while preserving access by users with disabilities.


Rekommendationer
Precis som med kryptering så ska man inte göra som Martin Timell; själv. Lägg istället krut på en känd CAPTCHA. Jag rekommenderar vanligtvis reCAPTCHA (som är gratis). Huvudsaken är att eventuellt lyckade attacker hanteras relativt snabbt. Det hände till exempel med just reCAPTCHA i december. När en sådan utbredd CAPTCHA knäcks är det större chans att det upptäcks, rapporteras och hanteras.

Generellt är det ganska svårt att ge riktlinjer för hur en stark CAPTCHA ser ut. Olika deformationer och algoritmer kan tillsammans ha oförutsedda effekter. Eftersom konceptet CAPTCHA är fött på universitet finns det gott om utrymme för en akademisk syn...


Trots detta kan några riktlinjer vara:
  • Det ska vara svårt att separera enskilda tecken.
  • Det ska finnas slumpmässighet på både enskilda tecken och hela ordet.
  • Nyanser av färger (även gråskalor) är lätta att ta bort.
  • Strikt horisontella och vertikala streck är lätta att ta bort.
  • Streck som är tunnare än texten är de lätta att ta bort.
Avslutningsvis, CAPTCHA är ett klart utmanande område som sysselsätter många intelligenta personer på båda sidor. Det fina med det hela är att oavsett vem som vinner så tjänar vi på det som "samhälle"; antingen får vi högre säkerhet eller så pressas AI-fronten framåt ett snäpp.

--
Stefan Pettersson


Det är skillnad på XSS och XSS

Det är skillnad på XSS och XSS Cross-site scripting innebär kortfattat att en användare på en sårbar webbsida kan attackera en annan användare av samma webbsida. Det hela bygger på förtroende; din lokala ICA-handlare är sårbar eftersom jag kan gå in och lägga ett förgiftat äpple i fruktavdelningen som du sedan köper och äter. Du skulle aldrig ha ätit äpplet om jag gav det till dig direkt men eftersom du litar på ICA och inte har någon möjlighet att avgöra om det är ett äkta ICA-äpple så är det här ett effektivt sätt att förgifta dig.

I verkligheten är det förstås lite mer komplicerat. Det finns i grunden två sorters XSS-attacker: reflected och persistant. Reflected är oerhört vanligt förekommande, jag skapar en URL till en sårbar sida, URL:en innehåller attackkoden och när du klickar på länken studsar koden på sidan och du åker dit. Det är den här sorten som XSSed samlar på och just nu finns 36 000 XSS-sårbarheter registrerade. En försvarlig mängd.

Den andra sorten, persistant, har ingenting med länkar att göra. Där är det helt enkelt så att en attack mot en webbsida leder till att attackkoden sparas och sedan visas för besökare. Varje besökare. Nu blir förgiftad så fort du sätter foten i ICA-butiken, vare sig du gillar äpplen eller inte!

Folk accepterar generellt inte vilken skillnad det är på reflected XSS och persistant XSS. Det är jämförbart med att hindra Adam från förorten att åka till jobbet, och att sänka hela gröna tunnelbanelinjen.

Lyckligtvis är den här sorten synnerligen ovanlig... förutom när den kommer i form av SQL injection. Det är en fin gräns mellan persistant XSS och SQL injection där det är möjligt att skriva till databasen. Angripare kunde inte bry sig mindre.

Samsung.se hackar (ovetandes) sina kunder.

Reflected XSS är inget att ligga vaken om nätterna för, även om du driver en sida med många besökare. Persistant däremot...

--
Stefan Pettersson

Firefox skyddar mot XSS

(Publicerad 2009-10-07)

Mozilla har börjat införa content security policy (CSP) i webbläsaren Firefox. CSP ger utvecklare möjlighet att skydda sina besökare mot cross-site scripting.

John Wilander (Omegapoint/OWASP Sweden) pratade om vitlistning av script med Computer Sweden i våras och gissade där att Mozilla skulle vara först ut med en lösning. I somras visade det sig att han verkade ha rätt och nu är CSP på väg att rullas ut med Firefox.

Hur det fungerar
Beskrivningen som ges i dagens TechWorld är en bra analogi. Det handlar om en innehållsdeklaration. När webbläsaren kontaktar en webbserver och hämtar en sida fås också en lista på vilka script som ska ingå:

Vi har det här scriptet för att styra vårt menysystem, vi har det här scriptet för att hålla koll på besökarantal och dessutom det här för att anpassa sidan efter din webbläsare. Det är allt.

Anta att samma sida har en sårbarhet där andra besökare kan injicera javascript i innehållet t ex via en kommentarfunktion på en blogg. Trots att en av kommentarerna innehåller javascript så kommer webbläsaren inte att köra det eftersom det inte finns med i innehållsdeklarationen. Läs mer om specifikationen här.

Content security policy ger alltså webbutvecklare möjlighet att skydda sina besökare mot cross-site scripting. I detta inkluderas alla attacker som resulterar i att script injiceras i sidor, även om det sker via t ex SQL injection vilket har varit ganska vanligt.

Överkurs
Säkerheten vilar på att en angripare inte kan modifiera innehållsdeklarationen i samband med att script injiceras i sidan. Det är ett godtagbart antagande. Om en angripare har möjlighet att ändra innehållsdeklarationen d v s HTTP-headers på vägen från servern till klienten eller direkt på servern så är cross-site scripting ett av dina mindre problem.

Det här betyder inte att det är dags att göra sig av med NoScript riktigt än. Skyddet ligger i utvecklarnas händer men attacken det skyddar mot är riktat mot besökaren.

--
Stefan Pettersson

Twitter XSS-maskar och behovet av pålitliga källor

(Publicerad 2009-04-15)

Under påskhelgen drabbades Twitter av ett mindre antal cross site scripting maskar. Twitter var i vanlig ordning inte speciellt snabba på att reagera. Det var däremot malwarespridarna som snabbt ordnade bra google-placeringar.


Angreppet sägs ha börjat med att 17-årige Michael Mooney "inte hade något bättre för sig". Att Twitter var långsamma att reagera och att de blivit angripna flertalet gånger förr är intressant i sig, men här skulle jag bara kort vilja nämna något som blev en trend under 2008 och som lär fortsätta växa. Nämligen att de som sprider malware utnyttjar ett existerande behov kring något aktuellt.

Gör en sökning på Google på 'twitter worm' (utan ') och titta igenom sökresultaten. Vid det här laget då jag skriver så har Google taggat flera av dessa sidor som malware-spridare, något som inte fanns där från början. Faktum är att det till och med finns med på top 10 sökresultat.

Google-sökning på twitter worm; skadlig kod sprids genom att utnyttja aktuella händelser och förtroende som finns för Google:

Screenshot av sökresultat.


Vad jag kan komma ihåg så blev fenomenet att utnyttja aktuell information populärt i och med spridningen av Storm med start januari 2007. Då var det aktuella händelser som Katrina, påsk, jul osv som användes för att få folk att öppna bifogade filer och följa länkar.

Eftersom det var effektivt tog idén fäste och det skapades falska antivirus som "hittade" och mot betalning "rensade" virus. I själva verket installerade de trojaner.

Nu har trenden gått mot att utnyttja ännu mer specifika och aktuella händelser - och se till att man hamnar högt på google då det söks på detta. Vi lär få se mycket mer av detta framöver.

Den som inte vill bli smittad av malware eller råka ut för desinformation bör göra som seriösa journalister alltid har gjort - se till att ha pålitliga källor.

--
Carl-Johan "CJ" Bostorp

PHP är enkelt att få fungerande, men säkerheten då?

(Publicerad 2009-03-05)

En undersökning bland 500 utvecklare världen över har visat att PHP är scriptspårket utvecklarna är mest nöjda med. I en kommentar till IDG säger Ola Bini att han tror det har att göra med "det är lätt att få en fungerande lösning". Och då lider säkerheten.

Artikeln på IDG nämner också att intresset för scriptspråk fortsätter öka i popularitet. Jag har i flera år talat om de olika krafter som ligger bakom varför vi ser så ohyggligt många sårbara webbapplikationer. En av dem är just att det finns väldigt kraftfulla scriptspråk.

Det finns fyra synliga faktorer som beställaren och omgivningen är synnerligen intresserade av: funktionalitet, tillgänglighet, kostnad och kalendertid för utvecklingen.  Alla fyra märks och är lätta att mäta. Sist kommer ett "jag vill ha den säker också", som brukar specificeras synnerligen luddigt. Självklart kommer utvecklingen då att luta åt att uppfylla de aspekter som är synliga och man vet kommer märkas och följas upp. Temat återfinns i min artikel från sommaren 2007.

Det är enkelt att få en applikation till det stadiet där den beter sig fungerande för en vanlig användare. Men eftersom det är så enkelt ställs det låga krav på utvecklarna, samtidigt som det ställs höga krav för att kunna koda säkert. De höga kraven kommer från en hög komplexitet med mängder av olika språk och protokoll som behöver kunnas, förutom den "naturliga" kodkomplexiteten.

Just PHP är särskilt sårbart i det här avseendet och det är jätteviktigt att man utbildar sina utvecklare i säker kodning.

--
CJ

RSS 2.0