Hier noch ein paar weitere Anmerkungen
Cookies
Wie sichere ich den einen Keks ab? Vorm Krümelmonster verstecken? Nein ernsthaft, wie sichere ich so einen ab?
Was man ja machen kann, ist ein Cookie nur für einen bestimmten Pfad setzen.
Ein Hauptanwendungsfall von Cookies ist die Speicherung des Sitzungsidentifikators. Kommt man an dieses Cookie ran und die Sitzungseinstellungen der Anwendung sind auf eine Zeitüberschreitung der Sitzung nach 10 Tagen eingestellt, kann dieses Cookie ohne Abmeldung des betroffenen Nutzers so lange verwendet werden. Also wäre hier eine “abgesicherte” Sitzungskonfiguration wohl eher zu empfehlen.
Man könnte das Sitzungscookie auch verschlüsseln, bloß bringt das vermutlich nichts. Ob man das verschlüsselte oder unverschlüsselte Cookie als Angreifer an den Server sendet ist ja egal.
Bei einigen Cookies könnte Verschlüsselung aber schon Sinn machen. Um z. B. Angreifern keine interne Struktur der Anwendung zu verraten, die über die Cookies bekannt werden würde.
Was gemacht werden kann sind folgende Cookie-Eigenschaften zu setzen wenn benötigt:
-
path
für den das Cookie gültig ist
-
secure
wenn gesetzt, wird das Cookie nur über mit TLS verschlüsselte Verbindungen gesendet (Vertraulichkeit & Authentizität)
-
port
Liste von Ports bei welchen das Cookie bei der Anfrage mitgegeben wird
-
domain
zum expliziten angeben der Domäne bei welcher das Cookie mitgesendet werden soll
-
discard
um Nutzer Agenten explizit mitzuteilen, dass das Cookie nach beenden des Browsers gelöscht werden soll
-
max-age
wie lange das Cookie gültig ist
Siehe auch RFC 2965
Keine Cookies zu verwenden ist zwar schwierig, sollte aber in jedem Fall angestrebt werden.
Zertifikate
Bezüglich der TLS Zertifikate und der Konfiguration der entsprechenden Webserver, Datendanksysteme und eventuell für die Webseite vorhandene Mailserver ist der TLS Konfigurationsgenerator von Mozilla meinerseits zu empfehlen.
Dadurch geht man dem Problem aus dem Weg, welche Cipher Suites noch sicher bzw. zu empfehlen sind. Natürlich alles unter der Voraussetzung, dass der Konfigurator aktuell gehalten wird.
Bezüglich TLS Protokoll Versionen ist mir aus einer Kryptographie Vorlesung bekannt, dass Versionen 1.2 und 1.3 aktuell als sicher gelten und guten Gewissens empfohlen werden können. Das deckt sich auch mit den deaktivierten Versionen (Intermediate Configuration siehe Konfigurator Verweis oben).
HPKP wird anscheinend nicht mehr empfohlen
Skripte und Verweise
Wenn möglich kein Javascript verwenden, ansonsten die CSP Kopfzeile entsprechend der vertrauenswürdigen Quellen richtig konfigurieren.
Zusätzlich kann die Integrität (siehe SRI) der zu ladenden Skripte und Verweise mittels eines Hash-Werts überprüft werden. Dieser kann als integrity
Attribut bei Skripten (script
) und Links (link
) angegeben werden und beschränkt sich dabei nicht auf Skripte und Stilvorlagen.
Eine Beispiel:
<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.12.0/css/all.css"
integrity="sha256-ybRkN9dBjhcS2qrW1z+hfCxq+1aBdwyQM5wlQoQVt/0=" crossorigin="anonymous"/>
<script src="http://code.jquery.com/jquery-3.5.1.min.js"
integrity="sha256-9/aliU8dGd2tb6OSsuzixeV4y/faTqgFtohetphbbj0=" crossorigin="anonymous"></script>
Wichtig zu erwähnen ist hier wohl, dass wenn die Ressource von einer anderen Domäne geladen wird das crossorigin="anonymous"
Attribut explizit gesetzt werden muss. Andernfalls prüft der Browser die Prüfsumme nicht und die entsprechende Prüfsumme ist nutzlos.
Hier ein SRI Onlinegenerator und auch der Befehl für openssl
.
HTTP Kopfzeilen
- HSTS (siehe RFC)
- XSS Schutz (Die üblichen Kopfzeilen sind nur noch für ältere Browser notwendig, sonst seit CSP obsolet… Siehe MDN)
- CSP Zum Einstellen, von welcher Domäne ein Frame eingebunden werden darf, woher Skripte geladen werden dürfen etc. Siehe W3C Arbeitsentwurf