On Sat, 19 Oct 2002, Henrik Bentel wrote:
> Date: Sat, 19 Oct 2002 19:08:35 +0000 > From: Henrik Bentel <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: problem with session tracking and redirection http<---> https > > 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. > It's not specific to servlets at all ... it's a fundamental issue for anything running across http/https that wants to do the equivalent of sessions. > 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? > Not necessarily. Consider an ecommerce site. You'd typically maintain the shopping cart as some sort of collection in a session attribute. You could easily make the case that this information is not particularly sensitive (especially if you haven't collected any personal identification information yet). So, it's quite reasonable to run this part of the app across http. However, once you go to the checkout phase of the app, you should switch to https for the screen that submits the credit card details and that sort of thing, so that nobody can snoop that data as it's being transmitted. However, you are not done yet. Once a particular session has been switched from http to https, it MUST contain logic to never accept a subsequent request (for that session) from http again. Otherwise, your app is subject to attacks like repeatedly submitting the "Purchase Confirmation" form again, and causing multiple orders to be submitted. > I don't see why the servlet container should force this behaviour. Shouldn't > it be up to the developer to determine what is a security issue and not? The http->https transition is supported by the servlet spec (and by Tomcat). That's what the <transport-guarantee> element in a security constraint is for. The https->http transition is not supported because it is fundamentally flawed, and it would be irresponsible for the container to allow naive developers to unknowningly create vulnerable applications. > 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. > > 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. > No you *cannot* do this safely (from a security perspective). The reason is that the session id *itself* is security sensitive information (because you stored state information in the session that login was successful). Once you switch back into http, the session id is transmitted in clear text, and is subject to hijacking. Anyone on the internet can submit requests using that session id, and the requsts will be executed by your app as if they were submitted by the person who was originally authenticated. Developers who feel that it's sufficient to use https only for the login screen, but want to use http for the rest of the session, are fooling themselves that they have accomplished anything useful (from a security perspective). > 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. > > The example probably isn't a good example for how a typical website enforces > secure validation, but I just want to raise the point that the "hole" is > still there, since sessions created under http are available in all schemes. > It could just as easily be misused by a developer. > You are correct that the restriction I'm talking about doesn't deal with DoS attacks based on causing lots of sessions to be created. It deals with a completely different issue. Craig -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
