1. EXERCISE BACKGROUND

The vulnerable application pane loads the TraderDASH application. In this application, a user is able to quickly buy and sell stocks with a single-click order execution. It has also a quite ordinary profile for managing user details.

ACTION

Click My Account -> My profile link to open the profile page.

2. CHANGE EMAIL FUNCTIONALITY

Bob is an attacker. While he was browsing the Web, he came across the TraderDASH application. Since registration was free and accessible, Bob created a user to test the app.
When Bob was managing his profile details, he noticed that when he changes his email, no additional confirmation is required.

ACTION

As Bob, click the Change email link and enter the following email into the New email field:
[email protected]
Click SAVE to continue.

Bob examines the request that was sent to the server when he changed the email and finds out that there is no CSRF token. This opens the possibility of a CSRF attack.

3. CHANGE EMAIL CODE

Let’s see how this Change Email functionality is implemented from the code perspective.

This HTML form has a single input field for a new email. Submitting this form invokes the HTTP POST request to the https://traderdash.codebashing.com server.

This POST request contains new email value

4. ATTACK PREPARED

To exploit the CSRF vulnerability, Bob first registers a domain called coolnews.me to host a malicious web page, and after that, he creates that malicious page containing the code that exploits the CSRF vulnerability.

Let’s quickly analyze the source code of Bob’s malicious page before proceeding with the CSRF attack.

As you can see, Bob’s malicious code will change the victim’s email to [email protected]. This will allow Bob to use password restore functionality on victim’s TraderDASH account.

The form with a single hidden prefilled input field is not visible in the browser

The form is submitted using the javascript after the page is loaded.

5. ATTACK PERFORMED

Alice is logged in to the TraderDASH application. She was busy thinking about her trading strategy when she received an email from Bob.
In his email, Bob advertised his malicious website
Alice would normally ignore unsolicited emails, but the information in the email looks relevant to her, so she decides to open it.

6. MALICIOUS CODE EXECUTED

After the malicious web page opens in her browser, Alice notices that the news portal is offline for maintenance.
Let’s investigate what has happened after Alice opened the malicious website.

---

ACTION

Click NEXT to learn how the CSRF vulnerability was exploited.

6. MALICIOUS CODE EXECUTED

After the malicious web page opens in her browser, Alice notices that the news portal is offline for maintenance.
Let’s investigate what has happened after Alice opened the malicious website.

When Alice logs in to the TraderDASH application, she receives a session identifier from the server, and this session ID is saved by her browser. Each request that the browser makes to the application contains a cookie with this session identifier. It lets the server know that Alice still uses the same browser to access TraderDASH.
When Alice clicks Bob’s link, the malicious page is loaded into her browser. The JavaScript code on the page instructs Alice’s browser to submit the prefilled HTML form without any interaction from Alice.
When the form is submitted, the browser sends a request to https://traderdash.codebashing.com/profile/changemail with Bob’s email in the parameter and adds Alice’s session identifier to the request. (The browser adds a cookie to the request because the cookie has been saved for TraderDASH before and has not expired yet.)
The server receives the request for email change with Alice’s session identifier and presumes that Alice has made this request using her browser.
The <form> and JavaScript code residing on the malicious page are invisible to Alice (unless she inspects the source code of the page), so she doesn’t even suspect the page to perform any malicious actions.

7. SUCCESSFUL ATTACK

Let’s look at Alice’s Profile page now.

As you can see, Bob’s malicious code changed Alice’s email to the email contained in the code ([email protected]).
Now Bob can request password reminder on Alice’s account, and receive the reset password link to the mailbox he has access to.

8. REMEDIATION STRATEGY

First, it is important to notice that not all the requests should be protected from CSRF. Only those requests that change application state (e.g. modify any data or status) should be protected.
Second, it is also important that requests that change the application state should not be sent using the GET request method. Sending data in GET requests leads to disclosure of this data in diverse locations. For example, if you use synchronizer token with the GET request, then this token will be sent as a parameter of URL, which could lead to its disclosure.
(To see more examples of potential caching of sensitive data sent in GET parameters or as part of an URL, refer to our Authentication Credentials in URL lesson for your respective back-end language).
Third, in some frameworks built-in security controls against CSRF expect state-changing data to be sent using only the POST request, thus GET requests are not protected by default by these frameworks.
You can defend from CSRF in several ways.

9. REMEDIATION – SYNCHRONIZER TOKENS

Synchronizer token (also called Anti-CSRF or CSRF token) is a random value that is added to the request. CSRF token should be associated with the user session. Every time the user loads the page or opens a new session, a server generates a synchronizer token, saves it, and transfers to the user.
The token can be transferred to the user, for example, as a part of HTML, in JSON, or in an HTTP header.
There are several ways the synchronizer token can be submitted to the server.

After the user submits a form or triggers a request in JavaScript, the CSRF token saved in the user’s browser is sent in the state-changing request. It is compared to the token saved on the server, and if those tokens do not match, the request is rejected.
This control relies on the fact that no one can guess the value of the CSRF token because it is generated by a cryptographically secure pseudo-random number generator. And without knowledge of a CSRF token tied to the user session, CSRF attack is not possible.

CSRF token is added as the input field.

CSRF token is added into the JQuery POST request.

10. REMEDIATION – DOUBLE-SUBMIT COOKIES

If it is problematic to store CSRF tokens tied to user sessions on the server, the double-submit cookies pattern can be used.
For each request, in addition to a synchronizer token sent by some form or some JavaScript code, a cookie is set containing the same synchronizer token. If the token in the cookie doesn’t match the token in the request, the request is rejected.

CSRF token is sent in a cookie.

Also, the CSRF token is sent in the POST request parameter.

11. REMEDIATION – CUSTOM HEADER

Synchronizer token can also be sent in a custom header (this header can be set using JavaScript). If the token in the header is not equal to the token generated when the page has been loaded, the request is rejected.
The control relies on the Same-Origin policy that prevents a malicious site from sending cross-origin requests with a custom header. Note that Cross-Origin Resource Sharing (CORS) should be disabled or properly configured in this case.

CSRF token is sent in the custom X-CSRF-TOKEN HTTP header.

All three security controls rely on the fact that CSRF token is impossible to guess and that it can’t be obtained by an attacker.
Same-Origin policy (https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) restricts a script on a malicious page from accessing the protected page and stealing CSRF token from DOM or a cookie.
Always consider that if an XSS vulnerability is present, then the attacker could access both DOM and cookie, thus bypassing CSRF protection.
Different languages and frameworks implement the described controls in a different manner. Ensure that they are always enabled and properly configured.