WebsiteBaker Support (2.13.x) > General Help & Support

How to protect images on a "Logged In Only" page

(1/3) > >>

CodeALot:
Situation: An image is on a page that you can only access once you're logged in. The images however, are stored in the /Media folder. So in theory, someone who knows the URL, could potentially acces the image file directly, bypassing the login-requirement. Also, crawler software would find all the images in de /Media folder(s). Even those images that you want to be accessible for logged in users only.

How would you prevent this?

dbs:
Hi, the AI of your choice could help you.
e.g.
- a folder with the images in media
- a entry in .htaccess what leads all requests for this folder to a special file
- the special file (e.g. protected_media.php) checks the login status and shows the image(s)

not tested

crnogorac081:
https://forum.WebsiteBaker.org/index.php/topic,16282.msg106825.html

Check this and this

https://forum.WebsiteBaker.org/index.php/topic,17482.0.html

crnogorac081:
And which modul you use in backend to Make content for this ?

sternchen8875:


--- Quote ---Situation: An image is on a page that you can only access once you're logged in. The images however, are stored in the /Media folder. So in theory, someone who knows the URL, could potentially acces the image file directly, bypassing the login-requirement. Also, crawler software would find all the images in de /Media folder(s). Even those images that you want to be accessible for logged in users only.

--- End quote ---

(english)
I'm not sure if I should start by explaining the technical background, but since this is a question every site operator has likely considered, I want to try for the benefit of the community. The best way to do this is with an analogy.

A CMS—or rather, any CMS—is the application layer. At this level, the system handles internal security, manages the internal transport of data, and checks the permissions granted to users.

Its counterpart is the web server, which is the delivery layer. Its job is to serve files that are then read and displayed by the browser using various methods.

A CMS can be as secure as it wants; if the web server isn't, you have open doors. The reverse is also true. The issue of the /media directory being public affects many systems. The main reason for this in the past was likely the desire to display content from /media publicly anyway. As a result, little effort was invested in protecting the source files.

Added to this is a fundamental technical problem: Anything a browser can display can also be "saved" by the visitor.
Method 1: Basic Protection via .htaccess

A first step to make direct access more difficult is an entry in the .htaccess file in the CMS's root directory.

(File types and domain need to be adjusted)
   

--- Code: ---RewriteEngine On
# Block access if the request for an image is not coming from your own domain.
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourdomain.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [F]
--- End code ---

 

This rule prevents direct links to the files or embedding them on external websites. It's a relatively simple task, but it's not a "vault." Several points work against it:

- The HTTP_REFERER can be spoofed.

- If the image is used within the website's content, the visitor already has the file on their computer, for example, in the browser's cache.

Method 2: The Most Secure Approach (Delivery via PHP)

Currently, the most secure method is the one where every file to be delivered must be passed through a PHP script. This script first checks for permissions within the CMS and only then, depending on the outcome, sends the requested file to the browser. The directories where these protected files are stored must, in turn, be completely locked down from direct access using their own .htaccess file (e.g., with Deny from All).

But, and this is the crucial point: What happens after that is no longer in the hands of the CMS or the web server, but in the hands of the visitor. Anything that appears in their browser is then under their control.

---------------------------------------------------------------------------------------------
(german)
Ich bin nicht sicher, ob ich zuerst die technischen Zusammenhänge erklären sollte, aber da es eine Frage ist, über die jeder Webseitenbetreiber schon mal nachgedacht hat, möchte ich es für die Community versuchen. Am besten geht das mit einem bildlichen Beispiel.

Das CMS – oder besser gesagt, jedes CMS – ist die Anwenderebene. Auf dieser Ebene sorgt das System für die interne Sicherheit, prüft den internen Transport von Daten und die erteilten Berechtigungen der Benutzer.

Das Gegenstück ist der Webserver, er ist die Bereitstellungseben e. Seine Aufgabe ist es, Dateien zur Verfügung zu stellen, die mit verschiedenen Methoden vom Browser gelesen und dargestellt werden.

Ein CMS kann so sicher sein, wie es will – ist der Webserver das nicht, hat man offene Türen. Umgekehrt gilt das Gleiche. Die Problematik, dass das /media-Verzeichnis öffentlich ist, betrifft viele Systeme. Der Hauptgrund dafür war wohl in der Vergangenheit, dass man Inhalte aus /media ja auch öffentlich anzeigen möchte. Daher wurde in den Schutz der Quelldateien bisher kaum Arbeit investiert.

Dazu kommt das technische Grundproblem: Alles, was ein Browser darstellen kann, kann vom Besucher auch "gesichert" (gespeichert) werden.
Methode 1: Grundlegender Schutz via .htaccess

Ein erster Schritt, um den direkten Zugriff zu erschweren, ist ein Eintrag in der .htaccess-Datei im Hauptverzeichnis des CMS.

(Dateitypen und Domain müssen angepasst werden)


--- Code: ---RewriteEngine On
# Zugriff blockieren, wenn die Anfrage für ein Bild nicht von deiner eigenen Domain kommt.
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?deinedomain.de [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [F]
--- End code ---

Diese Regel sorgt dafür, dass direkte Links auf die Dateien oder die Einbindung auf fremden Webseiten unterbunden werden. Das ist eine relativ einfache Aufgabe, aber eben auch kein "Tresor". Dem stehen mehrere Punkte entgegen:

-  Der HTTP_REFERER kann gefälscht werden.

- Wird das Bild im Inhalt der Webseite genutzt, hat der Besucher es bereits auf seinem PC, z.B. im Cache des Browsers.

Methode 2: Der sicherste Ansatz (Auslieferung per PHP)

Als sicherste Methode gilt aktuell die Variante, bei der jede auszugebende Datei eine PHP-Datei durchlaufen muss. Dieses Skript prüft zuerst die Berechtigungen innerhalb des CMS und sendet erst dann, abhängig vom Ergebnis, die gewünschte Datei an den Browser. Die Verzeichnisse, in denen diese geschützten Dateien liegen, müssen dann wiederum durch eine eigene .htaccess-Datei (z.B. mit Deny from All) komplett für den direkten Zugriff gesperrt werden.

Aber, und das ist der entscheidende Punkt: Was danach passiert, liegt nicht mehr in den Händen des CMS oder des Webservers, sondern in denen des Besuchers. Alles, was in seinem Browser erscheint, kann er dann auch benutzen.

Navigation

[0] Message Index

[#] Next page