Cross-Site Request Forgery protection in web applications via Synchronizer Token Patterns
A number of effective methods exist for prevention of CSRF (Cross-Site Request Forgery) attacks. For web applications, multiple solutions exist to block malicious traffic and prevent attacks. Among the most common mitigation methods is to generate unique random tokens for every session request or ID.
Any state changing operation requires a secure random token (e.g., CSRF token) to prevent CSRF attacks.
We have a simple login page to provide username and password which is checked with the hardcoded values. |
| Synchronizer Token Success |
 |
| Synchronizer Token Failure |
Any state changing operation requires a secure random token (e.g., CSRF token) to prevent CSRF attacks.
Characteristics of a CSRF Token:
The CSRF token is added as a hidden field for forms or within the URL if the state changing operation occurs via a GET.
- Unique per user session
- Large random value
- Generated by a cryptographically secure random number generator
The CSRF token is added as a hidden field for forms or within the URL if the state changing operation occurs via a GET.
The server checks and verifies the token before respond to any client request. Further, the server rejects the requested action if the CSRF token fails validation. Session requests having either duplicate tokens or missing values are blocked. Alternatively, a request that doesn’t match its session ID token is prevented from reaching an application.
In order to facilitate a "transparent but visible" CSRF solution, developers are encouraged to adopt the Synchronizer Token Pattern.
This blog post will discuss how to use Synchronizer Token Patterns to protect our own website against Cross-Site Request Forgery.
This blog post will discuss how to use Synchronizer Token Patterns to protect our own website against Cross-Site Request Forgery.
Example:
If the login credentials are wrong it will shows an error message. When login is successful, a session will be created and the session id will be used to map with the CSRF token that will be generated along with the session creation.
Then the user redirects to a web page that allows the user to update a post. When this page loads with the help of AJAX, generated CSRF token value will be added to a hidden field in the HTML form.
Once the user updates a post CSRF token will be validated. If it is valid user will see the post he updated.
In here we store CSFR token values on the server side (since we run our project in localhost we store it in a .txt file).
Then the user redirects to a web page that allows the user to update a post. When this page loads with the help of AJAX, generated CSRF token value will be added to a hidden field in the HTML form.
Once the user updates a post CSRF token will be validated. If it is valid user will see the post he updated.
In here we store CSFR token values on the server side (since we run our project in localhost we store it in a .txt file).
GitHub Link : https://github.com/nimeshikaranasinghe/Cross-Site-Request-Forgery-protection-Method-1.
There are 5 .php files and one. txt file.
Login Page
You can enter your username and password in this form.
index.php
This is the index.php file we create it as for our login page.
When the form is submitted user will be redirected to the home.php page.
home.php
If the login credentials are wrong it will show an error message.
If the login is successful, a successful message will be displayed.
Upon login, a new session will be created and session identifier will be set as a cookie in the browser.
At the same time, a CSRF token will be generated and stored it in the server side (here we save it in a text file).
As you can see Ajax is used to call the csrf_token_generator.php file to get the generated CSRF token value and put it inside the hidden textfield in the HTML form.
csrf_token_generator.php
This php file generates the csrf token. Also, it sets a browser cookie with the value of session_id. After that CSRF token value will be stored in a text file called Tokens.txt along with its session_id.
openssl_randon_pseudo_bytes() is used to generate the 32bit long csrf token. In order to use this function, you have to have openssl installed. Otherwise it will give you an error. The generated value then converted into its base64 value using base64_encode () function in order to make it more secure.
In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires.
Updated_post.php
Once the form in home.php is submitted user will be redirected to this page.
This will act as an endpoint that accepts HTTP POST requests and respond with the CSRF token. The endpoint receives the session cookie and based on the session identifier, return the CSRF token value.
Once the HTML form is submitted to the action, in the server side, extract the received CSRF token value in the hidden text field and check if it is the correct token issued for the particular session.
This is where checkToken function gets called. Obtained session cookie and the corresponding CSRF token for the session will be send as parameters. If the returned value of the function is true, the user can view his/her updated post.
token.php
This php file has checkToken function which gets two parameters (CSRF token and session id) and return true if the given parameters match with the values that are stored inside the text file.
CSFR_Tokens.txt
However, that this may result in usability concerns. For example, the "Back" button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server. Regardless of the approach taken, developers are encouraged to protect the CSRF token the same way they protect authenticated session identifiers, such as the use of TLS.
Comments
Post a Comment