A successful CSRF attack involves the attacker tricking the victim user into performing an unintentional action. It gives an attacker the ability to partially get around the same-origin policy, which is meant to stop various websites from interfering with one another. For instance, they might need to do this to make a money transfer, change their password, or update their email address on file.
In addition, the attacker might take complete control of the user's account depending on the nature of the action. For example, the attacker might be able to fully control all the data and functionality of the application if the compromised user has a privileged role within it.
Examining a practical example is the best way to comprehend a CSRF attack. For example, assume that your bank's website offers a form that enables money transfers from the user who is currently logged in to another bank account. The transfer form, for instance, might resemble the example shown above.
The corresponding HTTP request might look like this:
POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: JSESSIONID=randomid
Content-Type: application/x-www-form-urlencoded
amount=100.00&routingNumber=1234&account=9876
Let's say you log in to your bank's website and then visit a malicious website without logging out. An HTML page with the following format can be found on the malicious website:
<form method="post"
action="https://bank.example.com/transfer">
<input type="hidden"
name="amount"
value="100.00"/>
<input type="hidden"
name="routingNumber"
value="evilsRoutingNumber"/>
<input type="hidden"
name="account"
value="evilsAccountNumber"/>
<input type="submit"
value="Win Money!"/>
</form>
You press the submit button because you enjoy winning money. But unfortunately, you unintentionally sent $100 to a malicious user during the process (See the input type is defined as hidden in the form). This occurs because the malicious website cannot see your cookies, and the bank-related cookies are still sent with the request.
Even worse, JavaScript could have automated the entire procedure. This implies that you weren't even required to press the button. It might also occur if a user visits a legitimate website that has been the victim of an XSS attack.
Note: Commonly asked Spring Security interview question