Synchronizer Token Pattern for Cross-Site Request Forgery Prevention
Within the contemporary context in which most of the communication and transactions are taking place over the web, the data being transferred are susceptible to many forms of attacks. An eminent attack type out of many is the Cross-Site Request Forgery attack. therefore, defense mechanisms which include Synchronized Token sample and Double publish Cookies got here into mild.
Cross-Site Request Forgery (CSRF), also called session riding and XSRF, is a common application-layer vulnerability that allows the malicious attacker to use an active session of the target to perform tasks on his behalf with out his prior knowledge or consent. CSRF incidents are tough to detect as they may be disguised into everyday user requests.
What is a CSRF attack?
CSRF attacks take advantage on the web applications inability to authenticate user access. These type of attacks commonly take form as follows.
Assume a victim user logs in to a web application which is vulnerable to Cross-Site Request Forgery, it will initiate a session which will have a unique session ID as a token of identification, which then, allows them to interchange information with the server and perform tasks. An attacker can utilize a unsolicited email with some malicious code planted inside or any other social engineering technique (often times in tandem with other techniques ) to trick the user on clicking a link which runs a background code against the targeted web application. If successful, the web application will assume the commands are legitimate and will execute them.
https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/
As an example, my banking website, example.com, does not protect itself against CSRF. You, an unsuspecting example.com user, also happened to be logged in to example.com. Now, an Attacker might send you (and millions of other example.com users, of course) an HTML e-mail including the following tag.
<img src="https://www.example.com/transfer?amount=1000&destination=ruween">If you have a webmail client that loads images automatically, the transfer request will be made from your browser using your IP address and your example.com session cookies, exactly as if you made the request yourself. My bank website, therefore, treats this like a legitimate request and sends $1000 from your account to Attacker’s account. All evidence suggests you legitimately made this transaction from your logged-in browser.
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.
The Solution — Synchronizer Token Pattern.
Synchronizer Token Patterns as a Prevention Mechanism
Synchronizer Token Pattern, generally abbreviated as STP, is a technique where a token is embedded by the web application in all HTML forms, which is verified by the server side.
The token in particular is a unique arbitrarily generated secret value that cannot be predicted by an Attacker, which is used to authenticate legitimate users. Tokens are often time generated using cryptographic methods with multiple layers of encryption and encoding placed on top of it.
Although it introduces some level of complexity in the server side due to the burden associated with checking validity per every request, Synchronizer Token Patterns can be considered as the most compatible as it primarily relied on HTML.
The following section contains an explanation of a sample implementation of Synchronizer Tokens using PHP, AJAX and JQuery. (Source Code — Github)
Login Form
Users need to input their credentials to gain access, which verifies them using generated token. If successful, users are redirected to the main page.
- uniqid — Generates a unique identifier based on the current time in microseconds.
- mt_rand — Generate a random value via the Mersenne Twister Random Number Generator
- sha1 — Calculate the sha1 hash of a string, in this example, the function will calculate the hash of the string (unique(mt_rand))
- base_convert — Convert a number between arbitrary bases, in this case, hash value will be converted into a number of base value 36
- substr — Only return up until the 32 character.
Once the token is generated, it will be placed inside the HTML form, as a hidden value, which then will be sent to the server as a part of the POST request.
Login Form with the hidden value field
Once the server receives the data, it will check for it’s validity and return an error message if the credentials are incorrect. If not, it will generate a new session cookie and update the loggedin status as true. Then the user will be redirected to the main page.
main page
Verified users can send credits, although the server will check authenticity of each request using synchronizer tokens.
Inside the main page, an Ajax call will be placed to the PHP back end in order to generate another token for the requests per session.
Ajax call to request the new Token
The back end will process the request and generate a new token using the Token::generate() function.
Token Class :: generate function
Then it’ll echo that value back to the Ajax call, which in turn will be used inside the request form.
echo the token and call the mapper function
The code will access the mapper function to concatenate the session id with the newly created token.
mapper function
Again, similar to the login form, a hidden field will include the freshly created token.
the Empty value will be updated using the Ajax “data”
Once POST-ed back to the server, it will separate the mappedCookie, and compare the mapped CSRF token value and session id with the POST data to verify authenticity.
Comparison of the mappedCookie data with POST data
If the CSRF token is not kept sufficiently secret and is disclosed in some way, the application may still be vulnerable to CSRF. The token should also be invalidated after some time and after the user logs out.
