[ic] New SecureProtect directive to prevent sidejacking

[Mike Heins]

Quoting Peter (peter at pajamian.dhs.org):
> On 30/10/10 17:13, Mike Heins wrote:
> > Quoting Peter (peter at pajamian.dhs.org):
> >> Why do we need to limit it to logged in users?  Why can't we protect
> >> secure pages in the session before someone is logged in?
> > 
> > Nothing stops you from generating your own MV_SHASH via another
> > process. Feel free.
> > 
> > But what information would you base the hashing on? We can't use IP
> > address or MAC address, if they are sniffing. Session keys are kind of
> > pointless -- if you did that you would only be protected on
> > the *second* page. What's the point?
> 
> What about just a random token stored in the session itself?  If the
> secure cookie has the wrong token or non-existent then secure access is
> denied.

That prevents the multi-day de-authentication scheme.

> 
> > And why would you put secure information in a session before someone
> > authenticates? In normal operation, you don't want to use SSL, and
> > why waste CPU cycles on a random non-authenticated user?
> 
> Someone can go right through to checkout without logging in, and even
> complete checkout as a "guest" (albeit with an implicit login).
> Certainly a good deal of data can be accumulated just from the browsing
> habits of the user, what items they add to their cart, etc. before they
> login.  On a multi-page checkout there is even personal telephone and
> address data that is stored and can be retrieved, and all before the
> customer has to login.

That type of behavior doesn't make them a target for sidejacking.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.328.4479  <mike at perusion.com>

Being against torture ought to be sort of a bipartisan thing.
-- Karl Lehenbauer