Das Bundesverfassungsgericht hat die 6-monatige Speicherung von
Telefon- und Internetdaten zur Strafverfolgung für unzulässig erklärt.
Nach dem Urteil der Karlsruher Richter stellt die Aufbewahrung der
Verbindungsdaten in der jetzigen Form einen besonders schweren Eingriff
in das Fernmeldegeheimnis dar. [Zitat: dradio.de]
Ich denke dieses Urteil, das zunächst einmal die deutschen Terrorschützer in ihre Schranken weisst auch Auswirkungen auf ganz andere Anwendungen der Informationstechnologie haben wird. Wie sieht es zum Beispiel mit Googles ins Kreuzfeuer geratenem StreetView aus? Oder die LKW-Autobahnmaut?
Als Web-Entwickler treibe ich mich natürlich nicht nur auf guten Seite (auf dem Server) sondern auch auf der dunklen, bösen Seite: im Browser herum. Neben den Tücken die HTML und CSS bei der täglichen Arbeit bieten, kann man sich mit JavaScript weitere Probleme aufhalsen.
Aber zum Glück gibt es Prototype.js! Prototype.js setze ich nun schon vier Jahre ein und es hat mein Leben völlig verändert. So macht das Programmieren mit JavaScript wirklich Spaß und man sieht sich im Browserkrieg nicht immer in die Defensive gedrängt.
Auch heute waren Prototype.js und script.aculo.us wieder maßgeblich daran beteiligt ein Problem zu lösen - und zwar schick, klein, elegant und ohne ganz ohne Browserschlamassel.
Security by Obscurity (Sicherheit durch Verschleierung) ist natürlich keine Methode um echte Sicherheit zu erreichen. Selbst wenn es sich nicht um offenen Source Code handelt, ist es nur eine Frage der Zeit bis die Verschleierungsmaßnahmen durschschaut und damit geknackt werden. Aber auch Fehler im Programm können zu Sicherheitsproblemen führen. Gerade bei Open Source Produkten, deren Quellcode im Prinzip jeder nach sicherheitsrelevanten Fehlern durchsuchen kann, werden solche Lücken schnell entdeckt und publik - und in der Regel auch schnell geschlossen.
So konnte ich neulich beobachten wie eine kleine, private Webseite mit rund 800 Angriffen über HTTP beschossen wurde. Offensichtlich handelte es sich um einen "Scanner" der bekannte Sicherheitslücken gleich haufenweise automatisch ausprobiert. Darunter waren Angriffe auf Typo 3, Joomla, Foren, Galerien und und und.
Auch meinen eigenen Webseiten (auch der angegriffenen) liegt ein Open Source Produkt zu Grunde (eigentlich mehrere): Wombat. Obwohl Wombat (natürlich) das beste Produkt des Universums ist :-), sind Fehler nicht ausgeschlossen. Normalerweise beklage ich, dass Wombat von niemandem verwendet wird, aber dadurch hat Wombat einen Security by Obscurity Vorsprung: Da kein Mensch weiss wie Wombat funktioniert, kennt auch niemand die Sicherheitslücken (wenn es welche gibt), ergo gibt es keine Angriffe auf das System.
Die einfachsten Rezepte sind oft die besten. Über ein eben solches bin ich gerade im PHP Kochbuch (www.oreilly.de) gestolpert. Eben dieses ist in einer überarbeiteten Auflage erschienen vor ein paar Tagen fand ein Exemplar den Weg in meinen Briefkasten. (Eigentlich fand es den Weg zur Klingel - für den Briefkasten ist das Buch zu dick.)
Das Rezept, welches mir beim durchblättern zufällig ins Auge sprang, ist eines zur Vermeidung von Tippfehlern. Konkret geht es um die Verwechslung von "=" und "==". Während ersteres eine Zuweisung ist, handelt es sich letzterem um einen Vergleich.
if ($foo == 'bar') {
// do something
}
if ($foo = 'bar') {
// do something
}
Solche Fehler sind, da sie zum einen die Programmlogik und gleichzeitig noch eine Wert ändern sehr ärgerlich und oftmals ebenso schwer zu finden. Ein einfaches Rezept so etwas zu vermeiden, ist es den konstanten Wert auf die linke Seite des Gleichheitszeichens zu setzen.
if ('bar' == $foo) {
// do something
}
if ('bar' = $foo) {
// do something
}
Diese Schreibweise ändert nichts an der Programmlogik, verhindert aber die Zuweisung, bzw. PHP wird sofort (mit recht) meckern und die Bearbeitung des Skriptes mit einem Fehler abbrechen. Das ist für mich Grund genug in Zukunft immer darauf zu achten, Bedingungen in nach diesem Rezept zu formulieren.
Was die anderen - gefühlt - zehntausend Rezepte in diesem Buch angeht, glaube ich viele schon zu kennen oder gab es einfach keine Berührungspunkte mit diesem Gebiet. Das PHP Kochbuch ist bestimmt auch kein Werk welches von vorne bis hinten durchgelesen werden will. Dafür ist es als Ratgeber insbesondere bei der Beschäftigung eines neuen Themas hervorragend geeignet. Darüber hinaus finde ich, dass sich der dicke Wälzer besonders gut zum schmökern eignet. Ich werde ihn daher als Briefbeschwerer auf dem Schreibtisch liegen lassen und hin und wieder eine zufällige Seite aufschlagen und ein paar Rezepte meiner Hausmannskost hinzufügen.
Eine Webseite besteht normalerweise aus mehr als aus einer Datei. Da gibt es Bilder, Stylesheets, Javascript und natürlich HTML. Bei dynamische Seite werden die eingetlichen HTML-Dateien durch Skripte ersetzt - dafür kommen aber meist noch Konfigurationsdateien hinzu. Sobald eine Seite auch nur ein klein bisschen komplexer wird, tut man gut daran Programmcode in Klassen und HTML-Schnipsel in Templates auszulagern. Am Ende sind es unzählige Dateien, die alle irgendwo und irgendwie Verwendung finden. Um Ordnung zu halten und den Überblick nicht zu verlieren landen Bilder im Bilderordner, Templates im Templateordner, PHP-Klassen im Includeverzeichnis usw. Das macht natürlich Sinn, ich empfehle aber die Ordnerstruktur um eine Ebene zu erweitern.
Die Idee ist, nur diejenigen Dateien im Web zugänglich zu machen, die auch tatsächlich vom Browser heruntergeladen werden müssen. Das trifft sicherlich für (die meisten) Bilder, Stylesheets und überhaupt alle statischen Inhalte zu. Was auf jedenfall nicht zugänglich sein soll sind Konfigurationsdateien (in denen womöglich Datenbankpasswörter im Klartexte gespeichert sind), PHP-Klassen (die sowieso nichts ausgeben) und Templatedateien (die kein vollständiges und mit Platzhaltern gespicktes HTML enthalten). All diese Datein dürfen nicht durch einfaches erraten der URL über den Browser zugänglich gemacht werden. Selbstverständlich ist es möglich den Zugriff auf diese Dateien durch geschickte Regeln in der Konfiguration des Webservers (z.B. in der htaccess-Datei) zu unterbinden. Allerdings werden solche Regeln schnell kompliziert wenn die verbotenen Dateien über das ganze Projekt verstreut sind.
Der umgekehrte Weg: ausschließlich "Web-Dateien" auch über Web verfügbar zu machen ist viel einfacher (und sicherer). Dazu braucht es nur ein Verzeichnis - nennen wir es htdoc. Da kommen alle Bilder, Stylesheets und natürlich auch die index.php hinein. Außerhalb dieses Verzeichnis gibt es Ordner für PHP-Klassen, HTML-Templates, Konfigurationsdateien, Caches, Logdateien und was auch immer. Nun muss nur noch der Webserver so konfiguriert werden, dass das DOCUMENT_ROOT - um im Apache-Jargon zu sprechen - dieser Webseite auf das Verzeichnis htdoc zeigt. Damit sind alle Dateien außerhalb dieses Verzeichnisses für den Besucher der Webseite unerreichbar - ganz einfach dadurch, dass die Dateien die nicht ins Web gehören auch nicht im Web sind.
Natürlich erzähle ich damit nichts neues. Diese Methode wende nicht nur ich schon seit Jahren an. Was mich aber verblüfft (und enttäuscht), wie wenig dieses Prinzip bei all der Diskussion um Sicherheit angewandt wird. Zum einen ist es natürlich bedauerlich, dass es nicht Standard von Webhosting-Paketen geworden ist das DOCUMENT_ROOT in einen Unterordner zu verlegen. Tragischer finde ich, dass es so viele Webprojekte gibt (z.B. OpenSource CMSe), die diesen Grundsatz nicht befolgen. Wer also ein neues Projekt startet oder dabei ist eines zu verbessern sollte sich Gedanken darüber machen was ins Web gehört und was nicht.