Blog

tags: news software deutsch opensource apache howto


04.Feb.2017 15:48 - zuletzt aktualisiert: 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!




Creative Commons Lizenzvertrag
Dieses Werk ist lizenziert unter
Creative Commons Namensnennung 4.0 International .

Kommentare

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

Kommentar verfassen








😀😁😂😃😄😅😆😇😈😉😊😋😌😍😎😏😐😑😒😓😔😕😖😗😘😙😚😛😜😝😞😟😠😡😢😣😤😥😦😧😨😩😪😫😬😭😮😯😰😱😲😳😴😵😶😷🙁🙂🙃🙄🙅🙆🙇🙈🙉🙊🙋🙌🙍🙎🤐🤑🤒🤓🤔🤕🤖🤗🤘🤠🤡🤢🤣🤤🤥🤦🤧👍𝄞🌍🌹🍻🍾

Datenschutzerklärung

Ihre IP-Adresse, Browserinformation (useragent-string) etc werden von dieser Blogsoftware nicht gespeichert. Trotzdem könnte es sein, daß der Betreiber dieser Webseite solche Daten von Ihnen speichert. Das ist allerdings außerhalb der Reichweite dieser Blogsoftware. Bitte sehen Sie sich die Datenschutzerklärung der Webseite an um mehr darüber zu erfahren!

Diese Blogsoftware speichert generell keine Daten von Ihnen. Nur falls Sie einen Kommentar hinterlassen, müssen ein paar Daten gespeichert werden. Sie brauchen hier keine persönlichen Daten angeben. Abgesehen vom Kommentar selbst sind alle anderen Angaben freiwillig!
Es ist vollkommen in Ordnung falls Sie ihren Namen nicht angeben wollen, ihr Kommentar wird dann als 'anonym' angezeigt werden.
Falls Sie Benachrichtigungen erhalten wollen, wenn hier neue Kommentare erscheinen, dann brauchen wir dazu natürlich Ihre Emailadresse. Diese wird sicher gespeichert und nicht weitergegeben. Falls Sie nicht benachrichtigt werden wollen, lassen Sie das Feld Benachrichtigungen einfach leer.
Falls Sie Ihre Webseite mit Ihrem Namen verknüpfen wollen, brauchen wir natürlich Ihre Webadresse. Ansonsten kann auch dieses Feld leer bleiben.

Falls Sie einen Kommentar hinterlassen wollen werden folgende Daten gespeichert werden:

  • Zeit und Datum Ihres Kommentars
  • Ihr Name (falls angegeben)
  • Ihre Emailadresse (falls angegeben)
  • Ihre Webseite (falls angegeben)
  • Ihr Kommentar
  • einige technische Informationen, die mit Ihnen nichts zu tun haben, z.Bsp. zu welchem Blogartikel Ihr Kommentar gehört und eine eindeutige ID für Ihren Kommentar