A Cross Site Request Forgery(CSRF) occurs when a malicious web site causes a user’s web browser to perform an unwanted action on a trusted site. These attacks have been called the “sleeping giant” of web-based vulnerabilities, because many sites on the Internet fail to protect against them and because they have been largely ignored by the web development and security communities. This Vulnerability allows an attacker to make users perform actions that they don’t intend to perform, it also allows an attacker to circumvent the same origin policy.

Introduction to Cross Site Request Forgery(CSRF) | Ethical Hacking

Also Read: Introduction to Shodan Search Engine [Ethical Hacking Tutorial]

The same-origin policy (SOP) is a web browser security mechanism that aims to prevent websites from attacking each other. It Restricts scripts from one origin to access script from another origin. Without SOP, a malicious website or web application could access another without restrictions. That would allow attackers to easily steal sensitive information from other websites or even perform actions on other sites without user consent.

Impact 

The impact of CSRF can be very severe depending on the purpose of the application. When a feature is vulnerable to CSRF attacks, attackers seek to trick users into loading a malicious page.

This page with malicious code will send requests through a user’s browser as if it were a legitimate user action, allowing the attacker to perform actions such as changing the password and/or other personal information or changing the user’s personal settings and configurations on the vulnerable platform. 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.

An attacker’s aim for carrying out a CSRF attack is to force the user to submit a state-changing request. Examples include:-

• Submitting or deleting a record.
• Submitting a transaction.
• Purchasing a product.
• Changing a password.
• Sending a message.

How does a CSRF work

In order to Execute a CSRF there has to be three categories fulfilled:-

a) Cookie-based session handling: The success of a CSRF attack depends on a user’s session with a vulnerable application. The attack will only be successful if the user is in an active session with the vulnerable application.

b) A relevant action: An attacker must find a valid URL to maliciously craft an action. This action might be a privileged action (such as modifying permissions for other users) or any action on user-specific data.

c) No unpredictable request parameters: An attacker also needs to find the right values for the URL parameters. Otherwise, the target application might reject the malicious request.

Mitigation

There are several ways to mitigate the Cross Site Request Forgery attacks by classifying genuine requests from non genuine requests on the server side.

a) Anti-CSRF Tokens: These are related pairs of tokens given to users to validate their requests and prevent issue requests from attackers via the victim. Each token contains a unique, unpredictable, secret value that is not guessable by a third party. Anti-CSRF tokens can be generated once per session or for each request. Per request tokens are more secure than per-session tokens as they provide attackers a shorter timeframe to exploit the tokens.

b) Double Submit Cookie: This technique is easy to implement and is stateless. In this technique, we send a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match. When a user visits (even before authenticating to prevent login CSRF), the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session identifier.

c) Validating the Referrer and Origin of the request: This defense relies on the same-origin policy (SOP) restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers do not allow JavaScript to make cross origin requests with custom headers.

• Determining the origin the request is coming from (source origin). Can be done via Origin or Referer headers.
• Determining the origin the request is going to.

d) Same Site Cookie attribute: The Strict value will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link.

e) User Interaction Based CSRF Defense: The following are some of the example techniques that can act as strong CSRF defense when implemented correctly.

• Reauthentication
• One Time Token
• Captcha

Demonstration on DWVA

In this demonstration we will try to see how to Execute a Cross Site Request Forgery on the DVWA.
The first thing we need to do is to initiate our DVWA server and open it up on our favorite browser.

Next we will fill the form and intercept the request with a burp suite so that we can build our proof of concept CSRF template. Before we open our Burp suite we will see the code and figure on how it works. To see the source code click on the tab Source.

Ok that's simple enough, the script takes the user input and checks if the two passwords match, if they do then the password is updated, if not then it's not updated. What we can see here is that there are no protection against CSRF. Now let’s intercept our request using Burp suite.

After intercepting the request we will forward the request to “Generate CSRF POC” by right clicking and click the tab Engagement tool -> Generate CSRF POC where we will see the below output.

Next we can modify the value of the password to anything we want. For that click on Regenerate once we crafted our CSRF payload. Then we can test it on our browser by clicking on Test in Browser. We can then copy the directory and paste it in our browser.

We will see a Submit request button that we need to click on. After we submit request, the CSRF payload will send the changed password form and change the password of the application.

Conclusion

Most interesting CSRF vulnerabilities arise due to mistakes made in the validation of CSRF tokens and these CSRF attacks are relatively simple to diagnose, exploit and fix. Sites can be analyzed in a matter of seconds; at- tacks can be constructed in a matter of minutes. The most plausible explanation for the prevalence of these attacks is that web developers are unaware of the problem or think (mistakenly) that defenses against the better-known cross- site scripting attacks also protect against CSRF attacks. The root cause of CSRF and similar vulnerabilities probably lies in the complexity of today’s Web protocols