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?
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? 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.
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.
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]>
To: Tomcat Users List <[EMAIL PROTECTED]>
Subject: Re: problem with session tracking and redirection http<---> https
Date: Fri, 18 Oct 2002 21:48:36 -0700 (PDT)
On Fri, 18 Oct 2002, Maninder S Batth wrote:
> Date: Fri, 18 Oct 2002 19:28:59 -0700
> From: Maninder S Batth <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: problem with session tracking and redirection http<---> https
>
> please correct me if i am wrong. Session id could be hijacked anytime if
> it is transmitted as clear text. so once user has loged in , and user
> gets new session id , this session id could be sniffed
> and the person can still be impersonated.??
Yes.
> how is this related to
> https-->http transitiion?
If the session was originally established on the https connection, the
session id has never been transmitted in the clear, so it cannot be
hijacked except when the application accepts a non-https request for that
session (or the attacker can impersonate an existing SSL session, in which
case we've all got much bigger problems).
If the session was originally established under https, but the application
switches back to http, the session id is transmitted in the clear from
that point on, and is subject to hijacking. This is the logical flaw we
discussed earlier this week with regards to a request to accept the login
screen on https (to avoid the password being transmitted in the clear) and
then switch back to http for the remainder of the session. From the
security point of view, this is worse than useless (worse because it gives
you a false sense of confidence).
Craig
>
> Craig R. McClanahan wrote:
>
> >On Fri, 18 Oct 2002, Henrik Bentel wrote:
> >
> >
> >
> >>Date: Fri, 18 Oct 2002 23:07:17 +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
> >>
> >>
> >>
> >>yeah, I always encode the redirection URL.
> >>it's waird that it works if the session is created which under http, but not
> >>under https.
> >>
> >>bug maybe?
> >>
> >>
> >>
> >
> >Nope ... avoidance of a huge security hole.
> >
> >Once a session is accessed via https, it should never ever be allowed to
> >be accessed from http again. The reason for this is that the session id
> >is transmitted in clear text, so anyone who can snoop the network can
> >hijack your session and impersonate the originally authenticated user
> >(even if that user originally authenticated on an encrypted channel).
> >
> >Do not, under any circumstances, design applications that depend on
> >maintaining session state across an https --> http transition.
> >
> >Craig McClanahan
> >
> >
> >--
> >To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
> >For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
> >
> >
> >
>
> --
> Your favorite stores, helpful shopping tools and great gift ideas.
> Experience the convenience of buying online with Shop@Netscape!
> http://shopnow.netscape.com/
>
>
--
To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
_________________________________________________________________
Internet access plans that fit your lifestyle -- join MSN. http://resourcecenter.msn.com/access/plans/default.asp
--
To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
