SYNCHRONIZED TOKEN PATTERN

Implementing Mitigation Methods For CSRF Attack — SYNCHRONIZED TOKEN PATTERN

What is CSRF ?😮

Cross site request forgery (CSRF), also known as XSRF, Sea Surf or

Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in.

A successful CSRF attack can be devastating for both the business and user. It can result in damaged client relationships, unauthorized fund transfers, changed passwords and data theft — including stolen session cookies.

CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.

CSRF Examples: 😎

Before executing an assault, a perpetrator typically studies an application in order to make a forged request appear as legitimate as possible.

For example, a typical GET request for a $100 bank transfer might look like:

A hacker can modify this script so it results in a $100 transfer to their own account. Now the malicious request might look like:

A bad actor can embed the request into an innocent looking hyperlink:

Next, he can distribute the hyperlink via email to a large number of bank customers. Those who click on the link while logged into their bank account will unintentionally initiate the $100 transfer.

Note that if the bank’s website is only using POST requests, it’s impossible to frame malicious requests using a <a> href tag. However, the attack could be delivered in a <form> tag with automatic execution of the embedded JavaScript.

This is how such a form may look like:

What is Synchronized Token Pattern ? 👀

Synchronized Token Pattern is one mechanism to prevent or handle the security attack: Cross-Site Request Forgery (CSRF).

Each time a user logs in, a new session is created for the user if the site allows multiple logins like Facebook, allowing users to log in from many browsers and devices. In Synchronized Token Pattern, a random string token is generated in the server side whenever a user logs in and a new session is created. This token is stored in the database mapped to each session of the user. The server then exposes a URL which can be accessed by the user to get the generated CSRF token.

Lets assume that the user is an Administrator making a user account for another user of the system. The admin will fill the form providing the relevant details of the user and submit it. The server will receive all the form details through the request made to the backend.

After obtaining the token, the user can embed the token in a hidden field in the form and send the token in the request along with the user details to the server when posting data. This way, the server can identify whether the request is valid as only a valid request will contain the Session Id, Username, and CSRF token that matches the values stored in the database.

The user must make an AJAX call to obtain this CSRF token. The attacker will not be able to obtain this token, as whenever a browser makes an AJAX call, it validates the current domain against the request domain. If the call is made to www.abc.com, this domain should match in the browser and the server call. The browser will only send the request if the domain matches. By default, making Cross-domain AJAX calls is not possible as it is blocked. It can be enabled if needed, but for these security reasons we do not enable it normally.

As attacker will not be able to obtain the CSRF token using an AJAX call as domains will not match, CSRF will not be possible as attacker’s form will not contain the CSRF token, making the request invalid even if all the other details match.

The diagram below illustrates the flow of the Synchronized Token Pattern process mentioned above:

In the below example instead of using real database I have hard-codded the the username and password for the demonstration purpose.

Username — test@gmail.com

Password — 123456

STEP 1 — index.html 👌

First you have to create a prototype of a login page. I have created a page called index.html and inside this page I have added a form and the action of this page goes to login.php file.

You can refer the Figure 1 to go through the implementation of the index.html and you can refer the Figure 2 to take an idea about my UI of the Login page.

Figure 1

Figure 2

After providing the correct login credentials the user is redirected to add_user.html .

STEP 2 — login.php 👌

When we move to the Login.php a new session is made for the user for an each login and as well as a new PHP session ID is generated for each invalid session which is already exists.

Figure 3

For an each login session a CSRF token also generates and this token is going to store in an Array and it is mapped against the session ID through the line.

Figure 4

Actually the CSRF token is a randomly generated token and to create this token, hashing algorithms should use and for this implementation SHA256 has been used.

Figure 5

The array that stores CSRF tokens mapped against the Session is added to the Session through the line mentioned below.
The advantage is that we can access it from other server-side files.

Figure 6

STEP 3 — add_user.html 👌

By using AJAX call the CSRF token can be retrieved and when user clicks the Insert Button the details are submitted to the validate_token.php page . In the UI the form is asking 4 user inputs and after submitting the data the function called getToken sends the Token with the submission.

Figure 7

Figure 8

Figure 9

The function getToken() contains and AJAX call and $.ajax it contains jquery and if the jquery wasn’t there the function wont work and you will get a message called “function undefined”. When we move to the next line type which depicts how the method is passing; Is it GET or POST and the URL shows to where the ajax request should directed. And the next line contain another inner function called .done()and this function shows if there is any reponse from the URL that you entered in upper line and as well you can use .success() instead of using .done() . If there is something goes wrong then it will prompt to the .fail() . This is how that function works. After the content of the form loading to the javascript function getToken() is called it calls to the token_dispatcher.php page to retrieve the CSRF Token which has been generated for the current session.

STEP 4 — token_dispatcher.php 👌

To return the CSRF token for the particular session token_dispatcher.php checks whether it should met with following conditions.

• Check whether the PHP session ID is set
• whether the request is POST or not

Figure 10

STEP 5 — validate_token.php 👌

When the enterred details are submitted to validate_token.php on Insert button click, the CSRF Token values will be compared and validated, and a message will be returned based on the outcome of the comparison.

Figure 11

A successful message will be displayed if the tokens are matched or else if not it will display and error message.

Figure 12

Figure 13

This is how the one of the CSRF mitigation method : synchronized token pattern implemented.

You can get the source code by my github account. 💪