tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
Date Fri, 06 Feb 2009 18:53:01 GMT
Dave Pawson wrote:
> 2009/2/6 Caldarale, Charles R <Chuck.Caldarale@unisys.com>:
>>> From: Dave Pawson [mailto:dave.pawson@gmail.com]
>>> Subject: Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the
>>> place to constrain the mime type?
>>>
>>> Unless the client specifies that one single mime
>>> type (and no other), I want to reject it
>> Unless you have an extremely specialized client in mind, you will be rejecting all
requests.  No browser will ever limit itself to a single mime type.
> 
> 
> That's it. Again, my code, hence very specialised.
> No browsers, IE or FF! Just my java end point.
> 
I believe that what Chuck is trying to tell you - and in many more words 
than his - is this :

Your service, whatever it is, will have a listening TCP port, waiting 
for requests from your clients.
Thus, any of many available programs out there (not talking only about 
browsers), can connect to that TCP port, and basically send anything 
they want to it. Including things resembling the requests you are 
expecting, with whatever HTTP headers they want to specify, including 
those which you would maybe use to attempt to distinguish your genuine 
clients from the others.

Thus, rejecting requests on the base of something they include or not, 
unless the something is some secret encrypted key available only to your 
server and its genuine clients, will not be a good enough measure if 
your goal is to avoid someone downloading something from your server 
that they shouldn't.

I (or anyone else on this list) can fake any such HTTP request, at any 
time, within 1 minute of you giving us the hostname and port, and 
download one of your xml templates.
And we would not even have to write any new program to do it.

If there is a secret key, and if it is fixed, then anyone once capturing 
a packet between your clients and your server, would be able to re-use 
that key and fake one of your clients forever.
If the key is variable, but based on some simple algorithm, then 1) you 
would still have to develop the algorithm and 2) unless you are a 
cryptographic expert, someone will break it if there is enough interest 
to justify it, and even only for the fun of it.

If security is one of your purposes thus, do not try to use things like 
content-type headers or the like, use a secure form of communication 
developed by experts and available for free, such as HTTPS.
You would just have to plug-in the pieces, and then develop your 
application as if the security layer wasn't even there.

And if security is not in the picture, then forgive me the above 
lecture, I got lost somewhere along about what your purpose really is.

But if you're still interested, I have a similar lecture about the 
difference between Valves and servlets (or servlet filters), and why one 
may be more adapted than the other to any particular purpose.
Not at any deep Tomcat/Java level though.



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


Mime
View raw message