tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darryl Miles <darryl-mailingli...@netbauds.net>
Subject Re: Session hijacking with Tomcat/Myfaces - unable to fix it
Date Fri, 11 Aug 2006 03:27:19 GMT
Tomas Hulek wrote:
> Unfortunately, filters are skipped (ie. not called at all) when form-based
> login page is processed as a result of client requesting a secure area.
> 
> We tried that too...
> 
> By the way, the original URL that the client requested is hidden in the
> session in a way which prevents the web app from copying it to a new
> session object.

Sorry I was thinking of the general usage case (I dont use Servlet spec 
security contraints myself, the mechanisms I use are implemented in 
application code).  Its straightforward to fix the <security-constaints> 
implementation to provide better security since it has access to 
internal container code, but...

That still leaves a pure web-app developer out in the cold.  Because 
there is no mechanism for him to ask the HttpSession object if it has 
been exposed to a non-secure channel.  Only Tomcat can manage this extra 
flag situation effectively because it is container code that is in 
charge of session management and emitting the Set-Cookie line, so when 
it does that it sets a flag if the connection is not considered a secure 
channel.

This is the only missing building block a web-app developer needs to 
know to be able to reliably fix the problem from there.


And like I said the client end of the problem is sorted with the 
"Secure;" attribute.  So the client can be trusted not to leak 
information at the wrong time.  The problem is that the lack of 
mechanism at the server end to do the same.


The cleanest way to implement a solution is to have a 
sessionIdHasBeenExposedViaUnsecureChannelFlag and also have a built in 
HttpSession.makeSessionSecure();


public HttpSession makeSessionSecure(HttpServletRequest request) {
  HttpSession newSession = null;
  if(request.getScheme("HTTPS")) { // this might be too crude for 
production use in detecting if the request is via a secure channel
   // there is no point making the session secure if the request we are 
currently on is not secure itself
   if(thisSession.hasBeenExposedViaUnsecureChannelFlag()) {
    newSession = HttpSession.createNewSession();
    newSession.setSecure(true);  // turns on the "Secure;" flag
    // Ideally we should have a create and setSecure() as one atomic 
action ensuring the session never existed for any moment without the 
Secure flag set.

    // Migrate data
    for(Object o : thisSession.getAttributes()) {
     newSession.setAttribute(o);
    }

    // Possibly do internal session management stuff (as necessary)

    thisSession.invalidate();

    // Possibly do stuff to force new Set-Cookie line in next response 
(but I think that happens by default anyway, even through it does not 
have to as the client remembers it)
   }
  }
  return newSession;
}


Then the caller just needs to "security prune" the attributes that were 
migrated after calling.

You could probably dump the 'request' argument, I was just making the 
obvious point that there is no use making a session secure if we're not 
already inside a secure channel.  But that could be considered 
misuse/application programming error.


The actual enforcement of secure channel can then be done easily inside 
a regular web-app filter.  With a check along the lines of

if(session.hasBeenExposedViaUnsecureChannelFlag()) {
  session.invalidate()
}



I agree with the original poster, it is not practically possible to use 
HTTPS for everything.  The HTTP protocol has a clear mechanism to deal 
with this security concern.  The culprit here is the lack of 
understanding on this issue by the Servlet specification and therefore 
Tomcat.



In response to the guy suggesting different path's well the HTTP Cookie 
specification allows for this also with the 
Path="/ServletContext/secure"; attribute.  But going down this avenue 
you are placing unnecessary restrictions on a web-application, where as 
the approach above does not.


Darryl

---------------------------------------------------------------------
To start a new topic, e-mail: users@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