Eigene Webseiten vor fremden Frames schützen

Es kommt ja immer wieder mal vor, dass die eigene Homepage irgendwo im Web von fremden Leuten per HTML-Frame eingebunden wird – diese Leute machen sich also fremde Webseiten zu eigen. Okay – das mag allenfalls ein urheberrechtliches Problem sein, aber man kann diese uralte HTML-Technik (Frames sind in HTML5 nicht mehr vorgesehen!) auch für richtig bösartige Sachen nutzen. Da baut sich jemand Böses einen Frameset, bindet darin meine Webseite ein und verlinkt seinen Frameset z. B. bei Twitter. Nun wird meine Webseite von zigtausenden Surfern angeklickt – schlimmstenfalls reißt das meinen Webserver in die Knie. Oder jemand lässt mittels Frames meine schöne, hochkulturell wertvolle Seite zusammen mit was-weiß-ich-was-für Seiten im Browser erscheinen.

Wie kann man das nun verhindern? Nun, ich betreibe eine kleine Homepage auf einem Apache2-Server auf einem Raspberry Pi (für wenige Besucher pro Stunde reicht das voll und ganz). In der httpd.conf habe ich eine Zeile eingefügt, welche bewirkt, dass in dem HTTP-Response-Header eine Anweisung ausgegeben wird, dass meine Webseiten nur von meinem eigenen Webserver in Frames eingebunden werden darf. Diese Zeile lautet wie folgt:

Header always append X-Frame-Options SAMEORIGIN

Anstatt „SAMEORIGIN“ kann man auch die Option „DENY“ setzen. Dann darf nicht mal mehr mein eigener Webserver den Content in Frames darstellen – wer weiß, was meine Designer-Kollegen da für einen Unfug treiben 🙂

Nachdem man die Änderung in der httpd.conf gespeichert hat, startet man den Webserver mit sudo service apache2 restart neu. Sollte es beim Neustart zu Fehlermeldungen kommen, ist in der Apache2-Konfiguration das Modul „mod_headers“ nicht aktiviert. Dies kann man nachholen, in dem man in der Konsole „sudo a2enmod headers“eingibt. Jetzt sollte der Apache2-Neustart fehlerfrei laufen.

Und wie testet man jetzt, ob die Änderung wirklich aktiv ist? Hier gibt es eine Testseite, in der man sich den HTTP-Header des eigenen Webservers (und natürlich jedes anderen Webservers der Welt) ansehen kann. Dort sollte jetzt die Zeile

X-Frame-Options: SAMEORIGIN

erscheinen.

Übrigens: Wenn Sie keinen Zugriff auf die Servereinstellungen Ihres Webspaces haben – man kann auch mit .htaccess das Kapern Ihrer Webseiten mit Frames verhindern. Die hinzuzufügende Zeile lautet: Header append X-FRAME-OPTIONS „SAMEORIGIN“

Ach ja, und wo wir schon mal dabei sind: Wenn Sie in der Auflistung des HTTP-Headers die Zeile sehen: „X-Powered by“ – und dahinter Ihre detaillierte PHP-Version (ein Freudenfest für Hacker!), sollte man das schleunigst in der php.ini abschalten, indem man in der Zeile expose_php = On das „On“ durch ein „Off“ ersetzt.

WordPress: Upload-Limit erhöhen

In einer neuen WordPress-Umgebung mit podPress stand ich vor dem Problem, dass das vom Hoster vorgegebene Limit von Uploads per PHP-Funktionen – 8 MB – zu klein war (meine Podcast-Audiodateien sind bei Weitem größer). Auf der Medien-Upload-Seite in WordPress nervte schon die warnende Fußzeile „Maximale Dateigröße für Upload: 8 MB.“ Auf die php.ini meines Webpacks habe ich keinen Zugriff, somit konnte ich so ohne Weiteres dieses Limit nicht erhöhen.

Aber es gibt eine einfache Lösung, wie man dieses Limit aushebeln kann: wieder einmal htaccess. Man schreibt einfach eine Datei „.htaccess“ mit folgendem Inhalt:

<IfModule php5_module>
php_value upload_max_filesize 60M
php_value post_max_size 60M
php_value max_execution_time 1200
php_value max_input_time 1200
</IfModule>

Diese .htaccess lädt man dann per FTP in das WordPress-Unterverzeichnis „wp-admin“ hoch, und schon ist das Upload-Limit auf 60 MB heraufgesetzt. Außerdem hat man nun 1.200 Sekunden (20 Minuten) Zeit für den Upload größerer Dateien. Natürlich könnte ich vorab große Audiofiles auch per FTP uploaden und den entsprechenden Path dann im Blogbeitrag in WordPress einbinden. Aber is doch schöner so, nä?

Ich hoffe, dass Ihr Webhoster solche .htaccess-Spielchen ebenfalls zulässt. Wie ich hörte, funktioniert das nicht überall. Also: Ausprobieren.