Einige Sicherheitsoptionen müssen etwas mehr berücksichtigt werden als andere. Einige lassen sich ohne weiteres Nachdenken einschalten, andere brauchen viel Nachdenken und müssen wahrscheinlich gleich nach dem Einschalten getestet werden.
No-brainers
Verbieten Sie Content-Type Sniffing
Diese Option verbietet, dass der Browser versucht, unerwartete Inhaltstypen für meist CSS und JavaScript zu verarbeiten. Einige Browser versuchen bei unerwarteten Informationen über die gerade geladene Datei zu verstehen, welche Art von Inhalt sich in dieser Datei befindet. Und dann könnten sie versuchen, eine bessere Verwendung für die Datei zu finden als die, die im Dokument angegeben wurde. Dies ist fast immer nutzlos und kann von Angreifern missbraucht werden.
Meine Empfehlung: Schalten Sie es einfach ein
Entfernen Sie ausgehende Informationen über Ihren Server
Diese Option filtert alle von Ihrem Server gesendeten HTTP-Header, die Angreifern eine Vorstellung davon vermitteln, welche Software und welche Version der jeweiligen Software auf Ihrem Server verwendet wird. Ob es sich um die Drupal-Version, die Apache-Version, die PHP-Version oder irgendeinen anderen Hinweis darauf handelt, welche Art von Software Ihr Server verwendet, ein potentieller Angreifer kann einfach nach Schwachstellen für diese suchen und sie missbrauchen.
Dies könnte es schwieriger machen, bestimmte Probleme mit Ihrem Server zu debuggen. Denken Sie daran, dass Sie diese Funktion jederzeit mit einem einfachen Klick aktivieren oder deaktivieren können. Falls Sie also beim Debuggen einige Header vermissen, schalten Sie sie aus und später wieder ein.
Meine Empfehlung: Schalten Sie es einfach ein
Cross-site scripting Schutz
Für den Fall, dass ein Angreifer einen manipulierten Link an einen Ihrer Kunden senden oder bösartige Inhalte in Ihre Website einschleusen kann, schützt diese Option den Benutzer, indem sie den Browser das Dokument auf Angriffe scannen lässt.
Diese Option hat zwei Einstellungen: Sie können entweder unsichere Skripte entfernen oder das Rendern der Site auf einmal verhindern.
Es sind Hunderte von Angriffen bekannt, und die Chancen stehen gut, dass ein Angreifer, der Ihre Website angreift, mehr als nur einen verwendet. Mit den Optionen zum Entfernen unsicherer Skripte kann der Browser jeden von ihm entdeckten Angriff entschärfen, aber Angriffe, die er nicht entdeckt hat, werden trotzdem ausgeführt. An dieser Stelle kommt die Option Rendering verhindern ins Spiel. Wenn der Browser einen einzigen Angriff auf die Seite entdeckt, wird er die Seite überhaupt nicht rendern.
Meine Empfehlung: Rendering verhindern
Thinking required
Es gibt ein paar Funktionen, die davon abhängen, ob Ihre Website konsequent HTTPS verwendet oder nicht.
Wenn Sie sicher sind, dass HTTPS überall auf Ihrer Website verwendet wird und Ihr Server wahrscheinlich bereits Datenverkehr, der http anfordert, auf https umleitet, gibt es einige Optionen, die Sie in wao.io aktivieren sollten.
HTTP-URLs zu HTTPS umleiten
Dadurch wird nicht nur sichergestellt, dass keiner Ihrer Benutzer unsichere Inhalte sieht, sondern auch, dass eine http-Anforderung gar nicht erst auf Ihren Server gelangt. wao.io übernimmt die Aufgabe und leitet Ihren Client auf die https-Version der angeforderten Ressource um. Dies erhöht nicht nur die Sicherheit, sondern auch die Performance der Umleitung.
Meine Empfehlung: Wenn Sie https konsequent verwenden, schalten Sie es ein
Cookie Sicherheit
Auch diese Option hat zwei verschiedene Einstellungen. Sie können Cookies entweder davor schützen, über unsichere Verbindungen offengelegt zu werden, oder sie für unsichere Verbindungen ganz verbieten.
Beide Optionen fügen das Sicherheitsflag zu jedem Cookie hinzu, das Sie über den Set-Cookie-HTTP-Header setzen. Das bedeutet, dass der Client diese Cookies nicht sendet, wenn er eine unsichere http-Verbindung verwendet. Die Verbieten-Option wird sogar alle Set-Cookie-HTTP-Header entfernen, wenn die Verbindung unsicher ist.
Meine Empfehlung: Wenn Sie https konsequent verwenden, verbieten Sie Cookies für unsichere Verbindungen.
Einschränken der Einbettung in andere Webseiten
Nachdem wir nun die Funktionen ausgeschlossen haben, die auf HTTPS basieren, wollen wir uns nun den Funktionen zuwenden, die alles rund um Iframes behandeln.
Um eine durchdachte Entscheidung für diese Optionen zu treffen, müssen Sie wissen, ob Ihre Website in Iframes angezeigt werden soll oder muss, und - falls ja - welche Domains diese Iframes verwenden.
Mit der folgenden Option können Sie steuern, wo Iframes, die Ihre Website enthalten, erlaubt sind. Eine mögliche Antwort auf die Iframe-Frage lautet "Ich weiß es nicht". In diesem Fall sollten Sie die Einbettung nicht einschränken. Wenn Sie jedoch wissen, dass keine Iframes erforderlich sind, damit Ihre Website und Ihr Unternehmen korrekt funktionieren, sollten Sie die Einbettung einfach sofort verbieten.
Falls Sie die Domains kennen, die Iframes zur Anzeige Ihrer Website verwenden, gibt es zwei mögliche Ergebnisse: Die Domain, die den Iframe verwendet, ist entweder immer die Domain, die im Iframe enthalten ist, oder sie ist es nicht. Im ersten Fall können Sie die Einbettung nur von demselben Ursprung aus erlauben, im zweiten Fall können Sie eine Liste der Domains angeben, die Iframes verwenden dürfen.
Meine Empfehlung: entweder verbieten oder eine Liste der Ursprünge angeben
Cookies auf dieselbe Website beschränken
Auch bei dieser Funktion geht es darum, Ihre Webseite in Iframes anderer Leute einzubetten. Wenn Ihre Seite nicht von anderen eingebettet werden soll, sollten Sie die Cross-Site-Nutzung verbieten. Wenn sie von anderen eingebettet wird, sollten Sie sie wahrscheinlich nur für Navigationsanfragen zulassen. Wenn Sie sie wirklich für nicht-navigatorische Anfragen zulassen müssen, nehme ich an, dass Ihr Dienst technisch anspruchsvoll ist und Sie diesen Leitfaden ohnehin nicht benötigen.
Meine Empfehlung: entweder verbieten Sie die standortübergreifende Nutzung oder erlauben Sie sie für Navigationsanfragen.
Senden von Informationen über den Verweiser einschränken (Referrer-Policy)
Der Browser lässt jeden gerne wissen, welche URL Ihr Besucher gerade angesehen hat, wenn er eine Anfrage stellt.
Das bedeutet, dass der Browser unabhängig davon, ob er ein JavaScript von Tracking- oder Werbediensten, ein Bild von einem Bildhoster oder eine Website lädt, nachdem Ihr Besucher Ihre Website verlassen hat, die vollständige URL sendet, von der die Anfrage stammt. Dies ist ein potentielles Informationsleck, da diese Dritten nun wissen könnten, wie viele Artikel der Benutzer in seinem Warenkorb hat oder welches Produkt er gerade angeschaut hat.
Nun sind einige Dienste auf den Referrer als Autorisierungsmittel angewiesen. Möglicherweise möchte der Bildhoster die Bilder nur auf Ihrer genauen Website anzeigen. Selbst dann sollte er vielleicht nicht in der Lage sein, zu erkennen, wie viele Artikel sich im Warenkorb Ihres Kunden befinden.
Während die Referrer-Politik eine Reihe von Optionen hat, die im Detail einschränken, über welche Art von Verbindung welche Informationstiefe geteilt wird, habe ich einen Favoriten. Und zwar deshalb, weil er die Privatsphäre respektiert, indem er fast nie einen der Anwendungsfälle für die Überweisungsmechaniken bricht.
Meine Empfehlung: Senden Sie nichts, wenn weniger sicher, Referrer-Ursprung bei Cross-Origin, Referrer-URL sonst
Alle Merkmale, die ich in diesem Artikel nicht erörtert habe, erfordern ein tieferes Verständnis dessen, was sie bewirken, wann sie nicht verwendet werden sollten und vor allem, was sie bei falscher Verwendung kaputt machen könnten. Wenn Sie weitere Informationen zu einer dieser Funktionen oder zu den hier besprochenen Themen benötigen, wenden Sie sich einfach an unser Support-Team. Wir helfen Ihnen gerne weiter!
