Potentielle Gefahren beim Datei Upload

[Gunther]

Hallo werte Selfgemeinde!

Ich habe nun das erste Mal einen Datei Upload bei einem kleinen Mini-Projekt. Im Kern habe ich mich an Dateiupload und Überprüfung mit PHP orientiert.

Nun geht es mir aber noch um die Frage der größtmöglichen Sicherheit und die potentiellen Gefahren.

Eigentlich sind die Dateien, die upgeloadet werden sollen vom Typ 'lua' (es handelt sich also um Lua Script Dateien). Da der MIME-Type unbekannt ist, werden diese als "application/octet-stream" übertragen.

Ich habe mich daher aktuell erstmal für die Variante entschieden, nur Dateien vom Typ "text/plain" zuzulassen. Allerdings muss der User dann vorher seine .lua Datei in eine .txt Datei umbenennen/umkopieren.

Könnte ich auch gefahrlos den direkten Upload der Lua Dateien zulassen?
Was müsste ich dann alles prüfen, bzw. beachten?
Welche potentiellen Gefahren stecken in der Sache?

Für eure Hilfe meinen besten Dank im Voraus!

Gruß Gunther

[Vinzenz Mai]

Hallo Gunther,

Eigentlich sind die Dateien, die upgeloadet werden sollen vom Typ 'lua' (es handelt sich also um Lua Script Dateien). Da der MIME-Type unbekannt ist, werden diese als "application/octet-stream" übertragen.

Ich habe mich daher aktuell erstmal für die Variante entschieden, nur Dateien vom Typ "text/plain" zuzulassen. Allerdings muss der User dann vorher seine .lua Datei in eine .txt Datei umbenennen/umkopieren.

Könnte ich auch gefahrlos den direkten Upload der Lua Dateien zulassen?

Wie werden diese Dateien "weiterverarbeitet", d.h. was wird mit diesen Dateien gemacht? Daraus resultieren erst die möglichen Gefahren.

Freundliche Grüße

Vinzenz

[Beat]

Eigentlich sind die Dateien, die upgeloadet werden sollen vom Typ 'lua' (es handelt sich also um Lua Script Dateien). Da der MIME-Type unbekannt ist, werden diese als "application/octet-stream" übertragen.

Ich habe mich daher aktuell erstmal für die Variante entschieden, nur Dateien vom Typ "text/plain" zuzulassen. Allerdings muss der User dann vorher seine .lua Datei in eine .txt Datei umbenennen/umkopieren.

Könnte ich auch gefahrlos den direkten Upload der Lua Dateien zulassen?

Wie werden diese Dateien "weiterverarbeitet", d.h. was wird mit diesen Dateien gemacht? Daraus resultieren erst die möglichen Gefahren.

Nicht ganz einverstanden. Das Wort "weiterverarbeiten" kann falsch aufgefasst werden.
Akzeptiert er einen Upload eines php Scriptes,
und ich erfahre den Pfad/Namen,
kann ich das Script ausführen,
sofern mich nicht das Pech anderer Beschränkungen verfolgt.

Es ist also schon wesentlich, dass bestimmte Dateitypen gar nicht beim Upload akzeptiert und gespeichert werden.

Wesentlich ist, was der Server bei Request eines bestimmten Dateityps (/in einem bestimmten Pfad) tun würde.

mfg Beat

[Vinzenz Mai]

Hallo,

Wie werden diese Dateien "weiterverarbeitet", d.h. was wird mit diesen Dateien gemacht? Daraus resultieren erst die möglichen Gefahren.

Nicht ganz einverstanden. Das Wort "weiterverarbeiten" kann falsch aufgefasst werden.
Akzeptiert er einen Upload eines php Scriptes,
und ich erfahre den Pfad/Namen,

das ist Weiterverarbeitung.

kann ich das Script ausführen,

Nein, in den meisten Fällen nicht. Das ist Weiterverarbeitung.
Was nutzt Dir die Angabe

/pfad/zu/verzeichnis/das/nicht/über/http/erreichbar/ist

Nichts. Keine Ausführung möglich. Keine Gefahr.

Deswegen will ich wissen, was mit den Dateien gemacht wird. Werden sie nur irgendwo archiviert, dann gibt es überhaupt keine Gefahr.

Es ist also schon wesentlich, dass bestimmte Dateitypen gar nicht beim Upload akzeptiert und gespeichert werden.

Kann man machen. Wird man machen wollen. Ist nicht unbedingt notwendig. Könnte unerwünscht sein, auch dafür gibt es Anwendungsszenarien. Hier könnte man Nicht-Klartext-Dateien aussondern. Möglicherweise gibt es einen LUA-Skript-Validator. Damit könnte man alles, was kein LUA-Skript ist, verwerfen - was in jedem Fall sinnvoll wäre.

Freundliche Grüße

Vinzenz

[Gunther]

Hallo Vinzenz und Beat!

Wie werden diese Dateien "weiterverarbeitet", d.h. was wird mit diesen Dateien gemacht? Daraus resultieren erst die möglichen Gefahren.

Bis jetzt verschiebe ich die Datei per move_uploaded_file() in ein *Unterverzeichnis meines Projekts.

Wenn das erfolgreich war, lese ich die Datei mittels fgetss() in einen String ein.

Aus diesem "picke" ich mir per diverser preg_match/preg_replace/etc. Aktionen meine benötigten Informationen raus, verarbeite diese und speichere diese in mehreren Cookies - fertig.

Gruß Gunther

*Welche Rechte setze ich denn notwendiger-/ idealerweise für das Uploadverzeichnis?

[Beat]

Wie werden diese Dateien "weiterverarbeitet", d.h. was wird mit diesen Dateien gemacht? Daraus resultieren erst die möglichen Gefahren.

Bis jetzt verschiebe ich die Datei per move_uploaded_file() in ein *Unterverzeichnis meines Projekts.

das heisst, es ist via http erreichbar?
Das ist eventuell schlecht.
Entweder ausserhalb des docroot oder mit .htaccess schützen.
Andernfalls müsstest du zu diesem Zeitpunkt absolut sicher sein, dass jeder Request in dieses directorie nur die Datei ausliefern wird, oder sich nur auslieferbare Dokumente dort befinden.

Wenn das erfolgreich war, lese ich die Datei mittels fgetss() in einen String ein.
Aus diesem "picke" ich mir per diverser preg_match/preg_replace/etc. Aktionen meine benötigten Informationen raus, verarbeite diese und speichere diese in mehreren Cookies - fertig.

Der Sinn des letzteren weiss ich jetzt nicht.
Das hat ja höchstens damit zu tun, dass der, der die Datei hochlud, nun ein Folgerecht zu dieser Datei gewinnt.

*Welche Rechte setze ich denn notwendiger-/ idealerweise für das Uploadverzeichnis?

Solche die ausreichen, dass dein Script in diesem Direktory Dateien anlegen und löschen darf. Das ist 775 oder 757 je nach dem...

Ich arbeite nicht mit PHP, kenne also dessen Besonderheiten nicht.

mfg Beat

[Gunther]

Hi Beat!

Bis jetzt verschiebe ich die Datei per move_uploaded_file() in ein *Unterverzeichnis meines Projekts.

das heisst, es ist via http erreichbar?

ja

Das ist eventuell schlecht.
Entweder ausserhalb des docroot oder mit .htaccess schützen.
Andernfalls müsstest du zu diesem Zeitpunkt absolut sicher sein, dass jeder Request in dieses directorie nur die Datei ausliefern wird, oder sich nur auslieferbare Dokumente dort befinden.

Also würde bspw. eine .htaccess mit folgendem Inhalt

<FilesMatch ".*$" >
  ForceType application/octet-stream
  </FilesMatch>

ausreichen (es befinden sich nur die upgeloadeten Dateien in diesem Verzeichnis)?

Gruß Gunther

[Beat]

Andernfalls müsstest du zu diesem Zeitpunkt absolut sicher sein, dass jeder Request in dieses directorie nur die Datei ausliefern wird, oder sich nur auslieferbare Dokumente dort befinden.

Also würde bspw. eine .htaccess mit folgendem Inhalt

<FilesMatch ".*$" >
  ForceType application/octet-stream
  </FilesMatch>
ausreichen (es befinden sich nur die upgeloadeten Dateien in diesem Verzeichnis)?

FilesMatch ".*$"
matcht "ksdlf", "hdfh.", "dklk..", "fkjkdj..."

Wohl nicht, was du beabsichtigst.

Wenn du willst, dass schlicht alles in diesem Ordner via Browser Dialog zum Speichern angeboten wird, dann verwende ForceType generell, und nicht in einer FilesMatch Direktive.

mfg Beat

[Gunther]

Hi Beat!

FilesMatch ".*$"
matcht "ksdlf", "hdfh.", "dklk..", "fkjkdj..."

Wohl nicht, was du beabsichtigst.

Wenn du willst, dass schlicht alles in diesem Ordner via Browser Dialog zum Speichern angeboten wird, dann verwende ForceType generell, und nicht in einer FilesMatch Direktive.

Ja, sorry. Das kommt davon, wenn man zu schludrig mit Copy & Paste arbeitet ;-). Sollte natürlich FilesMatch ".*" heißen, was ja identisch zu deinem Vorschlag ist.

Was mich aber noch interessieren würde, ist folgendes:
Welche allgemeinen "Gefahren" bestehen denn, wenn ich einem User einen File Upload ermögliche?
Er könnte eine PHP Datei, oder sonst irgendeine ausführbare Datei hochladen, die, wenn sie per HTTP erreichbar ist, dann ggf. "Schaden" anrichtet. Richtig? Sonst noch irgendwelche potientielle Gefahrenquellen?

Wie kann man sich (am besten/ sichersten) vor diesen Gefahrenquellen schützen?

• Datei in ein Verzeichnis außerhalb des doc root verschieben, bzw. in eines, welches nicht über HTTP erreichbar ist
• Verzeichnis zugangsschützen mittels .htaccess
• Dateien im Verzeichnis nur zum Download ausliefern
  mehr?

Und wie sicher ist die Methode mit fgetss()? Laut Manual "Diese Funktion ist identisch mit der Funktion fgets(), außer dass fgetss() versucht, vorhandene HTML und PHP-Tags aus dem gelesenen Text zu entfernen." versucht die Funktion ja, evt. vorhandene Tags zu entfernen. Reicht das nicht aus?

Ich "bearbeite" die hochgeladene Datei ja, indem ich mir nur die relevanten Teile heraussuche. Wenn ich anschließend nur diese in dem File speichern würde, müsste das doch auch einen sicheren Schutz ergeben, oder?

Gruß Gunther

[Beat]

Was mich aber noch interessieren würde, ist folgendes:
Welche allgemeinen "Gefahren" bestehen denn, wenn ich einem User einen File Upload ermögliche?

Ganz allgemein: Sofern du keine andere Beschränkung einrichtest, kann X ein File hochladen und Y kann es herunterladen, als Oktett Stream.
Dadurch ist dein Server ein offenes Filesharing System.
Da bist du auch kontrollpflichtig, soviel ich weiss. Wenn eine Bastelanleitung zum Bombenbau über deinen Server vertrieben wird, kann das in bestimmten Ländern unangenehme Folgen haben.

Er könnte eine PHP Datei, oder sonst irgendeine ausführbare Datei hochladen, die, wenn sie per HTTP erreichbar ist, dann ggf. "Schaden" anrichtet. Richtig?

Nur dann, wenn eine php Datei in diesem Directory geparst wird.
Ich bin mir nicht sicher inwiefern ForceType OctettStream dies generell verhindert.

Sonst noch irgendwelche potientielle Gefahrenquellen?

Was, wenn ich eine .htaccess Datei hochlade?

Wie kann man sich (am besten/ sichersten) vor diesen Gefahrenquellen schützen?

Indem du das Verhalten und die Einstellungen deines Servers kennen lernst.

• Datei in ein Verzeichnis außerhalb des doc root verschieben, bzw. in eines, welches nicht über HTTP erreichbar ist

Das hat zur Folge, dass du zum Zugriff auf diese Dateien dann einen spezielles (php) Skript gebrauchst, welches dann für jeden Filetyp den angemessenen Content-Type und das richtige Transfer-Encoding sendet.

• Verzeichnis zugangsschützen mittels .htaccess

Ein Zugangsschutz ist kein Missbrauchsschutz.
Aber du könntest alles sperren in einem Verzeichnis, ausser einem Script, dessen Aufgabe es ist, die Daten kontrolliert (wie im obigen Fall) auszugeben.

• Dateien im Verzeichnis nur zum Download ausliefern
  mehr?

Wie gesagt. Du darfst nicht rigend eine Datei unter einem vorgegebenen Dateinamen einfach speichern, sonst lade ich dir eine .htirgendwas drauf.

Und wie sicher ist die Methode mit fgetss()? Laut Manual "Diese Funktion ist identisch mit der Funktion fgets(), außer dass fgetss() versucht, vorhandene HTML und PHP-Tags aus dem gelesenen Text zu entfernen." versucht die Funktion ja, evt. vorhandene Tags zu entfernen. Reicht das nicht aus?

Du kannst natürlich sagen: eine php Datei ohne php sensible tags sein ungefährlich. Aber ich bin mit bezüglich PHPs Lückenhaftigkeit schon beinahe sicher, dass man nicht darauf wetten sollte.

Was machst du damit wenn ein lua Dokument dummerweise etwas enthält, was wie php aussieht?

Ich "bearbeite" die hochgeladene Datei ja, indem ich mir nur die relevanten Teile heraussuche.

In dem Sinne brauchst du ja gar keinen Dateiupload, sondern ein Formular würde es ebenso tun.
Wenn ich der Autor eines Dokumenttypstandards wäre, würde ich mir ja so ein filtern zutrauen. Aber auf irgend welche Filetypen?

Wenn ich anschließend nur diese in dem File speichern würde, müsste das doch auch einen sicheren Schutz ergeben, oder?

Du kannst ja Dateien verzipppacken. Dann sind sie per se nur Downloadfiles. Aber damit ist dann auf dem Server eine direkte Verwendung ausgeschlossen.

mfg Beat

[Sven Rautenberg]

Moin!

Eigentlich sind die Dateien, die upgeloadet werden sollen vom Typ 'lua' (es handelt sich also um Lua Script Dateien). Da der MIME-Type unbekannt ist, werden diese als "application/octet-stream" übertragen.

Ich habe mich daher aktuell erstmal für die Variante entschieden, nur Dateien vom Typ "text/plain" zuzulassen. Allerdings muss der User dann vorher seine .lua Datei in eine .txt Datei umbenennen/umkopieren.

Diese Prüfung des Mimetyps ist unsinnig. Die Angabe stammt vom hochladenden HTTP-Client - das kann ein handelsüblicher Browser sein, aber genausogut ein manipulierender Angreifer, der deine Prüfung auf korrekten Mimetyp einfach umgeht, indem er den gewünschten Typ sendet, aber trotzdem "böse Dateiinhalte".

Könnte ich auch gefahrlos den direkten Upload der Lua Dateien zulassen?

Vermutlich ja.

Was müsste ich dann alles prüfen, bzw. beachten?

Dateien hochladen zu lassen ist noch nicht wirklich gefährlich. Spannend wird es, wenn die Dateien danach dann genutzt werden sollen.

Folgende Gefahrenmomente fallen mir da spontan ein:

1. Die Datei wird wieder zum Download angeboten. Dann sind alle Besucher der Website gefährdet, die diese Datei wieder herunterladen. Das einfachste vorstellbare Szenario: Die Datei ist ausführbar und enthält ein Schadprogramm. Fiesere Dinge wären Sachen wie "eine manipulierte Bilddatei nutzt eine Lücke im Browser aus". Aber da ja alle Internetsurfer regelmäßig ihre Browser aktualisieren, kann sowas natürlich nie passieren... ;)

2. Bei Punkt 1 kann man natürlich noch sagen: Soll jeder selbst aufpassen! Interessant wird's allerdings, wenn hochgeladene Dateien auf dem eigenen Server genutzt werden sollen. Im Prinzip fällt das unter das glorreiche und umfassende Thema "Eingabevalidierung", denn natürlich sind auch Daten, die aus hochgeladenen Dateien bezogen werden, Benutzereingabe im Sinne des Eingabevalidierungsgesetzes (EinValG). Jede weiterverarbeitende Instanz muß also damit rechnen, dass sie vollkommene Schwachsinnsdaten vorgesetzt bekommt, und muß diese selbstverständlich tolerieren und zurückweisen, ohne abzustürzen oder gar schädlichen Code auszuführen.

3. Ein letzter Punkt trifft eher auf "dumme Zufälle kann man nie ausschließen" zu: Hochgeladene Dateien stehen nach der Eingangsverarbeitung genauso auf der Festplatte, wie alle anderen Dateien. Gefährlich werden kann das auch dann, wenn eine Datei zwar harmlos heißt, aber tatsächlich die Bytes eines ausführbaren Programms enthält. Welche Sicherungsmechanismen existieren, um zu verhindern, dass die Datei tatsächlich unabsichtlich als Programm gestartet wird? Unter Windows hängt die Startbarkeit vom Dateinamen ab (wobei es leider viel mehr Extensions gibt, die als startbar angesehen werden, als nur EXE, COM und BAT). Unter Linux ist der Name irrelevant, hier hängt alles am X-Bit der Dateirechte - und zwar getrennt für User, Gruppe und Welt.

Welche potentiellen Gefahren stecken in der Sache?

Es kommt sehr darauf an, was du mit den hochgeladenen Dateien machst, und wie exakt du die Dateien prüfst, bevor du das machst.

Quellcodedateien einer Programmiersprache hochzuladen ist erstmal eher harmlos - sofern du nicht beabsichtigst, den Code zu kompilieren und auszuführen. Wobei Lua da eventuell abschottbar in einer eigenen VM laufen könnte und von daher Schadoperationen keine oder nur sehr begrenzte Auswirkungen haben könnten - das wäre dann aber ein Spezialfall, der nicht zu verallgemeinern ist.

- Sven Rautenberg

[Gunther]

Moin Sven!

Diese Prüfung des Mimetyps ist unsinnig. Die Angabe stammt vom hochladenden HTTP-Client - das kann ein handelsüblicher Browser sein, aber genausogut ein manipulierender Angreifer, der deine Prüfung auf korrekten Mimetyp einfach umgeht, indem er den gewünschten Typ sendet, aber trotzdem "böse Dateiinhalte".

Stimmt. Ich überprüfe nun die Dateiendung der hochgeladenen Datei. Ist diese ~= .lua wird die Verarbeitung abgebrochen. Zusätzlich habe ich in meine .htaccess ein
  <Files *.lua>
    Order allow,deny
    Deny from all
  </Files>
eingetragen. Ist das jetzt ein ausreichender Schutz?

Dateien hochladen zu lassen ist noch nicht wirklich gefährlich. Spannend wird es, wenn die Dateien danach dann genutzt werden sollen.

Ja, das sollte bei allen Vorkehrungen gegen möglichen Missbrauch noch möglich sein. ;-)

Welche potentiellen Gefahren stecken in der Sache?

Es kommt sehr darauf an, was du mit den hochgeladenen Dateien machst, und wie exakt du die Dateien prüfst, bevor du das machst.

Na ja, wie schon erwähnt "durchsuche" ich die Datei, die ich zuvor in einen String eingelesen habe, ob die erforderlichen Inhalte vorhanden sind. Wenn ja, "picke" ich diese heraus, verarbeite sie noch ein wenig, um sie dann zu speichern (Cookies) und den Benutzer auf eine andere Seite (Ausgangsseite) weiterzuleiten, die die Informationen aus den Cookies entsprechend verarbeitet. (Ja, Cookies sind "zwingend" erforderlich für die Benutzung der Website!)

Quellcodedateien einer Programmiersprache hochzuladen ist erstmal eher harmlos - sofern du nicht beabsichtigst, den Code zu kompilieren und auszuführen.

Nein, das habe ich nicht vor.

Im übrigen vielen Dank für deine Auflistung möglicher Gefahrenquellen. Denn um eine möglichst sichere Anwendung zu stricken, muss man ja erstmal um diese wissen, um wirkungsvolle und umfassende "Gegenmaßnahmen" treffen zu können. Und genau da hapert es bei mir (u.a.) - auf die meisten Böswilligkeiten so mancher User käme ich nie im Leben.

Dank & Gruß
Gunther

[Sven Rautenberg]

Moin!

Diese Prüfung des Mimetyps ist unsinnig. Die Angabe stammt vom hochladenden HTTP-Client - das kann ein handelsüblicher Browser sein, aber genausogut ein manipulierender Angreifer, der deine Prüfung auf korrekten Mimetyp einfach umgeht, indem er den gewünschten Typ sendet, aber trotzdem "böse Dateiinhalte".
Stimmt. Ich überprüfe nun die Dateiendung der hochgeladenen Datei. Ist diese ~= .lua wird die Verarbeitung abgebrochen.

Naja, ich kann weder der Prüfung des Mimetyps noch der Dateiendung irgendetwas relevantes abgewinnen. Die Dateiendung explizit nicht als ".lua" haben zu wollen erscheint mir widersinnig, wenn man Lua-Skripte behandelt. (Oder meint "~=" etwa "ungleich"...)

Zusätzlich habe ich in meine .htaccess ein
  <Files *.lua>
    Order allow,deny
    Deny from all
  </Files>
eingetragen. Ist das jetzt ein ausreichender Schutz?

Das wurde andernorts schon mal angesprochen: Lagere diese Dateien außerhalb des vom Web aus erreichbaren Bereichs. Diese Pauschalbehandlung "nichts, was hochgeladen wurde, kann runtergeladen werden", ohne dass explizit irgendwelche Prüfungen und Sonderfälle beachtet werden, hilft ganz gut gegen übersehene Lückenbildung.

Generell ist für die Sicherheit die grundsätzliche Einstellung (sprich: Geisteshaltung) des Programmierers wichtig. Wenn der eher paranoid ist und kritische Prüfungen kombiniert mit pauschalen negativen Vorurteilen über die möglichen auftretenden Inhalte, führt das zu einer pessimistischen Behandlung der von außen eintreffenden Dateien, von denen nur die besten, standardkonformsten "überleben".

Das Gegenteil wäre das eher blauäugige "wird schon nichts passieren" - und nur, wenn mal was passiert ist, wird dieses Problem dann explizit gefixt, bis das nächste Problem auftritt.

Da hast du ja, wie dieser Thread beweist, zumindest schon mal das Bewußtsein entwickelt, dass Sicherheit nicht blöd ist und nur für Idioten da. :)

Im übrigen vielen Dank für deine Auflistung möglicher Gefahrenquellen. Denn um eine möglichst sichere Anwendung zu stricken, muss man ja erstmal um diese wissen, um wirkungsvolle und umfassende "Gegenmaßnahmen" treffen zu können. Und genau da hapert es bei mir (u.a.) - auf die meisten Böswilligkeiten so mancher User käme ich nie im Leben.

Die Liste ist natürlich nicht vollständig - kann sie nie sein.

Wie du selbst entdeckt hast, wäre es beispielsweise blöd, sich ".php"-Dateien auf den Webspace hochladen zu lassen, die man dann per HTTP abrufen und dabei von PHP-Interpreter ausführen lassen kann.

Sowas würde dir ja aber nie passieren, wenn du pauschal hochgeladene Dateien nie direkt zum Download anbietest, sondern sie immer nur per Skript zurücklieferst, welches die Dateiinhalte nicht ausführt, sondern als Bytedatenstrom mit "application/octet-stream" sendet.

Bilder könnte man, falls eine entsprechende Formatprüfung positiv ausfällt, ja auch mit entsprechendem Bild-Mimetyp schicken.

Deshalb: Pauschal erstmal Dinge zu verbieten, und dann geprüfte Einzelfälle wieder aufzuweichen, ist die weitaus bessere Strategie, als Dinge gar nicht zu beachten, und nur für einzelne Fälle Verbote zu installieren.

- Sven Rautenberg

[Gunther]

Hallo Sven!

Stimmt. Ich überprüfe nun die Dateiendung der hochgeladenen Datei. Ist diese ~= .lua wird die Verarbeitung abgebrochen.

Naja, ich kann weder der Prüfung des Mimetyps noch der Dateiendung irgendetwas relevantes abgewinnen. Die Dateiendung explizit nicht als ".lua" haben zu wollen erscheint mir widersinnig, wenn man Lua-Skripte behandelt. (Oder meint "~=" etwa "ungleich"...)

Ja, wenn man meint, sich ein paar Zeichen beim Eintippen sparen zu können ...! Ich meinte "ungleich".
Meine Überlegung war folgende:
Der User, der die Anwendung verwendet, hat die entsprechende(n) Datei(en) als lua Datei vorliegen. Für den User also kein extra Aufwand, um seine Datei uploaden zu können. Wenn ich nun andererseits nur Dateien mit der Endung .lua in mein Verzeichnis verschiebe, und dort den Zugriff auf lua Dateien per htaccess verbiete, bin ich auf der sicheren Seite was etwaigen Missbrauch per Zugriff/ Download anbelangt, und kann bei Bedarf aber immer noch per Script auf die Dateien zugreifen.

Zusätzlich habe ich in meine .htaccess ein
  <Files *.lua>
    Order allow,deny
    Deny from all
  </Files>
eingetragen. Ist das jetzt ein ausreichender Schutz?

Das wurde andernorts schon mal angesprochen: Lagere diese Dateien außerhalb des vom Web aus erreichbaren Bereichs. Diese Pauschalbehandlung "nichts, was hochgeladen wurde, kann runtergeladen werden", ohne dass explizit irgendwelche Prüfungen und Sonderfälle beachtet werden, hilft ganz gut gegen übersehene Lückenbildung.

Ja, sehe ich ein. Wobei ich dabei wieder vor der Frage stehe, wie ich was konfigurieren muss, damit mein PHP Script die benötigten Rechte hat.
BTW: Da habe ich doch noch etwas Interessantes im Archiv gefunden: http://forum.de.selfhtml.org/archiv/2003/12/t67386/#m385578 ;-)

Deshalb: Pauschal erstmal Dinge zu verbieten, und dann geprüfte Einzelfälle wieder aufzuweichen, ist die weitaus bessere Strategie, als Dinge gar nicht zu beachten, und nur für einzelne Fälle Verbote zu installieren.

Na dann bin ich doch langsam auf dem richtigen Weg (hoffe ich) :-)!

Vielen Dank nochmal für deine wirklich hilfreichen und ausführlichen Erklärungen!

Gruß Gunther

[Sven Rautenberg]

Moin!

Meine Überlegung war folgende:
Der User, der die Anwendung verwendet, hat die entsprechende(n) Datei(en) als lua Datei vorliegen. Für den User also kein extra Aufwand, um seine Datei uploaden zu können. Wenn ich nun andererseits nur Dateien mit der Endung .lua in mein Verzeichnis verschiebe, und dort den Zugriff auf lua Dateien per htaccess verbiete, bin ich auf der sicheren Seite was etwaigen Missbrauch per Zugriff/ Download anbelangt, und kann bei Bedarf aber immer noch per Script auf die Dateien zugreifen.

Das ist genau die Denkweise, die du vermeiden solltest. Du definierst dir hier trennscharfe Bedingungen, die gut funktionieren, wenn alles innerhalb normaler Parameter läuft. Aber dein gesamter Schutz bricht zusammen, sobald auch nur eine Komponente den kleinsten Fehler zeigt.

Angenommen, es gelingt mir durch einen Trick, eine Datei mit böser Dateiendung durch deine Uploadprüfung zu schmuggeln, dann steht die hinterher in diesem Verzeichnis und ist öffentlich abrufbar, weil dein Zugriffsschutz nur die Dateien abschirmt, die angeblich durch deine Uploadprüfung durchkommen.

Oder du vertippst dich blöderweise, und der Upload prüft auf ".lau"-Dateien, der Schutz wirkt aber auf ".lua" - oder umgekehrt.

Mit "Pessimismus" bei der Sicherheitsbetrachtung würdest du dich einfach auf gar keine Diskussion einlassen und das fragliche Verzeichnis einfach pauschal für sämtliche Zugriffe vom Web aus sperren - und könntest dann bei der Uploadprüfung beliebig viele Fehler machen, ohne dass man deshalb auf die Datei zugreifen könnte.

Die einfachste Methode, ein Verzeichnis vom Web aus unerreichbar zu machen, wäre halt, es außerhalb des DOCUMENT_ROOT-Verzeichnisses zu platzieren. Das Skript kann, weil es über das Dateisystem operiert, dort zugreifen - HTTP aber nicht.

Ja, sehe ich ein. Wobei ich dabei wieder vor der Frage stehe, wie ich was konfigurieren muss, damit mein PHP Script die benötigten Rechte hat.

Es gibt ja durchaus Webspaces, bei denen man es sich nicht einrichten kann, solch ein außerhalb gelegenes Verzeichnis zu benutzen. Aber wenn es möglich ist, sollte der Zugriff mit PHP keinerlei Unterschied aufweisen im Vergleich zu einem webverfügbaren Verzeichnis.

BTW: Da habe ich doch noch etwas Interessantes im Archiv gefunden: http://forum.de.selfhtml.org/archiv/2003/12/t67386/#m385578 ;-)

Wer schreibt denn sowas? :)

- Sven Rautenberg

[Gunther]

Moin Moin!

Meine Überlegung war folgende:
Der User, der die Anwendung verwendet, hat die entsprechende(n) Datei(en) als lua Datei vorliegen. Für den User also kein extra Aufwand, um seine Datei uploaden zu können. Wenn ich nun andererseits nur Dateien mit der Endung .lua in mein Verzeichnis verschiebe, und dort den Zugriff auf lua Dateien per htaccess verbiete, bin ich auf der sicheren Seite was etwaigen Missbrauch per Zugriff/ Download anbelangt, und kann bei Bedarf aber immer noch per Script auf die Dateien zugreifen.

Das ist genau die Denkweise, die du vermeiden solltest. Du definierst dir hier trennscharfe Bedingungen, die gut funktionieren, wenn alles innerhalb normaler Parameter läuft. Aber dein gesamter Schutz bricht zusammen, sobald auch nur eine Komponente den kleinsten Fehler zeigt.

OK, OK, auch wenn es manchmal etwas länger dauert, aber jetzt habe ich es begriffen! ;-)

Die einfachste Methode, ein Verzeichnis vom Web aus unerreichbar zu machen, wäre halt, es außerhalb des DOCUMENT_ROOT-Verzeichnisses zu platzieren. Das Skript kann, weil es über das Dateisystem operiert, dort zugreifen - HTTP aber nicht.

Ja, sehe ich ein. Wobei ich dabei wieder vor der Frage stehe, wie ich was konfigurieren muss, damit mein PHP Script die benötigten Rechte hat.

Es gibt ja durchaus Webspaces, bei denen man es sich nicht einrichten kann, solch ein außerhalb gelegenes Verzeichnis zu benutzen. Aber wenn es möglich ist, sollte der Zugriff mit PHP keinerlei Unterschied aufweisen im Vergleich zu einem webverfügbaren Verzeichnis.

Ich hab' es jetzt so gemacht (also ein Verzeichnis außerhalb des DOC-ROOTs). Nur die open_basedir Einstellung musste ich entsprechend anpassen, damit es funktioniert.

Also wie gesagt, ich glaube, dass ich das Grundprinzip, wie man solche Dinge handhaben sollte, verstanden habe, dank deiner ausführlichen (und geduldigen) Erklärungen! Denn schließlich möchte ich eben nicht aufgrund meiner Unwissenheit/ Unkenntnis diverser Dinge, den "bösen Jungs" Tür & Tor öffnen. Aber jetzt sollte ich ja nun endgültig auf der sicheren Seite sein.

Besten Dank nochmal und schönes Wochenende!

Gruß Gunther