Blog
tags: news software deutsch opensource apache howto
Permalink: https://musicchris.de/blog?id=77&langopt=english
.htaccess - ein paar Kniffe und interessante Links
Nachdem ich immer wieder mal an meiner .htaccess
-Datei rumgeschraubt habe, will ich hier mal den aktuellen Stand zum Thema Sicherheit teilen. Zuerst mal ein paar gute Seiten, auf denen ich schöne Tips, Anregungen und Erläuterungen fand:
- https://perishablepress.com/stupid-htaccess-tricks - dort gibt es eine Unmenge an wirklich brauchbaren und teilweise auch cleveren Tricks
- https://httpd.apache.org/docs/2.2/howto/htaccess.html - natürlich darf die Apache-Dokumentation nicht fehlen!
- https://wiki.selfhtml.org/wiki/Webserver/htaccess - selfHTML. Immer eine gute Adresse!
Vor einiger Zeit gab es im OSBN ein paar Artikel, in denen es um Sicherheitstest und insbesondere um die Apache-Konfiguration ging. Daraus entsponn sich eine kleine Diskussion. Ein paar Schnipsel unserer .htacces Dateinen wurden unter die Lupe genommen und wir versuchten unsere Server sicherer zu machen. Im Sicherheitstest habe ich nun ein A+ erreicht. So sieht in meinem Falle die Konfiguration aus:
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Xss-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"
Header always set Content-Security-Policy "default-src 'self';"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set X-Powered-By "42"
Header always set Server "depressed robot"
Diese paar Zeilen reichen, um den Apache, bzw seine Antworten so zu ändern, daß viele Probleme nicht mehr greifen. CrossSiteScripting wird unterbunden, bzw, der Browser wird angewiesen keine Inline-Scripte auszuführen. Nichtmal inline-CSS wird zugelassen. Nachdem ich diese Einstellung eingeführt hatte, mußte ich zwar erstmal meine Seite neu schreiben, weil ich natürlich bequemerweise überall onclick='alert(Hallo Welt!);'
drinstehen hatte. Das mußte alles in eine externe .js-Datei ausgelagert, und durch EventListener ersetzt werden. Das war ne harte Nummer, aber es fühlt sich natürlich viel besser an, einen sicheren Server zu haben, als jeden Tag damit zu leben, daß meine Besucher eventuellen Attacken ausgesetzt sein können.
Also, die Optionen X-Xss-Protection und Content-Security-Policy erzwingen in dieser Konfiguration, alles JavaScript und CSS in eine eigene Datei auszulagern. Z.Bsp. scripts.js und style.css
Was eigentlich Standard sein sollte: Alle Anfragen auf https umbiegen:
# Redirect all requests to https!
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</ifmodule>
Ich halte es für eine regelrechte Sicherheitslücke im Apache, daß die .htpasswd direkt ausgelesen werden kann! Die kann man sich dann speichern und in aller Ruhe zuhause eine Brute-Force-Attacke auf die Hashes fahren, um dann mit dem passenden Passwort sich an der Seite anzumelden. *kopfschüttel*
Naja, unterbinden läßt sich das ganz einfach so hier: (Gefunden bei be-jo.net.) Sollte in keinem Apachen fehlen.
# Stop Apache from serving .ht* files
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
So, ich hoffe, jemand konnte vielleicht was Neues lernen, was er noch nicht kannte. Vielleicht hat jemand noch mehr gute Tips, so daß ich vllt was Neues lernen kann... Laßt gerne einen Kommentar da!
comments
1) Daniel
04.Feb.2017 21:32
Eine Frage: Was meinst du mit .htpasswd auslesen? Die sollte man in ein Verzeichnis legen, das man von außen eben nicht abrufen kann! Ich zitiere https://httpd.apache.org/docs/2.4/howto/auth.html:
"This file should be placed somewhere not accessible from the web. This is so that folks cannot download the password file. For example, if your documents are served out of /usr/local/apache/htdocs, you might want to put the password file(s) in /usr/local/apache/passwd."
PS: Im Kommentarformular steht immer "otional" ohne p.
2) chris_blues
04.Feb.2017 21:36
Was mich da am meisten dran ärgert, daß diese Dateien überhaupt ausgeliefert werden!
? Na hoppla! Danke für den Hinweis!
3) Jörg
05.Feb.2017 10:08
Sonst könnte man ja auch überall .htaccess Dateien auslesen. Konntest du die .htpasswd denn bei dir über den Webrowser abrufen?
4) chris_blues
05.Feb.2017 10:32
Ich werd grad unsicher! Hin und wieder gabs die als plaintext im Browser. Es ist allerdings auch möglich, daß ich selber beim basteln an der .htaccess da irgendwas Blödes gemacht hab.
Hab jetzt ein paar Tests gemacht, mit der Direktive an und aus, und in beiden Fällen konnte ich die nicht auslesen.
Wer weiß, was ich da gestern gemacht hab... ?
5) tux.
06.Feb.2017 13:33
Echt? Kein Linux mehr?
6) chris_blues
06.Feb.2017 14:01
7) tux.
06.Feb.2017 14:05
8) anonymous
07.Feb.2017 19:40
9) Julius
08.Feb.2017 16:27
Bei der CSP müsste
Content-Security-Policy "default-src 'self'"
eigentlich eigentlich ausreichen, man muss nicht alles einzeln verbieten.Gruß
Julius
10) chris_blues
09.Feb.2017 12:59
post a comment
privacy declaration
Your IP-address, useragent-string etc are not stored by this blog-software. Still, it is possible that the hoster of this website may store data like this. But that is beyond the scope of this blog-software. Check out this website's privacy declaration to find out more about that!
This blog-software generally doesn't store any information about you. Only if you post a comment, some data will have to be stored. You don't have to input any personal information here. Except for the comment itself, all fields are optional!
If you don't want to tells us your name, that's fine. It will be shown as 'anonymous'.
If you want to receive notifications on following comments, naturally you'll have to give us your email address. It will be stored and not be shared with anybody. If you don't want to be notified, just leave the notifications field empty.
If you want your name to be linked to your website, you'll have to give us your site's address. Otherwise leave this field empty.
This data will be stored in case you decide to post a comment here: