Security Tip van de week: veilig met HTTP headers
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.
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 :)
DNSSEC in samenwerking met DANE zou een goeie stap voorwaards zijn.
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.
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.
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.
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.
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
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
