[OWASP-Delhi] Anti-CSRF token in cookie and post form

reuben kurien reubengkurien at gmail.com
Tue Jul 7 18:42:38 UTC 2015


Hi Vaibhav,

In your case, you only need to match token A with token B in the same
request. Now I understand that you cannot control the token A value in the
cookie, but can control the token B value  in the post form.

Actually you need not control token A. You just need a mechanism to know
what is the value of token A that is currently being sent by the browser to
the server (assuming it is not per request, but per session or worse, valid
for a preset period of time). For this you'll require to be able to execute
Xss on the cookie (i.e., without httponly flag), predict or "fix" the
cookie value. Alternatively, assuming the "secure" flag is not set for this
particular cookie, it may be possible to make the user click on a http url
of the app(using social engineering) which will make the browser send
currently valid cookie values in clear text over the wire. At this point an
attacker who can sniff traffic can obtain the cookie. If your application
is already running on HTTP, then you need not bother with the above methods
since you have greater problems at hand than CSRF. :-)

Now, whether these things are possible in your scenario was not clear to me
from your description. Hope this helps.

Regards,
Reuben
Apologies for not being clear at first place. I'll give it another shot :-)

The application has a Anti-CSRF token checking mechanism in which it is
just checking if the Anti-CSRF token sent in POST request is the same as
present in the cookie value being sent in the same POST request.

Now, since the application is not checking if the Anti-CSRF token presented
in the POST request is the same as what was set earlier, it is viewed as
vulnerable.

For creating a valid CSRF poc, I need to craft a POST request in which the
form has a Anti-CSRF token (may be '123') and I need to send the same
Anti-CSRF token in the cookie value.

Problem with creating this CSRF poc is, that HTML/JS code can not send
 cookies to the server due to the restriction in JavaScript (they are just
auto sent by browser itself).

Any way to create a working exploit?

On Sun, Jul 5, 2015 at 2:22 AM, Pankaj Upadhyay <mr.p.upadhyay at gmail.com>
wrote:

> A lot of web applications keep session-cookie as secure and other cookies
> as it is. If that is the scenario, adversary will be able to sniff the
> cookie and get the CSRF Token.
>
> "Now the problem is that we can not manipulate cookie value with
> Javascript "
>
> I didn't understand the above statement. Are you saying that this cookie
> has Httponly attribute set?
>
> Thanks
> Pankaj
>
> On Saturday, July 4, 2015, Vaibhav Gupta <vaibhav12jan at gmail.com> wrote:
>
>> Hello all,
>>
>> I recently encountered an application which was having its random
>> anti-csrf token in cookie and the same random token was sent in the POST
>> form. If I tamper the cookie and the post form anti-CSRF token with the
>> same value, server will validate my request.
>>
>> Example:
>>
>> POST /account/delete
>> HOST: XYZ
>> Cookie: CSRF_Token=123456
>>
>> account_id=10101&CSRF_Token=123456
>>
>> Now the problem is that we can not manipulate cookie value with
>> Javascript and hence cannot fiddle with the anti-csrf token present in
>> cookie. Is there a way to create a working exploit?
>>
>> Apologies if I am unable to clear the scenario.
>>
>> Thanks
>> Vaibhav
>>
>
>
> --
> Sent from MI3
>


_______________________________________________
OWASP-Delhi mailing list
OWASP-Delhi at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-delhi
LinkedIn Group: https://www.linkedin.com/groups?gid=89270
Twitter: https://twitter.com/OWASPdelhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-delhi/attachments/20150708/ed374253/attachment.html>


More information about the OWASP-Delhi mailing list