RE: Unable to impersonate another user although having its cookie

["Hellman, Matthew" <Hellman.Matthew () principal com>]

> > The probe I do is opening two sessions with two different users (one
> > in internet explorer and one in firefox). Then I copy the cookie
> > belonging to one user and substitute it in a request done by the other
> > user (using WebScarab). The app throws and error and disconnects the
> > validated and legal user.

Can you be more specific?  What is the actual response to the request (e.g. 302 redirect, 401 error page, 404 error 
page, etc). The server can certainly invalidate the session on the backend, but I don't know if I understand what you 
mean by "disconnects".  I assume you mean that session token simply becomes unusable?

> > I think that some info is stored in server side about the client who
> > owns each cookie.

The server only knows what the client told it, which is all contained within the request.  It is possible for the 
server to attempt to validate the IP address and/or some HTTP headers, such as user-agent and referer. Validating the 
headers is somewhat uncommon because they are so easily manipulated. I wouldn't go there first in terms of 
troubleshooting, but that could be it. If we're talking SSL, perhaps the SSL session id is somehow tied to the 
application session identifier?

Did the actual request with the appended cookie value fail?  What can happen is that the browser fetches other 
resources (images, etc) that don't contain the cookie you manually added.  This results in a failure (possibly a 
redirect), obscuring the fact that your "session hijacking" actually worked. I know I've missed this on occasion;-)

> > Is this possible? Is it the normal operation in sessions in CakePHP?

See "S I" response.  Cake has validating the user agent header as a config option it seems.


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Connect () principal com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.