HSTS-Empfehlungen in .htaccess

Oct 18 2020

Bitte beachten Sie meinen vorherigen Beitrag im unten stehenden Hyperlink

Ich habe meine .htaccessDatei aktualisiert , um ein HSTS zu berücksichtigen, zusammen mit vielen der empfohlenen Änderungen. Siehe den Ausschnitt unten. Ich möchte betonen, dass die Implementierung eines HSTS für niemanden, der neu darin ist, leicht genommen werden darf . Vor diesem Hintergrund suche ich nach Ratschlägen, was anders gemacht werden kann als diejenigen, die über Kenntnisse verfügen .htaccess.

#IMPLEMENT HSTS
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

#CUSTOM ERROR PAGES
ErrorDocument 400 /allerror.php
ErrorDocument 401 /allerror.php
ErrorDocument 403 /allerror.php
ErrorDocument 404 /allerror.php
ErrorDocument 405 /allerror.php
ErrorDocument 408 /allerror.php
ErrorDocument 500 /allerror.php
ErrorDocument 502 /allerror.php
ErrorDocument 504 /allerror.php

RewriteEngine On

#REDIRECT TO SECURE HTTPS CONNECTION
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] #FORCE WWW TO NON-WWW RewriteCond %{HTTP_HOST} ^www.example.com [NC] RewriteRule ^(.*)$ https://example.com/$1 [L,R=301] #URL EXTENSION REMOVAL RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC] RewriteRule ^ /%1 [NC,L,R] RewriteCond %{REQUEST_FILENAME}.html -f RewriteRule ^ %{REQUEST_URI}.html [NC,L] #HOTLINKING PROTECTION RewriteCond %{HTTP_REFERER} !^https://(www\.)?example\.com(/.*)*$ [NC]
RewriteCond %{HTTP_REFERER} !^$ RewriteRule \.(css|flv|gif|ico|jpe|jpeg|jpg|js|mp3|mp4|php|png|pdf|swf|txt)$ - [F]

#CONTENT SECURITY POLICY
<FilesMatch "\.(html|php)$"> Header set Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data: 'unsafe-inline'; media-src 'self' data: 'unsafe-inline'; connect-src 'self';" </FilesMatch> #REDIRECT FOR DATE PAGE RewriteRule ^date$ /storage/date-202010 [R=301,L]

#REDIRECT FOR HOME PAGE
RewriteRule ^home$ / [R=301,L] #PREVENT DIRECTORY BROWSING Options All -Indexes #FILE CACHING #cache html and htm files for one day <FilesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=43200"
</FilesMatch>
    #cache css, javascript and text files for one week
<FilesMatch "\.(js|css|txt)$"> Header set Cache-Control "max-age=604800" </FilesMatch> #cache flash and images for one month <FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|mp4|png)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>
    #disable cache for script files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$"> Header unset Cache-Control </FilesMatch> #BLOCKS FILE TYPES FOR USERS <FilesMatch "\.(ht[ap]|ini|log|sh|inc|bak)$">
Require all denied
</FilesMatch>

HSTS-Implementierung

Um einige Dinge zu beachten, die ich bei der Erforschung von HSTS gelernt habe:

  1. Ein SSL-Zertifikat ist erforderlich
  2. Wenn Ihre Websites über HTTP verfügbar sind, leiten Sie alle Anforderungen mit einer permanenten 301-Weiterleitung an HTTPS um.
  3. Nehmen Sie Folgendes in Ihre .htaccessDatei auf : Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Das maximale Alter muss mindestens 10886400 Sekunden oder 18 Wochen betragen. Gehen Sie für den Wert von zwei Jahren.
  4. Fügen Sie Ihre Domain über den ersten Link unten einer Preload-Liste hinzu.

Ich ermutige alle, jede Quelle unten zu lesen, um weitere Informationen zu erhalten.

  • Übermittlung der HSTS-Preload-Liste
  • Was ist HSTS und warum sollte ich es verwenden? | Acunetix
  • Was ist HSTS und soll ich es implementieren? | Netzwerkdynamik
  • Warum Websites HSTS verwenden sollten, um Sicherheit und SEO zu verbessern

Antworten

3 MrWhite Oct 27 2020 at 23:09

HTTP Strict Transport Security (HSTS) hat zwei Aspekte:

  1. Implementierung von HSTS auf Ihrer Site.
  2. Senden Sie Ihre bereits HSTS-fähige Site an die HSTS-Preload-Liste . Hier wird die "Liste der HSTS-Sites" direkt im Browser zusammengestellt, wodurch vermieden wird, dass die erste Anforderung überhaupt über HTTP erfolgt (wobei die Anforderung möglicherweise für MITM-Angriffe anfällig ist).

Sie scheinen geradewegs auf # 2 zu gehen. Dies wird nicht unbedingt empfohlen. Stellen Sie sich die "Preload-Liste" als eine einfache Fahrt vor. Technisch ist es möglich, aus der Preload-Liste entfernt zu werden. Realistisch gesehen möchten Sie nicht einmal darüber nachdenken. (Es ist schwer - langsam - genug, nur von HSTS zurückzutreten.)

Auf der Seite zum Übermitteln der Preload-Liste selbst wird nicht empfohlen, direkt zu "Preload-Listenübermittlung" zu wechseln. Es wird empfohlen, den max-ageParameter über einen bestimmten Zeitraum (Monate) zu erhöhen , bevor der letzte Schritt zur Übermittlung an die Vorladeliste ausgeführt wird. Test Test Test in der Zwischenzeit, um sicherzustellen, dass SSL-Zertifikate zuverlässig erneuert werden, keine Warnungen vor gemischten Inhalten usw. usw.

Ich wäre auch vorsichtig bei der Übermittlung von HSTS-Preload-Listen (oder bis zu einem gewissen Grad sogar von HSTS selbst) auf einem gemeinsam genutzten Server , auf dem Sie nicht die volle Kontrolle über die SSL-Konfiguration haben. Sie geben nicht an, ob Sie sich auf einem gemeinsam genutzten Server befinden oder nicht, aber da Sie diese gesamte Konfiguration in ausführen .htaccess, gehe ich davon aus, dass Sie es sind. Wenn Sie über einen eigenen Server verfügen und Zugriff auf die Serverkonfiguration haben, sollte das meiste davon in der Server- / Virtualhost-Konfiguration konfiguriert werden (und dies ist wahrscheinlich einfacher und zuverlässiger).

Denken Sie daran, dass auf Ihre Site nur über HTTPS zugegriffen werden kann, wenn Sie die HSTS-Route gegangen sind (und Benutzer auf die HTTPS-Site zugegriffen haben oder sich in der "Preload-Liste" befinden) . Dies gilt nicht nur für Ihre Website, sondern auch für Dienste von Drittanbietern, die Sie möglicherweise verwenden (Warnungen von Browsern mit gemischten Inhalten usw.).

#IMPLEMENT HSTS
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Dadurch wird der erforderliche HSTS-HTTP-Antwortheader für "die meisten" * 1- Antworten festgelegt (beachten Sie jedoch den preloadParameter, der anfangs wahrscheinlich weggelassen werden sollte).

* 1 Diese Anweisung legt jedoch nicht unbedingt den erforderlichen Header für alle Antworten fest. Eine Anforderung von HSTS ist, dass Sie den Header auch auf "Umleitungs" -Antworten setzen (z. B. www auf non-www auf HTTPS). Derzeit macht das oben nicht dies. Sie sollten diealways Bedingung in derHeaderDirektive verwenden, um den Header für andere Antworten als 200 OK festzulegen. Zum Beispiel:

# Use "always" condition to set on "redirects" as well.
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

(Ich habe den preloadParameter vorerst auch entfernt .)

Sie benötigen den <IfModule>Wrapper nicht und sollten entfernt werden. mod_headers sollte standardmäßig aktiviert sein. Dies ist Ihr Server. Sie wissen, ob mod_headers aktiviert ist oder nicht. mod_headers muss aktiviert sein, damit dies funktioniert. Sie möchten nicht, dass dies stillschweigend fehlschlägt, wenn mod_headers nicht verfügbar ist. Sie benötigen eine Benachrichtigung, sobald dies mit einem Fehler in Ihren Protokollen fehlschlägt.

Viele Artikel Zustand , dass Sie sollten nur die Set - Strict-Transport-SecurityHeader auf sichere (HTTPS) Antworten. Und die "Übermittlung der Preload-Liste" gibt tatsächlich eine "Warnung" aus (nicht unbedingt ein "Fehler", glaube ich), wenn Sie den Header auch über HTTP senden. Während jedoch nur muss auf der HTTPS - Antwort gesetzt wird, ignorieren kompatibele Browser diese Header , wenn über eine unverschlüsselte HTTP - Verbindung gesendet (zur Vermeidung von MITM - Angriffen) , so sollte es keine Rolle , ob der Header „unnötig“ ist geschickt über HTTP als auch. Dies wäre einfacher in den entsprechenden <VirtualHost>Containern in der Hauptserverkonfiguration zu verwalten . Das Senden dieses Headers nur für HTTPS-Antworten in .htaccessist komplexer (und daher fehleranfälliger). Sie müssten eine zusätzliche Umgebungsvariable verwenden, mit der Sie den HSTS-Antwortheader bedingt festlegen können.

Zum Beispiel:

# Set environment var "HSTS" if accessed over HTTPS connection
RewriteCond %{HTTPS} on
RewriteRule ^ - [E=HSTS:1]

# Conditionally set only on HTTPS connections (ie. when "HSTS" env var is set)
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains" env=HSTS

Ansonsten glaube ich, dass Ihre verbleibenden Richtlinien in Bezug auf HSTS in Ordnung sind. Aber wie immer Test Test Test.


Lösen Sie mehrere (unnötige) Weiterleitungen auf

#FORCE WWW TO NON-WWW
RewriteCond %{HTTP_HOST} ^www.example.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

#URL EXTENSION REMOVAL
RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC]
RewriteRule ^ /%1 [NC,L,R]

Ein potenzielles Problem hier (mit der 2. und 3. kanonischen Weiterleitung oben nach der HTTP-zu-HTTPS-Umleitung) ist, dass dies möglicherweise zu zwei zusätzlichen Weiterleitungen führt, wenn www+ .htmlangefordert wird. Dies könnte behoben werden, indem Sie einfach die beiden Weiterleitungen umkehren und den kanonischen Hostnamen in die Weiterleitung "URL EXTENSION REMOVAL" aufnehmen (wie in meiner Antwort auf Ihre frühere Frage erwähnt ).

Zum Beispiel:

#URL EXTENSION REMOVAL
RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC]
RewriteRule ^ https://example.com/%1 [R=301,L]

#FORCE WWW TO NON-WWW
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule (.*) https://example.com/$1 [R=301,L]

In meiner vorherigen Antwort finden Sie einen alternativen Ansatz für die Weiterleitung "URL EXTENSION REMOVAL", mit der einige potenzielle Probleme behoben werden.

Wenn Sie die wwwSubdomain nicht für andere Hostnamen verwenden (z. B. www.subdomain.example.com), können Sie das CondPattern in der Umleitung von www zu non-www zu einfach vereinfachen ^www\., d. H. Jeder angeforderte Hostname, der einfach gestartet wird www., anstatt den gesamten Hostnamen zu überprüfen.


Zusätzliche Korrekturen

Schleife zum Entfernen / Umschreiben der URL-Erweiterung (500 Internal Server Error)

Es gibt noch ein paar andere Probleme, die ich in Ihrer früheren Frage nicht angesprochen habe und die sich nicht auf HSTS beziehen, auf die ich weiter unten eingehen werde ...

#URL EXTENSION REMOVAL
:
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^ %{REQUEST_URI}.html [NC,L]

Dies (und ähnliches) ist eines dieser Codefragmente, die "blind" überall kopiert / eingefügt werden (und ich meine überall ) als "Standard" -Methode zum Anhängen (URL-Umschreiben) der Dateierweiterung bei Verwendung von URLs ohne Erweiterung. Obwohl es wahrscheinlich für Ihre gültigen URLs "funktioniert", weist es einen schwerwiegenden Fehler beim Anfordern ungültiger URLs auf ...

Wenn /about.htmles sich um eine gültige Datei handelt, die Sie beim Anfordern der URL ohne Erweiterung bereitstellen möchten, /aboutfunktioniert sie in Ordnung. Wenn ich jedoch (böswillig) angefordert habe /about/oder /about/<anything>Ihr Server in eine spiralförmige Umschreibeschleife gerät, führt dies zu einer Antwort auf 500 interne Serverfehler. Der Endbenutzer sollte nicht in der Lage sein, eine solche Antwort aufzurufen (möglicherweise anfälliger für DDOS-Angriffe und anderes feindliches Verhalten).

Dies liegt daran, dass REQUEST_FILENAME(der zugeordnete Dateisystempfad) nicht unbedingt auf denselben öffentlichen URL-Pfad verweist wie die REQUEST_URIVariable (angeforderter URL-Pfad).

Um dies zu beheben, verwenden Sie REQUEST_URIdurchgehend. Zum Beispiel:

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI}.html -f
RewriteRule ^ %{REQUEST_URI}.html [L]

(Die NCFlagge ist hier in der RewriteRuleRichtlinie überflüssig .)

Weitere Informationen hierzu finden Sie in meiner Antwort auf die folgende ServerFault-Frage .

Hotlink-Schutz - Vereinfachen Sie den Zustand

#HOTLINKING PROTECTION
RewriteCond %{HTTP_REFERER} !^https://(www\.)?example\.com(/.*)*$ [NC]

Dies ist relativ gering. Die Regex in der obigen Bedingung kann vereinfacht werden. Zu diesem Zeitpunkt in der .htaccessDatei wurde der Hostname bereits (www\.)?kanonisiert , um das WWW der Subdomain zu entfernen, sodass das Submuster oben überflüssig ist. Wie das (/.*)*$nachfolgende Untermuster, das einfach zu allem anderen passt . Sie müssen hier eigentlich nichts übereinstimmen , sondern nur behaupten, dass der RefererHeader mit dem entsprechenden (Schema +) Hostnamen beginnt.

Zum Beispiel:

RewriteCond %{HTTP_REFERER} !^https://example\.com

Auch hier ist die NCFlagge überflüssig. Das Erzwingen einer Übereinstimmung ohne Berücksichtigung der Groß- und Kleinschreibung, wenn dies nicht erforderlich ist, führt nur (ein kleines bisschen) mehr Arbeit für Ihren Server aus und kann Sie in einigen Fällen für Schwachstellen öffnen ("doppelte Inhalte" sind häufig - obwohl dies hier kein Problem darstellt). .

Aktivierung nicht erforderlich Options

#PREVENT DIRECTORY BROWSING
Options All -Indexes

Dies verhindert nicht nur das "Durchsuchen von Verzeichnissen". Das AllArgument ermöglicht eine Reihe anderer Dinge, die Sie wahrscheinlich nicht benötigen, z. B. serverseitige Includes ( Includes) und die Möglichkeit, CGI-Skripte auszuführen ( ExecCGI). (Dies ist übrigens das einzige Mal, dass Sie Argumente mit a +oder -mit solchen ohne mischen können.) Um nur das Durchsuchen von Verzeichnissen zu verhindern (dh das automatische Generieren von Verzeichnisindizes durch mod_autoindex), entfernen Sie das AllArgument.

Sie benötigen jedoch wahrscheinlich nur FollowSymLinks(was möglicherweise bereits in der Serverkonfiguration festgelegt ist), sodass Sie stattdessen Folgendes festlegen können:

Options FollowSymLinks

Beachten Sie das Fehlen von +oder -. Diese nur Sätze FollowSymLinks, so deaktivieren Indexes( „Verzeichnissuche“) , wenn es wurde bereits festgelegt.