tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eilers <>
Subject Re: Why are some header values hidden in ?
Date Wed, 13 Sep 2000 14:08:07 GMT

ReHi !

> > [...]

> > More detailed questions:
> >
> > What is the reason to exclude the "authorisation" header by the following
> > code ?
> >
> > if (!match.equals("authorisation"))
> >         request.addHeader(name,value);
> >

> The concern in this case was that the user credentials might get
> inadvertently exposed -- for example, if you were running SnoopServlet 
> the protection of a security constraint.  The philosophy behind this is 
> container managed security should be totally transparent to applications.

Well I do unterstand the intention behind that,  but ...

> For your particular scenario, you can find out the username
> (request.getRemoteUser()) -- you just cannot find the password.

>  However, it
> does make your use case pretty difficult to implement.

> What would you think
> about a configurable parameter that defaults to suppressing this header, 
> allows you to change this if you need it?

Well, if it was just for that special use case of mine I would say a 
configurable parameter is OK and i don't care about what it's default is.

On the other hand i don't really get the argument of inadvertently 
exposed credentials.
Either a Authentication mechism is secure or it is not secure.
HTTP/1.1 defines some secure and some lazy secure or insecure 
authentication mechanisms.
If access to the Authorisation header reveals security relevant 
information this can only be the case if an insecure authentication 
mechanism is used anyway ( eg. basic authentication ). 

I can see no valid reason to make the endpoints of a client server 
connection more secure than what already is revealed over the network 
connection. Why should the software running on the server get less 
information than the attacking man in the middle. If it can be 
/sbin/snoop (ed) on /dev/ether why should a SnoopServlet not see it ?

On the other hand the documentation for getHeaderNames() in the servlet 
API is

Returns an enumeration of all the header names this request contains

So if it really is useful for some cases to have that configurable 
parameter that allows the container to turn that all to most ( which it 
don't really think it is ) this should be clearified in the servlet ( 2.3 
) spec and servlet programs should have a some hasAllHeaderNames() kind 
of function available.

> >
> > And what is the reason for excluding the jsession Session ID Cookie from
> > the list of cookies by using this construct ?
> >
> > if
> > (cookies[i].getName().equals(org.apache.tomcat.connector.Constants.Sessi
> > onCookie))
> > // ...
> > else
> > request.addCookie(cookies[i]);
> >

> A similar philosophical reason -- container session management should 
also be
> transparent. 

If something is transparent doesn't that mean than you can look through 
it and see everything on the other site ;-)

> For your "proxy" use case, it seems like a configurable option
> for this would also solve the problem.

Here my argument against this is also similar as for the header names,

The documentation for getCookies() in the servlet API at least for now is

Returns an array containing all of the Cookie objects the client sent 
with this request.

Unless this is not identified as an errata in the Java servlet 
specification it shouldn't be implemented differently to this 

Summing everthing up so far:

I think the best would be to have a configurable option as you suggested,
but the default should be not to suppress this header and not to suppress 
this cookie because the DEFAULT for tomcat should be to be compliant to 
the servlet api specification.

> Craig

> ====================
> See you at ApacheCon Europe <>!
> Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
> Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
>                                     Applications to Tomcat


View raw message