image

Security Tip van de week: veilig met HTTP headers

maandag 22 oktober 2012, 12:18 door Jurre van Bergen, 13 reacties

Security.nl lanceert een nieuw onderdeel waar elke week een andere professional, expert, onderzoeker of lezer een security tip geeft. Persoonlijke tips, varierend van het veilig configureren van Windows, een handige security tool of het juist instellen van een firewall, waarmee de tipgever zijn systeem, applicatie of netwerk veiliger maakt.

Heb jij ook een leuke, originele, maar bovenal goede security tip die niet mag ontbreken, stuur dan een mail naar redactie@security.nl.

Deze week de tip van Jurre van Bergen

Introductie
In de tip van deze week wil ik het hebben over HTTP headers die in browsers als Chromium en Firefox zijn opgenomen en de beveiliging van je browser kunnen verbeteren. Sommige van deze technieken zijn nog in 'draft'. Dit betekent dat er nog geen uiteindelijke versie van de specificatie is. Desalniettemin hebben diverse browsers al wel draftversies verwerkt, zoals Chromium en Firefox. Internet Explorer loopt statistisch gezien hier op achter.

Content Security Policy
Content Security Policy (CSP) is een HTTP header die een restrictie meegeeft waar contact vandaan mag komen. Sommige sites hebben Javascript van derde partijen die in jouw browser worden geladen. Bijvoorbeeld Facebook, Google Analytics, Mixpanel en Content Delivery Networks (CDN - systeem dat content aan internetgebruikers biedt, zoals bijvoorbeeld filmpjes en downloads - red.).

Met het gebruik van de CSP headers kun je de kans verkleinen dat, wanneer iemand een CDN van een derde partij kraakt en malware of HTML-injectie meestuurt, je hiervan slachtoffer wordt, of dat er gegevens naar de derde partij lekken. CSP stopt dus onveilige inline JavaScript, maar stopt bijvoorbeeld geen cross-site scripting (XSS) via het Document Object Model (DOM) in je browser.

X-Frame-Options
Via deze optie kun je aan de browser meegeven dat pagina's gerenderd moet worden die via een iframe binnenkomen. Deze beveiligingstechniek is ontworpen om complexe aanvallen als ClickJacking tegen te gaan. Je kunt twee verschillende opties meegeven. De eerste is 'deny', hiermee wordt het iframe totaal niet geladen, de tweede is “sameorigin”, de pagina kan wel worden gerenderd als hij van dezelfde origine is als de pagina waar hij geladen wordt.

X-XSS-protection IE8+
Het XSS-filter werd geïntroduceerd in Internet Explorer 8 door Microsoft als een tegenaanval op 'non-persistent XSS aanvallen'. Je kunt ervoor kiezen om deze header mee te geven vanaf je applicatie om je gebruikers minder vatbaar te maken voor XSS-aanvallen, mocht je site ooit misbruikt worden hiervoor. Ik zou alleen niet al te veel vertrouwen op deze beveiligingstechniek, maar gewoon je input goed filteren.

Strict Transport Security
Ook om HTTPS verkeer te beveiligen zijn er verschillende opties. Eén daarvan is een certificaat 'pinnen' via een header. De techniek heet 'HTTP Strict Transport Security (HSTS)", dit maakt het mogelijk dat je alleen via HTTPS naar de site surft. Ook maakt dit het een stuk lastiger om een connectie van SSL te strippen via sslstrip. Deze tool is gemaakt door Moxie Marlinspike.

De draftversie die in Chromium was geïmplementeerd en de mensen in Iran gebruikten ten tijden van het Diginotar-debacle waren niet vatbaar als ze bijvoorbeeld Twitter bezochten, omdat de browser verbeterde beveiliging implementeerde zoals HSTS. Via de Chrome-browser kan je zelf ook sites toevoegen via chrome://net-internals/#hsts.

De HSTS-techniek maakt het dus een stuk lastiger om je beveiligde verbinding af te luisteren, behalve als Juliano Rizzo en Thai Duong weer een aanval vinden om SSL mee aan te vallen, zoals de BEAST- en CRIME-aanval.

Vertrouwen
Ik zou niet te snel vertrouwen op de methodes zonder dat je weet welke 'threat models" ze hebben. Ik raad iedereen aan om de standaarden eens door te lezen. Er zijn nog veel meer drafts voor standaarden die misschien worden aangenomen. Als je het leuk vindt om die te volgen heeft Tom Ritter een mooi overzicht gemaakt met wat er speelt bij IETF.

Jurre van Bergen is medeoprichter van Black Mountain Security, dat in mei 2012 is opgericht.

Dit artikel is geschreven op persoonlijke titel van de auteur en reflecteert niet noodzakelijk de zienswijze van Security.NL.

Reacties (13)
22-10-2012, 12:35 door Anoniem
En wat is nou de "tip"...?
22-10-2012, 13:06 door [Account Verwijderd]
[Verwijderd]
22-10-2012, 13:10 door WhizzMan
Wie zet of stuurt deze headers precies? Welke applicaties doen er wat mee? Als een webserver of browser een van deze headers sturen en een MITM aanvaller stript deze er gewoon tussenuit, wat gebeurt er dan?
22-10-2012, 13:56 door Anoniem
Feitelijk zijn al deze headers een poging om een 'broken' security model wat te verbeteren door suggesties aan de browser mee te geven die gebruikt kunnen worden om een paar gaten in het security model dynamisch te dichten. Een permanente oplossing verwacht ik echter niet uit deze hoek. We zouden eigenlijk het security model voor de webbrowser eens goed moeten herzien.
22-10-2012, 15:40 door Anoniem
HSTS is wel veel-belovend, mits het b.v. in de DNS (i.c.m. DNSSEC) geimplementeerd wordt i.p.v. als HTTP Header.
22-10-2012, 17:02 door Anoniem
Door Anoniem: HSTS is wel veel-belovend, mits het b.v. in de DNS (i.c.m. DNSSEC) geimplementeerd wordt i.p.v. als HTTP Header.
Onzin. niet "i.c.m." maar de woordjes omdraaien en dan "i.p.v". Zucht.
22-10-2012, 17:58 door Anoniem
Door WhizzMan: Wie zet of stuurt deze headers precies? Welke applicaties doen er wat mee? Als een webserver of browser een van deze headers sturen en een MITM aanvaller stript deze er gewoon tussenuit, wat gebeurt er dan?
De truc is dat bijvoorbeeld een HSTS header wordt gechacet voor een langere tijd, dus als je een site bezoekt die eerst niet wordt ge-MITM-d en je browser slaat de informatie op, het niet mogelijk is om een MITM aanval uit te voeren zolang de header geldig is/
22-10-2012, 21:16 door wica128
De missende tip is:
Zet een proxy op, die headers kan aanpassen en toevoegen.
Zodat je oa. er voor kan zorgen dat.
X-Frame-Options altijd opsameorigin staat.

:)
Maar ja, met een proxy kan je nog meer ellende er uitfilteren :)
23-10-2012, 00:20 door JurrevanBergen
Door Anoniem: HSTS is wel veel-belovend, mits het b.v. in de DNS (i.c.m. DNSSEC) geimplementeerd wordt i.p.v. als HTTP Header.

DNSSEC in samenwerking met DANE zou een goeie stap voorwaards zijn.

Door wica128: De missende tip is:
Zet een proxy op, die headers kan aanpassen en toevoegen.
Zodat je oa. er voor kan zorgen dat.
X-Frame-Options altijd opsameorigin staat.

:)
Maar ja, met een proxy kan je nog meer ellende er uitfilteren :)

De headers kan je toevoegen via je webserver, applicatie vanaf je webserver of een aparte proxy hiervoor, wat je voorkeur heeft.

Door WhizzMan: Wie zet of stuurt deze headers precies? Welke applicaties doen er wat mee? Als een webserver of browser een van deze headers sturen en een MITM aanvaller stript deze er gewoon tussenuit, wat gebeurt er dan?

De ontwikkelaar zet de headers op via een webserver, applicatie vanaf je webserver of een aparte proxy hiervoor, wat je voorkeur heeft. De applicaties die er wat mee doen heb ik net opgenoemd, namelijk, browsers. MITM aanvallen worden moeilijk als je HSTS headers en een public key pinned, vooropgesteld dat, de eerste keer dat je de site bezoekt er geen MITM plaatsvind, of iets als convergence/tack als plugin hebt in je browser. Dan zou er geen MITM kunnen plaatsvinden, in andere gevallen wel.

Door Anoniem: Feitelijk zijn al deze headers een poging om een 'broken' security model wat te verbeteren door suggesties aan de browser mee te geven die gebruikt kunnen worden om een paar gaten in het security model dynamisch te dichten. Een permanente oplossing verwacht ik echter niet uit deze hoek. We zouden eigenlijk het security model voor de webbrowser eens goed moeten herzien.

De huidige industrie bij IETF wordt beheerst door grote bedrijven als Microsoft, Google en andere, die eerst hun eigen standaarden intern ontwikkelen en al toepassen in haar eigen producten en zo deze doordrukken, zonder dat er goed wordt gekeken welke standaard hier nu een beter en veiliger internet opleveren.
23-10-2012, 15:52 door Preddie
Jurre bedankt voor je bijdrage man ! ;)
23-10-2012, 23:47 door Anoniem
Wat in het artikel mist en het misverstand daarover blijkt ook uit de eerste comments: de tips zijn voor website makers.

Ik mis alleen nog wel een aantal andere opties (misschien omdat veel mensen ze wel kennen, maar als je op het Internet kijkt worden ze toch niet veel gebruikt), zoals:

- secure optie bij het versturen van cookies
- httponly optie bij het versturen van cookies

HTTP/2.0 gaat misschien alleen maar via TLS werken ("SSL" zoals HTTPS), omdat via tcp port 80 (http) een nieuw protocol introduceren vanwege proxy servers, etc. eigenlijk niet mogelijk is. Ze zullen SPDY gebruiken als basis dus kun je daar naar kijken om te zien hoe dat er uit ziet.
24-10-2012, 12:51 door WhizzMan
Bedankt voor de verduidelijking!
24-10-2012, 14:54 door Anoniem
Door JurrevanBergen:
De huidige industrie bij IETF wordt beheerst door grote bedrijven als Microsoft, Google en andere, die eerst hun eigen standaarden intern ontwikkelen en al toepassen in haar eigen producten en zo deze doordrukken, zonder dat er goed wordt gekeken welke standaard hier nu een beter en veiliger internet opleveren.

Dat is eigenlijk ook deels de bedoeling van de standaarden organisaties als W3C en in mindere mate IETF. Maar IETF doet wel graag aan hergebruik van bestaande product onderdelen.

W3C is heel duidelijk dat ze graag werkende voorbeelden wil zien om te kijken wat handig werkt en wat niet en om dingen uit te proberen en om anderen de mogelijkheid te geven het uit te proberen. Dat kan ook prima met bijvoorbeeld een vendor prefix. Wat een browser fabrikant inbouwd wordt niet 1 op 1 overgenomen en opgenomen als standaard.

Waarom willen ze dat ? Om dat als je iets eenmaal tot standaard is gemaakt je het, zo is gebleken, ook eigenlijk niet meer kunt aanpassen. Een aantal browsers werkt ook samen in de WHATWG om daar nieuwe standaarden te ontwikkelen.

Als je mee wilt helpen bij IETF of W3C dat kan gewoon hoor !

Luister maar eens goed naar deze video http://vimeo.com/16326857 het deel over vendor-prefixes begint om 20:35
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.