1. Start
  2. Blog
  3. Kommunikationssicherheit
  4. HTTP Security Header schützen Ihre Besucher

HTTP Security Header schützen Ihre Besucher

Die­ser Artikel wurde am 09.07.2019 um die Header Expect-CT und Referrer-Policy erweitert.

Webseiten-Betreiber stecken häu­fig einen gro­ßen Auf­wand in den Schutz des ei­ge­nen Inter­net­an­ge­bots vor An­grif­fen. Mit einer durch­dach­ten Ar­chi­tek­tur und re­gel­mä­ßi­gen Pen­tests kann ein ho­hes Sicher­heits­ni­veau er­reicht wer­den. Da­bei kon­zen­trie­ren sich die Maß­nah­men in der Re­gel je­doch nur auf die Ser­ver-Sei­te und Kom­mu­ni­ka­tion. Der Be­nutzer auf der Client-Sei­te muss in der Re­gel selbst für seine Sicher­heit sor­gen.

Client-Server-Kommunikation
Anfra­ge und Ant­wort im Client-Ser­ver-Mo­dell

HTTP Security Header

Um seine Be­nutzer den­noch vor An­grif­fen bei der Ver­wen­dung des ei­ge­nen In­ter­net­an­ge­bots zu schützen, kön­nen Web­sei­ten-Be­trei­ber so­ge­nannte Se­cu­ri­ty Hea­der ein­setzen. Da­bei han­delt es sich um HTTP Ant­wort-Hea­der, wel­che dem Brow­ser Si­cher­heits­an­wei­sun­gen ge­ben.

Eine Kom­mu­ni­ka­tion von Brow­ser (Client) und Ser­ver läuft ver­ein­facht fol­gen­der­ma­ßen ab, wo­bei die Se­cu­ri­ty Hea­der grün her­vor­ge­ho­ben sind:

Anfrage des Clients
GET / HTTP/1.1
Host: aramido.de
Antwort des Ser­vers
HTTP/1.1 200 OK
Date: Tue, 09 Aug 2016 09:04:07 GMT
ETag: [...]
X-Content-Type-Options: [...]
Strict-Transport-Security: [...]
X-Frame-Options: [...]
Content-Security-Policy: [...]
X-XSS-Protection: [...]
Set-Cookie: PHPSESSID=[...]; path=/; domain=aramido.de; secure; HttpOnly;
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html lang="de">
[...]
</html>

Trotz Ab­siche­rung der Web­an­wen­dung sind An­grif­fe wie Click­jacking, SSL-Strip­ping und Cross-Site In­jec­tions mö­glich. Die­se lau­fen teils Brow­ser-sei­tig ab und der Be­nutzer müss­te die­se An­grif­fe selbst er­ken­nen. Aus die­sem Grund kann der Be­trei­ber einer Web­sei­te den Brow­ser über Se­cu­ri­ty Hea­der an­wei­sen, beis­piels­wei­se eine Sei­te nur über das https-Pro­to­koll auf­zu­ru­fen oder kein In­line-Java­Script inner­halb der Web­sei­te zu­zu­las­sen.
Im Nach­fol­gen­den wer­den alle HTTP Se­cu­ri­ty Hea­der vor­ge­stellt. Wir em­pfeh­len je nach Si­tua­tion von allen Hea­dern Ge­brauch zu ma­chen.

1. Strict-Transport-Security

HTTP Strict Trans­port Security (HSTS) weist den Brow­ser an die Web­sei­te nur noch über sichere https-Ver­bin­dun­gen auf­zu­ru­fen und schützt da­durch bei­spiels­wei­se vor SSL-Strip­ping-An­griffen. Um diese An­wei­sung zu ken­nen, muss der Client die Web­seite natür­lich min­des­tens ein Mal auf­ge­ru­fen ha­ben. Hier­zu gibt es je­doch Ab­hilfe: es ist mö­glich sei­ne Do­main in eine Pre-Load-Lists ein­tragen zu las­sen, wo­durch ein frisch insta­llier­ter Brow­ser be­reits weiß, wel­che Sei­ten nur per https auf­ge­ru­fen wer­den sol­len.

Beispiel
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

2. Public-Key-Pins

Public Key Pinning (HPKP) ist ein Me­cha­nis­mus, der den Miss­brauch von SSL-Zer­tifi­ka­ten ver­hin­dert und da­durch beis­piels­wei­se das Ri­si­ko von Man-in-the-Middle-Angrif­fen (MITM) stark re­du­ziert. Erst kürz­lich ist es wie­der ge­lun­gen Zer­ti­fi­ka­te für be­lie­bi­ge Do­mains aus­zu­stel­len. Durch Key Pin­ning kann der Admi­nis­trator dem Brow­ser mit­teilen, wel­che Zer­ti­fi­kate inner­halb eines be­stimm­ten Zeit­raums für eine ver­schlüs­selte Kom­munika­tion ver­wen­det wer­den dür­fen. Wird ein anderes Zerti­fikat ver­wen­det, des­sen Signa­tur für den Brow­ser unbe­kannt ist, wird die Ver­bin­dung ab­ge­lehnt. Der Schutz tritt ein, nach­dem zum ersten Mal eine Ver­bin­dung auf­ge­baut und der Hea­der über­tra­gen wur­de.

Beispiel
Public-Key-Pins: pin-sha256="Xij2j0o8bKDyEgvB5G4j1Qv0rIi8TSBHBC02B3clUVq="; pin-sha256="YgGWX7JFtb+h6Ctb51sPZiWo3gw9Fr+uJgwmI+TcKLb="; report-uri="http://example.com/pkp-report"; max-age=1209600; includeSubDomains

3. X-Frame-Options

Durch den X-Frame-Op­tions Hea­der können so­genann­te Click­jacking-An­griffe ver­mie­den wer­den, indem Brow­ser die Dar­stel­lung einer Web­seite inner­halb eines Frames verhin­dern. Ist es nicht vor­gese­hen, dass Ihre Web­seite durch einen Iframe auf einer anderen Web­seite ein­gebun­den wird, aktivie­ren Sie diesen Security Header.

Beispiel
X-Frame-Options: deny

4. X-XSS-Protec­tion

Durch den X-XSS-Protec­tion Security Header wird der Browser-Filter gegen Cross Site-Scripting ge­steu­ert. Damit können einige, jedoch nicht alle XSS-Angriffe ver­eitelt werden. Die Schutz­maß­nahme bie­tet dem­nach ein zusätz­liches Netz für einen Defense-In-Depth-An­satz (Zwiebel­schalen­prinzip).

Beispiel
X-XSS-Protection: 1; mode=block

5. X-Content-Type-Options

Bestimmte Browser können über diesen Header ange­wiesen wer­den nur den über einen weite­ren HTTP-Header gesetz­ten Con­tent Type zur Typen­inter­preta­tion einer Da­tei zu ver­wen­den.

Beispiel
X-Content-Type-Options: nosniff

6. Content-Security-Policy

Content-Security-Policy-Header (CSP) können Benu­tzer vor einer gro­ßen An­zahl von An­griffen schü­tzen und sind wohl die mäch­tigs­ten Security-Header. Durch sie kann der Browser beis­piels­weise an­ge­wiesen wer­den aus wel­chen Quel­len Bil­der stam­men oder an wel­che URLs For­mu­lare Da­ten senden dür­fen.

Beispiel
content-security-policy: default-src 'none'; style-src 'self'; img-src 'self' https://cdn.aramido.de; report-uri /csp/report

7. Expect-CT:

Mit dem Expect-CT Header kann der Ser­ver dem Client mit­teilen, dass das Zertifikat, das bei verschlüsselten Verbindungen mitgeliefert wird, die Anforderungen für Certificate Transparency erfüllen muss. Genauer: das Zertifikat muss einen signierten Zeit­stempel ent­halten, wann das Zertifikat an ein Log von Certificate Transparency übermittelt wurde. Ist kein Zeitstempel enthalten, handelt es sich mit großer Wahr­schein­lich­keit um ein nicht auto­risiertes Zertifkat und die Vertrau­lichkeit und Integrität der verschlüsselten Ver­bind­ung ist gefährdet.

Es werden mehrere Direktiven an­geboten, um das Verhalten des Expect-CT Headers zu steuern:

  • max-age: Gibt die Zeit in Sekunden an, wie lange die Inform­ation des Headers im Brower ge­speichert und als gültig erachtet werden soll. Diese Direktive ist zwingend er­forderlich.
  • report-uri: Enthält eine absolute URL, an die Fehler gemeldet werden können. Es muss HTTPS ver­wendet werden.
  • enforce: Erzwingt die Validier­ung des Zertifikats. Im Fehler­fall wird, sofern an­ge­geben, eine Fehler­bericht gesendet und die Verbindung abgelehnt.
Die Direktiven können entweder durch Komma getrennt oder in getrennten Headern angegeben werden.

Beispiele
Expect-CT: max-age=108000, enforce, report-uri="https://report.aramido.de/Expect-CT/report"

Expect-CT: max-age=108000, enforce
Expect-CT: report-uri="https://report.aramido.de/Expect-CT/report"

Mit der Direktive enforce kann die Über­prüf­ung er­zwungen werden. Im Fehler­fall wird die Ver­bindung ab­ge­lehnt und eine Meld­ung generiert, sofern eine report-uri an­ge­geben wurde.

8. Feature-Policy

Mit­hilfe des Feature Policy-Header können diverse Funktionen des Brow­sers granular ge­steuert werden. Grund­sätzlich setzt sich der Feature Policy-Header aus einer Direktive und Kontroll­optionen zusammen. Die Direktive be­schreibt die zu ver­wendende Funktion. Folgende Brow­ser-Funktionen können mit dem Feature Policy-Header be­schränkt werden:

  • autoplay
  • camera
  • display-capture
  • document-domain
  • encrypted-media
  • fullscreen
  • geolocation
  • microphone
  • midi
  • payment
  • vr

Diese Direktiven können mit vier ver­schiedenen Kontroll­optionen zusammen auftreten:

  • *: Erlaubt die Nutz­ung der Funktion in allen Be­reichen der An­wendung (inklusive Ifames).
  • 'self': Erlaubt die Nutz­ung der Funktion in alle Bereichen der An­wendung, außer bei Iframes, die von einer anderen URL eingebunden werden.
  • 'none': Die Nutz­ung der Funktion ist nicht möglich.
  • 'src': Die Nutz­ung der Funktion ist nur dann möglich, wenn die Quelle hier gelistet wird.

Die Seite https://caniuse.com stellt die Verbreitung des Feature Policy-Headers in diversen Brow­sern dar.

Beispiel
Feature-Policy: display-capture 'none'; document-domain 'none'; geolocation 'none'; microphone 'none'

Security Header über­prü­fen

Um das eigene Internet­ange­bot zu über­prüfen, ste­hen im Inter­net diver­se Tools zur Ver­fü­gung. Das HTTP-Obser­vatory bietet die Mö­glich­keit mit einem Mal eine Web­seite durch meh­rere Scanner prü­fen zu las­sen. Bei auto­mati­schen Tests ist es natür­lich wich­tig Er­geb­nisse zu veri­fizie­ren und zu inter­pre­tieren.

Fazit

Wer von Security Hea­dern Ge­brauch macht, unter­nimmt nicht Maß­nah­men auf Ser­ver-Sei­te und der Kom­muni­kations­ebene, son­dern auch auf der Benutzer-Seite. Aktuelle Brow­ser kön­nen mit Securi­ty Hea­dern um­gehen und schützen den Be­nutzer vor An­griffen wie SSL-Strip­ping, Man-in-the-Middle und Click­jacking. Zwar wird es auch durch den Ein­satz von Security Headern keine ab­so­lute Sicher­heit ge­ben; dennoch ist es ein rich­tiger Schritt in Rich­tung Defense-In-Depth.

Update 04.05.2020

Beim Expect-CT-Header hatte sich ein Fehler eingeschlichen. Dort hieß es: falls ein Zeitstempel enthalten ist, handelt es sich sehr wahrscheinlich um ein gefälschtes oder ungültiges Zertifikat. Richtigerweise muss es natürlich heißen, dass falls kein Zeitstempel enthalten ist, handelt es sich sehr warhscheinlich um ein gefälschtes oder ungültiges Zertifikat. Vielen Dank an den Aufmerksamen Leser.

Andreas Sperber
Verschlüsselung Cross Site Scripting (XSS) JavaScript Secure Coding Social Engineering Man-In-The-Middle (MIM) Click-Jacking SSL-Stripping HTTP Strict Transport Security (HSTS)

Am 09.07.2019 in der Kategorie Kommunikationssicherheit veröffentlicht.

‹‹ Zurück zum Blog