HTTP Security-Header

[einsiedler]

Hallo liebe Forumer,

zur Zeit kümmere ich mich um den Schutz meiner websites, leider ist dies notwendig weil ein Paar Idioten es wohl lustig finden sie zu attackieren. Meine Fragen gehen in Richtung HTTP Security-Header

Meine Frage ist, ist dies wohl ausreichend:

## Mod Headers – Security
<IfModule mod_headers.c>
   Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
   Header set X-Content-Type-Options "nosniff"
   Header set X-XSS-Protection "1; mode=block"
   Header append X-Frame-Options "SAMEORIGIN"
   Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure; SameSite=Strict"
   Header unset X-Powered-By
   Header unset Server
   Header set Referrer-Policy "no-referrer"
</IfModule>

Oder fehlt da noch etwas? Bitte gebt mir mal Ratschläge!

Eine Abfrage dort: https://securityheaders.com

bringt meine beiden Hauptseiten wenigstens auf den Level B, ein A wäre mir schon lieber. Also was fehlt dort?

Und/oder: Gibt es irgendwo Infos, bevorzugt auf deutsch, wo mal noch mehr nachlesen könnte?

Gruß der misanthrop

[Raketenwilli]

Eine Abfrage dort: https://securityheaders.com

bringt meine beiden Hauptseiten wenigstens auf den Level B, ein A wäre mir schon lieber. Also was fehlt dort?

Schwer zu sagen, was da fehlt, so lange mir nicht klar ist, was Du mit „meine beiden Hauptseiten“ meinst.

ABER:

https://securityheaders.com/?q=https%3A%2F%2Fcode.fastix.org%2F&followRedirects=on

Ich hab das also geschafft, kann Dir jedoch folgendes mitteilen:

Die Einstufung „A“ schafft nicht mal die nsa (nsa.gov hat dort „D“. Auch Banken schaffen längst nicht durchweg „A“.

Mit „B“ bist Du ganz gut dabei, für weitere Aussagen müsste man Deine Sicherheitsbedürfnisse prüfen - und z.B. ob Du überhaupt von Benutzern erstellten Content hast. Da liegen meist die letzten Schwellen (inline-Script, inline-CSS). Und manche der Erfordernisse für die Einstufung mit „A“ entfalten bei so manchem Webauftritt keine Wirkung.

Was „schlecht“ ist, ist rot, ggf. orange markiert.

[Walze]

Die Einstufung „A“ schafft nicht mal die nsa (nsa.gov hat dort „D“. Auch Banken schaffen längst nicht durchweg „A“.

Als wenn das nun Maßstäbe für irgendwas wären. Bei Banken in der Theorie nachvollziehbar, aber die NSA hat mit Verbraucherschutz im weiteren Sinne nun wirklich überhaupt nichts zu tun, ganz im Gegenteil.

[Raketenwilli]

Wie kommst Du nur darauf, dass es in diesem Therad um Verbraucherschutz geht?

[Walze]

Wie kommst Du nur darauf, dass es in diesem Therad um Verbraucherschutz geht?

Sämtliche der von ihm hinterfragten Kopfzeilen schützen mindestens hauptsächlich, wenn nicht sogar alleine den Verbraucher (Besucher), nicht den Anbieter (Server).

Aber auch davon unabhängig, hinsichtlich des Serverschutzes, sind weder Banken noch irgendeine Behörde per se Vorbilder.

[Der Martin]

Hallo,

Wie kommst Du nur darauf, dass es in diesem Therad um Verbraucherschutz geht?

Sämtliche der von ihm hinterfragten Kopfzeilen schützen mindestens hauptsächlich, wenn nicht sogar alleine den Verbraucher (Besucher), nicht den Anbieter (Server).

nein, nicht sämtliche. Zumindest das Weglassen des Server- und des X-Powered-By-Headers zielen eher auf den Schutz des Servers ab - wenn auch nur durch Obscurity und damit sehr fragwürdig.

Aber auch davon unabhängig, hinsichtlich des Serverschutzes, sind weder Banken noch irgendeine Behörde per se Vorbilder.

Das kann ich weder belegen noch widerlegen, aber mein Bauchgefühl sagt spontan: Ja, stimmt!

Live long and pros healthy,
 Martin

[Raketenwilli]

Wie kommst Du nur darauf, dass es in diesem Therad um Verbraucherschutz geht?

Sämtliche der von ihm hinterfragten Kopfzeilen schützen mindestens hauptsächlich, wenn nicht sogar alleine den Verbraucher (Besucher), nicht den Anbieter (Server).

Achso. Ich hätte jetzt auf „Besucherschutz“ abgestellt. Was jetzt den Anbieter betrifft, so hat der natürlich im Falle eines Ausnutzens der durch die Header zu schließenden, genauer „zu verengenden Lücken“ durchaus auch einen, womöglich sogar erheblichen Schaden.

[Der Martin]

Hallo Einsiedler,

zur Zeit kümmere ich mich um den Schutz meiner websites, leider ist dies notwendig weil ein Paar Idioten es wohl lustig finden sie zu attackieren.

das wirft die Fragen auf: Was verstehst du unter Schutz, und wie sehen die Attacken aus?

Worauf ich hinaus will: Ein paar HTTP-Header zu setzen, bringt noch keinen Schutz. Weder gegen gezielte Angriffe, noch beispielsweise gegen einen unspezifischen DoS-Angriff. Das sind nur freundliche Aufforderungen an die Clients, doch bitte dies und das zu tun oder zu unterlassen.

## Mod Headers – Security
<IfModule mod_headers.c>
   Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
   Header set X-Content-Type-Options "nosniff"
   Header set X-XSS-Protection "1; mode=block"
   Header append X-Frame-Options "SAMEORIGIN"
   Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure; SameSite=Strict"
   Header unset X-Powered-By
   Header unset Server
   Header set Referrer-Policy "no-referrer"
</IfModule>

Einige der Optionen bzw. der davon betroffenen Header kenne ich gar nicht. Den Server-Header und den X-Powered-By zu unterdrücken, ist vielleicht eine gute Idee, um nicht jedem gleich zu verraten, welcher Server und welche sonstige Software da so läuft. Aber Security by Obscurity war noch nie eine gute Idee (jedenfalls nicht für sich allein).

Oder fehlt da noch etwas? Bitte gebt mir mal Ratschläge!

Letztendlich ist es entscheidend, möglichst viele tatsächliche Angriffsvektoren zu eliminieren. Also keine Scripte einsetzen, die für gewissen Lücken bekannt sind wie ein bunter Hund, in den serverseitig laufenden Scripten generell keine Daten von außen unbesehen für bare Münze nehmen, dafür zu sorgen, dass die auf dem Server (der Maschine) laufende Software beim Bekanntwerden von Sicherheitslücken möglichst schnell aktualisiert wird. Das ist nicht nur deine Aufgabe, sondern auch die deines Hosters.

Eine Abfrage dort: https://securityheaders.com

bringt meine beiden Hauptseiten wenigstens auf den Level B, ein A wäre mir schon lieber. Also was fehlt dort?

Keine Ahnung. Aber nach der dürftigen Beschreibung dieses Dienstes prüft der auch nur auf das Vorhandensein möglichst vieler exotischer HTTP-Header. Das bringt aber noch keinen Mehrwert.
Es nützt ja auch nichts, wenn du an deiner Gartenlaube möglichst viele Reklame-Aufkleber von Chubb, ABUS, BKS und anderen Herstellern von Sicherheitsschlössern anbringst.

Live long and pros healthy,
 Martin

[einsiedler]

Hi Martin,

alles gut, was die ganzen Scripte betrifft, da ist alles wunderbar geschützt, vorgestern wurde eine SQL Injection bzw. XSS-Attacke locker abgewehrt. Gestern wurden einige Formulare zugespammt aber scripttechnisch wurde alles dann nicht abgeschickt (post). Heute bekam ich Mails mit Angeboten zum Parkplatzsex in meiner Umgebung (mit einem Link zur webseite dorthin), da will mir jem. etwas unterjubeln, die kommen irgendwie nicht weiter. Dahingehend ist alles wunderbar, nur ein Punkt der dazugehört ist halt auch der Header.

Danke für Deine Infos.

Gruß der misanthrop

[Walze]

zur Zeit kümmere ich mich um den Schutz meiner websites, leider ist dies notwendig weil ein Paar Idioten es wohl lustig finden sie zu attackieren.

## Mod Headers – Security
<IfModule mod_headers.c>
   Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
   Header set X-Content-Type-Options "nosniff"
   Header set X-XSS-Protection "1; mode=block"
   Header append X-Frame-Options "SAMEORIGIN"
   Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure; SameSite=Strict"
   Header unset X-Powered-By
   Header unset Server
   Header set Referrer-Policy "no-referrer"
</IfModule>

Nichts davon schützt deine Seiten, du schützt damit deine Besucher.

Für eine A-Bewertung brauchst du lediglich Strict-Transport-Security, Content-Security-Policy und X-Content-Type-Options. Bei mir war das bislang immer problemlos möglich, wobei Content-Security-Policy natürlich auch wirklich benutzt werden sollte. Wer da lauter 'unsafe'-Werte und eine ellenlange Liste an Drittanbietern drin hat, hat den Sinn nicht so ganz verinnerlicht.

X-XSS-Protection und X-Frame-Options (und viel mehr) sind in Content-Security-Policy enthalten. Damit solltest du dich beschäftigen und die beiden alten rauswerfen.

An den Cookies rumzufummeln scheint mir eher ein Doktern am Symptom zu sein als eine Beseitigung der Ursache. Du solltest wissen, wo du Cookies setzt, also solltest du auch dort die gewünschten Optionen setzen und nicht erst zwischen Tür und Angel, kurz bevor sie in die weite Welt hinaus sind.

Die geschwätzigen X-Powered-By und Server kann man löschen, aber es ist nicht so, dass du damit irgendeine Sicherheitslücke ausschaltest. Entweder hast du die aktuellste Software auf dem Server und bist auf der sicheren Seite, oder du hast sie eben nicht, dann hilft dir aber das Versteckspiel nichts. Das ist so sinnvoll wie ein Schild, "Diese Tür ist abgeschlossen": Wer rein will, rüttelt so oder so an der Tür. Das Löschen der beiden Angaben ist ein Akt der Netzhygiene, eine Reduzierung des Hintergrundrauschens, nicht mehr.

Schlussendlich, der Sinn von Referrer-Policy ist mir schleierhaft, genauer: eine Datenschutzoption an dieser Stelle einzubauen. Möchte der Besucher nicht, dass sein Browser die vorherige Seite verrät, dann soll er ihn entsprechend einstellen. Meinen Browser-Hersteller, dass das besser wäre, dann sollen sie ihre Browser ab Werk so einstellen. Aber die Verantwortung für die Browser auf die Seitenbetreiber abzuwälzen ist ein wenig albern. Das ist bestenfalls eine Verzweiflungstat ob der Unfähigkeit der erstgenannten beiden Gruppen.

Davon abgesehen ist no-referrer eine schlechte Wahl. Mit same-origin versteckst du deine Herkunft genauso vor anderen, bekommst aber selbst die Informationen, die du sowieso irgendwo im Zugriffsprotokoll hast, aber eben direkt bei dem betreffenden Zugriff. Es erleichtert die Suche nach der Herkunft von Zugriffen auf nicht existierende Daten. (Zugegeben: Kümmerst du dich eh nie um die Fehler, die dein Server für dich protokolliert, kannst du auch bei no-referrer bleiben.)

Im Übrigen auch nett: https://observatory.mozilla.org/

[einsiedler]

Dank Dir für Deine Info`s...

Was hälst Du davon:

Content-Security-Policy: default-src "none"; script-src "self"; connect-src "self"; img-src "self"; style-src "self";

Wäre dies sinnvoll?

Und dann die X-XSS-Protection und X-Frame-Options raus oder zusätzlich noch?

Gruß der misanthrop

[einsiedler]

Korrektur:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">
<meta http-equiv="X-Content-Security-Policy" content="default-src 'self'; script-src 'self'">
<meta http-equiv="X-WebKit-CSP" content="default-src 'self'; script-src 'self'">



Header set Content-Security-Policy "default-src 'none'; frame-src 'self'; font-src 'self';img-src 'self' meineseite.de; object-src   'self'; script-src 'self'; style-src 'self';"

[Walze]

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">
<meta http-equiv="X-Content-Security-Policy" content="default-src 'self'; script-src 'self'">
<meta http-equiv="X-WebKit-CSP" content="default-src 'self'; script-src 'self'">

Header set Content-Security-Policy "default-src 'none'; frame-src 'self'; font-src 'self';img-src 'self' meineseite.de; object-src   'self'; script-src 'self'; style-src 'self';"

Besteht die Möglichkeit, direkt HTTP zu beeinflussen (hier: header set), würde ich keine <meta>-Sachen benutzen. Das führt nur zu Fehlern und Lücken. Es muss beachtet werden, dass sämtliche HTML-Seiten die <meta>-Angaben einbinden und in obigem Fall hast du auch noch sich widersprechende Angaben in <meta> und header (hier vielleicht versehentlich, aber das zeigt trotzdem genau das Problem, das entsteht, wenn dieselbe Sache an zwei Orten eingerichtet wird).

X-Content-Security-Policy und X-WebKit-CSP: Ja, nein, vielleicht … Aktuelle Browser kennen Content-Security-Policy als solche, mit den beiden X-Dingern erschlägst du wohl noch irgendwelche etwas älteren Browser. Den Nutzen kann man nicht absprechen, aber ich frage mich bei sowas immer, ob jemand, der mit einem alten Browser unterwegs ist, nicht noch ganz andere Probleme hat. Die Welt kann ich damit nicht retten und einem von 10.000 Besuchern noch extra die Windeln anzulegen ist das Meinige irgendwie auch nicht.

default-src 'self'; script-src 'self'

Das ist nicht so hübsch, denn script-src nimmt als Vorgabe sowieso default-src. Sind beide Angaben identisch, kann die spezifischere weg.

default-src 'none'; frame-src 'self'; font-src 'self';img-src 'self' meineseite.de; object-src 'self'; script-src 'self'; style-src 'self'

Das ist wegen default-src 'none' schon sehr verbarrikadiert, aber kann man natürlich machen.

Überlege dir, ob du selbst <frame> oder <iframe> benutzt (ansonsten frame-src raus), ebenso <object>, <embed> oder <applet> (ansonsten object-src raus).

Spaßeshalber würde ich statt meineseite.de ausdrücklich https://meineseite.de benutzen, falls der betreffende Server HTTPS kann. Wenn schon, denn schon.

Anekdote anbei: Mich hat default-src 'none' vor einer Weile auf dem falschen Fuß erwischt. Einer SVG-Grafik fehlte plötzlich die Farbe. Es hat eine Weile gedauert, bis mir auffiel, dass die Farbe ja in der SVG-Datei festgelegt, mithin style-src 'unsafe-inline' nötig war.

X-Frame-Options

… ersetzt du durch "frame-ancestors: 'none'", hat also mit frame-src nichts zu tun. Beachte auch, dass frame-ancestors zu den Werten gehört, die nicht auf den Vorgabewert von default-src zurückfallen.

X-XSS-Protection

… ergibt sich automatisch, sobald dein script-src kein 'unsafe-inline' enthält.

https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Content-Security-Policy hat eine große Übersicht. Bei Mozilla findest du auch Infos zu X-XSS-Protection etc.

[einsiedler]

Hey, vielen Dank.

Das katapultiert meine Seiten (bei https://securityheaders.com/) zu A und bei (https://observatory.mozilla.org/) sogar zu A+ ... nett!!!

Was ich mich aber bei (https://observatory.mozilla.org/) frage, ist, der zieht mir 5 Punkte ab weil: Initial redirection from HTTP to HTTPS is to a different host, preventing HSTS

Das ist etwas was ich nicht verstehe.

Beide Seiten sind auf dem selben Server.

Die eine Seite wird in meinem File Manager (im Plesk) unter "httpdocs_meineseite" gebucht die andere eben nur "meineseite.de", eben in dieser Basisverzeichnis-Liste!

HAHA, und ich sehe gerade das meine Videos nicht angezeigt werden. Wie verhält sich das dann?

Gruss der misanthrop

[Walze]

Was ich mich aber bei (https://observatory.mozilla.org/) frage, ist, der zieht mir 5 Punkte ab weil: Initial redirection from HTTP to HTTPS is to a different host, preventing HSTS

Dein Browser sollte für den geneigten Seitenbastler diversen Krimskrams an Bord haben (bei Firefox im Menü unter Web-Entwickler), dort sollte sich auch ein Werkzeug zur Beobachtung des HTTP-Verkehrs befinden (Firefox: Netzwerkanalyse). Damit kannst du den Umleitungsvorgang im Detail nachvollziehen.

Ich kann nur blind vermuten, dass du vielleicht von http://meineseite nach https://www.meineseite und anschließend nach https://meineseite umleitest (oder etwas Ähnliches). Das wäre nicht nur etwas umständlicher als der direkte Weg, sondern könnte auch der Grund für den Schluckauf sein.

HAHA, und ich sehe gerade das meine Videos nicht angezeigt werden.

Diesen Tipp …

https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Content-Security-Policy hat eine große Übersicht.

… hättest du wirklich beherzigen sollen. Vielleicht gibt's hier bei Selfhtml auch was auf Deutsch, falls das Englische dir nicht behagt.

[Walze]

Die automatische Worttrennerei erschien mir bis dato nur als penetrant-unnötiger Spielkram, aber das da oben, das Verfälschen von URLs ist Mist, liebe Forenbetreiber. Den Bindestrich habe ich da nicht hingesetzt.

(Und nicht die Verantwortung auf "hyphens: auto" schieben. Funktioniert etwas offenkundig nicht, muss man es auch nicht einschalten, nur weil's lustig aussieht.)

[Tabellenkalk]

Hallo,

Die automatische Worttrennerei erschien mir bis dato nur als penetrant-unnötiger Spielkram, aber das da oben, das Verfälschen von URLs ist Mist, liebe Forenbetreiber. Den Bindestrich habe ich da nicht hingesetzt.

Backticks helfen, sind aber eigentlich für kurzen Code gedacht, muss man wohl auch für URLs nehmen...

Gruß
Kalk

[Der Martin]

Hallo,

Die automatische Worttrennerei erschien mir bis dato nur als penetrant-unnötiger Spielkram, aber das da oben, das Verfälschen von URLs ist Mist, liebe Forenbetreiber. Den Bindestrich habe ich da nicht hingesetzt.

(Und nicht die Verantwortung auf "hyphens: auto" schieben. Funktioniert etwas offenkundig nicht, muss man es auch nicht einschalten, nur weil's lustig aussieht.)

aus genau diesem Grund steht in meinem benutzerspezifischen Foren-Stylesheet schon lange hyphens: none !important; drin. Außerdem bin ich sowieso der Meinung, dass man Silbentrennung sehr bewusst und sparsam einsetzen sollte - nur bei sehr langen, evtl. zusammengesetzten Wörtern, und dann auch nur an natürlichen Wortfugen.

Live long and pros healthy,
 Martin

[TS]

Hello,

eine mögliche Verbesserung der Sicherheit befindet sich mMn an einer ganz anderen Stelle, bzw. erforderlichen Maßnahmen, die ich hier schon oft gepredigt habe:

• Applikationen sollten einfache Textlogs schreiben, z. B. über Fehlversuche
  -- Responsecodes 401, 404, 5xx, usw.;
  -- Fehlgeschlagene Datenbankzugriffe, ...
• Fail2ban sollte diese Logdatei im Auge behalten
• Fail2ban sollte durch das Filter Recidive ergänzt werden, dass bei bestimmter Anzahl mehrfacher Fehlversuche die Angreifer-IP ganz sperrt und dem Admin eine Nachricht sendet.

Glück Auf
Tom vom Berg

[einsiedler]

Hi TS,

alles GUT, das ist bereits alles gemacht, dahingehend sind alle scripte optimal "abgesichert".

Ein Punkt nur, der auch dazugehört betrifft halt meine Fragestellung!

der misanthrop