Guide to CSRF

What is CSRF? Let’s unpack! 

• CSRF (Cross-Site Request Forgery) is a web security vulnerability that allows an attacker to induce victims to perform actions that they don’t intend to perform. 
• The victim can be forced to execute those actions through any method that gets them to load a resource automatically. Eg – img tag, script tag, onload form submit, etc. 
• This happens unknowingly because the actions are performed by the victim’s browser, not by the victim explicitly.

Synonyms - Session Riding, One-click attack, XSRF, Sea Surf, Hostile Linking.

To perform CSRF attack the attacker/malicious user should determine the right value of all the form fields and URL inputs. It works by exploiting the trust of a web site which it has on its user.

Pre-requisite -

In order to exploit CSRF vulnerability, the user should be logged into the target application means the user’s session should be active.

Impact - 

The impact of this attack depends on the application’s functionality and the level of privilege the victim possesses.

Attack Scenario - 

Let us take an example of a website with change password functionality. To change the password all you have to do is, provide a new password and then click on the change button. Now let’s suppose you have logged in to that application (means account session is active) and at the same time you visit some malicious URL in a new tab of the same browser. As soon as you visit that malicious page your password will get changed automatically without your knowledge/consent.

What happened just now ?

1) User logged in to the vulnerable application.
2) User visits a malicious link or clicks on some button.
3) Malicious link/button is crafted with csrf payload
4) On exploitation the csrf payload/request is triggered from vulnerable website on behalf of user. Cookies and session ids are automatically sent by browser. 
5) Since the user’s session is valid , the server will take action by treating it as a valid request.
6) User’s password will be updated as a result.

GET > If the vulnerable application is transmitting form data using GET HTTP method then it’s quite simple to exploit CSRF issue. The attacker just needs to create a malicious URL crafted with csrf payload and send it to his target user.

http://localhost/DVWA/vulnerabilities/csrf/?password_new=newpass&password_conf=newpass&Change=Change#

POST > If POST method is being used for transmitting form data then the attacker will need to craft an HTML page in order to exploit the csrf vulnerability.

How to Exploit :

1) The attacker visits the website and found it vulnerable.

2) He created csrf payload and send it to any user.

{ This can be carried out as a targeted attack on a particular user or on large scale users.}

3) Then he will convince the user to perform some action, such as clicking on some link or button.

{Now how will he convince the victim, that is something related to social engineering and we all know that humans are the weakest link in cyber security.}

4) The moment the victim clicks on that link/button, the CSRF payload will be executed in the backend, and eventually, the attacker will get the expected result.

Every single click counts !!!

Behind the UI - Actually, the CSRF attack takes advantage of the fact that the browser sends the cookie to the webserver automatically.

How ?

Post authentication, the browser stores the session cookie value at client-side and sends those session ID for all subsequent requests. Since HTTP is stateless this is done to remember users' interactions with the website. While submitting the csrf, the request will get send with the session ID and it will be treated as a valid/original request by the web server.

Preventing CSRF vulnerabilities -

1) CSRF token – It is also known as synchronizer token. The application should embed a unique and random token with every state-changing form which is sent back to the client. The token can be implemented as a part of the hidden parameter inside an HTML form or as a form header and that should be validated at the back end while submitting a form.

2) Same site cookie - The same site cookie attribute restricts the browser from sending session cookie value with every request. It can be used to control whether and how cookies should be submitted in cross-site requests. Possible values for this attribute are Lax, Strict, or None.

• Strict attribute — No cross-site requests will receive the cookie

• Lax attribute — Only cross-site requests having safe methods Such as GET will receive cookie, 

GET method - The request should use GET method

• None attribute — Every cross-site request will receive cookie

3) Same-origin policy – The application should impose a strict same-origin policy so that it won’t accept any request that doesn’t belong to the targeted/same origin. 

4) Referer Header Check - Checking referer header is an additional preventive measure. It will allow only the parent domain as referrer.

Thanks for reading :)

Keep learning Keep growing:)

:)