XSS-skanner som Chrome-tillägg

Gareth Heyes har släppt sin cross-site scripting-skanner "XSS Rays" i ny version, denna gång som ett Google Chrome-tillägg. Läs om verktygets funktioner och ladda ner tillägget.

Testa säkerheten i din webbläsare

Säkerheten i webbapplikationer är som bekant helt beroende av säkerheten i webbläsaren, både läsarens stöd för säkerhetsfunktioner och läsarens avsaknad av säkerhetsbuggar.

Det finns ett intressant testverktyg på nätet – Browserscope Security Test. Där kan du enkelt testa hur väl din webbläsare stödjer säkerhetsfunktioner såsom Strict Transport Security och om den skyddar mot kända hack såsom JSON hijacking.

Det finns också en sammanfattning av hur olika webbläsare klarar sig:

• Bäst just nu är Chrome 6 som godkänt på 15 av 16 test.
• Firefox 3.6 får bara 10 av 16 men med den senaste versionen av NoScript så når Firefox 14 av 16.
• Safari 5 får 13 av 16.
• IE 8 får 10 av 16 men IE 9-betan når 12 av 16.
• Opera får 9 av 16.

/John Wilander, chapter co-leader

Säkrare SSL med Strict-Transport-Security

En riktig säkerhetssnackis har varit Strict-Transport-Security (STS) som motmedel mot ett flertal av de man-in-the-middle-attacker som presenterats mot SSL/HTTPS. Nu var det till och med tema i veckans Steve Gibson-podcast "Security Now!" så det är hög tid att skriva om det här.

Användarna accepterar varningar

Vem har inte sett sin webbläsare varna för ett felaktigt SSL-cert? Och vem har inte klickat vidare i övertygelse om att det ligger slarv bakom, dvs att driften inte köpt och driftsatt nytt cert i tid?

Jag har faktiskt bara träffat en IT-människa som verkligen bromsat in vid den där varningssidan och han var inte någon säkerhetskille. Det var en utvecklare "på andra sidan" mitt projekt som mejlade oss och cc:ade beställare och chefer för att påtala denna "show stopper". Han skulle göra ett anrop till vår testmiljö där vi självklart inte körde med ett skarpt cert. Vi fick mejla honom plus alla chefer och förklara att han fick göra ett säkerhetsundantag.

Men om vi bortser från denna enda person så är beteendet där ute att klicka sig förbi varningen. Folk i gemen har vant sig vid att webbsidor kan orsaka varningar men fungera bra. Så vad säger att internetbanken inte ska kunna uppvisa en sån varning? Vips så har vi sänkt ribban rejält för man-in-the-middle. Attackeraren behöver inte skapa ett SSL-cert signerat av en godkänd CA om offret ändå godkänner hans/hennes fulcert.

Strict-Transport-Security lovar "Inga fulcert"

Idén bakom Strict-Transport-Security är att webbservern kan publicera en header som säger:

"Jag levererar bara sidor över https och garanterar att jag inte kommer köra med ett ogiltigt certifikat. Om du skulle få svar på den här adressen med ett ogiltigt certifikat så ska du på inga villkor tillåta användaren att klicka sig vidare. Detta gäller i X sekunder framåt."

Formellt ser svaret från servern ut så här (verkligt exempel från https://www.paypal.com/se):

shell> curl -i https://www.paypal.com/se

HTTP/1.1 200 OK

Date: Sat, 21 Aug 2010 19:47:14 GMT

Server: Apache

Cache-Control: private

Pragma: no-cache

Expires: Thu, 05 Jan 1995 22:00:00 GMT

Set-Cookie: [snip/]; domain=.paypal.com; path=/; Secure; HttpOnly

(... fler cookies ...)

Vary: Accept-Encoding

Strict-Transport-Security: max-age=500

Transfer-Encoding: chunked

Content-Type: text/html; charset=UTF-8

Servern kan också lägga till information om att regeln ska gälla alla subdomäner. Grammatiken ser ut så här:

Strict-Transport-Security =

"Strict-Transport-Security" ":" "max-age" "=" delta-seconds [ ";" "includeSubDomains" ]

Webbläsaren tillåter inga fulcert

Grunden till STS-funktionen är att en STS-medveten webbläsare (just nu bara Chrome och Firefox med NoScript) måste avbryta kommunkationen med en STS-sajt om certifikatet är ogiltigt. Det får inte finnas en chans för användaren att klicka sig förbi någon sorts varning. Tuffa tag helt enkelt.

Ett annat krav på en webbläsare som förstår STS är att den automatiskt gör om alla HTTP-anrop till HTTPS-anrop om det är en STS-sajt med giltig tidsstämpel. Det hindrar attacker i stil med SSLStrip.

Webbläsaren noterar servern som STS

När en STS-medveten webbläsare får en STS-header så måste den:

• Lägga till servern till sin lista över kända STS-servrar
• Uppdatera informationen om max-age och includeSubDomains om dessa fält skiljer sig från vad som sparats tidigare för den servern

Om webbläsaren får en HTML-kodad HTTP-header med STS, t ex ...

<META HTTP-EQUIV="Strict-Transport-Security" VALUE="max-age:0">

... så får den taggen inte användas. Annars skulle en attackerare kunna injicera STS-direktiv.

Server-konfiguration

Om man överväger att använda STS på sin server så är det några saker man ska tänka igenom.

Först är förstås hur bra man är på att sköta sina SSL-certifikat eftersom en STS-sajt helt enkelt inte kommmer att fungera om certet är ogiltigt. Har man ett kalendarium? Som fler än en person har ansvar för? Med rutiner som fortfarande funkar om tre år när certet går ut? Jag har mött alltför många organisationer som har dåligt samvete över sin obefintliga hantering av SSL-certifikat.

Sen måste man bestämma sig för en strategi för tidsstämplarna. Ska man alltid svara med ett fast tidsspann, t ex en vecka eller ska man svara med antal sekunder kvar tills certet går ut?

Svenska internetbanker kör inte STS. Än.

OK, tämligen få webbläsare har ännu stöd för STS men inget hindrar seriösa tjänsteleverantörer att implementera STS på sina HTTPS-servrar. Jag kollade de fyra stora internetbankerna. Ingen av dem kör STS. Än.

Tomma resultat för följande curl-anrop:

curl -i https://internetbank.swedbank.se/SecurityServer/SecurityServer | grep "Strict-Transport-Security"

curl -i https://internetbanken.privat.nordea.se/nsp/engine | grep "Strict-Transport-Security"

curl -i https://taz.vv.sebank.se/cgi-bin/pts3/wow/wo10.c1010.f001?I= | grep "Strict-Transport-Security"

curl -i https://secure.handelsbanken.se/bb/glss/servlet/prelogon?id=seprivsv | grep "Strict-Transport-Security"

Dödskalle vid trasigt SSL-cert

Google Chrome börjar visa en röd dödskalle vid felaktigt SSL-cert.

Chris Evans (en av talarna på sommarens konferens) skriver följande:

"The great thing about red skull + crossbones is that it highlights the site is broken and creates pressure to fix it."

Andra involverade i Chromium är tveksamma:

"Users have no control over the site, and they do have choices in browsers, so unless all browsers do it, most users will believe the browser is broken, not the site."

Det riktigt intressanta är att man överväger att visa dödskallen vid allvarliga varianter av mixat http/https-innehåll, ett vanligt problem vid mashups.

• Varning vid mixat innehåll med ex. <img> ger "spökhänglås" + grå https-text
• Fel vid mixat innehåll med ex. <script> ger dödskalle + röd https-text