Secure Software Systems

SYNCHRONIZER TOKEN-PATTERN

This blog post will discuss Synchronizer Token Pattern, very simple concept to mitigate the risk of being attacked through CSRF.

Used Technologies

Java
JavaScript
HTML
JSP
CSS

Tool mechanisms

Eclipse
Tomcat v9.0 server

CSRF or Cross-Site Request Forgery may be a standard security attack that’s listed in OWASP security risks. CSRF is essentially running malicious JavaScript code items to a targeted web site while not the data of the browser user. it’s additional target centrical attack wherever attacker needs to recognize what s/he desires to perform.

Synchronizer token pattern (STP) could be a technique wherever a token, secret and unique value for every request, is embedded by the web application in all HTML (Hypertext Markup Language) forms and verified on the server side. The token is also generated by any technique that ensures unpredictability and uniqueness (e.g. using a hash chain of random seed).

Synchronizer token pattern with a flow diagram.

The user sends GET request to a server
The server sets the cookie with session_id and saving session data with the token
The server returns HTML (hypertext markup language) with a form containing token in a hidden field.
The user submits a form, along with a hidden field.
The server compares token from the submitted form (hidden field) with the token saved in the session storage. If they match, it means the type is submitted by a user.

How it does work

Create a session id and token id

Create a function for session id.

User login. Hard coded user credentials

Upon login, generate session identifier and set as a cookie in the browser
At the same time, generate the CSRF token and store it in the server side. You may store it in-memory. The CSRF token is mapped to the session identifier.

In the website, implement 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.

Implement a web page that has a HTML form. The method should be POST and action should be another URL in the website. When this page loads, execute an Ajax call via a JavaScript, which invokes the endpoint for obtaining the CSRF token created for the session.

Once the page is loaded, modify the HTML form’s document object model (DOM) and add a new hidden field that has the value of the received CSRF token.

Once the HTML form is submitted to the action, in the server side, extract the received CSRF token value and check if it is the correct token issued for the session. You this, you need to obtain the session cookie and get the corresponding CSRF token for the session and compare that with the received token value.

If the received CSRF token is valid, show success message.

CSRF Token equals to hidden Token. It means valid token. Show verified message.

If the received CSRF token is invalid, show error message.

CSRF Token not equals to hidden Token (hidden token is null). It means invalid token. Show verification failed message.

DOUBLE SUBMITTING COOKIE-PATTERN

This blog post will discuss Double-Submit Cookie Pattern also known as Stateless CSRF Defense, for preventing Cross-Site Request Forgery.

Used Technologies

Java
JavaScript
HTML
JSP
CSS

Tool mechanisms

Eclipse
Tomcat v9.0 server

Double submitting cookies 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 are equal.

Double submitting cookie pattern with a flow diagram.

When a user authenticates to a site, the site should generate a session identifier and set a cookie in the browser.
At the same time, it generates the cryptographically strong random value or the CSRF token for the session and set it as a cookie on the user’s machine separate from the session id.
The server does not have to save this value in any way, that’s why this pattern is sometimes also called Stateless CSRF Defense.
The site then requires that every request include this random value as a hidden form value (or another request parameter).
A cross-origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy.
Just retrieve the CSRF cookie from the response and add it into a special header to all the requests.

How it does work

Create a session id and token id.

Create two functions for session id and CSRF token id.

User login. Hard coded user credentials.

Upon login, generate session identifier and set a cookie in the browser. At the same time, generate the CSRF token for the session and set a cookie in the browser. The CSRF token value is not stored in the server side.

Implement a web page that has a HTML form. The method should be POST and action should be another URL in the website.

When the HTML form is loaded, run a JavaScript which reads the CSRF token cookie value in the browser and add a hidden field to the HTML form modifying the DOM.
When the form is submitted to the action, the CSRF token cookie will be submitted and in the form body, the CSRF token value will be submitted.

In the web page that accepts the form submission (the URL of the action), obtain the CSRF token received in the cookie and also in the message body. Compare the two values received and if they match, show success message. If not show error message.