Synchronizer Token Pattern (STP)
Cross-Site Request Forgery (CSRF)
Cross-site request forgery (also known as CSRF) is a vulnerability in web security that enables an attacker to induce customers to take actions they do not plan to do. It enables an attacker to partially circumvent the same policy of origin, intended to avoid interfering with each other by distinct websites. Typically, CSRFs are carried out using malicious social engineering, such as an e-mail or link that tricks the victim into sending a forged application to a server. Since the unsuspecting user is authenticated at the time of the attack by their application, a legitimate request can not be distinguished from a forged one.
How to prevent Cross-site Request Forgery?
As a temporary solution, users can use a separate browser to visit malicious websites rather than using their default browser where they are logged into their important accounts so that the browser can’t access the cookies of the default browser. Although it can be done, this is not very practical.
In GET applications, CSRF is quite simple because information is sent in the URL as query parameters. It has, therefore, become a convention not to use GET applications to execute any state-changing activities. If the attacker understands what parameters to send, a request for a POST is also not secure. Therefore, to avoid CSRF, the server creates a token and the server recognizes the application as valid only in the presence of this token.
There are two significant security patterns we can enforce to avoid this safety issue of CSRF attack.
- Synchronizer token pattern
- Double submit cookie
I described what Web Applications CSRF attack is. Now, in this blog post, I will clarify the Synchronizer Token Pattern as one of the alternatives identified for this safety attack by CSRF.
Synchronizer token pattern
The implementation would produce a one-time CSRF token in Synchronizer Token mode and store it on the server side against the sessionID. It would send this token integrated in the HTML. This token will be sent along with other parameters when the customer requests an intervention such as Transfer Funds. The server will validate sessionID and this token value. If they match, the request will be completed.
The token is produced by shape unique. Therefore, there is no way for the attacker to access this. Even if the attacker submits the other parameters, the server will not finish the action because the token is not available. This prevents CSRF.
What does Synchronizer token pattern do?
When a user authorized on a site is loaded whenever the form or links associated with sensitive server-side operations are loaded, a random1-time string associated with the current session of the user will be generated automatically. This random string is added as a concealed field to the HTML form. Whenever the user wishes to do a state-changing operation, this token will send along with the HTTP request.
Then the server-side will validate the cost token that comes with HTTP request, with the current session and relevant csrf token.
Let’s Try Out,
This application is developed using PHP & JS code (Github link — click here)
First, by entering username and password, you need to login to the application. I hardcoded the credentials for the demo.
- User name-admin
- Password -csrf
login.php
Using a POST technique, this login form sends user credentials. If the user is successfully authenticated, a unique Session-Id and CSRF token will be created in conjunction with this session, and a session I d will be set as a browser cookie.
CSRF token is placed on the server side against the session identifier. You can see the CSRF token in the text file called (Token.txt )of the project,
iFd8n7pcQsSXFkm2WcMnVt6sudY16GufZWZQfrLlUXU= : CSRF token
lj0ar20kmq7rr6cdk2p04qg9j6 : Session ID
After page loaded,
To update some user status, I have introduced a POST request. This produced CSRF token and the session cookie is included in the post request.
home.php
PHP part is implemented in order to validate the user inputted credentials. AJAX is used to call the “Genarator.php” file so that it can get the generated CSRF token value created for the session and add to the hidden field in the HTML form’s document object model.
Send an ajax call to the server after the user has logged in to the browser to get csrf token. Then the server will react and add it to the concealed sector with the token.
Genarator.php
A user session will be created and set as a cookie in the browser with session_id
A CSRF token is generated in the server-side [32 bit of CSRF token is generated by base 64 encoding of “openssl_random_pseudo_bytes( )” function]. Session_id is used to map with the above CSRF token (here in a text file “Tokens.txt”)
token.php
The “checkToken( )” function gets the CSRF token and session_id. If the above-given parameters match with the values that are stored there in the text file “Tokens.txt”, then it returns true.
If the token is valid server accepts the request.
If the server is not valid, disregard the application,
In the next blog post, we will look at how Double Submit Cookie pattern can be used to prevent CSRF attacks.