|
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 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) 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 |
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
Juan Kinunt wrote:
> Hi,
>
> I'm auditing a web application programmed in CakePHP and I'm having a problem.
> I'm almost sure the authentication mechanism is carried by a cookie
> but I'm unable to impersonate another user using its cookie.
> 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.
> I think that some info is stored in server side about the client who
> owns each cookie.
>
> Is this possible? Is it the normal operation in sessions in CakePHP?
>
> Any info or pointer would be very useful.
>
> Thanks.
>
>
>
[ reply ]