logo

NetzRose

Gepflegte Linklisten, onlineTermine und Artikel für IT, Freiheit und Genuss.

.htaccess mit CSP


Eine der wichtigsten Dateien, die möglichst gleich zu Beginn einer Internetpräsentation angefertigt werden sollte, ist m.M.n. die Konfiguritionsdatei .htaccess

Früher hatte ich noch Schwierigkeiten, sie überhaupt zu finden, weil vor dem Punkt nichts steht.
Aber ich ging ihr weiterhin eher aus dem Weg, weil ich die aufzustellenden Regeln für beispielsweise einen Apache-Server nicht verstand und der kleinste Tippfehler gleich eine böse Server-Error-Meldung verursacht.

Wichtig bei zeitgemäßen Internetauftritten ist, dass in den HTML-Dateien selbst keine Gestaltungsanweisungen CSS und kein dynamisierender wie JS enthalten ist.
Entsprechende Dateien werden separat angelegt und im HTML-Head eingebunden.

Mike Kuketz fragte bereits 2016 "Wie datenschutzfreundlich ist deine Webseite?" und gab u.a. den Tipp zu den Validatoren moz://a Observatory und Webbkoll.

Da mir der Datenschutz der User und die Sicherheit des vServers sehr wichtig sind, bemühte ich mich, die .htaccess möglichst richtig abzufassen, denn mit einer langen Datenschutzerklärung und möglichst wenig Erfragen von Daten, ist es nicht getan.

Ich erinnere mich noch, dass ich damals, als ich den Tipp bei Kuketz las, nicht mal wusste, wo um Himmelswillen ich diese anscheinend so wichtigen Header setzen soll.

Inzwischen bin ich dahinter gekommen und habe auch manches weitere dazu gelernt. Sodass es vielleicht eine gute Idee sein könnte, wenn ich hier mal meine .htaccess ein wenig bespreche. Daher habe ich auch etwas Platz gemacht. Statt der sonst gerne genommenen 4 Spalten, gibt es für diesen Artikel 2 Spalten. Denn was die einzelnen Einträge in der .htaccess nicht haben sollten, sind Zeilenumbrüche. Es ist also wichtig, sie in einem normalen Texteditor zu schreiben.

Alles werde ich nicht ausführen, weil es genügend Quellen dazu im Netz gibt. Das ist ja dann anhand der Bezeichnungen leicht zu recherchieren. Es geht mir besonders um meine kleine Lernkurve zur CSP.

Am Besten wäre wohl, Du würdest einfach bei den Validatoren netzrose.de eingeben. Dann bekommst Du ausführliche Erklärungen. Zumal Du vielleicht Bilder, Videos, Schriften etc. von anderen Quellen einbindest und mein Beispiel entsprechend modifizieren wirst.

...


... Fortsetzung

1. Zeile: Referrer-Policy

Header set Referrer-Policy: no-referrer

2. Zeile: Strict-Transport-Security

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

3. Zeile: Content-Security-Policy

Header set Content-Security-Policy: "default-src 'none'; style-src 'self' https://*.netzrose.de; img-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; media-src 'self'"

Mit default-src 'none' wird erst mal alles verboten. Das muss auch gleich als erstes kommen. Erst durch die anschließende Aufzählung werden dann diverse Möglichkeiten wieder erlaubt.

Mit style-src 'self' https://*.netzrose.de ist festgelegt, dass nur CSS-Dateien von der Domain netzrose.de und deren Subdomains (*=Joker) eingebunden werden dürfen. Es genügt in dieser Zeile, für 'self' ein mal die Domain anzugeben.

Mit img-src 'self' gebe ich an, dass nur Bilder von diesem Server eingebunden werden.

Mit frame-ancestors 'self'; base-uri 'self'; form-action 'self' erfülle ich wichtige Aspekte, die von den Validatoren abgefragt werden.

Mit media-src 'self' werden z.B. Videos innerhalb von HTML5 abspielbar, sofern sie hier liegen. Beispiel Hörbücher sammeln.

Würde ich z.B. JS verwenden, käme noch die Direktive script-src hinzu.

...


... Fortsetzung

CSP modifizieren für externe Bibliotheken

Wer sicherheitsbewusst arbeitet, wird auf CSS und JS von Bootstrap und Icons von Font Awesome verzichten. Wenn nicht, dann würde in die CSP der .htaccess eingebaut:

Header set Content-Security-Policy: "default-src 'none'; img-src 'self' https://*.netzrose.de; font-src 'self' https://use.fontawesome.com; style-src 'self' https://maxcdn.bootstrapcdn.com; script-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; media-src 'self'"

Ich habe für dieses Beispiel die Direktiven so umgestellt, dass zunächst weiterhin klar ist, was 'self' bedeutet, nämlich https://*.netzrose.de
Danach habe ich die weiteren Angaben miteinander kombiniert.
Da Bootstrap bereits bei style-src genannt ist, braucht man es bei script-src nicht erneut anführen.
Allerdings ist es mit der CSP in der .htaccess noch nicht getan.

Es sind noch Einträge in den Html-Dateien zu modifizieren. Wenn man im Head-Bereich der HTML-Dateien z.B. die bootstrap.min.css einbinden möchte, sähe das z.B. so aus:

<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.2/css/bootstrap.min.css" integrity="sha384-Tfj13fqQQqqzQFuaZ81WDzmmOU610WeS08VMuHmElK5oI2f7NwojuL6VupYXR/jK" crossorigin="anonymous">

und für die bootstrap.min.js sähe das z.B. so aus:

<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/js/bootstrap.min.js" integrity="sha384-B4gt1jrGC7Jh4AgTPSdUtOBvfO8shuf57BaghqFfPlYxofvL8/KUEfYiJOMMV+rV" crossorigin="anonymous"></script>

Solchen Code erstellt jeweils der SRI Subresource Integrity Hash Generator.

Update: Dank des umgesetzten Hinweises gemäß Privacy-Handbuch wird mein Browser bei Schriftarten jedoch lieber nicht mitspielen.

WARNUNG: Hacker missbrauchen Google Apps Script, um Kreditkarten zu stehlen und CSP zu umgehen. Artikel (engl.) bei bleepingcomputer 🆕️.

...


... Fortsetzung

Weitere Einträge in die .htaccess

X-Frame und X-Content

Header set X-Frame-Options "DENY"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"

Diese Angaben werden ebenfalls abgefragt. Da ich keine Scripte einsetze und keine Cookies, sind die entsprechenden optionalen Regeln auch nicht nötig.

Sonstiges: Firewall

Kürzlich habe ich festgestellt, dass jemand unbefugt ein Programm (gobuster) für Penetrationtests auf meinem vServer sein Unwesen treiben ließ. Da es noch weitere Kandidaten gibt, habe ich folgende Anweisung notiert:

# unerwünschte Spionage-Programme aussperren
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^.*(gobuster|Adsbot|SEOkicks).*$ [NC]
RewriteRule .* - [F,L]
RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule ^ - [F]

Eine Zeile, die mit einem Gatter (#) beginnt, ist ein Kommentar. Er hilft mir, den Überblick zu behalten.
Bei Perishable Press habe ich mir außerdem die 7G Firewall geholt und den Inhalt in die .htaccess kopiert.

...


... Fortsetzung

Start- und Fehlerseite

ErrorDocument 404 /index.html
DirectoryIndex /index.html

Wie man sieht, habe ich keine Fehlerseite, sondern schicke gleich zum Inhaltsverzeichnis weiter. Eine Fehlerseite irritiert User eher, als eine Fehlerseite, denke ich.
Aber Ich schaue mir regelmäßig im Statistik-Programm Webalizer die Eingangsseiten an. Entdecke ich eine fehlerhafte, lege ich eine Dauerhafte Weiterleitung an.

https, statt http und ohne www

RewriteCond %{HTTP_HOST} ^www\.netzrose\.de$ [NC]
RewriteRule ^(.*)$ http://netzrose.de/$1 [L,R=301]
 
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]

Dauerhafte Weiterleitungen

Schreibweise der dauerhaften Weiterleitung in der .htaccess
Statt ausführlich von netzrose.de/einpfad/alt1.html zu netzrose.de/einpfad/neu1.html genügt:

RewriteEngine On
Redirect 301 /einpfad/alt1.html /einpfad/neu1.html
Redirect 301 /einpfad/alt2.html /einpfad/neu2.html
Redirect 301 /einpfad/alt3.html /einpfad/neu3.html
...

Die Liste ist bei mir durch die Umstellung letzten November von einem CMS aufs Manuelle ziemlich lang. In einigen Monaten werde ich sicher einige Weiterleitungen wieder löschen können. Zwar muss die .htaccess wohl bei jedem Dateiaufruf immer frisch mitgeladen werden, aber da ich ansonsten recht sparsam mit Code bin, ist das nicht weiter tragisch.

So, damit wären wir weitgehend durch. Sonstige Angaben und Regeln sind so individuell, dass sie hier nicht aufgeführt werden müssen.
Ich hoffe, es sind keine Fehler drin. Und wenn doch, bin ich zuversichtlich, dass mich die Menschen im Fediverse darauf hinweisen.