Web Application Security
Unable to impersonate another user although having its cookie Jul 01 2009 10:14AM
Juan Kinunt (kinunt gmail com) (4 replies)
Re: Unable to impersonate another user although having its cookie Jul 03 2009 08:47PM
Guillermo Caminer (flaco webappsec gmail com) (1 replies)
Re: Unable to impersonate another user although having its cookie Jul 06 2009 06:22PM
José Manuel Molina Pascual (raistlinmolina gmail com)
RE: Unable to impersonate another user although having its cookie Jul 01 2009 04:26PM
Hellman, Matthew (Hellman Matthew principal com) (1 replies)
Re: Unable to impersonate another user although having its cookie Jul 02 2009 02:11PM
Guillermo Caminer (flaco webappsec gmail com)
Since HTTP is a stateless protocol, the only way the server can relate a request to a user is to
maintain a session: in your case, with a cookie. But of course, it is possible to use ANY data in
the HTTP request to do this association (data which you CAN control, unless there is some encrypted
parameters) and maybe (unfortunately for you) some data you can not (like origin IP address, SSL ID).

So go ahead and play with the parameters you can control and try to reproduce the stolen session
request.

One more thing: are you considering the application business logic? Some applications require the
actions to be taken in a certain order. Ex: opA, opB then opC. Maybe you're "jumping" actions (going
from opA straight to opC) and that's why you're getting disconnected. Always consider the
application business logic.

By the way: you do not need to use different browsers to test sessions. You can run two instances of
firefox with the 'no-remote' command line option. This way you can have to different instances which
do not share cookies (you can also have two different firefox profiles running). This way you don't
have to copy the User-Agent header that IE is sending to the server.

Guillermo Caminer

>>> 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 (at) principal (dot) com [email concealed] 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.
>
>
>
>

[ reply ]
Re: Unable to impersonate another user although having its cookie Jul 01 2009 02:30PM
Irene Abezgauz (irene abezgauz gmail com) (1 replies)
Re: Unable to impersonate another user although having its cookie Jul 01 2009 02:42PM
Michael Yelland (myelland brotherhoodbank com)
Re: Unable to impersonate another user although having its cookie Jul 01 2009 02:00PM
pUm (hijacka googlemail com) (4 replies)
Re: Unable to impersonate another user although having its cookie Jul 01 2009 03:02PM
jay tomas infosecguru com (1 replies)
Re: Unable to impersonate another user although having its cookie Jul 01 2009 03:29PM
Christopher Firth (lists 100mb com au)
Re: Unable to impersonate another user although having its cookie Jul 01 2009 02:50PM
Marc Ouwerkerk (olderchurch gmail com)
Re: Unable to impersonate another user although having its cookie Jul 01 2009 02:39PM
S I (skander iversen gmail com) (1 replies)
Re: Unable to impersonate another user although having its cookie Jul 01 2009 04:20PM
Heine Deelstra (hdeelstra gmail com) (1 replies)
Re: [SOLVED] Unable to impersonate another user although having its cookie Jul 02 2009 02:53PM
Juan Kinunt (kinunt gmail com)
Re: Unable to impersonate another user although having its cookie Jul 01 2009 02:20PM
Brad Causey (bradcausey gmail com)


 

Privacy Statement
Copyright 2010, SecurityFocus