CSRF (Cross-site request forgery)

Cross-site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding.
Vulnerability Name: Cross-site request forgery on [Domain name]
Vulnerability Description:  This vulnerability refers to an attack against authenticated web applications using cookies. The attacker is able to trick the victim into making a request that the victim did not intend to make.
[Don't forget to add your vulnerability description, the one given above is general description]
Payload: [CSRF Payload]
Steps to Reproduce: 
1.Login to the application.
2.Go to the [URL].
3.Save the above CSRF Payload as csrfexploit.html file
4.Open that csrfexploit.html file in the browser, logged-in to the application.
5.Once the page loads, click on submit button.
6.Go back to application, you will the content is updated.
7.This is Cross-site request forgery.
 Proof-of-concept: Snapshots or video link attached.
Impact: The attacker causes the victim user to carry out an action unintentionally. For example, this might be to change the email address on their account, to change their password, or to make a funds transfer. Depending on the nature of the action, the attacker might be able to gain full control over the user's account. If the compromised user has a privileged role within the application, then the attacker might be able to take full control of all the application's data and functionality.
Attack Scenario: Suppose there's a CSRF vulnerability on myprofile page, here the attacker can create a custom CSRF exploit which changes the victims email address, if the victims click on the malicious link passed by the attacker. If the attacker is successful in changing the email address of the victim's account then he can request a new password with the password reset functionality and take full control towards the Victim's account.
[The above was a basic attack scenario you need to alter it according to the Workflow]
Remediation:  The most robust way to defend against CSRF attacks is to include a CSRF token within relevant requests. The token should be:
1.Unpredictable with high entropy, as for session tokens in general.
2.Tied to the user's session.
3.Strictly validated in every case before the relevant action is executed.
​
Clickjacking
Directory Browsing
Last modified 3yr ago