Website-Einbindung in iFrame verhindern

Als ich mir heute die Server-Logfiles angesehen habe, ist mir direkt ein sehr merkwürdiger Referrer aufgefallen. Ein solcher Referrer ist schlicht und einfach ein Hinweis darauf, von welcher (fremden) Seite die eigene Website aufgerufen wurde. Diese Information wird – sofern man die Funktion nicht deaktiviert hat – automatisch vom Browser an den Webserver übermittelt.

Beim Besuch dieser verweisenden Seite musste ich jedoch mit Erstaunen feststellen, dass man startapp.de dort einfach als iFrame eingebunden hat. Meines Erachtens ein No-Go.

Gut, dass ich auf selfhtml.org etwas gefunden habe, womit man genau dies verhindern kann. Die Antwort lautet: Javascript. Es ist eigentlich ein alter Hut, aber so wie es scheint immer noch ein probates und unverzichtbares Mittel, damit der eigene Internetauftritt im gesamten Browserfenster dargestellt wird.

Wenn auch ihr verhindern möchtet, dass eure Seite oder euer Blog in einem iFrame geladen wird, fügt einfach den folgenden Code-Schnipsel in den Header-Bereich eurer Website ein:

<script type=“text/javascript“>
if (top != self)
top.location = self.location;
</script>

Wichtig ist, dass diese Anweisung vor dem abschließenden </head> eingebunden wird.

micha’s tech-blog setzt auf HTML5 und CSS3

firefox-logo

An dieser Stelle ein technischer Hinweis in eigener Sache. micha’s tech-blog setzt hinsichtlich des Designs auf HTML5 und CSS3. Diese neuen Webstandards werden von älteren Browsergenerationen nicht unterstützt. Es kommt damit zu einer falschen bzw. keiner brauchbaren Darstellung. So wird beispielsweise der Internet Explorer erst ab Version 8 unterstützt. Hinsichtlich „Responsive Design“ konnte ich auf mobilen Geräten gute Ergebnisse mit Safari unter iOS und Chrome unter Android feststellen. Das beste „Look & Feel“ auf einem Desktop-PC bietet meines Erachtens eine aktuelle Version des Firefox-Browsers.

WordPress-Sicherheit erhöhen

wordpress-logo

WordPress ist ein beliebtes und dementsprechend weitverbreitetes Blogging-System. Wenn auch ihr mit dem Gedanken spielt, ein Blog mit WordPress zu realisieren, dann sind die folgenden Vorkehrungen sicherlich hilfreich. Vorweg: 100%ige Sicherheit wird es nie geben, aber eins ist sicher: So selbstverständlich wie man sein Auto zur Inspektion oder zum TÜV bringt, genauso muss man sich um einen Internetauftritt kümmern. Es reicht nicht, diesen einmal zu installieren und der technischen Seite danach keine Beachtung mehr zu schenken. Womit wir auch schon beim Thema wären…

Ich gehe an dieser Stelle davon aus, ihr habt euch die WordPress-Dateien im .zip-Format bereits aus einer offiziellen Quelle heruntergeladen. Entpackt dieses Archiv und benennt den Hauptordner in etwas Abstraktes um. Uploaded diesen dann via FTP auf euren Webspace in einen Domain-Ordner eurer Wahl. Die (Sub-)Domainzuordnung muss dann noch auf diesen abstrakten Pfad gemappt werden. Wenn der Aufruf der gewünschten URL im Browser funktioniert, sollte der Installationsprozess starten.

WordPress setzt auf PHP (serverbasierte Scriptsprache) und MySQL. Letzteres dient dazu, Einstellungen, Seiteninhalte, Artikel und alles was so dazugehört in einer Datenbank abzuspeichern. Dazu werden sog. SQL-Queries performed und die Informationen in Tables abgelegt. Diese Datenbanken und Tabellen sind natürlich ein beliebtes Angriffsziel. Man hört in diesem Zusammenhang öfters mal den Begriff SQL-Injection. Bei der Installation ist das Standard-Tabellen-Präfix wp_ vorbelegt. Das sollte man durch einen individuellen String (Beispiel: qx12_) ersetzen. Dieses prefix könnte theoretisch dazu dienen, dass man mehrere Websites in einer Datenbank unterbringt. Aus vorgenannten Gründen ist davon allerdings abzuraten. Sollte es auf einer Website zu Problemen externer Natur kommen, legen diese schlimmstenfalls nicht direkt mehrere Internetauftritte gleichzeitig lahm.

 Wenn man mit der Installation fertig ist, hat WordPress eine Datei mit dem Namen wp-config.php angelegt, wo sämtliche während der Installation abgefragten Attribute zu finden sind (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). Ihr findet dort ebenfalls die ganzen KEYs, welche für jedes Blog individuell sind und auch sein müssen. In früheren Versionen von WordPress konnte bzw. musste man diese Schlüssel manuell über die Seite https://api.wordpress.org/secret-key/1.1/salt/ erzeugen und via copy & paste einfügen. Heutzutage geschieht dies automatisch. Ihr könnt die Keys später auch von Zeit zu Zeit ändern, danach müssen sich lediglich aktuell angemeldete User neu einloggen. Legt die wp-config.php eine Verzeichnisebene höher ab. WordPress sollte bzw. wird sie dort finden. Damit sind die DB-Zugriffsdaten sicher ausgelagert.

Wenn alles soweit vorbereitet ist, sollte man sich daran machen die sicherheitskritischen Bereiche des Blogs für böswillige Besucher unerreichbar zu machen. Darunter zählt zum einen die Datei wp-login.php und zum anderen der Ordner wp-admin. Das ganze kann über .htaccess realisiert werden, sofern euer Webspace-Paket dieses Feature vorsieht. Man könnte dann entweder eine zusätzliche Passwortabfrage einbauen oder – sofern ihr über eine statische oder eine selten wechselnde IP-Adresse verfügt (z.B. Kabel-Internet ohne Zwangstrennung) – nur einen ganz bestimmten Client zulassen. Wenn ihr euch für letzteres entscheidet, dann müsst ihr eine .htaccess-Datei mit folgendem Inhalt in diesem Ordner ablegen:

<Files wp-login.php>
order deny,allow
deny from all
allow from 127.0.0.1
</Files>

127.0.0.1 müsst ihr natürlich durch die zugelassene IP ersetzen. Solltet ihr im Vorfeld schon die Permalink-Funktion aktiviert haben, so müsst ihr die bestehende .htaccess-Datei nur noch durch den obigen Code ergänzen. Bei dynamischen IP-Adressen (solltet ihr den Aufwand der Sicherheit wegen betreiben wollen) muss diese Datei nach jeder Zwangstrennung angepasst werden. Den Ordner wp-admin sichern wir mit folgendem .htaccess-Inhalt:

order deny,allow
deny from all
allow from 127.0.0.1

Hier 127.0.0.1 analog ersetzen. Diese .htaccess muss direkt im Ordner „wp-admin“ abgespeichert werden. Wer sich jetzt fragt, warum er Dateien, aber keine Verzeichnisse in einer .htaccess-Datei absichern kann, dem sei gesagt das die Verwendung der <Directory>-Direktive nicht über .htaccess möglich ist. Das bedeutet, man muss die IP nach einem Reconnect immer zweimal ersetzen. Muss jeder für sich selbst entscheiden. 😉

Wer sich für die Passwort-Methode entscheidet sollte wissen, dass dieses im Klartext übertragen wird. Ebenso beim normalen Login ins Backend. Wer nicht gerade über einen dedicated Webserver verfügt, sondern sich seinen Webspace nach dem Shared-Hosting-Prinzip teilen muss, dem sind SSL-Zertifikate leider verwehrt. In der Praxis bedeutet dieser Umstand, dass theoretisch das Mitlesen und Aufzeichnen eurer Login-Daten z.B. im unverschlüsselten WLAN eines Internet-Cafés möglich ist. Das ganze könnte man unterwegs durch den Einsatz eines eigenen VPN absichern, doch das würde an dieser Stelle den Rahmen sprengen und beansprucht einen eigenen Blog-Artikel. Dennoch hierzu eine kurze Anmerkung: Wenn ihr Euch von unterwegs, sprich von einer fremden IP, einloggen wollt, dann hättet ihr eigentlich keinen Zugriff auf das Weblog mit .htaccess-Sperre. Da ihr dies aber dann über ein VPN-Gateway macht, sieht es für den Webserver so aus, als wenn ihr vom heimischen Rechner auf ihn zugreift. Das bedeutet Sicherheit und Flexibilität.

OK, so weit, so gut. Bevor man mit dem Bloggen loslegt, empfiehlt es sich einen neuen Administrator-Account anzulegen. Dadurch können böse Besucher zum einen unter der User-ID Nr. 1 schonmal keinen Administrator-Account ermitteln und zum anderen ist die Umbenennung des Benutzernamens (gleich Login) von WordPress leider nicht vorgesehen. Der neue Administrator sollte möglichst kryptisch angelegt werden. Das man ein starkes Passwort bestehend aus Zahlen, Sonderzeichen, Gross- und Kleinbuchstaben wählen sollte erklärt sich von selbst. Mit diesem meldet man sich auch gleich an, löscht den ersten Administrator und legt einen weiteren User, z.B. in der Rolle eines Redakteurs an. Dieser Benutzer sollte dann zum eigentlichen Bloggen verwendet werden. Der Administrator wird dann nur noch für tiefgreifende Änderungen, z.B. die Struktur und sonstige Einstellungen betreffend oder das Editieren der Theme-Dateien verwendet.

Das sind im Großen und Ganzen einige Tips um WordPress sicherer zu machen. Achja, bevor ich es vergesse: WordPress sucht automatisch nach Updates der Core-Dateien, Themes und Plugins. Es empfiehlt sich diese regelmäßig durchzuführen, weil damit sowohl Sicherheitslöcher gestopft, als auch Fehler ausgemerzt  und weitere Verbesserungen implementiert werden. Bei der Menge der Plugins gilt grundsätzlich: So viele wie nötig, so wenige wie möglich. Da sich auch in den beliebten Erweiterungen Malware befinden kann, sollte man diese mit Bedacht auswählen.