Page 2 of 2 First 12
  • Jump to page:
    #16
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2012
    Posts
    16
    Rep Power
    0
    Originally Posted by Jacques1
    No.

    When you send the whole picture, the client has the whole picture. There's nothing you could do to change that. As soon as the picture arrives at the client, it's too late to protect it.

    Whether the browser stores this picture in the temp folder doesn't matter. The fact is, the user has received it, and this allows them to watch it. Most browsers have developer tools, which let you go through all received data. But you might as well record the network traffic (as already mentioned by E-Oreo).

    Once your server has sent the data, the user has full access to it. Period. You cannot restrict the access afterwards, hide certain parts or anything like that. If the response is out, it's out -- just like a letter. You cannot send somebody a letter and then somehow have them only read certain parts of it.

    Understanding this is very, very important, because it's pretty much the foundation of all web security.

    You either have to store different versions of the "big picture", each one containing only the things that are meant to be seen by a particular user group. Or you need to create the picture dynamically with a server-side graphics library. But you cannot have one picture for everybody and "filter" it with JavaScript.

    And of course you mustn't allow direct access to any private picture, because this would make nonsense of all the protection. You have to deliver them with PHP after successful authentication.

    Great answer!

    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.

    I've only done a couple of image effects in javascript that involves drawing individual pixels, but fillRect draws about 300 000 pixels a second on my ancient laptop, $ctx.putImageData; does about 100 000 ops/sec on my iphone, so you could write a script that "scans" each individual pixel and then logs the rgb & x/y coords in a javascript file.

    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
    Here is one security flaw I see; just right off the bat:
    Code:
    xmlHttp.open("GET","botparts.xml",false);
    Ok, botparts.xml is not dynamic based on say (an individuals login; ie => botparts.xml?cousin=bob&key=293092URIJKDF). So, that being said: I view your source code; download your XML file and your page with the JS code in it; then I manipulate it to show full photo and upload files to internet for all to see. Which, by the way... would be super easy; because all I have to do is attach your base domain to this:
    Code:
    imagepath[2] = "/bigpic/familyfun.png"
    Like so:
    Code:
    imagepath[2] = "http://www.myfamilymemorys_or_whatever.com/bigpic/familyfun.png"
    And... I just exploited your content and if I want to be slick like rick; I just download all of your internal files; serve them up on a fraudulent website and pone them off as mine or... even worse... yours; for all the world to see. And trust me... ppl do it all the time. Websites like this are used predominantly for Phishing, but can be extremely malicious and try to destroy your online reputation (if you have one established); then in turn hurting your businesses name. They may even infect this new created fraudulent website with viruses and then they will keep on causing harm to others; long past your initial impact. No one will want to use your site again; for photos services or anything else for that matter, because of your now infamous security whole.

    Slippery Slope: Your customers leave your site or who knows, they may even legally seek damages for your lack of security of intellectual property. And... who know's; a judge might actually award them a settlement. Then you loose your business or may even do a little jail time. Haha, now; all of this is loosely formatted on a extremely unlikely end result, but you get the idea; behind what everyone is telling you (above) and that is: basically when you send non-protected data, in any type of HTTP stream; that can be interpreted by a browser, there are ways around your methods of client side interception/security barriers.

    Now, my advice: do a subscription based download service of the images; based on server side login interactions with a database. Yes, someone can try to back door hack into your database or try to make it crash with a bruit force attack; so they can get the login info and/or the image data, but that is a far less likely scenario; then me, viewing your source code and having complete access to all your content.
    Superb post!!

    Yes, you are absolutely right - I mentioned it in my previous post, but I didn't put it in my coded example: the image (now turned javascript file as per Jacques1 post) that is being served up is under this rewrite rule:

    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?
  2. #17
  3. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    You've really fallen in love with that idea, have you?

    Why do you think this JavaScript file is better than an actual image? It is an image, it's just a different way of expressing it. Anybody can easily turn those JavaScript commands back into pixel data. You can either have JavaScript render it and make a screenshot, or you can write a simple JavaScript -> JPEG compiler.

    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.

    Forget about canvas, forget about XML, JavaScript, HTML5 and all that other fancy stuff. You've fallen victim to the law of the hammer: If all you got is a hammer, everything looks like a nail. Meaning you try to use a tool you like for a problem it isn't suitable for.

    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.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  4. #18
  5. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,317
    Rep Power
    7170
    so you could write a script that "scans" each individual pixel and then logs the rgb & x/y coords in a javascript file
    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.

    let's say you have a very big image containing 300 smaller large thumbnails for your online family album.

    In order for this to work we don't want to use PHP's gd library to split it up to individual thumbnails as that would create a new http request for every image and our webserver - every image taking say 0.5 sec because the webserver only allows for 2 simultanious http connections just for the sake of argument.

    that would then be 2.5 minutes worth of waiting for the images to load.
    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
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
Page 2 of 2 First 12
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo