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 21:02:58 GMT
On 10/2/2015 1:55 PM, André Warnier (tomcat) wrote:
> On 02.10.2015 21:18, Bill Ross wrote:
>> 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
>
> isn't that a giveaway still ?

It gives some random information for someone to chew on, until they find 
this email:

          "resized_" + rand.nextInt(7) + "_" + rand.nextInt(100000) + ".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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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