How to make CSRF attack using POST request
Imagine if www.example.com processed fund transfers through a GET request that will include two parameters: the amount that is to be transferred and the identifier of the account to which the money will be transferred. The below example shows a legitimate URL, which will request that the web application transfers a 100,000 units of the appropriate currency to Fred’s account.
The request will include with it the Cookie for the authenticated user, so there would be no need to define which account the money will be transferred from. This means that if a normal user would access this URL, they would be required to authenticate, so the web application will know from which account the funds will be withdrawn. Now that we know how this request can be used for legitimate reasons, we can figure out a way how to trick a victim into sending the request that the attacker wants, while authenticated as the victim .
If the web application being exploited is expecting a GET request, then the attacker can include an tag on their own website, that instead of linking to an image, it will send a request to the bank’s web application:
<img src="http://example.com/transfer?amount=1000000&account=Fred" />
The browser, under normal circumstances, will automatically send the Cookies that are related to that web application, therefore allowing the victim to perform a state change on behalf of the attacker, where the state change is a transfer of funds.
CSRF attacks using POST requests
Although this attack works on GET requests considerably easily, attackers can also make use of the POST method to send requests. In fact, most state changing requests will be done through POST requests which will send any parameters and values in the request body and not the URL itself as in a GET request. This means that exploitable web applications will be more likely to accept POST instead of GET requests when a state change is involved.
Take the following example using the onload function, which will automatically send a request from the victim’s browser as soon as the page loads up. Let’s take the following example:
<body onload="document.csrf.submit()"> <form action="http://example.com/transfer" method="POST" name="csrf"> <input type="hidden" name="amount" value="1000000"> <input type="hidden" name="account" value="Fred"> </form>
As soon as the page loads, the onload function ensures that the form named csrf is submitted, which will in turn send the POST request. Taking a look at the csrf form, we can see that it includes two parameters and their values, that have been statically set up by the attacker, where example.com will identify the request as legitimate, since it will include the victim’s Cookies.