[ic] New SecureProtect directive to prevent sidejacking

[Peter]

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.

> 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.


Peter