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

Dhruv Soi dhruv.soi at torridnetworks.com
Tue Jul 7 19:42:02 UTC 2015


Thats correct.

It can be done with a combination with some other vulnerability like
File upload, stored XSS, and not straight forward.

On Tue, Jul 7, 2015 at 11:13 PM, Minhaz A V <minhazav at gmail.com> wrote:
> Hi Vaibhav,
> You cannot create or set or read cookie for another domain from your domaim.
>
> So CSRF of this kind wouldn'tbe possible.
>
> Not sure, if I could understand it fully. Have written quick code for
> you to assess my understanding:
>
> ==poc.html==
> <!DOCTYPE html>
> <html>
>   <head>
>     <script>
>       function myFunction() {
>         document.cookie = "csrfToken=token123";
>
> document.createElement('form').submit.call(document.getElementById('myForm'));
>       }
>     </script>
>   </head>
>   <body onload="myFunction()">
>     <form id="myForm" name="myForm" action="http://localhost/poc.php"
> method="POST">
>       <input type=hidden name="username" id="username"
> value="someusername"/>
>       <input type=hidden name="csrfToken" id="val3" value="token123"/>
>       <input type=hidden name="submit" id="submit" value="Continue"/>
>     </form>
>   </body>
> </html>
>
> ==poc.php==
> <?php
>   var_dump($_POST);
>   var_dump($_COOKIE);
> ?>
>
>
>
> On Tue, Jul 7, 2015 at 9:03 PM, Vaibhav Gupta <vaibhav12jan at gmail.com>
> wrote:
>> 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


More information about the OWASP-Delhi mailing list