Whether or not I have masked the file name in the header properly, which I can't verify easily but believe is working, I have definitely masked the name in the URL and protected myself against later downloads:
HTTP ERROR 404 Problem accessing /images/_ewjMC3. Reason: Not Found While on the server side: ...TagResourceServlet - DANGER OLD HASH ATTACK ... Will the fame and money just arrive? I'll settle for 6 month's salary (that's how long I've been working on my own unpaid :-) <div>-------- Original message --------</div><div>From: "André Warnier (tomcat)" <a...@ice-sa.com> </div><div>Date:10/02/2015 2:46 AM (GMT-08:00) </div><div>To: users@tomcat.apache.org </div><div>Subject: Re:[OT] loading images through a Servlet </div><div> </div>On 02.10.2015 11:39, Bill Ross wrote: > And if I find anyone hitting me with unknown or aged-out hashes I will report > their IP addresses to porn sites so they can be blocked there as well. This > honeypot activity could be an alternate source of income, if I hadn't just > disclosed the method :-) > Never mind that. If you have actually found an innovative solution to the "browser-knows-all-anyway" conundrum, much bigger fame (and income) awaits you. > Bill > > <div>-------- Original message --------</div><div>From: Bill Ross > <r...@cgl.ucsf.edu> </div><div>Date:10/02/2015 2:04 AM (GMT-08:00) > </div><div>To: Tomcat Users List <users@tomcat.apache.org> > </div><div>Subject: Re: loading images through a Servlet </div><div> > </div>Thanks Andre for the well-considered reply. To Thad - thanks, I also > asked on stackoverflow after here. > > I believe I have solved the obfuscation problem independent of the > javascript issue. What I just got working is logically: > > img.src = "/images/" + /servlet/getnext(params) > > Where I now have a Servlet at /images that serves the file, thanks to a > generous coder at stackoverflow. I'll post the nicely designed code here > if anyone wants. > > I am adding a table to map random hashes to file names. I'll insert > there and have getnext() return the hash instead of the file name. The > new Servlet I just added will look up the hash, check the age of the > record and refuse it if older than a second, and then serve up the > mapped file from the filesystem with current date and some flippant > random file name in the headers. > > So as far as I can see, the only thing not obfuscated is the image > itself and my ego, which is harmless here. > >> I can think of even more hare-brained schemes where for instance some > Ajax function of yours could open a websocket connection to the server, > and receive a stream of image objects from the server over that single > connection and "plug" them into the page as appropriate. But any kind > of thing like that would start to deviate seriously from standard > practices, and need a serious effort of development and debugging before > it could be considered as "production-level". > > This is exactly what I was fishing for, and I thought maybe it had been > solved in some javascript library. > >> P.S. and if you really want to know how to display tons of images > fast, I suggest that you have a look (in a manner of speaking of course) > at some of those many XXX websites. They /must/ have ways to do this > efficiently.. > > Maybe I will be selling to them :-) Thinking of my slideshow app overall. > > Bill > > > > On 10/2/2015 1:16 AM, André Warnier (tomcat) wrote: >> On 01.10.2015 23:52, Bill Ross wrote: >>> Please let me know if there is a better place to ask >>> Servlet/javascript interface questions. >> >> For the javascript part, there are probably better places. But the >> people here are awesome, so it's worth giving it a try. >> For the servlet side of it, this /is/ probably one of the best places. >> But let's start with javascript : >> >> First a general principle : if you are thinking about security or any >> form of obfuscation in the face of a determined and competent client, >> basically forget it. To get an image or anything else from a server, >> the browser (or else), has to know how to get it, so you need to send >> it that information. And once the server sends any information to the >> client, it is no longer under your control, because the browser (or >> other program, such as curl and the like) is under total control of >> the client (user). >> >> So, as long as /that/ is not your ultimate purpose, >> >>> >>> I have a slide show web page that does the logical equivalent of: >>> >>> var img = new Image(); >>> img.src = "/images/" + /servlet/getnextfile(params) >>> img.[onload]: document["image"].src = img.src; resizeImage(); >>> >>> Rather than using the 'getnextfile' servlet to get a file name and >>> then load it, I would >>> like to have getnextfile return a stream of bytes from the database >>> which seems feasible >>> (streaming a BLOB I assume), but I don't know how to receive that >>> into an Image (which >>> wouldn't have 'src' set - ?). >> >> Have a look here : http://www.w3schools.com/jsref/dom_obj_image.asp >> >> The javascript DOM "img" object does not seem to have any callable >> method by which it can retrieve its own image content. The only way >> to have it retrieve that content, is by changing its "src" property. >> This you can do, and it will apparently refresh its own image by >> itself when you do. >> But the "src" property has to be set to a URL, so it "retrieves >> itself" by making a HTTP call to the server.. chicken and egg kind of >> thing. >> >> In a form of obfuscation, you could try to set the "src" property to >> something like 'javascript: retrieve_image("some id")' (Note: I >> haven't tried this), and then have this "retrieve_image()" function be >> something in one of your javascript libraries, which would in turn >> retrieve the image from the server, in a way less visible to the >> casual script kiddie. >> >> But do not forget that the browser first has to receive that >> javascript library from the server, so it has it, and the person >> controlling the browser can see it, and turn it off at will or modify >> it to do anything he wants; see basic principle above. >> In a more sophisticated way, you can probably add a custom method to >> the img objects on the page (see jquery for that kind of thing), so >> that you can have them change their own src property and retrieve >> their content in a less-immediately visible way. But again, refer to >> basic principle above. >> >>> >>> One motivation is to reduce the round trips to the server for faster >>> response time. >> >> Basically, you still have to retrieve the image from the server, so I >> do not believe that you will gain much on that side. >> >> Also, over quite a long period by now, as well browsers as webservers >> have been both well-debugged and optimised to death, to respectively >> retrieve and serve "things" using the "normal" HTTP methods (think of >> caching e.g., on both sides, and content compression), and avoid >> introducing security holes in the process (*). >> Anything that you would do yourself is likely in the end to be even >> less optimised and secure. >> (This is not to discourage innovation of course. You might after all >> still invent a better mousetrap). >> >> (*) yes, I know, successive IE versions are kind of a counter-example >> to that statement. >> >>> Another motivation is to keep the filename from the user. >> >> See basic principle. Anyone who installs the "web developer" plugin >> into his Mozilla browser, can ultimately find out anything about >> anything that is part of the page shown in the browser. >> >> I can think of even more hare-brained schemes where for instance some >> Ajax function of yours could open a websocket connection to the >> server, and receive a stream of image objects from the server over >> that single connection and "plug" them into the page as appropriate. >> But any kind of thing like that would start to deviate seriously from >> standard practices, and need a serious effort of development and >> debugging before it could be considered as "production-level". >> So the question would be : is it worth it ? >> >> >> P.S. and if you really want to know how to display tons of images >> fast, I suggest that you have a look (in a manner of speaking of >> course) at some of those many XXX websites. They /must/ have ways to >> do this efficiently.. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
