Print

[crypto]

Hi.
When i upload my jpg to the server, i send it into a dir but this dir must have read access for everyone. So if somebody finds this dir (ie www.site.com/cpg142/albums/album_name/) he can browse the album without any login.
If sb wants to send a link to only one photo (www.site.com/cpg142/albums/album_name/01.jpg), he will send a link to the whole album without guessing (you just have to remove filename).
The dir with photo should be protected by .htaccess (Deny from all) and the jpg should be read by a php script that checks session and returns the photo. Not a direct acces to the file.

Thx.

[kegobeer]

This is not a security issue.  If a person figures out how to directly access the image there is no security vulnerability.

htaccess doesn't work for IIS, so your solution doesn't work for all users of Coppermine, only Apache users.  Work is being done for a future version that does a better job of hiding images from direct access.

[crypto]

I dont really know IIS but i think it provides a similar way to prevent access.
I think it's a problem because an user can think that photos are password protected and it's not the case.

I'm triing to prevent direct acces by using url-rewriting and a file that checks "rights" (until the future version ...)
I am looking for the piece of code that checks rights...

[kegobeer]

Serving images via a script is not a simple piece of code - it involves a lot of work.  I know, because I've been working on it.  The system must work for all file types, and not just images.  Coppermine does a lot more than show pictures.  Any such system must work with every type that Coppermine handles and work on every type of webserver.

I'm not working on any type of url rewriting.

[amirw2k]

This thing is a general security issue and should be protected in the settings of the server.

However, there's a simple solution for this. Put an empty file in the directory called index.html. This prevents browsing the directory.
Basically it can be implemented into coppermine, but I think it's best to solve this by setting the server correctly.

By the way, wouldn't this script you're talking about overload the server? This script can deliver more "security" issues because you can use it to mass-download the entire gallery by changing the id of the picture.

Amir W.

[crypto]

This thing is a general security issue and should be protected in the settings of the server.

However, there's a simple solution for this. Put an empty file in the directory called index.html. This prevents browsing the directory.
Basically it can be implemented into coppermine, but I think it's best to solve this by setting the server correctly.

By the way, wouldn't this script you're talking about overload the server? This script can deliver more "security" issues because you can use it to mass-download the entire gallery by changing the id of the picture.

Amir W.

the problem is not only directory listening...
Preventing acces just by thinking that users can't guess file name sucks! It's not security, it's just a fucking hazard game.
Almost everybody uses guessables filenames.

When you browse an album, the img urls will stay in your historic and anywhere else... The next user can see img without login and with the actual version there is no way to protect img from it. This is why direct acces should be avoided.
Moreover I don't see the problem with mass-download, an user who wants to download an album dont need any other script, you can make a small app that browse an coppermine album. This is not a security issue.


Url-Rewriting is not needed but it's juste easyier for me... (Otherwise I ll have to modify coppermine code)

[ulikoeln]

If an Image can be requested directly, this is not a security issue -
I think you are mixing up "security" with image protection.The latter is a design
deceision, and it depends on what the gallery owners want.

If somebody would code the "perfect" delivery script, this would mean that
for every single image you would have to check permissions of the user or group
to that specific image, then the permissions to one of the real or virtual galleries
 it is located in, then you could also do checks for download quota, do some
IP or UserAgent checks to ban (or allow) image search engines and so on and so on.

If all this would become part of CM, then we all need to order new database servers right now. And
big ones.  For me, it is perfectly OK to deliver images directly, not via delivery script.
Other users may have different requirements - so the really perfect delivery
method would be configurable (direct delivery for performance saving, protected
delivery for those with specific copyright paranoia.) IMHO, this should not
get high priority - after all, we are talking about a web gallery tool mostly for
public use and not for commercial image collections.

Regards,
Ulrich

[donnoman]

if someone wants your images, they are going to get them. If they are readable by your apache default user and served by http, they can be requested and stored elsewhere, including if they are not in your document root.

you can scrape almost any site with winhttrack; for every measure that comes out to protect images, another comes out to circumvent it.

The only way to truely protect images is over SSL using Webserver authentication. (ie: default http user doesn't have filesystem rights to read the images)

then you have to beat and flog your users.... because they'll give out the passwords... and your back to square one.

[janus]

I have tested it with a .htacces file.

It works, but I've got a question.

Now all users must use thier logins second times - at first for the CM itself, and then to view a file.

Is it possible to switch the htaccess protection off, if you already have been logged in the CM?