Cross-Site Request Forgery

• Cross-Site Request Forgery, or CSRF for short is a common and regular online attack. CSRF also goes by the acronym XSRF and the phrase “Sea-Surf”.
• CSRF attacks include a malicious exploit of a website in which a user will transmit malicious requests that the target website trusts without the user’s consent.
• In Cross-Site Scripting (XSS), the attacker exploits the trust a user has for a website, with CSRF on the other hand, the attacker exploits the trust a website has against a user’s browser.

• Basically, an attacker will use CSRF to trick a victim into accessing a website or clicking a URL link that contains malicious or unauthorized requests.

• It is called ‘malicious’ since the CSRF attack will use the identity and privileges of the victim and impersonate them in order to perform any actions desired by the attacker, such as change form submission details, and launch purchases or payments for the attacker or a third-party account.

• Upon a request against most websites, browsers will include along any credentials related with the particular website, such as the session cookie of the user, basic authentication credentials, the IP address of the user, etc.
• Thus, if user’s authentication session is still valid, an attacker can use CSRF to launch any desired requests against the website, without the website being able to distinguish whether the requests are legitimate or not.

A Simple Example of a Cross-Site Request Forgery

• As described above, in order for a CSRF attack to be performed, the user must be authenticated with the target website.
• Assuming the victim is authenticated, the attacker can include a link or script in a third-party website that the victim visits.
• Thus, when the victim visits that website or link, the rogue script will be executed without the victim being aware of it. For instance, in a chat forum, an attacker posts a message which contains an image tag or an HTML image element.
• However, the source of the image contains a link which performs an action on a victim’s bank website account.
• So, instead of an image file the attacker has included a link that performs a bank transaction. Below is an example of the image tag containing a rogue URL.

$\text{\ltimg src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=Fred"\gt}$

Preventing Cross-Site Request Forgery (CSRF) Vulnerabilities

• The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append unpredictable challenge tokens to each request and associate them with the user’s session.
• Such tokens should at a minimum be unique per user session, but can also be unique per request.
• By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user Finding and Remediating Cross-Site Request Forgery (CSRF) Vulnerabilities
• The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user.
• Without such an unpredictable token, attackers can forge malicious requests.
• Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets

Cross-site request forgery What is Cross-Site Request Forgery?
1. Cross-Site Request Forgery (CSRF) is an attack that forces authenticated users to submit a request to a Web application against which they are currently authenticated. CSRF attacks exploit the trust a Web application has in an authenticated user (Conversely, cross-site scripting (XSS) attacks exploit the trust a user has in a particular Web application).
2. A CSRF attack exploits a vulnerability in a Web application if it cannot differentiate between a request generated by an individual user and a request generated by a user without their consent.
3. An attacker’s aim for carrying out a CSRF attack is to force the user to submit a state-changing request. Examples include:
a) Submitting or deleting a record.
b) Submitting a transaction.
c) Purchasing a product.
d) Changing a password.
e) Sending a message.

How does Cross-Site Request Forgery works?

i) When a user tries to access a site, the browser often automatically includes the credentials in the request, to make the login process more convenient. These credentials may include the user’s session cookie, basic authentication credentials, IP address, and Windows domain credentials. 
ii) The risk inherent in this mechanism is that attackers can easily impersonate the user. Once a user passes the site’s identity verification, the site cannot differentiate between a forged request and a legitimate user request.
iii) In a CSRF attack, an attacker assumes the victim’s identity, and uses it to perform actions on behalf of the user, without their consent. Attackers typically follow this process:

• They use social engineering techniques to persuade the victim to click a link via email, chat message, or similar form of communication. 
  
• Either the malicious link itself, or a web page the user visits, triggers a request to the targeted site
  
• The request supposedly comes from the user, and takes advantage of the fact that the user is already signed into the website. 
  
• The website acknowledges the request and performs the attacker’s requested action, without the user’s knowledge or consent.
  

iv) CSRF attacks typically attempt to change server state, but can also be used to gain access to sensitive data. If an attacker successfully performs a CSRF attack against the victim’s account, they can transfer funds, purchase a product, modify account information such as the shipping address, modify the password, or any other action available when the user is signed in.

What are CSRF Tokens?
i) A CSRF token is a unique, unpredictable secret value generated by a server-side application, and sent to the client for inclusion in subsequent HTTP requests issued by the client.
ii) After the token is issued, when the client makes a request, the server checks to see if the request contains the expected token, and rejects it if the token is missing or invalid.
iii) CSRF tokens can prevent CSRF attacks, because they prevent attackers from forming Fully valid HTTP requests, which they can feed to a victim.
iv) The attacker cannot determine or predict the value of the user’s CSRF token, so any request they generate should not be accepted by the application.

How can an application prevent a Cross-Site Request Forgery attack?
i) To defeat a CSRF attack, applications need a way to determine if the HTTP request is legitimately generated via the application’s user interface. The best way to achieve this is through a CSRF token. A CSRF token is a secure random token (e.g., synchronizer token or challenge token) that is used to prevent CSRF attacks. The token needs to be unique per user session and should be of large random value to make it difficult to guess.
ii) A CSRF secure application assigns a unique CSRF token for every user session. These tokens are inserted within hidden parameters of HTML forms related to critical server-side operations. They are then sent to client browsers.
iii) It is the application team’s responsibility to identify which server-side operations are sensitive in nature. The CSRF tokens must be a part of the HTML form—not stored in session cookies. The easiest way to add a non-predictable parameter is to use a secure hash function (e.g., SHA-2) to hash the user’s session ID. To ensure randomness, the tokens must be generated by a cryptographically secure random number generator.

Limitations
i) 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.
ii) An attacker must find a valid URL to maliciously craft. The URL needs to have a state-changing effect on the target application.
iii) An attacker also needs to find the right values for the URL parameters. Otherwise, the target application might reject the malicious request.