Netz - Rettung - Recht

Alle Webanwendungen. die - wie Serendipity - den Upload von Dateien ermöglichen, müssen verhindern, dass statt Bildern und Videos aktive Inhalte hochgeladen werden, bspw. PHP-Scripts. Denn da die Bilder vom Browser angezeigt werden sollen, liegen die Uploads in einem von außen aus dem Web erreichbaren Verzeichnis, und wenn es jemandem gelingt, dort ein PHP-Script zu platzieren, dann kann er auf dem Webserver eigenen Code ausführen. Dafür braucht es natürlich zunächst einmal Upload-Rechte in Serendipity, aber es soll ja dennoch nicht jeder, der dort Bilder hochladen darf, auch Code ausführen dürfen. Nachdem Webserver sich bei der Frage, was sie mit abgerufenen Dateien tun sollen, meistens an der Dateiendung orientieren, achtet Serendipity darauf, dass keine Dateien mit “verbotenen” Endungen hochgeladen werden.

Es stellte sich aber heraus, dass es - nur auf Windows-Webservern! - möglich war, eine Datei ohne Endung hochzuladen (bspw. datei) und sie dann in datei.php umzubenennen. Unter Linux funktionierte das nicht; es kam dann datei.php. heraus, und das ist nicht ausführbar. Windows scheint aber diesen Punkt mit “leerer” Endung wegfallen zu lassen. Außerdem muss man natürlich sagen, dass das Anhängen eines Punktes an den Dateinamen kaum der richtige Weg zu sein scheint, mit diesem Problem umzugehen - zumal sich in dem Bugreport ein weiteres Problem zeigte: beim nächsten Aufruf der Mediendatenbank “verschwand” diese umbenannte Datei (jedenfalls aus der Datenbank - auf der Platte war sie noch da).

Der naheliegende Bugfix - Punkte am Ende von Dateinamen verbieten bzw. entfernen - erwies sich daher nicht als ausreichend. Das “Anhängen” eines Punktes an Dateien ohne Endung beim Umbenennen ist nicht nur falsch - es führte auch dazu, dass die in der Datenbank gespeicherte Datei (datei) scheinbar auf der Platte nicht mehr vorhanden war (dort hieß sie ja datei.) und daher aus der Datenbank gelöscht wurde. Nach Behebung dieses Fehlers war dann klar, dass beim Umbenennen von Dateien der Check auf “verbotene” Namen fehlte, der beim Upload durchgeführt wurde. Danach aber war nicht nur das Loch auf Windows-Systemen gestopft, sondern auch die Mediendatenbank wieder ein wenig stabiler.

Und weil es ohnehin ein Release geben musste, haben wir noch einen weiteren Fehler behoben (überlange Worte in Kommentaren wurden in der “Dashboard”-Übersicht des Admin-Backends nicht umgebrochen) und die Pluginverwaltung um die Angabe der Quelle der dort gezeigten Plugins ergänzt: ist das jeweilige Plugin bei Serendipity dabei, kann es von Spartacus installiert werden oder existiert es nur lokal auf der Platte, erhält also auch keine Updates? Mit dieser Änderung war es dann auch möglich, den Link zu weiteren Informationen auf den Spartacus-Webseiten für alle dort vorhandenen Plugins anzuzeigen, auch dann, wenn diese bereits installiert sind - das ging vorher nicht.

Insofern gilt: unter Linux ist das Update auf 2.3.4 nicht zwingend, aber es behebt immerhin komische Seiteneffekte in der Mediendatenbank und fügt Plugin-Quellen hinzu.