Security Headers -> D

  • Betroffene Version
    WoltLab Suite 5.4

    Hallo,

    auf "https://securityheaders.com/?q=https%3A%2F%2Flol-scout.de&followRedirects=on" wird meine Seite auf "D" eingestuft und möchte das ganze auf "A+" korrigieren. Da mein Englisch leider nicht perfekt ist, kann ich auch mit denn Fehlermeldung nichts anfangen.

    Ich habe bei Hetzner einen Webspace Packet Levelt 4 "https://www.hetzner.com/webhosting".

    Ich weiß nicht, wie ich hier auf Apache oder nginx komme. Ich bin in Sachen Technik mit Webspace oder vServer leider unerfahren,. Sicherlich gibt es hier Genies, in der Hinsicht, die mir da helfen können.

    Ich habe gelesen, man kann das ganze beseitigen indem man was ins .htacces einbindet. Was genau, weiß und kann ich auch nicht sagen.

    Gruß und Bitte um Mithilfe.

  • Wenn du den Apache verwendest, könntest du mal das hier in die .htaccess im root deiner Domain eintragen und schauen ob es geholfen hat.

    Code
    <IfModule mod_headers.c>
        Header add Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Header add Content-Security-Policy "script-src: 'self'"
        Header add X-Content-Type-Options "nosniff"
        Header add ReferrerPolicy "no-referrer-when-downgrade"
        Header add Permissions-Policy "geolocation=(self), microphone=()"
    </IfModule>

    nginx weiß ich leider nicht.

    Milestones:

    • 18.02.2022 19:14 CET: Erste PWA installiert (und es war ausgerechnet YouTube Music)
  • Also zuerst einmal: A+ wirst du mit der WoltLab Suite nicht hinbekommen, da du den Content-Security-Policy-Header nicht so strikt einstellen kannst, den ein A+ erfordern würde.

    Dann würde ich erst einmal schauen, dass du weißt, was diese Header überhaupt tun. Ich gehe nicht davon aus, dass dir das bewusst ist, wenn du nicht weißt, wie du sie hinterlegen kannst und du sagst, dass dein Englisch schlecht ist. Also der Reihe nach:

    X-Frame-Options gibt an, ob deine Website innerhalb eines iframes geladen werden darf bzw. welche Websites deine Website in einem iframe darstellen dürfen.

    Strict-Transport-Security weist den Browser an, deine Website nur per HTTPS aufzurufen. Über einen Zeitstempel, also eine Anzahl Sekunden, gibst du mit, wie lange diese Anweisung im Browser zwischengespeichert wird. Einmal zwischengespeichert, wird der Browser diese angegebene Anzahl der Sekunden die Website nur noch per HTTPS aufrufen, auch wenn das aufgrund von Fehlern o. ä. nicht mehr möglich ist.

    Des weiteren kannst du noch angeben, dass sämtliche Subdomains unter dieselbe Regel fallen.

    Content-Security-Policy gibt an, welche Inhalte deine Website darstellen darf (bsp. von welcher Quelle Bilder geladen werden dürfen, wie und von wo Skripte eingebunden werden dürfen etc.). Das ist auch der Punkt, bei dem die WoltLab Suite ein A+ verhindert.

    X-Content-Type-Options verhindert, dass der Browser versucht, von Inhalten den MIME-Type, also den eigentlichen Dateityp, selbst zu erkennen. Stattdessen wird forciert, dass der MIME-Type verwendet wird, der vom Browser für den jeweiligen Inhalt mitgesendet wird.

    Referrer-Policy gibt an, welche Informationen der Browser an andere Websites als Referrer sendet, wenn du die aktuelle Website verlässt. Du kannst den Browser damit beispielsweise anweisen, dass der Referrer immer nur aus https://lol-scout.de/forum/ besteht, sodass andere Websites immer nur sehen, dass der Benutzer von deiner Website kommt, aber nicht, von welcher Unterseite genau.

    Permissions-Policy gibt an, welche Funktionen vom Browser auf deiner Website verwendet werden, wie beispielsweise Geo-Standort, Mikrofon, Kamera etc.

    Zur Umsetzung
    Da bei dir der Apache eingesetzt wird, kannst du sämtliche Header über eine Datei namens .htaccess in deinem Hauptverzeichnis der Domain setzen. Die nachfolgenden Codes musst du dort alle einfügen.

    Für Strict-Transport-Security:

    Code
    Header set Strict-Transport-Security "max-age=31536000"

    Das weist den Browser an, die Website nur noch per HTTPS aufzurufen, und speichert diesen Wert für 365 Tage.

    Willst du auch, dass das für alle Subdomains gilt, musst du noch ein includeSubDomains hinzufügen:

    Code
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    Außerdem gibt es noch die Möglichkeit, diesen Wert in einer Liste speichern zu lassen, die fast alle modernen Browser verwenden, sodass dieser Header-Wert dort bereits gespeichert ist, bevor der Browser die Website das erste Mal aufruft. Das geht mit preload:

    Code
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    Für Content-Security-Policy:

    Hier gibt es verschiedene Möglichkeiten, am besten schaust du dir mal https://developer.mozilla.org/en-US/docs/Web…Security-Policy an, um ein Gespür dafür zu bekommen, welche Inhalte du dort alles anpassen kannst. Ich verwende bei mir folgende Konfiguration:

    Code
    Header set Content-Security-Policy "default-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval' kittmedia.com *.kittmedia.com https://www.google.com https://cdn.ampproject.org:*; style-src 'self' 'unsafe-inline' kittmedia.com *.kittmedia.com *.google.com https://cdn.ampproject.org; img-src 'self' data: kittmedia.com *.kittmedia.com; font-src 'self' data: kittmedia.com *.kittmedia.com; connect-src 'self' wss://kittmedia.com wss://node.kittmedia.com *.kittmedia.com https://cdn.ampproject.org blob: https://cdn.ampproject.org; media-src 'none'; object-src 'none'; frame-src 'self' kittmedia.com *.kittmedia.com https://www.youtube-nocookie.com https://www.google.com; frame-ancestors 'self'; worker-src 'self' kittmedia.com *.kittmedia.com; form-action 'self' https://kittmedia.com https://*.kittmedia.com https://www.paypal.com; upgrade-insecure-requests; block-all-mixed-content; base-uri 'self' kittmedia.com *.kittmedia.com; manifest-src 'self'; child-src 'self' kittmedia.com *.kittmedia.com blob: 'self' kittmedia.com *.kittmedia.com;"

    Das musst du entsprechend mindestens auf deine Domain anpassen. Und vermutlich brauchst du keine Verbindungen zu wss://kittmedia.com wss://node.kittmedia.com oder https://cdn.ampproject.org.

    Für X-Content-Type-Options gibt es nur einen gültigen Wert:

    Code
    Header set X-Content-Type-Options "nosniff"

    Für Referrer-Policy:

    Hier musst du selbst entscheiden, wie der Referrer an andere Websites übergeben werden soll. Ich habe es bei mir folgendermaßen:

    Code
    Header set Referrer-Policy "same-origin"

    Für Permissions-Policy:

    Hier kommt es natürlich darauf an, was du genau verwenden willst. Um beispielsweise Kamera und Mikrofon zu deaktivieren, weil du sie auf deiner Website nicht verwendest, sieht der Header so aus:

    Code
    Header set Permissions-Policy "camera=(); microphone=()"
  • Das ist das einzige, was du zu meinem Beitrag zu sagen hast? ;(

    Und: es zeigt mal wieder, wie unsinnig diese Prüfungen sind. Denn okay, nun hast du ein A+, dennoch ist mein Header vermutlich besser, weil er mehr externe Inhalte einschränkt, während bei dir fast alles erlaubt ist, Hauptsache HTTPS. ?(

  • Muss ich die einzelne Befehle in die .htaccess reinschreiben, wenn ich das richtig verstanden habe.

    Steht auch in meinem Beitrag:

    Da bei dir der Apache eingesetzt wird, kannst du sämtliche Header über eine Datei namens .htaccess in deinem Hauptverzeichnis der Domain setzen. Die nachfolgenden Codes musst du dort alle einfügen.

    Naja, das mag sein. Wenn man aber weiß, dass es definitiv keine externen Inhalte gibt und geben wird, so kann man darauf auch verzichten.

    Du magst das wissen, die Prüfseite aber nicht.

  • ...

    Für Content-Security-Policy:

    Hier gibt es verschiedene Möglichkeiten, am besten schaust du dir mal https://developer.mozilla.org/en-US/docs/Web…Security-Policy an, um ein Gespür dafür zu bekommen, welche Inhalte du dort alles anpassen kannst. Ich verwende bei mir folgende Konfiguration:

    Code
    Header set Content-Security-Policy "default-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval' kittmedia.com *.kittmedia.com https://www.google.com https://cdn.ampproject.org:*; style-src 'self' 'unsafe-inline' kittmedia.com *.kittmedia.com *.google.com https://cdn.ampproject.org; img-src 'self' data: kittmedia.com *.kittmedia.com; font-src 'self' data: kittmedia.com *.kittmedia.com; connect-src 'self' wss://kittmedia.com wss://node.kittmedia.com *.kittmedia.com https://cdn.ampproject.org blob: https://cdn.ampproject.org; media-src 'none'; object-src 'none'; frame-src 'self' kittmedia.com *.kittmedia.com https://www.youtube-nocookie.com https://www.google.com; frame-ancestors 'self'; worker-src 'self' kittmedia.com *.kittmedia.com; form-action 'self' https://kittmedia.com https://*.kittmedia.com https://www.paypal.com; upgrade-insecure-requests; block-all-mixed-content; base-uri 'self' kittmedia.com *.kittmedia.com; manifest-src 'self'; child-src 'self' kittmedia.com *.kittmedia.com blob: 'self' kittmedia.com *.kittmedia.com;"

    Das musst du entsprechend mindestens auf deine Domain anpassen. Und vermutlich brauchst du keine Verbindungen zu wss://kittmedia.com wss://node.kittmedia.com oder https://cdn.ampproject.org.

    Vielen Dank erneut an dieser Stelle Chef,..

    Ich habe es soweit gebracht, dass mein Status derzeit auf "A" und grün ist.

    Ich verstehe jedoch nicht, was genau dieser "Content-Security-Policy" wirken soll und wie ich das genau einbinde. Denn wie Du oben geschrieben hast, brauche ich die Verbindung ja nicht. Um auch an der Stelle auf "grün" zu bekommen muss ich dafür was genau tun und für was wirkt das ganze?

    Um ehrlich zu sein habe ich die Funktion darin nicht genau verstanden. Würde mich sehr freuen, wenn Du mir da aufklären würdest, Danke.

  • Mein .htaccess sieht wie folgt aus:

    Wenn Euch etwas komisch vorkommt und Ihr der Meinung seit, dass müsste oder sollte raus, dürft Ihr mich gerne korrigieren.

    Ergebnis: A+

  • Da du zwingend unsafe-inline und unsafe-eval aktivieren musst, gibt es hier kein besser, oder schlechter... Das ist übrigens auch der Grund, warum ich mich vom klassischen CSP-Header getrennt habe.

    Du beziehst dich lediglich auf JavaScript bezüglich des „besser oder schlechter“, aber CSP kann ja noch wesentlich mehr. Ob es sinnvoll ist, den Header deshalb komplett rauszuschmeissen? Ich denke nein.

    Um ehrlich zu sein habe ich die Funktion darin nicht genau verstanden. Würde mich sehr freuen, wenn Du mir da aufklären würdest, Danke.

    Dieser Header definiert, welche Inhalte auf welche Weise geladen werden dürfen. Beispielsweise kannst du darin JavaScript, das direkt auf deiner Seite im Quellcode zu sehen ist und nicht über eine extra Datei geladen wird, deaktivieren (solltest es aber nicht, da die WoltLab Suite das benötigt). Grundsätzlich ist das dafür gedacht, dass wirklich nur die Inhalte auf deiner Website funktionieren, die du kennst und dementsprechend konfiguriert hast. Sollte deine Website beispielsweise durch eine Sicherheitslücke kompromittiert werden, kann das helfen, den Schaden zu begrenzen, weil möglicherweise der Schadcode vom Browser aufgrund dieses Headers am Ende nicht ausgeführt wird.

  • dann öffne mal deine Browserkonsole :)

    und was hast Du da gefunden?


    Du beziehst dich lediglich auf JavaScript bezüglich des „besser oder schlechter“, aber CSP kann ja noch wesentlich mehr. Ob es sinnvoll ist, den Header deshalb komplett rauszuschmeissen? Ich denke nein.

    Dieser Header definiert, welche Inhalte auf welche Weise geladen werden dürfen. Beispielsweise kannst du darin JavaScript, das direkt auf deiner Seite im Quellcode zu sehen ist und nicht über eine extra Datei geladen wird, deaktivieren (solltest es aber nicht, da die WoltLab Suite das benötigt). Grundsätzlich ist das dafür gedacht, dass wirklich nur die Inhalte auf deiner Website funktionieren, die du kennst und dementsprechend konfiguriert hast. Sollte deine Website beispielsweise durch eine Sicherheitslücke kompromittiert werden, kann das helfen, den Schaden zu begrenzen, weil möglicherweise der Schadcode vom Browser aufgrund dieses Headers am Ende nicht ausgeführt wird.

    Danke für deinen Beitrag. Ich wurde jedoch kein bisschen dadurch schlauer.

    Ich muss mir da auf jeden Fall jmd suchen, der sich damit auskennt und mir das mal genauer erklärt. Leider verstehe ich grad echt nicht, was ich da getan habe.

  • Hab das sofort mal rückgängig gemacht.

    Wo liegt genau mein Fehler?

    Code
    Header set Content-Security-Policy "default-src 'none'; script-src 'self' lol-scout.de *.lol-scout.de https://www.google.com https://cdn.ampproject.org:*; style-src 'self' lol-scout.de *.lol-scout.de *.google.com https://cdn.ampproject.org; img-src 'self' data: lol-scout.de *.lol-scout.de; font-src 'self' data: lol-scout.de *.lol-scout.de; connect-src 'self' wss://lol-scout.de wss://node.lol-scout.de *.lol-scout.de https://cdn.ampproject.org blob: https://cdn.ampproject.org; media-src 'none'; object-src 'none'; frame-src 'self' lol-scout.de *.lol-scout.de https://www.youtube-nocookie.com https://www.google.com; frame-ancestors 'self'; worker-src 'self' lol-scout.de *.lol-scout.de; form-action 'self' https://lol-scout.de https://*.lol-scout.de https://www.paypal.com; upgrade-insecure-requests; block-all-mixed-content; base-uri 'self' lol-scout.de *.lol-scout.de; manifest-src 'self'; child-src 'self' lol-scout.de *.lol-scout.de blob: 'self' lol-scout.de *.lol-scout.de;"

    So stand Sie im .htaccess drin.

    Was kann davon raus und was müsste ich hinzufügen?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!