Klopfers Webservice

Vorsicht vor doppelten Dateiendungen

Tue, 29 Jun 2010 20:23:32 GMT+1

Online-Anwendungen abzusichern, wird immer aufwändiger, was natürlich auch der Entwicklung zum Mitmach-Web geschuldet ist. So muss man grundsätzlich jeder Nutzereingabe misstrauen und daran arbeiten, sie von Schadcode zu befreien, um beispielsweise Cross-Site-Scripting-Attacken zu entschärfen.
Was vielen nicht bewusst ist: Auch bei Dateiuploads muss man besondere Vorsicht walten lassen.

Eine Angriffsmöglichkeit basiert auf einer Eigenart des Apache-2-Webservers. Dieser interpretiert nämlich mehrfache Dateiendungen. Um das zu verdeutlichen, ein kleines Beispiel: Nehmen wir an, der Webserver ist so konfiguriert, dass .pl-Dateien an den Perl-Interpreter geschickt werden, .php-Dateien an den PHP-Interpreter. Eine Datei beispiel.php.pl würde vom Apache also zu beiden Interpretern geschickt werden (was natürlich zumindest für einen Interpreter keinen Sinn ergeben würde).

Diese Eigenart führt zu einer Schwachstelle bei Datei-Uploads, wie viele Seiten ihren Mitgliedern per Webinterface ermöglichen, etwa um Profilbilder oder eigene Avatare zu realisieren. Viele Skripte prüfen nur oberflächlich, ob die Dateiendung auf eine Bilddatei hinweist (also zumeist .jpg, .jpeg, .png und .gif). So hat ein Angreifer die Möglichkeit, eine Datei der Form badscript.php.jpg hochzuladen, die er dann (sofern er die Adresse des Upload-Verzeichnisses kennt) über einen Browser aufrufen und mit den Rechten des Webservers als normales Skript ausführen kann.

Welche Gegenmaßnahmen muss man ergreifen?
Grundsätzlich ist zu empfehlen, den Dateinamen zu verändern und die Datei auf ihren Typ zu überprüfen. Die Überprüfung des Dateityps ist in PHP sehr einfach. Die Funktion getimagesize() liefert ein Array zurück, in dem an dritter Stelle die Art der Bilddatei angegeben ist (1 = GIF; 2 = JPEG, 3 = PNG usw.). Steht dort der Wert 0 oder ein Wert, der nicht zu den erwarteten Bilddateien passt, sollte das Upload-Skript die Datei löschen und eine Fehlermeldung ausgeben.
Wenn man so die Art der Bilddatei herausgefunden hat, kann man diese Information für den neuen Dateinamen verwenden (um etwa gültige Bilddateien, die mit falscher Dateiendung hochgeladen wurden, korrekt zu benennen) und selbst versehentliche doppelte Endungen zu tilgen. Außerdem bietet sich an, die neuen Dateinamen gleich so zu wählen, dass später hochgeladene Dateien keinesfalls den gleichen Namen bekommen können, also beispielsweise über Upload-Datum und -Zeit.

Wer also solche Upload-Skripte geschrieben hat, ohne bewusst auf diese Schwachstelle zu achten, sollte lieber jetzt noch einmal seinen Quellcode durchgehen.

Eventuell eingebundene Bilder und Videos werden im RSS-Feed nicht angezeigt. Bitte besuche die Website, um den Eintrag ggf. vollständig zu sehen und um ihn zu kommentieren.

HTML5 - Nun rauft euch doch mal zusammen

Fri, 25 Jun 2010 0:10:05 GMT+1

Mittlerweile wird ja laut getrommelt, um die Leute auf HTML5 heiß zu machen. Google, Apple und Mozilla basteln ganz tolle Demos, und Microsoft verspricht für den Internet Explorer 9 auch ganz viele HTML5-Features. Eigentlich geht's dabei nicht nur um HTML5, sondern auch um CSS3 und JavaScript (auf der Basis von ECMAScript edition 5), aber es hat sich ja eingebürgert, das alles als HTML5 zusammenzufassen. Ich sehe dabei trotzdem ein paar Probleme.

Das liegt nicht etwa daran, dass ich die ganzen Erweiterungen für schlecht oder unsinnig halten würde. Auch wenn ich persönlich für einige Sachen (noch) gar keine Verwendung wüsste, bin ich schon aufgeregt, was man da für neue Möglichkeiten bekommt. Das Problem liegt vielmehr bei der Implementierung. Die Browserhersteller sind unterschiedlich weit dabei, diese ganzen neuen Sachen einzubauen. Und als wenn das nicht reichen würde, stehen die Standards zum Teil noch gar nicht fest. HTML5 selbst wird erst 2022 zur offiziellen Empfehlung des W3C, auch wenn man schon zehn Jahre vorher das Stadium der relativen Stabilität des Entwurfs erreicht haben will, sodass dann tatsächlich eine allgemeine Vorstellung davon möglich ist, was eigentlich Standard ist und was nicht. An CSS3 arbeitet man seit zehn Jahren, und nur einige Teile davon sind bereits einigermaßen ausgefeilt.

Das sorgt natürlich dafür, dass die Browserhersteller vorsichtig sein müssen, was die Unterstützung solcher Dinge angeht. Microsoft machte mal bei der IE-Implementierung von CSS den Fehler, in die Breite die Werte von Padding und Border einzuberechnen - eine durchaus intuitivere und logischere Methode als die, die in der CSS-Definition vorgesehen ist, die aber der Firma heute noch als Internet Explorer Box Model Bug aufs Brot geschmiert wird.
Ein anderes Beispiel (ebenfalls in etwa zehn Jahre alt) ist der Kampf zwischen Microsofts iframe und Netscapes layer. In den jeweiligen Browsern wurden diese Tags eigenmächtig eingebaut. Sie leisteten in etwa dasselbe; das W3C übernahm dann schließlich iframe, und später konnten selbst die Netscape-Browser mit layer-Tags nichts mehr anfangen. Ich kaufte damals ein Javascript-Buch aus der Reihe "Das Einsteigerseminar" von Data Becker, und das beschäftigte sich groß und breit mit "Dynamischem HTML" - aber weil der Autor ein Netscape-Fan war, funktionierten nahezu sämtliche Beispiele im Buch nicht mit dem (damals eindeutig besseren) Internet Explorer.

Heutzutage benutzen die Browserhersteller bei CSS3 gerne browserspezifische Präfixe, so versteht also der Firefox die Eigenschaft -moz-border-radius, während man bei Safari und Chrome das gleiche Resultat (abgerundete Ecken) mit -webkit-border-radius erzielen kann. Das wird bei den oben erwähnten Demos natürlich zu einem Problem: Selbst wenn ein Browser alles kann, was in der Demo erwartet wird, so wird er (mehr oder weniger bewusst) oft ausgesperrt, weil in den Stildefinitionen z.B. nur auf Webkit-Browser geachtet wurde. Wenn ich mich nicht irre, traut sich noch kein Browser, das im CSS3-Vorschlag vorgesehene border-radius selbst zu interpretieren, weil sich ja die Definition noch ändern könnte.

Bei HTML5 selbst ist die Diskussion um das Video-Tag ja besonders stark, weil Microsoft und Apple den H.264-Standard unterstützen, Mozilla und Opera aber den patentfreien Theora-Codec. (Googles Chrome hat Unterstützung für beide Codecs.) H.264 hat das Problem, dass dafür Lizenzgebühren fällig werden könnten (zumindest die Mozilla-Foundation könnte die aber aus der Portokasse zahlen); Theora ist hingegen nicht so performant, ein ziemlich beschissen aufgebautes Format, welches Entwickler in den Wahnsinn treibt, und könnte zusätzlich durch unbeabsichtigte Patentverletzungen ebenfalls zu einem unfreien Codec werden. Für Webentwickler wie für Enduser heißt das, dass uns Flash doch noch für eine ganze Weile erhalten bleiben wird.

Bei modernen Browsern wäre es ideal, wenn man als Designer und Programmierer nicht dauernd Sonderwege gehen müsste. Ich bin ja erleichtert, dass man mittlerweile wenigstens bei HTML4, CSS2 und Javascript nur noch vergleichsweise geringe Anpassungen an spezifische Browser machen muss. Die Unterschiede bei den neuen Webtechnologien sind da ein extremer Rückschritt. Eine schnelle Einigung der Browserhersteller auf gemeinsame Vorgehensweisen (und wenn es sein muss, am trägen W3C vorbei) wäre hier wohl der beste Weg, um DeFacto-Standards für die neuen Technologien zu etablieren, auf die man sich einigermaßen verlassen kann.

Eventuell eingebundene Bilder und Videos werden im RSS-Feed nicht angezeigt. Bitte besuche die Website, um den Eintrag ggf. vollständig zu sehen und um ihn zu kommentieren.

Javascript-Frameworks

Mon, 21 Jun 2010 0:40:53 GMT+1

Ich mag sie nicht.
Damit will ich nicht sagen, dass sie schlecht wären, aber sie verschleiern Wirkungsweisen, und das wirkt sich negativ auf die Qualität der Skripte aus.

Dafür muss man sich nur mal viele Javascript-Tutorials angucken. In einem Tutorial geht es um Ajax - mit JQuery. Okay, denkt der geneigte Programmierer, ich benutze dann eben JQuery. Dann liest man in einem nächsten Tutorial etwas von einer ganz tollen Animationstechnik per Javascript - mit der script.aculo.us-Bibliothek, welche wiederum auf dem Prototype-Framework basiert. Und schon steckt man in der Frameworkhölle, in der man versucht, mehrere Frameworks einzubinden, ohne dass sich alle im Weg stehen, obwohl man von jedem Framework gerade mal 1% der Funktionen für die Dinge benötigt, die man machen will.

Und das Schlimmste - man hat immer noch keine Ahnung, wie diese Effekte eigentlich realisiert werden, weil die Tutorials einem nur den Weg über vorgefertigte Funktionen der Frameworks erklären, aber nicht den Hintergrund. Das ist so, als würde man statt einem Pizzarezept die Nummer des Bringdienstes bekommen.

Seit einiger Zeit betreiben die Browserhersteller diesen unsäglichen Schwanzvergleich mit der Ausführungsgeschwindigkeit von Javascript - als wenn sie damit ein Problem lösen würden, was irgendjemand hätte. Im normalen Einsatzbereich von Javascript auf Websites ist die Ausführungsgeschwindigkeit der Skripte gar kein Flaschenhals, der die Funktionsfähigkeit merkbar beeinflussen würde. Bei Ajax ist es z.B. nicht die Geschwindigkeit des Javascripts, sondern die lange Antwortzeit des Servers, die oft eine schnelle Ausführung behindert. Ich nehme fast an, dass die Hersteller auf die Idee gekommen sind, weil so viele Leute einfach massenhaft Javascript-Frameworks auf ihre Seiten schmeißen, um irgendwelche Probleme zu lösen, die sie mit selbst geschriebenen Skripten viel schlanker meistern könnten.

Das Grundproblem liegt dabei natürlich nicht bei den Programmierern der Frameworks, sondern bei den Leuten, die mit Tutorials irgendwelche Tricks erklären wollen. Diese Tutorials sollten beschreiben, was das Framework eigentlich macht, um z.B. ein Element sanft einzublenden, anstatt einfach nur hinzuwerfen, mit welchen Befehlen man das Framework dazu bringt. So würde man eher dafür sorgen, dass man gewisse Effekte im Framework seiner Wahl nachbilden kann.

Allerdings wissen die Autoren der Tutorials ja oft selbst nicht Bescheid.
Kleiner Exkurs: Mittlerweile ist es ja modern, bei Ajax die Serverantworten nicht mehr als XML-Daten, sondern als JSON-String zu schicken. Ich mag JSON nicht, denn dieser String muss mit der Javascript-Funktion eval() interpretiert werden - und mir ist gar nicht wohl dabei, einen String, der womöglich nur untergeschoben wurde, einfach so als Javascript-Code ausführen zu lassen. In einem Tutorial las ich dann, man solle genau aus diesem Grund ein Framework benutzen, denn da müsse man eval() nicht verwenden. Allerdings benutzen die Frameworks selbst intern diese Funktion. Auch wenn sie vorher sicher versuchen, die Zeichenkette unschädlich zu machen - irgendwann muss darauf ein eval() angewendet werden. Selbst wenn man auf sein Framework vertraut, sollte man sich doch im Klaren sein, wo eventuelle Schwachpunkte liegen könnten. Wenn das nicht gegeben ist, so spielt man als Tutorial-Autor einen Kochlehrer, der selbst nur Fertignahrung aufwärmen kann.

Eventuell eingebundene Bilder und Videos werden im RSS-Feed nicht angezeigt. Bitte besuche die Website, um den Eintrag ggf. vollständig zu sehen und um ihn zu kommentieren.

Virtuelle Hosts mit dem WampServer

Sun, 20 Jun 2010 2:07:18 GMT+1

Bei mehreren voneinander unabhängigen Website-Projekten reicht ein Projektverzeichnis im WampServer nicht aus. Zum Glück kann man virtuelle Hosts einrichten, um dieses Problem zu lösen.

Zunächst sollte man sich die Verzeichnisstruktur überlegen, mit der man seine Projekte organisieren will. Meine Projekte sind in einem Unterordner "projects" des Wampserver-Installationsverzeichnis. Im Grunde genommen sieht die Struktur bei mir so aus:

Im www-Verzeichnis landen die eigentlichen Projektdateien, die Zugriffs- und Fehlerberichte sollen im logs-Verzeichnis gespeichert werden.

Jetzt, wo man die Struktur festgelegt hat, kann man sich um die eigentliche Konfiguration kümmern. Zunächst sorgen wir dafür, dass man die Projekte mit einer leicht zu merkenden Adresse in der Adressleiste des Browsers aufrufen kann. Hierfür editieren wir die hosts-Datei von Windows, zu finden unter C:\{Windows-Verzeichnis}\system32\drivers\etc\hosts. Es dürfte schon ein Eintrag für den localhost drin stehen, wir fügen dahinter ähnliche Codes an. 127.0.0.1 lc.projekt1
127.0.0.1 lc.projekt2Ich habe mir angewöhnt, Adressen wie lc.projektname zu verwenden, aber das ist Geschmackssache. Unsere Einträge in der Datei sagen Windows, dass es bei diesen Adressen die entsprechenden Anfragen an die IP-Adresse 127.0.0.1 senden soll - also an den eigenen Rechner.

Jetzt suchen wir das conf-Verzeichnis des von uns verwendeten Apache-Servers. Wenn der Wampserver unter C:\wamp\ installiert ist und wir Apache Version 2.2.14 benutzen, ist das conf-Verzeichnis unter C:\wamp\bin\apache\Apache2.2.14\conf zu finden. Dort erstellen wir eine Datei virtual-hosts.conf mit folgendem Inhalt.# Use name-based virtual hosting.
NameVirtualHost *:80

ServerName localhost
DocumentRoot "C:/wamp/www"

CustomLog logs/localhost.log combined
ErrorLog logs/localhost.error.log

Wir sind noch nicht fertig damit, aber zur Erklärung: Jeder virtuelle Host muss in dieser Datei verzeichnet werden - und dazu gehört auch der standardmäßige localhost im normalen www-Verzeichnis des WampServers, den wir ja nicht verlieren wollen. Für jedes weitere Projekt müssen wir aber einen weiteren Block in der folgenden Form eintragen:

ServerName lc.projekt1
DocumentRoot "C:/wamp/projects/projekt1/www"

Options Indexes FollowSymLinks
AllowOverride all
# onlineoffline tag - don't remove
Order Allow,Deny
Allow from all

CustomLog "c:/wamp/projects/projekt1/logs/access.log" combined
ErrorLog "c:/wamp/projects/projekt1/logs/error.log"

So weiß der Apache-Server, welche Verzeichnisse er für Anfragen an lc.projekt1 verwenden soll. Die Verzeichnisnamen müssen natürlich entsprechend eurer Installation angepasst werden, falls euer WampServer woanders installiert wurde oder ihr kreativere Namen als "projekt1" benutzt. Achtet auch darauf, in der Datei normale / zu verwenden, nicht die sonst unter Windows üblichen Backslashes.

Damit der Apache diese Datei aber auch einliest, muss man in der httpd.conf am Ende folgendes einfügen:Include conf/virtual-hosts.confWampServer neu starten - und schon sollten eure virtuellen Hosts erreichbar sein.

Eventuell eingebundene Bilder und Videos werden im RSS-Feed nicht angezeigt. Bitte besuche die Website, um den Eintrag ggf. vollständig zu sehen und um ihn zu kommentieren.

Eine Testumgebung mit WampServer

Sun, 20 Jun 2010 1:03:19 GMT+1

Wer dynamische Websites mit PHP und MySQL erstellt, sollte unbedingt auf seinem heimischen Computer eine Webserverumgebung installieren, um seine Skripte nicht auf einem öffentlich erreichbaren Server testen zu müssen.

Unter Windows empfehle ich den kostenlosen WampServer, der (wie der Name schon andeutet) einen Apache-Webserver mit PHP-Unterstützung und einen MySQL-Datenbankserver installiert. Zur Verwaltung der Datenbanken wird auch noch phpMyAdmin mitgeliefert. Der große Vorteil des WampServers ist, dass man verschiedene Versionen von Apache, PHP und MySQL installieren und per Knopfdruck auswählen kann, welche Version gerade laufen soll. So kann man die Zielserverumgebung exakt nachbilden, aber auch testen, ob die eigenen Skripte mit einer neueren Version immer noch funktionieren.
(Vorsicht: Jede MySQL-Version hat ihre eigenen Datenbanken, man muss also die entsprechenden Datenbanken nach einem Versionswechsel importieren, um mit der neuen Datenbankversion auf die Daten zugreifen zu können.) WampServer beachtet auch Unverträglichkeiten - so ist es z.B. nicht möglich, PHP 4 und Apache 2.2 gleichzeitig zu verwenden, da diese beiden Versionen inkompatibel zueinander sind.

Nach der Installation des WampServers findet man im Installationsverzeichnis den Ordner www, in dem man sein Projekt verwirklichen kann. Dieser Ordner ist nach dem Start des WampServers als "localhost" mit dem Browser erreichbar. (Zur Einrichtung von "virtuellen Hosts", um mehrere voneinander getrennte Projekte realisieren zu können, schreibe ich später einen eigenen Eintrag.)

Es ist allerdings möglich, dass nach der Installation einige Dinge nicht so funktionieren, wie sie sollten. So war es mir zum Beispiel nicht möglich, nach Umstellung auf PHP 5.3.1 den MySQL-Server als "localhost" anzusprechen - dies funktionierte nur mit der IP-Adresse 127.0.0.1. Daher musste ich auch die config.inc.php von phpMyAdmin entsprechend abändern, um die Datenbanken vernünftig verwalten zu können.
Ein weiteres Problem zeigt sich, wenn man die Konfiguration so abändern will, dass der Server die Seiten komprimiert ausliefert, um Traffic zu sparen. Hierfür muss man die Apache-Module deflate_module und headers_module aktivieren, ebenso die PHP-Einstellung zlib output compression. Zusätzlich muss in der httpd.conf des Apache-Servers nach dem letzten folgendes eingefügt werden:
AddOutputFilterByType DEFLATE text/html text/plain text/xml
text/css text/javascript application/x-javascript
application/javascript
Achtet darauf, dass zwischen und nur eine einzige Zeile steht. (Danke an Zigpress für diesen Tipp.)

Die Komprimierung funktionierte dann zwar bei meinen Projekten - allerdings konnte ich das nicht von phpMyAdmin sagen. Das Verwaltungstool meldet sich mit einem wirren Zeichensalat, weil dort die Komprimierung wohl zu Problemen führt. Um das Problem zu lösen, habe ich im libraries-Verzeichnis von phpMyAdmin die Datei ob.lib.php folgendermaßen abgeändert, um die Komprimierung komplett zu sabotieren:function PMA_outBufferModeGet()
{
static $mode = null;

if (null !== $mode) {
return $mode;
}

$mode = 0;

return $mode;
}

function PMA_outBufferPre()
{
register_shutdown_function('PMA_outBufferPost');
}

function PMA_outBufferPost()
{
}So wird phpMyAdmin wieder richtig angezeigt.

Im nächsten Beitrag erkläre ich die Einrichtung von virtuellen Hosts.

Eventuell eingebundene Bilder und Videos werden im RSS-Feed nicht angezeigt. Bitte besuche die Website, um den Eintrag ggf. vollständig zu sehen und um ihn zu kommentieren.

Willkommen!

Sat, 19 Jun 2010 15:26:17 GMT+1

Schon wieder ein neuer Blog - aber warum?

In diesem Blog möchte ich den Fokus auf Einträge zum Thema Internet, Webdesign und Webprogrammierung setzen - Dinge, die die meisten Besucher von Klopfers Web nicht interessieren dürften.

Außerdem dient diese Seite auch als Test für einige Programmteile, die später im neu programmierten Klopfers Web ihren Dienst verrichten sollen.

Ich freue mich über jeden Kommentar und hoffe, einige nützliche Tipps für einige von euch abgeben zu können.

Eventuell eingebundene Bilder und Videos werden im RSS-Feed nicht angezeigt. Bitte besuche die Website, um den Eintrag ggf. vollständig zu sehen und um ihn zu kommentieren.