Blog

tags: news software deutsch opensource apache howto


04.Feb.2017 15:48 - last update: 04.Feb.2017 17:22

.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:

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

Danke fรผr die Hinweise. Ich werde das mal mit meinem Setup vergleichen.

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

Ja, das ist etwas absurd. Bei meinem Hoster geht das leider nicht, die .htpasswd auรŸerhalb des http-root abzulegen. Also muรŸ ich die extra blockieren.

Was mich da am meisten dran รคrgert, daรŸ diese Dateien รผberhaupt ausgeliefert werden!

PS: Im Kommentarformular steht immer "otional" ohne p.

? Na hoppla! Danke fรผr den Hinweis!

3) Jรถrg

05.Feb.2017 10:08

Zumindest unter Debian ist eine solche Anweisung bereits standardmรครŸig in der apache2.conf enthalten:

#
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#
<FilesMatch "^.ht">
Require all denied
</FilesMatch>


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

Konntest du die .htpasswd denn bei dir รผber den Webrowser abrufen?

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

wir versuchten unsere Server sicherer zu machen


Echt? Kein Linux mehr?

6) chris_blues

06.Feb.2017 14:01

?

7) tux.

06.Feb.2017 14:05

Also doch? Tja... ?

8) anonymous

07.Feb.2017 19:40

Du kannst die Header auch in <IfModule mod_headers.c> ... </IfModule> setzen, wie du das auch bei mod_rewrite.c machst.

9) Julius

08.Feb.2017 16:27

Moin,

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

Stimmt. ?

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:

  • time and date of your post
  • your name (if supplied)
  • your email (if supplied)
  • your website (if supplied)
  • your comment
  • some technical information unrelated to you, like which blogpost this comment belongs to and a unique id for this comment