På ethvert site med respekt for sig selv, bør der være fire faste HTTP-headers med sikkerhed for øje. Det mener i hvert fald det hollandske webudviklingsfirma iBuilder, der har beskrevet headerne i et blogindlæg på firmaets hjemmeside.
1 CONTENT-SECURITY-POLICY
Headeren gør ifølge blogindlægget en hjemmeside stort set usårlig over for cross-site-scripting angreb (XSS). Altså javascript, som såkaldt ondsindede personer får til at køre på de klientmaskiner, som besøger en hjemmeside.
Ved at tilføje headeren Content-Security-Policy med de rette værdier, så er det muligt at kontrollere, hvorfra blandt andet flash, javascript, fonts og andet kan hentes og køres fra.
Som eksempel nævnes:
Headeren bevirker i dette tilfælde, at script-filer kun må komme fra det aktuelle domæne eller fra apis.google.com (Google JavaScript CDN)
Ulempen ved headeren er ifølge iBuilder, at Internet Explorer kun har begrænset understøttelse for headeren, ligesom der kun er understøttelse for den fra Android 4.4. Og så beskytter headeren heller ikke mod alle XSS-angreb.
2 X-FRAME-OPTIONS
Headeren beskytter mod click-jacking
Løsningen er:
Headeren kan bruges til at forhindre, at en side bliver vist i en iFrame. Hvis SAMEORIGIN også bliver anvendt, kan siden godt frames, hvis det sker på samme kilde, som server siden. Endnu en værdi er ‘ALLOW FROM http://url-here.example.com’ – der tillader siden at blive framet på den nævnte URL.
Bagsiden ved headeren er ifølge iBuilder, at headeren snart bliver forældet (deprecated) for i stedet at blive indlemmet i Content-Security-Policy 1.1, som dog endnu ikke er bredt understøttet. Så indtil da, er der ingen grund til at udelade X-Frame-Options, fremgår det af blogindlægget.
3 X-CONTENT-TYPE-OPTIONS
Headeren fortæller de browsere, der understøtter den, at de ikke skal forsøge at gætte typen af indhold, der bliver sendt fra serveren (Mime Sniffing). Sikkerhedsrisikoen kan her være, at en server eksempelvis tillader upload af billedfiler fra brugere, uden at tjekke, om det faktisk er billedfiler, der bliver uploadet ud fra andet end fil-endelsen, eksempelvis .jpg. I virkeligheden kan filen vise sig at være en HTML-fil. Og den kan ende med også at blive afviklet som en sådan, når browseren selv forsøger at sniffe sig frem til fil-typen.
Det kan fikses med:
Dog er headeren ifølge iBuilder kun understøttet af Chrome og Internet Explorer, men dermed vil den typisk også være understøttet af en del af de besøgende.
4 STRICT-TRANSPORT-SECURITY
Headeren fortæller browseren, at der kun skal forbindes til serveren via HTTPS. I stedet for alternativt at forbinde til eksempelvis netbanken over HTTP for så at blive viderestillet til HTTPS. Den teknik kan ifølge iBuilder muliggøre et man-in-the-middle angreb. Den angrebsvektor bliver angiveligt demonstreret med softwaren sslstrip.
Et eksempel, der fortæller browseren at anvende HTTPS-opkoblinger til sitet et år:
Ulempen er dog, at det foreløbigt kun virker på Firefox og Chrome, skriver iBuilder.
Hvad mener du? Er det fire must-have-HTTP-headere, og er der i virkeligheden andre, der er bedre?
Leave a Reply