Henrik Bentel wrote:
One of my problems is that I can't find anything in the servlet or tomcat documentation that mentiones any of this behaviour. If there is any, please send me the link.
Hi Henrik, I couldn't find anything specific in the Servlet Spec, but in general it's just not a good idea, as you may as well not use https at all. It's not just the servlet spec that you need to be aware of, but this is a more general HTTP/HTTPS problem. RFC2109 is not really clear on the topic, other than section 8.3 which talks about Unexpected Cookie Sharing. However there is an extension to this RFC, RFC2965 "Port Sensitive Cookies". Basically, you can't guarantee that the browser is going to send back the cookie if the ports are different
Also, since any time session tracking is used it can be picked up by someone, all use of https should stay strictly under https(ok, I'm over doing it). So basically if a webapp has any sensitive information, it should solely use https protocol for all transmissions, if using session tracking?
You're not over doing it. If you want to provide some security or protection of authentication then the entire session _must_ be encrypted or you may as well not bother.
I don't see why the servlet container should force this behaviour.
You can do your own session tracking if you want to. Just set your own cookies and use that. The servlet container provides a very convenient way of doing it. Of course, you'll have the same transition problems that the inbuild session management has.
Shouldn't it be up to the developer to determine what is a security issue and not? Just like JSP doesn't neccesseraly force the separation of business logic and content, just allowing it, should the servlet container force a restrictive behaviour of session tracking?
A lot of web sites don't want the over head of sending everything over https. Only parts of it for secure user validation. But they still want session tracking.
They may do, but they're broken if they don't keep an authentication session "safe" under ssl. Of course the session tracking can be used at different times for non crucial session tracking.
Just as a simple example:
So let's say you use the existence of an http session as a validation for a logged in user, but you don't store any "vital" information.
And you only allow http sessions to be created under https protocol to secure the submition of password. Beyond that point, no sensitive data is shared, so users can be redirected back to http protocol.
You really need to read up on how HTTP and the servlet spec says sessions are done. Basically HTTP is stateless and sessions are "faked" by transferring chunks of data between the client and the server. This may be via cookies or URL rewriting. For the sake of convenience, we'll use the cookie method in the example, but this is _not_ necessarily the only way that sessions may be tracked. So, you login "securely" under username and password "admin/secret" and those pieces of information are gone and lost forever. However, to maintain the session over the stateless protocol the server sets a cookie in the browser "SECRET_COOKIE=aaa56722derf". Now, as you transition to HTTP that piece of information is sent to the server in plain text that anybody can read. So, me being the evil wily hacker grabs that information, and sets a cookie in my evil hacked mozilla browser which will allow me to set arbitrary cookies and bingo, I'm now you.
With tomcat 4, the only way to use the same method would be to create a http seesion for every http request, then redirect to https, add some kind of validation flags in the session object, then redirect back. This to me is worse, as a DoS attack could force the servlet container to create a http session for every "Request", really putting a strain on your container.
I can't possibly think of any circumstance where you would need to perform such a contrived mechanism. In fact, I can't even understand what you're trying to do here. [ snip of rest of post ] -- Jon Eaves <[EMAIL PROTECTED]> http://www.eaves.org/jon/ -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
