Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Subject: Re: [OT] loading images through a Servlet
To: users@tomcat.apache.org
References: <7kdxlpyy353qxhw0asl5xene.1443782661038@email.android.com>
 <560E9215.2080807@ice-sa.com> <560ED89F.4070104@cgl.ucsf.edu>
From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat=29?= <aw@ice-sa.com>
Message-ID: <560EEF2C.400@ice-sa.com>
Date: Fri, 2 Oct 2015 22:55:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <560ED89F.4070104@cgl.ucsf.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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 ?

> 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