Geschützter Bereich mit Dateien zum Download

[lleeder]

Hi,

Ich habe einen geschlossener Benutzerbereich definiert, indem ich die entsprechenden Webseiten einer geschützten Kategorie zugeordnet habe. In diesen geschützten Webseiten möchte ich Dateien mit sensiblen Informationen verlinken, die ebenso wie die Webseiten nur für authentifizierte Frontend-Benutzer erreichbar sein sollen.
Allerdings lassen sich die in der Dateiverwaltung hochgeladenen Dokumente nicht schützen. Mit Kenntnis des Links <webadresse>/upload/<dateiname> kann die Datei von jedem heruntergeladen werden.
Gibt es eine Möglichkeit, die hochgeladenen Dateien nur für authentifizierte Frontend-Benutzer zugänglich zu machen?

Danke im Voraus.

Lutz

[Oldperl]

Hallo Lutz,

erst einmal willkommen im Contenido Forum.

Ja das sollte gehen. Du musst dafür eine Redirect-Datei nutzen, die den gewünschten Download nur bei vorhandener Authentisierung zur Verfügung stellt und das benutzte upload-Verzeichnis über eine .htaccess-Datei so schützen, das nur Scripte vom deinem Server/Domain Zugriff haben.

Das sollte eigentlich problemlos mit dem Up- and Downloadmodul http://forum.contenido.org/viewtopic.ph ... t=download
umsetzbar sein.

Gruß aus Franken

Ortwin

[OliverL]

Hier noch schnell eine htaccess die ich für so etwas nutze.

Bei ".../front_content.php?idart=20" muss natürlich die IdArt des DL-Template/-Modul rein und die Kategorie in dem der Artikel liegt sollte PW geschütztsein.
Mit dem Code werden alle Datein im Verzeichnis "cms/upload/secure/" geschützt.

!!! Bitte auffpassen wenn MR verwendet wird !!!

Code: Alles auswählen

RewriteEngine On

# Contenido Filepart Client 1 - START
RewriteRule ^http://www.domain.tpl/cms/upload/secure/(.*)$ http://www.domain.tpl/cms/front_content.php?idart=209&download=upload/secure/$1
# Contenido Filepart Client 1 - END

mfg OliverL

[Oldperl]

Hallo,

für diesen Anwendungsfall muss es nicht unbedingt eine .htaccess mit einer rewrite-rule sein, hier reicht eine .htaccess im entsprechenden Verzeichnis, die den Zugriff über das Web komplett verbietet.

Code: Alles auswählen

order deny,allow
deny  from all

Hochladen der Dateien wird ja entweder per FTP oder, in dem Fall besser, per Dateimanager gemacht. Ein Download wird über das Modul, welches nicht den direkten Link zurück gibt, sondern die Datei per PHP liest und sie anbietet, gemacht.
Da hier nur über PHP zugegriffen wird, ist die Lösung per deny, allow zu bevorzugen, da sie den Server weniger belastet.

Gruß aus Franken

Ortwin

[kummer]

na ja, irgendwie willst du sie ja dann doch herunterladen. dazu ist eine rewriterule natürlich schon nützlich.

[Oldperl]

na ja, irgendwie willst du sie ja dann doch herunterladen. dazu ist eine rewriterule natürlich schon nützlich.

Wenn ich die Datei über einen gekapselten Redirect zum DL zur Verfügung stelle, habe ich keinen direkten Zugriff auf die Datei, benötige daher auch keinen öffentlichen Pfad zur Datei. Soviel mir bekannt ist, kann das dieses Modul. Ich arbeite dort nur mit einem Zeiger auf den DL, den ich nur Intern zu dem passenden Pfad auflöse.
Da ich so keinen direkten Zugriff auf das Verzeichnis habe, kann ich diesen auch komplett sperren.
Macht man es so wie ich gesagt habe, benötigt man keine rewrite-rule, nein besser, sie wäre sogar umsonst, da immer nur per Redirct auf die Datei zugegriffen wird, und der Pfad zur Datei überhaupt nicht (öffentlich) bekannt ist, und daher auch nicht aufgerufen wird.

Gruß aus Franken

Ortwin

[OliverL]

Auch ne gute Lösung und sicher Sicherer als der redirect von mir.

aber ....

Ist das nicht problematisch wenn ich im MCE eine Datei verlinke?
Nach deiner Variante müsste ich doch dann jede Datei über das Modul einbinden und könnte keine DL-List von Mr. X nutzen oder?


mfg OliverL

[Oldperl]

Ist das nicht problematisch wenn ich im MCE eine Datei verlinke?

Von einer Verlinkung in Artikeln war ja hier überhaupt nicht die Rede, sondern Lutz wollte...

Ich habe einen geschlossener Benutzerbereich definiert,...
...In diesen geschützten Webseiten möchte ich Dateien mit sensiblen Informationen verlinken, die ebenso wie die Webseiten nur für authentifizierte Frontend-Benutzer erreichbar sein sollen.
...
Gibt es eine Möglichkeit, die hochgeladenen Dateien nur für authentifizierte Frontend-Benutzer zugänglich zu machen?

Da wäre die vorgeschlagene Lösung, unter Verwendung des UP-/Download-Modules, die sicherste und effektivste Lösung die mir einfällt.
Um diese Funktionalität auf einen kompletten Mandanten zu übernehmen, würde ich das Ganze im Core integrieren und den Tiny, bzw. die Dateiauswahl dort, dementsprechend modifizieren, so daß bei DL-Links immer über eine Redirect-Datei gegangen, bzw. in dem Fall sogar ein CEC verwendet wird.
Durch Verwendung des CEC ist dann sogar "Alles" möglich, so zum Beispiel DL-Statistiken und Auswertungen.
Sowas könnte man sicher problemlos umsetzen.

Gruß aus Franken

Ortwin

[kummer]

na ja, irgendwie willst du sie ja dann doch herunterladen. dazu ist eine rewriterule natürlich schon nützlich.

Wenn ich die Datei über einen gekapselten Redirect zum DL zur Verfügung stelle, habe ich keinen direkten Zugriff auf die Datei, benötige daher auch keinen öffentlichen Pfad zur Datei. Soviel mir bekannt ist, kann das dieses Modul. Ich arbeite dort nur mit einem Zeiger auf den DL, den ich nur Intern zu dem passenden Pfad auflöse.
Da ich so keinen direkten Zugriff auf das Verzeichnis habe, kann ich diesen auch komplett sperren.
Macht man es so wie ich gesagt habe, benötigt man keine rewrite-rule, nein besser, sie wäre sogar umsonst, da immer nur per Redirct auf die Datei zugegriffen wird, und der Pfad zur Datei überhaupt nicht (öffentlich) bekannt ist, und daher auch nicht aufgerufen wird.

Gruß aus Franken

Ortwin

nun ja, der pfad darf ja durchaus sichtbar sein. man muss bloss eingloggt sein, um auch etwas zu erhalten. die verschleierung des pfades bringt keine sicherheit. also deny from all plus rewrite, die auf eine datei weiterleitet, welche zunächst prüft, der ob der benutzer eingeloggt ist und über ausreichend rechte verfügt. ist das nicht der fall wird ein access-denied-header gesendet, andernfalls mit readfile die angesprochene datei geliefert. dass es anders auch geht ist schon klar. aber eine zusätzliche verscheierung bedeutet keinen gewinn.

[Oldperl]

Hallo,

habe ich schon erwähnt...

• das es mehrere Lösungswege gibt?
• das meiner nicht der allein wahre sein sollte?
• das ein deny/allow den Server weniger belastet als ein modrewrite?
• ein Verschleiern von Pfaden selbstverständlich ein sicherheitsrelevanter Aspekt ist?

Gruß aus Franken

Ortwin

[kummer]

seltsam dass ausgerechnet du immer mit dem spruch kommst von wegen der alleinige weg und so... das wird langsam langweilig ortwin.

1) klar gibt es mehrere lösungswege. darunter sind welche, die sind komfortabler und andere sind es weniger. die möglichkeiten reichen von emailversand über download bis persönlich vorbeibringen in form von tontafeln.

2) hier wirst du schon ein wenig spirituell. es scheint fast, als dürfe man das für und wider nicht mehr diskutieren. da würde ich dir einfach mal empfehlen, in dich hinein zu horchen. du wirfst anderen vor, was du selber machst.

3) für einen geschützten download macht die serverlast wohl kaum was aus. das ist ja dann relativ selten. wenn das eine rolle spielt, dann dürfte man contenido gar nicht erst für sowas einsetzen. nebenbei bemerkt erzeugt die ausgabe einer seite mit dem link wohl für erheblich mehr last, als das rewrite einer abfrage.

4) ohne ssl ist alles egal, ortwin. du hast ein leck und sorgst dich um verdunstung. dabei überträgst du alles plain text. aber auch wenn nicht: ganz verschleiern kannst du's nicht, sonst kann es der browser nicht herunterladen. und zum thema security through obscurity ist schon viel geschrieben worden. es lohnt sich, das mal zu lesen.

anyway, jeder darf es so machen, wie er will. es sollte jedoch noch erlaubt sein, varianten zu diskutieren. mehr ist hier nicht erfolgt.

[Oldperl]

anyway, jeder darf es so machen, wie er will.

Da stimme ich zu. Zum Rest muss ich nicht wirklich was sagen. (Langeweile?)

Gruß aus Franken

Ortwin

[kummer]

habe ich schon erwähnt...

• [...]
• ein Verschleiern von Pfaden selbstverständlich ein sicherheitsrelevanter Aspekt ist?

das kannst du im übrigen mit rewrite immer noch genau so haben. wenn es dir ein bedürfnis ist, kannst du ja durchaus so tun, als läge die datei in /ortwin/hat/sich/versteckt/ und liegt dabei in /cms... hmmm, upload? wenn dann jemand den ftp-zugang knackt, dauert es möglicherweise dann 10 sekunden länger, bis er die datei hat. wenn du dann in genau diesen sekunden die datei noch löschen kannst, dann hat du einen veritablen sicherheitsgewinn.

und in bezug auf die leistung: du sprichst über die last einer rewrite rule und bietest die datei zum download an, nachdem contenido vollständig hochgefahren ist um die authentizität des benuters zu prüfen? will heissen, die rewrite rule benötigt möglicherweise, na ja, sagen wir mal eine 10'000stel sekunde zur query-umwandlung und contenido dann 1 volle sekunde, bis alleine der download startet.

nicht persönlich nehmen, ortwin. ist nicht böse gemeint.

btw: der upload über das medienmanagement funktioniert auch mit einem deny from all einwandfrei. und auch der download aus dem backend. also alles ganz normal... wenn man rewrite rules nutzt. und auch downloadlisten funktionieren dann so, wie man es sich das gewohnt ist. dazu reicht im upload-verzeichnis zum beispiel ein verzeichnis protected und unterhalb diesem ein verzeichnis je zu berechtigende gruppe. in das protected-verzeichnis kommt eine htaccess mit einem deny from all. auf oberster ebene eine rewrite rule die alle requests von upload/protected auf die front_content.php leitet und dann kann der download innerhalb der normalen ausführung von contenido sogar mit hilfe eines modules erfolgen, wenn die ausgabepufferung eingeschaltet ist. oder man schreibt eine eigene datei oder nutzt die chains. ganz nach belieben. der verzeichnis-name unterhalb des protected dient dann zur ermittlung der erforderlichen gruppe für den download, dann ist zu prüfen, ob der benutzer authentifiziert und autorisiert ist und dann kann der download beginnen. vorausgesetzt, der benutzer hat ausreichend rechte. das ist jetzt eine ganz einfache variante. man könnte auch die muster der dateinamen verwenden oder den medienname, die beschreibung oder die keywords. was halt im einzelfall gefällt.

an dieser stelle muss noch angemerkt werden, dass eine solche lösung letztlich eben dann doch nicht als in dem sinn sicher anzusehen ist, als dass wirklich sensible informationen so angeboten werden können. auf shared hostings kann so einiges geschehen. hinzu kommen fahrig programmierte module, die ohne weiteres den zugriff auf diese dateien dann doch wieder ermöglichen können. das ganze ist eine gute methode, wenn man nicht möchte, dass sich jedermann so ohne weiteres bedienen kann. sind die informationen, die zum download angeboten werden als richtig schützenswert einzustufen, müssen freilich weitergehende massnahmen getroffen werden. die erste ist dann vermutlich, ein anderes instrument für diese aufgabe zu nehmen als ein cms.