Skip to main content

Synchronize Token Pattern

Synchronizer token pattern (STP) is a technique where a token, secret and unique value for each request, is embedded by the web application in all HTML forms and verified on the server side. The token may be generated by any method that ensures unpredictability and uniqueness. The attacker is thus unable to place a correct token in their requests to authenticate them.STP is the most compatible as it only relies on HTML, but introduces some complexity on the server side, due to the burden associated with checking validity of the token on each request. As the token is unique and unpredictable, it also enforces proper sequence of events. It can be relaxed by using per session CSRF token instead of per request CSRF token.


This Demo will be explain how its works. 






First you will get a login page which you can enter user name and password. The username is 'admin' and password is 'password'. When you enter the login button the process will be start. 


This is the source code of the login page. User name and password has been hard coded . after login details are match it will create an session and that will be call for Token class.






In this Token class , there is a function generate_token , it will be a create a random number (it can be anything unique) and it ll be save in the session variable call token. that will be save in the server side. that token will generate for only that person who logged in.






And that will be enroll u to enter secret code and the verify code. same as before secret code is 'secret' and Verify code is 'verify'. when u inspect the form there will be hidden input field with value of unique number. and source code of the this page as below,


as code shows , the hard coded value will be compare with the value entered.When the page load there is a script to run. AJAX function function will be called in that script. 







In this AJAX function it will call the endpoint call endpoint.php as show in upper figure and in the endpoint the session token we create when we login to the system will be assign to the JSON array.When the AJAX return that value in success function and and that value append to INPUT HIDDEN field in the form.When you submit that form it will compare the value value hard coded and it ll call the function check_token IN TOKEN class. what that check_token function do is it will check the value inside the form in THAT HIDDEN INPUT Field and the value saved in the session ($_SESSION['token'] == $_POST['csrf_token']) should be same. if it is same it will show the success message.

What attacker going to do is copy the whole source code and insert the value attacker want and it will send with on load function. what i have done here is i ll change the input field value and and submit the form.



When i submit the form it will compare the value with which store in the session and the value in INPUT HIDDEN field. and it will not valid the token and that process could not be success. and it will show the error message. That's mean, CSRF attack not possible with synchronize token.






GIT HUB Link : https://github.com/reaper-xx/Synchronize_Token_Pattern.git

Comments

Popular posts from this blog

Double Cookie Submit For Prevent CSRF

If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie. A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.when a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way, thus avoiding server side state. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cooki