A real challenge with JPEG files!

[yankleber]

Hi there,

I have this challenge that I think it's very hard to solve, but let's try it.

I am working on a website where the customer have about 4 thousand images (JPEG format), and he dont wants that some thief steal it. Ok, we are not worried about the "right-click and save" action, but with someone that uses a "website leech tool" (like BlackWidow) to suck the whole site and the 4 thousand images...

After a while, I concluded that the only way to prevent image stealing, is NOT TO KEEP the images on the website. Then I was thinking that, I could break any one of the 4 thousand images, in three parts and name it like:

42764872.prt (first 1/3 part of the file with the JPEG header)
92837483.prt (second 1/3 part of the JPEG file)
34873988.prt (last 1/3 part of the JPEG file)

Then I will have three bytes sequences, that, if joined in the right way will give me the JPEG file again. This way, no matter if someone can suck all the ".prt" files from my website, because he will not know what to do with that, because he dont knows which part belongs to each other neither the right combination.

Well, in my database I will have the right sequence to reassemble any one of the images.

I think that the idea is cool and it will work if... I can do that!

The problem is that I have no idea how to (even know if it's possible!) send three bytes sequences to PHP, and tell him: "hey, join these three guys. The result is a JPEG file, ok?"

That's my hard questions!!!

Thanks for your help!!!

[Crave]

I'm not exactly sure how it's done, but there is a way to encrypt the files to hide them. Check out this page, that what they do there so people can't steal their pictures like what you're worried about.

Also, you could put the pics in a database.

[Jerryscript1]

You could use base64_encode() to turn the images into txt files or database entries, and then show them by echoing the appropriate headers and base64_encode() http://php.holtsmark.no/base64img/

[yankleber]

Ok, but I think I just found out a cool solution, using blob.

Take a look in this tutorial that shows the step-by-step how to store images without have them in disk.

I needed to do some modifications in the PHP in order to have it working, but it worthed!

http://www.devarticles.com/c/a/MySQL/Blobbing-Data-With-PHP-and-MySQL/

Thanks for the interest!!!

[mtmosier]

I don't understand how these solutions are supposed to solve your problem. One way or another you're making all of these images available to people browsing your site, right? Site rippers can be indistinguishable from a web browser, and will save the images to disk after you've already put them back into the correct format for them.

Seems to me this only helps against attackers on the same machine with read access to your image files. But if they have read access to your image files, they probably have read access to your scripts, and so can just reverse whatever obsfucation you do.

(By the way, just playing devil's advocate with the intention of saving you some unnecessary work, assuming it is unnecessary.)

[rehfeld]

what i would do is force the visitor to verify they are not a bot before allowing them view any images.

for example, when you register for certain things they have that image with skewed looking letters, and make you type the letters into a text field. its very difficult for a bot to do that.

once they have verified they arent a bot, start a session and allow that user to view images.

as far as cutting up the images, not a bad idea but it wont stop anybody or anything, it will just make it more difficult. but if you reassemble the image before showing it to them, its pointless. you would need to reassemble the images using html, for example, putting the slices into an html table without any cellspacing, padding or borders.

[pingu]

Hi,

first off all I don't see the challange. Because this is the easiest thing in the world.

Originally posted by yankleber
Then I was thinking that, I could break any one of the 4 thousand images, in three parts and name it like:

42764872.prt (first 1/3 part of the file with the JPEG header)
92837483.prt (second 1/3 part of the JPEG file)
34873988.prt (last 1/3 part of the JPEG file)

Then I will have three bytes sequences, that, if joined in the right way will give me the JPEG file again. This way, no matter if someone can suck all the ".prt" files from my website, because he will not know what to do with that, because he dont knows which part belongs to each other neither the right combination.

Well, in my database I will have the right sequence to reassemble any one of the images.

I think that the idea is cool and it will work if... I can do that!

The problem is that I have no idea how to (even know if it's possible!) send three bytes sequences to PHP, and tell him: "hey, join these three guys. The result is a JPEG file, ok?"

This is total crap. Hey, I will not access the "images" directly from your site. I will just call your script. So the script is assembling the image right away for me and that's it. The only thing you do with this is that you will have processor load, which slow downs your site at all without any benefit.

A very easy solution for you could be:

• Dont allow access to the directories where the files are in (for example by using .htaccess in an appropriate way).

• Doing a script that takes the image to display as a parameter and doing some validation within the script. If the validation will give an OK, then output the image. If not, then output whatever you want (for example a stop sign or whatever).

If your validation is only based on the referer and/or the user agent string then you do not need any script at all. Just take a look into the manual of the apache into the mode_rewrite section and you will find anything you will need. There are even examples given.

Pingu

[mtmosier]

The problem with validating against the referer and/or user agent is that both come from the client (read "bot"). You can write a bot which fakes both of these, and it can look no different than a normal user in this aspect. (Heck, I've done it myself when the situation called for it.)

Not saying it won't stop the less savvy attackers. Just saying it's not foolproof. Never trust input provided by the user.

[pingu]

Originally posted by mtmosier
Not saying it won't stop the less savvy attackers. Just saying it's not foolproof. Never trust input provided by the user.

Sorry to say that, but you can't do a foolproof solution. Everything that is presented to the user in standardised way (which jpeg is) can be theft.
The only answer you always have to ask yourself: How high do I set the barrier?

For example the refering page may calculate a secret that is passed to the script that is responsible for validation and presenting the image. But even that can be bypassed easily by use of simple perl script.
The next level is to implement a user authorization with session handling. Again, when I'm a registered user then I can also implement a simple perl script to build an automated tool.
The next level could be to enable SSL. But I would bet that there exist some stuff on CPAN to bypass this.

What I'd like to say is that you can build barriers to make it difficult for the John Doe user. But there is no way to prevent it at all.

Pingu

[mtmosier]

Make them log in and then limit how many images they can view over a specific timeframe. No human is going to view 4 thousand images in a single night. Well, very few humans anyway.

[onion2k]

Originally posted by mtmosier
No human is going to view 4 thousand images in a single night. Well, very few humans anyway.

Depends what they're pictures of really..

😉

[rehfeld]

^lol

[BlackenedSky]

If you don't want people leaching your images, try storying them in a MySQL database as a BLOB entry. You can now read them from teh database instead.

Alternatively, password protect access to the directory, but when you go to include the image in a page, send the username and password headers to allow the image to be displayed on the page.

[BlackenedSky]

Originally posted by pingu

What I'd like to say is that you can build barriers to make it difficult for the John Doe user. But there is no way to prevent it at all.

Pingu

I beg to differ. Like I said in my last post, you can set up the server to require a username and password to access files in that directory, and then pass header information to access the directory via PHP. Additionaly, you can disable directory browsing as well.

If you want to deter them saving the image from teh page once loaded as well, how about watermarking them to make them almost useless to the leecher? I saw a tutorial on google the other day telling you how to watermark your images on teh fly as they are loaded and displayed using PNG files for the watermark.

[mtmosier]

Agreed on watermarking. Didn't think of that.

However, I don't follow you on the user and password. Are you saying don't make them publicly available? I have to assume this person doesn't have 4k images online for their own amusement. Or are you saying have a public registration. In which case a script can log in just like a user with a web browser does.

[BlackenedSky]

Best way to describe what I mean is go here: www.blackenedsky.com/admin and notice how you get a box asking for the username and password? tryin saving any files in there after browsing the directory and you won't be able to without my username and password.

basically if you do that with your folder, you can then send the headers via your PHP code required to automate the login for the folder so that you can use the images.

Also, if you turn off directory browsing, they shouldn't be able to view the files in any programs designed to save teh entire site - they should just see a blank folder instead, and notbe able to access the folder when they try via a browser. This would meany wouldn't need all that messy login stuff I mentioned above too because as far as anyone but is concerned, there are no images in the folder 🙂

EDIT:-----------------
Just thought though - even with directory browsing turned off if the user gets hold of the direct URL to the image they can still access it.

Only way I guess is via password protecting the folder on teh server and sending the HTTP authorisation headers when you try load the images into a web page.

[pingu]

Originally posted by BlackenedSky
Only way I guess is via password protecting the folder on teh server and sending the HTTP authorisation headers when you try load the images into a web page.

That is what I mean. As long as you have the login data and the URL (which you should have otherwise you will not even see the images at all - if you want this than just disable the access at all) you can do that:

wget http://user:[e-mail]

or that

wget --http-user=user --http-passwd=pass http://www.example.com

That is what I mean. For knowledged people (you don't even has to have programming skills, just to know how to use tools) you can bypass anything.

Pingu

[Jerryscript1]

While not fool-proof (I think this thread proves nothing is), you could use Flash or Java to display the images, that way they are never sent directly to the browser as jpg.

Even safer (still not fool-proof), use PHP's Ming module (http://ming.sourceforge.net) to convert the images to SWF on-the-fly.

Either way, a sniffer can detect the calls made by Flash to load the images, but I don't know if a bot can.

[BlackenedSky]

One other option based on the storing the images in a database idea is to save teh images into a database and then load them and display tehm from teh database with the watermarking idea from before.

Addtionally you could create the files with random names via PHP based on what you pull from teh database and then delete them when they are no longer needed. This way the image only exists while the server is loading it.

Least that's the theory anyway! I tried doing this myself a few months back but couldn't get it to work properly 🙁 Although I didn't really know what I was doing back then. Maybe some of you have an idea of how to do it so that the image is there for the page to display it, and isn't created and deleted before the page can get it?

One downside though is excessive server load if you take this approach and could also be slow.

[pingu]

Originally posted by BlackenedSky
One other option based on the storing the images in a database idea is to save teh images into a database and then load them and display tehm from teh database [..]

This does not help. It does not where the images are. If they are stored in a database or in directory on the filesystem.
Personally, I suggest to store only metadata in the database.

Originally posted by BlackenedSky
Addtionally you could create the files with random names via PHP based on what you pull from teh database and then delete them when they are no longer needed. This way the image only exists while the server is loading it.

What is the benefit. You will have certain link within a HTML document to the image to display. [font=courier]wget[/font] or other tools will get the link and such will get the image indepent where the image is fetched from (database, filesystem, ...).

To give you an working example: Take a look at the image: http://www.pingu.info/test/lasvegas.jpg
What you will see is an image, which you will not expect by the name of the image.
Now go to the main page http://www.pingu.info and log in with the username "phpbuilder" and the password "test" and then go back to the see the image http://www.pingu.info/test/lasvegas.jpg
Now, you will see what you expect by the name of this image.
(Currently, this will only work wiith cookies enabled, because the cookie will have the session ID.)

I can say, the image is placed at exactly that directory on the filesystem. No database, except for the user login. Even the access control itself is made without a database. It is just an XML files placed in the very same directory with the information to whom access is allowed:

<access type="restricted" user="phpbuilder" />

No complicated file create, delete, rename or whatever. Because this will only create server load without any benefit.

The relevant part of the script is only this

        // output the file
        if ($xmlAccess->isPublic($PATHS["filename"]) ||
            ($xmlAccess->isRestricted($PATHS["filename"]) && $xmlAccess->verify($PATHS["filename"], $Access)))
            readfile($PATHS["file"]);
        else {
            switch ($PATHS["filetype"]) {
                case "jpg":
                case "jpeg": readfile($PATHS["base"] . "images/noaccess.jpg"); break;
                case "png" : readfile($PATHS["base"] . "images/noaccess.png"); break;
                case "gif" : readfile($PATHS["base"] . "images/noaccess.gif"); break;
            } // switch ($PATHS["filetype"])
        } // if ($xmlAccess->isPublic($PATHS["filename"]) || ... else

    // now everything should be ok, we can leave the script
    exit;

But even this can be theft with an automated script. Even as it is based on session and the user name and password has to be a POST request (GET request will not work).

Watermarking will not help against theft. It will help only to show the legitimate copyright holder.

Currently, the most highiest barrier is the thing with Java or Flash as already suggested, AFAIK.

Again, a foolproof solution will never exist. The question is only how high do I set barrier to get it. This will depend on the value of the images.

Pingu