tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Ross <r...@cgl.ucsf.edu>
Subject Re: [OT] loading images through a Servlet
Date Fri, 02 Oct 2015 19:18:55 GMT
Installed FF, HttpFox wasn't installed, installed it but it doesn't show 
up under developer tools, but I found something and here are my headers:

HTTP/1.1 200 OK
Etag: W/"resized_2_33068.jpg-1443146350159"
Last-Modified: Fri, 25 Sep 2015 01:59:10 GMT         [random time in 
past 22.32455 days]
Expires: Sun, 01 Nov 2015 19:12:45 GMT
Content-Type: image/jpeg
Content-Disposition: inline;filename="resized_2_33068.jpg"; 
filename*=UTF-8''resized_2_33068.jpg
Content-Length: 157896
Server: Jetty(9.3.4-SNAPSHOT)

Bill

On 10/2/2015 7:17 AM, André Warnier (tomcat) wrote:
> On 02.10.2015 12:44, Bill Ross wrote:
>> Whether or not I have masked the file name in the header properly, 
>> which I can't verify easily
>
> Oh yes you can.
> Mozilla Firefox, plugins, Web Developer, HttpFox.
> click and open in its own window.
> click start
>
> then get your page (in the main window)
>
> then go back to the HttpFox window, click on a line and use the 
> various views available to see exactly what the browser has sent, and 
> what the server returned (headers and all).
>
>
>  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 :-)
>>
>
> You may want to refine your scheme a tad, thinking of the robots 
> (Google etc) which will be exploring your site.  You don't want to be 
> swamped by DANGER messages above for trivial cases (nor communicate 
> their IP to the XXX sites).
>
> Other than that, your scheme looks nice to me so far.
>
>
>>
>>
>> <div>-------- Original message --------</div><div>From: "André

>> Warnier (tomcat)" <aw@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 
>>> <ross@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message