Sicherheit beim Upload

[dedlfix]

Hi!

• fopen(quelle, nur lesend)
• flock(quelle, shared)
• fopen(ziel, nicht überschreibend/überschreibend, je nach Wunsch)
• flock(ziel, exclusive)
• Schleife fread(quelle, Datenblock) -> fwrite(ziel, Datenblock) bis Ende bei Quelle erreicht
• fclose(quelle)
• fclose(ziel)

Ich soll also die ganze Datei durch den Speicher schaufeln? Kannst du mir erklären, wie ich das bei vielen Uploads mache ohne dass das RAM knapp wird?

Üblicherweise nimmt man eine Blockgröße von wenigen KB. Damit ist der RAM-Verbrauch sehr überschaubar.

Insbesondere, da hier zwei Streams aktiv sind die beide Speicher fressen.

Zweimal wenige KB sind auch noch kein Kollapsgrund.

Ich lade jetzt also 4 Dateien hoch, bei der jede 2 GB gross ist. Wie soll das RAM das verkraften?

Sehr gut. Es ist nur die Zeit, die für das Kopieren statt Umbenennen/Verschieben draufgeht. Bei muf() wird sie nur benötigt, wenn das Umbenennen nicht geht, dann kopiert auch muf() die Datei nach obigem Prinzip.

Viel wichtiger ist aber, dass Du dir nochmal durchliest, was ich bisher im Artikel schon geschrieben habe über

• open_basedir
• upload_tmp_dir
• Kontrolle des Dateinamens (keine Pfade!)
• Kontrolle der Dateiendung (möglichst richtigstellen laut MIME-Type)
• keine Scripte zulassen
• am besten nur bestimmte Dateiendungen zulassen aus einer Positivliste
• Scriptausführung im Ablageverzeichnis (wenn es über HTTP/s erreichbar ist) unterbinden

Also soll ich meine Funktion so entwerfen, dass ein Anwender den Hoster vorschreiben muss, wie er seinen Server konfigurieren muss?

Nein, aber es wäre auch im Interesse des Hosters, wenn er die sicherheitsrelevanten Punkte beachten würde. Sie sind nämlich auch bei der Verwendung von muf() relevant, und zwar im gleichen Maße. muf() stellt nur sicher, dass der Dateiname eine hochgeladene Datei ist. Mit beiden Ansätzen kann eine Manipulation nicht ausgeschlossen werden, wenn die hochgeladenen Dateien in öffentlichen Verzeichnissen rumliegen oder irgendwie anders für andere schreibbar sind.

Erklärst du mir auch, wie das bei Massenhostern gehen soll? Hast du für Strato, 1&1 usw. nen Ansprechpartner, der dafür zuständig ist?

Bei den Webhosting-Angeboten von 1&1 ist mir bisher nur die CGI-Variante begegnet und dafür kann man eine eigene php.ini aufsetzen. Zumindest bei 1&1 kann man sich selbst darum kümmern.

Ansonsten ist dieser Typ insofern fürn Arsch, weil die relevanten Anwender gegen null tendieren.

Das finde ich nicht.

Bei Shared Hosting:
Bei PHP als Modul ist ein eigenes upload_tmp_dir für jeden virtual Host mMn die wichtigste Sicherheitsmaßnahme, die aber nur dann greift, wenn open_basedir auch vernünftig eingestellt wird.
Und wie hat mein Script darauf Einfluss? Wäre schon schön, wenn deine Tips auch umsetzbar sind.

Prinzipbedingt hat ein Script keinen Einfluss darauf. Das war weder gefordert, noch hat Tom versprochen, dieses Problem durch seine Kopiermethode zu lösen. Es ist aber nicht generell nicht umsetzbar.

Bei PHP als CGI/Fast-CGI gibt es noch andere Möglichkeiten, da da jeder Virtual-Host sowieso unter einem eigenen User läuft und bei vernünftigen Einrichtung des Temporärverzeichnisses sowieso nur dieser User zugreifen kann.

Laufen sollte. Wenn man aber das langsamere CGI statt Modul verwendet, dann sollte man wenigstens den Vorteil der Sicherheit durch eigenen User mitnehmen.

Und wie kann das Script prüfen ob die  Einrichtung vernünftig ist? Hast du dafür auch nen Ansatz wie man per Script den Server prüfen kann?

Man kan im Script die Konfigurationswerte auslesen. Allerdings ist es sehr aufwendig, einem Script beizubringen, gute von schlechten Werten zu unterscheiden. Doch wann braucht man das im Script? Sowas wäre eher für Setup-Scripte interessant und sinnvoll. Man kann sich aber auch vorher informieren, ob die Werte bereits ordentlich konfiguriert sind (oder sie passend selbst konfigurieren, wenn man daran nicht gehindert wird).

Und ja, mein Posting ist provokativ, verklag mich :P

Leider hat es auch wenig argumentative Substanz. Du hättest lieber die bereits ausgetauschten Argmente aufmerksam lesen sollen. Vieles davon wurde bereits geklärt und ist nicht mehr Gegenstand der Überzeugungsarbeit Tom gegenüber.

Aus deinem anderen Posting:

Und selbst wenn ich das Überschreiben verhindern will, wird es mit muf() nur ein Zweizeiler, denn ein file_exists ist doch ein klein wenig weniger Code als die Lösung von dir,die im Übrigen das gleiche Problem bietet, was du anprangerst, da in der Zeit zwischen fopen und flock die Datei von einem anderen Script manipuliert, gelöscht, verschoben, geändert oder sonst was werden kann.

Manipulation soll und kann damit nicht verhindert werden, dafür sind die Dateirechte und Verzeichniskonfigurationen das Mittel der Wahl. Toms Vorschlag kann wenigstens verhindern, dass zwischen file_exists() und dem Verschieben/Kopieren ein anderer Prozess eine Datei gleichen Namens anlegt, denn fopen($mode: x) offnet die Datei nur, wenn sie nicht existiert. An dieser Stelle kann abgebrochen werden. Dass diese Funktionalität in muf() eingebaut wird, sind bereits Bestrebungen im Gange.

Somit löst dein Ansatz in keinster Weise dein Problem (was IMO keins ist) sondern vergrössert lediglich den Ressourcenverbrauch und die Codelänge, dafür verlängert sich auch die Verarbeitungsgeschwindigkeit.
Somit hat deine Lösung als _keine_ Vorteile aber _sehr viele gravierende_ Nachteile.

Sie hat (noch) den Vorteil, dass sie nicht blind überschreibt. Die muf()-Lösung wird auch zum Mehralszweizeiler, wenn man das Überschreiben ordentlich verhindern will (siehe https://forum.selfhtml.org/?t=206726&m=1404169 ff.). Ansonsten sind die Nachteile eigentlich nur der längere Code und die Manipulierbarkeit der Einträge in $_FILES.

Lo!