Simulate CSRF attack

Question

I want to simulate CSRF Attack to check the vulnerability of my site. I tried this on my asp.net web application but was unable to simulate. So please help me simulate a CSRF attack. I simulated using test.aspx.

<form name="form1" id="form1" runat="server" method="post" action="mysite.com"> <script type="text/javascript"> document.cookie[".ASPXAUTH"] = "someaspxauth"; document.cookie["ASP.NET_SessionId"] = "somesessionid"; document.form1.submit(); </script> </form> 

What else am I missing? Thanks in advance.

Answer 1

To simulate CSRF, you will not include cookie or session information in malicious code. The whole point of CSRF is that the executable code does not know your session or cookie information. It simply assumes that the browser will include this in its request to the application.

So, to check, suppose you have a Transfer.aspx page that accepts the POST method and the txtFrom, txtTo and txtAmount parameters using the btnSubmit button, and you want to try switching from account 1 to account 2. Your malicious code could be that something like:

 <form action="http://www.mysite.com/Transfer.aspx" method="post"> <input type="hidden" name="txtFrom" value="1" /> <input type="hidden" name="txtTo" value="2" /> <input type="hidden" name="txtAmount" value="500" /> <input type="hidden" name="__VIEWSTATE" value="[PUT VIEWSTATE VALUE HERE]" /> <input type="hidden" name="__EVENTVALIDATION" value="[PUT EVENTVALIDATION VALUE HERE]" /> <input type="submit" name="btnSubmit" value="Go" /> </form> 

You need to know in advance which values ​​will have the form viewstate and eventvalidation, so you will need to copy it from your page when you are logged in correctly. This assumes that your viewstate is persistent, regardless of user or session.

You now have a malicious page. If you are logged in on one tab, open it on another tab and send it if you are vulnerable, then your transfer will occur. The reason is that cookies belonging to mysite.com are being sent, which means that your session, which is alive on a different tab, will be used.

To fix this, you will need a unique value for each session that will be included in your post. This is easiest to do with ViewStateUserKey and set it to the ASP.NET session ID or its hash. This will make your __VIEWSTATE value unique with each session, which means that you will no longer be vulnerable, because no one can predict what your __VIEWSTATE value will be.