June 17th, 2013, 02:57 AM
Originally Posted by Jacques1
I hadn't actually thought of the dev tools, and looking in Chrome you are absolutely right - you can see all kinds of different images there.
I also noticed that graphic elements like canvas elements don't seem to get logged, if you were to draw each pixel on a canvas and use that as an image then that should not get logged.
Then you should be able to draw those pixels onto a canvas and use that on top of the other canvas as you would with a picture, but without getting a readable file in dev tools/fiddler
Originally Posted by web_loone08
3. use a php/htaccess script to redirect every http request that doesn't come from the target page (and has the right auth token).
so we're on the same page on that one - possibly with the exception of the cousin=bob bit, I thought I'd store that in a session object instead but that's just me.
Then, just because it's fun to elaborate further, we can set the redirect to the same 404 page that the rest of the site have IF the referer information in an HTTP request doesn't come from your photoalbum page to throw hackers off track.
So, to sum it all up:
you log in and a php session stores who you are as well as get a 1 time authtoken
we load the arrays for the project from botparts.xml?key=293092URIJKDF
this xml is login specific, and serves up different data, but also has the locations of other files like the js file that has all the pixel info stored.
We extract pixel info from said file and recreate the image based on that on a second canvas.
We use the xml data to print out certain parts of the new canvas on to the background canvas.
Would that be safe?
June 17th, 2013, 02:08 PM
You've really fallen in love with that idea, have you?
The security gain from this is zero. All it does it is massively bloat your code and the data you have to send.
To cut it short: Forget about this canvas stuff. Canvas is great for drawing nice dynamic pictures, but it cannot increase security in any way. The fact that it doesn't leave an actual ".jpeg" file somewhere in the tmp folder doesn't mean a thing. As long as I can do what I did as a kid and make a screenshot, your click blocker (it's really just that) is useless. And even if I couldn't make a screenshot: Since you have to somehow send me the data of the image (in whatever format), I could always take this data and recreate the image whenever I want.
The problem of serving different data to different users is the oldest problem of the Internet and has already been solved many decades ago, way before anybody even thought about canvas elements and HTML5: You authenticate the user on the server, you choose or generate the user-specific data, and then you send it. That's it. No magic needed.
In your case: Store different versions of the main image or the main image itself outside of the document root. Write a PHP file to authenticate the user (with an API key, for example). Choose the right version of the image or extract it from the main image. And then serve it. It's really, really simple, and it works.
Again, I understand that you really like HTML5 and wanna do something interesting with it. But you've chosen the wrong job for the tool.
June 17th, 2013, 09:03 PM
Uncompressed image data is massive: consider a 100x100 24-bit color thumbnail.
A JPEG version of the image will be about 15KB.
If you allocate 1 byte for the x coord and 1 byte for the y coord (giving you a maximum image size of 255x255), the size of the image will be 390KB. Even if you skip the x/y coord, the image size is still 235KB per thumbnail.
300 100x100 thumbnails would be almost 70 megabytes. On a 1.5Mbps broadband connection at maximum theoretical speed, you would spend almost 3.5 minutes waiting for the image to just transfer. Additionally, unlike a normal image, the browser wouldn't be able to show any images during that wait period. Then if your system can only render 300k px/s, you'll spend another 10+ seconds waiting for it to render.
The amount of memory, data transfer and processor power required to do that is simply not realistic. Not to mention that anyone who has enough knowledge to know what fiddler or an element inspector are is going to be able to write a script to decode the image data if they want it anyway.
- Protect your images with authentication
- Don't combine the images together
- If you have too many HTTP requests on one page, use pagination
- If you need to combine images anyway, do it on the server side with GD or ImageMagick
- Putting a transparent GIF over the image will prevent non-technical people from saving the image
- Nothing can prevent technical people from saving the image