Re: Re: Re: The sound of one cookie (not) authenticating

[sutch]

Right, hidden fields are not secure. But Hero Zzyzzx was not concerned about secure sessions (I assume he would handle that through SSL). Instead the issue is that customers can mistakenly give away a link into their session just by giving the current URL to someone else.

I don't understand how computing a hash will prohibit sessions from being transferred with URLs. Is the server or the browser going to compute the hash? If the browser, then JavaScript is required (and I believe the issue is not requiring the customer to use cookies, and possibly other optional browser features like JavaScript). If the server, then the URL is usable by any browser (which means that it can be given to others along with the hashed session ID).

[arhuman]

Instead the issue is that customers can mistakenly give away a link into their session just by giving the current URL to someone else.

Ok I may have missed the question, it thought it was What's the best way to avoid Joe Blow having access to the original shoppers cart?.


I don't understand how computing a hash will prohibit sessions from being transferred with URLs

The hash use is only to one way to secure a parameter (verbatim from my post)
A parameter hashed this way can't be used in another session nor faked.


Is the server or the browser going to compute the hash?

The server, beccause only the server knows the 'private value'...


If the server, then the URL is usable by any browser (which means that it can be given to others along with the hashed session ID)

As the hash value is bound to an id session you just can't use it with another session !
So you can't reuse and old hash value nor even compute it (if you know your id session) to feed it to the server as you don't know the private value...

"Only Bad Coders Badly Code In Perl" (OBC2IP)

[sutch]

I still don't see how this prohibits sessions from being used by another browser. Maybe there is something obvious that I am missing. arhuman, can you please clarify this for me?

What information is used in the hash?

If the information in the hash is not directly tied to the browser (such as IP address, browser name), I don't see how a server can determine if the "incorrect" browser is requesting the session.

If only the session key and some private value is used in the hash, how does the server determine if the hashed value came from the browser that it was originally sent to or some other browser?