Hallo Felix,
Auch ich hatte schon länger mit der Idee gespielt, diesen Artikel irgendwann einmal aufzusplitten, habe aber gerade ein viel zu großes Projekt an der Backe, um mich dem Wiki überhaupt zu widmen.
Dafür gibst du mir Rückmeldung zu meinen Überlegungen, vielen Dank dafür!
- Man kann nur Bilder (JPEG, PNG und GIF) hochladen, diese werden auch mit
mime_content_type
überprüft (getimagesize
bringt keinen Mehrwert, es wird explizit im Manual davon abgeraten, diese Funktion zur Überprüfung von Bildern zu verwenden).Wenn man die FileInfo-Erweiterung nicht hat, wäre damit aber ein besserer Schutz gegeben, als überhaupt keiner. Aber ich habe natürlich keine Ahnung, wer auf diese Erweiterung heute verzichten muss. Eignet sich
getimagesize
nicht wenigstens als Fallback?
Ich denke nicht, die PHP-Entwickler schreiben explizit, dass getimagesize
ein gültiges Bild erwartet, um zuverlässig sinnvolle Werte zu liefern: „This function expects filename to be a valid image file. If a non-image file is supplied, it may be incorrectly detected as an image and the function will return successfully, but the array may contain nonsensical values.“
mime_content_type
basiert (mittlerweile?) sogar auf FileInfo, nachdem es in der Doku eine Zeit lang als deprecated markiert war, es fehlt aber in keiner unterstützten PHP-Version, zumindest wenn man es nicht explizit deaktiviert. In der Doku wird es sogar als FileInfo zugehörig kategorisiert. Ich denke, dass ein Vorhandensein vorausgesetzt werden kann. Wenn nicht, funktioniert das Skript halt einfach nicht.
SVGs spare ich erst einmal aus, weil die zu riskant sind. Dafür gibt es validierende Libraries, nur erhöht das wieder die Komplexität des Ganzen.
Warum nicht das Thema "Überprüfung auf gültige Bilddatei" in ein eigenes Unterkapitel auslagern? Dann kann man darauf verlinken und dort ausführlicher die Thematik des MIME-Sniffing behandeln.
Ich denke, dass das auf einer Datenbank mit Magischen Zahlen basierende mime_content_type
erst einmal alles abdeckt, was man auf dem Gebiet Bilder brauchen könnte – schwierig würde es aber hingegen bei einem XML-basierten Format einer bestimmten Applikation, wenn man nicht text/xml, sondern application/vnd.scribus[1] erhalten möchte, muss man tätig werden und auf die Dateiendung oder die Dateistruktur selbst schauen. Ich denke, dass das für den Dateiupload mit seinen gut unterscheidbaren Dateitypen an sich erst einmal keine Rolle spielt, man aber die Komplexität des Themas an anderer Stelle im Wiki tatsächlich anreißen sollte und auch im entsprechenden Glossar-Eintrag darauf verweist.
Das Thema ist dermaßen komplex und es gibt keine für alle Dateitypen anwendbares 1:1-Kochrezept (Audio/Video-Containerformate mit verschiedenen Codecs sind auch ein Thema für sich), das ist mir mittlerweile auch klar geworden, nachdem ich mich dumm und dämlich gesucht habe, was denn nun der Königsweg ist. Man kann höchstens als erste Instanz mime_content_type bemühen, muss die Fälle abfangen, in denen das nicht ausreicht und auf Dateiendung oder bestimmte Eigenschaften achten. Immer verbunden mit einer Risikoanalyse: Wenn diese Datei falsch eingestuft wird, welche Gefahr kann im gegebenen Kontext davon ausgehen?
Weil das kompliziert ist, auch die Beschränkung auf Bilder.
Ich glaube, das dürfte der Grundstein für einen eigenen Artikel zum Thema „MIME-Sniffing“ werden 🙃. Ich behalte es im Hinterkopf, die grundsätzlichen Überlegungen stehen hier ja schon.
Denn wenn man schon externe Libraries benötigt, dann aber gleich richtig zuschlagen und zeigen, dass man das tatsächlich tun sollte und wie am besten! Wenn das dann ein weiteres Zusatzkapitel Composer bedeutet, dann ist das auch nicht grundverkehrt.
Hehe, das gibt es sogar schon als eigenen Artikel 😀.
- Dateinamen werden zufällig erzeugt, man spart sich die ganzen Probleme mit Case-sensitivity, Zeichen oder ganzen Dateinamen mit spezieller Bedeutung.
Wie willst Du die Datenhaltung lösen, die den ursprünglich mitgelieferten Dateinamen mit dem zufällig erzeugten in Verbindung bringt?
In meinem ursprünglichen Ansatz gar nicht, hier im Forum wird er ja auch nicht gespeichert oder zumindest nicht verwendet, deshalb kann es je nach Anwendungsfall entfallen. Es ist bisher lediglich als mögliche Erweiterung vorgeschlagen (ohne vorher groß darüber nachzudenken, habe ich öfter einen Abschnitt mit möglichen Erweiterungen und Hinweisen dazu in meinen Tutorials integriert, ich halte das für didaktisch sinnvoll). Zum Thema Datenspeicherung habe ich bereits etwas geschrieben (vor ein paar Jahren kamen mal viele Fragen, wie man denn Daten einfach und persistent speichern kann und welche Vor- und Nachteile eine Lösung jeweils hat) und den Artikel Datenbank mit PHP habe ich auch auf der Agenda. Die drei Artikel können dann jeweils aufeinander verweisen.
Aktuell tendiere ich auch dazu, kein vollständiges Skript im Wiki vorzustellen, weil es eh jeder für sich anpassen muss und es auf GitHub bei SELFHTML auch besser aufgehoben wäre (Danke @Matthias Apsel).
Gruß
Julius
$ file -bi ScribusDokument.sla
lieferttext/xml; charset=us-ascii
, was ungenau, aber nicht gänzlich falsch ist, da es ein XML-Dokument ohne über ASCII hinausgehende Zeichen ist. ↩︎