Geschützte Dateien aus der Dateiverwaltung heraus herunterladen

Hallo,

wenn eine Datei in einem geschützten Verzeichnis liegt und ich sie durch einen Klick auf das Dateiicon in der Dateiverwaltung herunterladen will, bekomme ich (logischerweise) auch eine 403, also Forbidden. Aber sollte das Contao nicht in der Form abfangen, dass in der Dateiverwaltung alle Links durch solche, die mit einem \Controller::sendFileToBrowser() enden, ersetzt werden?

Ich würde sowas ja bauen, aber die Dateiverwaltung ist ja auch nicht sooo erweiterbar. Geht das vielleicht doch irgendwie schon? Und spielt dieses Problem bei Contao 4 überhaupt noch eine Rolle?

Ciao The_Unknown

Da musst Du nichts programmieren. Das gibt es bereits -- wenn auch etwas versteckt:

Bei der betroffenen Datei auf das Info-Icon klicken und im daraufhin erscheinenden Dialog "Die Datei herunterladen" klicken.

Der Verbesserungsvorschlag bleibe natürlich: wenn der Klick auf das Datei-Icon wegen "ist geschützt" nichts werden kann müsste er gar nicht erst verlinkt werden -- oder könnte durch den Link aus dem Dialog ersetzt werden.

Heihou

Ich erlaube mir, hier eine entsprechende Frage e contrario zu stellen:
Ich habe einige Verzeichnisse entsprechend geschützt (d.h. sie erscheinen in der Dateiverwaltung mit einem gelben Schloss). Das würde ja eigentlich heissen - und wie The_Unknown oben ja auch sagt - , dass ein Zugriff, insbesondere über den Link, welcher beim Upload über ein Formular versandt wurde, nicht funktionieren sollte. Nun funktioniert aber genau das problemlos, was mich etwas stutzig macht. Muss ich neben der Einstellung in der Dateiverwaltung sonst noch etwas ändern, damit das Verzeichnis sicher ist? An der Verzeichnisberechtigung über FTP sollteich da ja nichts machen müssen, oder? Oder anders gefragt, was ist die Standard-Einstellung?

Besten Dank und liebe Grüsse
leroy

Beschreibe das Problem genauer und gib einen Beispiel Link zu so einer Datei.

Ein Schützen eines Verzeichnisses legt eine .htaccess-Datei in ebenjenes. Dadurch ist ein direktes Aufrufen des Links abseits des CMS nicht möglich. Es klappt nur über den PHP-Code, der in Contao enthalten ist und dann bei entsprechendem GET-Parameter (file) die gewünschte Datei an den Browser zum Download schickt. Und diesen Zugriff bekommt man halt nur bei einem Downloadelement oder über das Backend, wie ich durch die obige Antwort gelernt habe :)

Nun, die Ausgangslage gestaltet sich so, dass ich unter "files" geschützte Verzeichnisse für Kundenuploads erstellt habe, v.a. für Benutzerverzeichnisse. Via Formular werden entsprechende Dateien in die Verzeichnisse hochgeladen. Für die Verzeichnisse ist jeweils die "Geschützt"-Funktion im BE aktiviert. Die .htaccess-Datei wird mit folgendem Inhalt im Verzeichnis abgelegt:

PHP-Code:

---

<IfModule !mod_authz_core.c>
  Order deny,allow
  Deny from all
</IfModule>
<IfModule mod_authz_core.c>
  Require all denied
</IfModule> 


---

Die Dateien werden mit der Zugriffsberechtigung 644 in den Verzeichnissen gespeichert. Die Verzeichnisse selbst verfügen über die Berechtigung 755.

Dieser Link führt zu einer Datei in einem geschützten Verzeichnis: https://www.omnius.ch/files/Benutzer...YG_460s_v2.jpg
Dieser kann aber - zumindest von mir - problemlos geöffnet werden, auch abseits des CMS.

Ich habe vor Kurzem ein Update auf die Version 3.5.6 durchgeführt - und wenn mich mein Erinnerungsvermögen nicht trübt, sollte es vorher geklappt haben.

Hilft das?

Besten Dank!

Hmm, Verzeichnisse werden in Contao 3.5.x und auch schon vorher mit einer .htaccess geschützt. So ein direkter Link wie angegeben dürfte also nicht funktionieren, das müsste der Webserver schon verweigern. Wenn der Link für dich funktioniert, dann auch für alle anderen, denn irgendeine in Contao eingetragene Berechtigung einer Mitgliedergruppe für das Verzeichnis wird hierbei nicht berücksichtigt. Entweder das Bild kann geladen werden oder eben nicht. Das geht direkt über den Server, Contao bekommt das gar nicht mit. Logischerweise kann ich es auch anzeigen. Da würde ich mal kontrollieren, was in der .htaccess des betreffenden Verzeichnisses drinsteht. Diese scheint jedenfalls das Herunterladen zuzulassen.

Wenn der Schutz korrekt besteht, heißt das in der Konsequenz allerdings, dass das Bild, wenn das Verzeichnis in der Dateiverwaltung auf "geschützt" gesetzt wird, von NIEMANDEM direkt angezeigt werden kann, nicht als Bildelement, Galerie oder per Deep Link. Es funktioniert dann allenfalls noch ein Download(s)-Element für Mitglieder mit der entsprechenden Berechtigung. Bei Download-Elementen greift die im Inhaltselement gesetzte Berechtigung für Mitgliedergruppen, auch wenn das Verzeichnis geschützt ist, weil hier die Datei über Contao bzw PHP auf dem Server nach Prüfung der Berechtigung an den Browser ausgeliefert wird.

Es liegt definitiv an der Konfiguration deines Webservers, anscheinend greift weder

Code:

---

Require all denied

---

wenn das mod_authz_core aktiviert wäre, noch

Code:

---

Order deny,allow
Deny from all

---

Man kann bei dir auch bspw. direkt auf die localconfig.php zugreifen - normalerweise ist ja der /system Ordner genau so geschützt.

Ok, gerade herausgefunden, warum das bei dir nicht funktioniert. Sieh' dir mal deine Response Header genauer an:

Code:

---

Server: nginx

---

;) Dein Webserver läuft auf nginx - nginx verarbeitet keine .htaccess Dateien.

So, habe das jetzt mal hier bei mir nachgestellt und festgestellt, dass der Schutz gegeben ist, ich bekomme beim direkten Aufruf ein Error 403 wie es sein soll. Allerdings dachte ich erst schon, es funktioniert nicht. Das Bild wurde erst angezeigt, bis ich dann das Bild im FF mit STRG-F5 neu geladen habe... War also wohl bei mir im Browsercache.

Zitat:

---

Zitat von Spooky

Dein Webserver läuft auf nginx - nginx verarbeitet keine .htaccess Dateien.

---

Das erklärt natürlich alles. :)

Ich danke euch recht herzlich! Ehm... wir sprechen also hier gerade von einer sicherheitstechnisch höchst bedenklichen Situation. WTF und ab ans beheben... ^^ Vielen Dank nochmal!

Naja, aus den PHP Dateien kann eh nichts extrahiert werden, weil die ja geparsed und nicht direkt ausgegeben werden, also derweil mal halb so wild, aber solltest du natürlich ändern ;)