How Synchronized Token Pattern Works?

What is a Cross Site Request Forgery Attack?

Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts. There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and Java Script XML http Requests, for example, can all work without the user’s interaction or even knowledge. Unlike Cross Site Scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user’s browser. In a CSRF attack, an innocent end user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user’s account.

What is a Cross Site Request Forgery Token ?

A CSRF token is a unique, secret, unpredictable value that is generated by the server-side application and transmitted to the client in such a way that it is included in a subsequent HTTP request made by the client. When the later request is made, the server-side application validates that the request includes the expected token and rejects the request if the token is missing or invalid.

CSRF tokens can prevent CSRF attacks by making it impossible for an attacker to construct a fully valid HTTP request suitable for feeding to a victim user. Since the attacker cannot determine or predict the value of a user’s CSRF token, they cannot construct a request with all the parameters that are necessary for the application to honor the request.

1. User sends GET request to a server
2. Server sets the cookie with session_id, and saving session data with the token
3. Server returns HTML with a form containing token in a hidden field.
4. User submits form, along with a hidden field.
5. Server compares token from the submitted form (hidden field) with the token saved in the session storage. If they match, it means that form is submitted by a user.

Advantages:

• Simple to implement.
• Works with AJAX.
• Works with forms.
• Cookie can actually be HTTP Only.

Disadvantages:

• All forms must output the hidden field in HTML.
• Any AJAX POST s must also include the value.
• The page must know in advance that it requires the CSRF token so it can include it in the page content so all pages must contain the token value somewhere, which could make it time consuming to implement for a large site.

Assignment Web-page

To demonstrate all of these things I have implemented a website using basic HTML and PHP. It is a login form and there is no database connected to it then the username and password are hard coded and there is only one valid user. The page is simple as you can see it. you just have to type the username and the password in the given fields and it will redirected automatically to another page. The username and the password is already given in the top of the page. USERNAME = sliit PASSWORD = password.

Since there is a one user any other invalid entries must be unauthorized. so validation process happens in the back-end by PHP. Any invalid entry that user enter, user is prompt to enter the valid username and password. Which person in the world who cannot see the totally given username and the password in the HTML footer? ;)

After the user giving the right credentials he will be redirected to page called login.php and it will look like this in front end. when the user type the right credentials and log in, immediately a session starts and a cookie generates. 

If the user press the logout button without waiting for  10 seconds he will be redirected to the previous login page with the session destroying.

Sessions and Cookies

Talking about sessions and cookies, when the page page load a session will start as well as a cookie will set for a time period of 40000 ms. in name of admin.

Then the given credentials are correct and they are matched with what are hard corded, cookies will be generated on session id and token.

we can examine this further by looking at the application database in the inspect element area of the browser.

We can see the same results from the SAML-tracer. it gives more details as well.

The session only will be validated for 10 seconds. after 10 seconds the session will be automatically destroyed and the page will be no more will be visible for the user. user must be need to login again to see the login.php page again with valid credentials.

There is another thing. If anyone can find the indexes of a web page and bypass the validation steps, it will be a very bad security violation for the web page itself. But the session and cookies will prevent those. In our demonstration website there is a page called login.php. so lets try to go to that page by directly entering it on to the URL.

It wont work as the hacker want the way as it should work. Because we setup when the session username variable is not set not to welcome the welcome page, It was implemented in the code.

Lets move into the most important thing,

CSRF Token

This was the best example story that I was managed to found…

• Assume you are currently logged into your online banking at www.mybank.com
• Assume a money transfer from abcbank.com will result in a request of the form http://www.abcbank.com/transfer?to=<SomeAccountnumber>;amount=<SomeAmount>. (Your account number is not needed, because it is implied by your login.)
• You visit www.cute-cat-pictures.org, not knowing that it is a malicious site.
• If the owner of that site knows the form of the above request (easy!) and correctly guesses you are logged into abcbank.com (requires some luck!), they could include on their page a request like http://www.abcbank.com/transfer?to=123456;amount=10000 (where 123456 is the number of their Cayman Islands account and 10000 is an amount that you previously thought you were glad to possess).
• You retrieved that www.cute-cat-pictures.org page, so your browser will make that request.
• Your bank cannot recognize this origin of the request: Your web browser will send the request along with your www.abcbank.com cookie and it will look perfectly legitimate. There goes your money!

This is the world without CSRF tokens:

Now for the better one with CSRF tokens:

• The transfer request is extended with a third argument: http://www.abcbank.com/transfer?to=123456;amount=10000;token=31415926535897932384626433832795028841971.
• That token is a huge, impossible-to-guess random number that abcbank.com will include on their own web page when they serve it to you. It is different each time they serve any page to anybody.
• The attacker is not able to guess the token, is not able to convince your web browser to surrender it (if the browser works correctly…), and so the attacker will not be able to create a valid request, because requests with the wrong token (or no token) will be refused by www.abcbank.com.source -

What is a CSRF token ? What is its importance and how does it work?

I am writing an application (Django, it so happens) and I just want an idea of what actually a "CSRF token" is and how…

stackoverflow.com

All the time this CSRF Token generated field is same as other input fields and special thing is it is a hidden area. and its value is a randomly generated value with Base64 * 20 chars = 120 bits or 32 random char form the set [a-zA-Z0–9]

I used function with encoded with base64_encoding [ Generates a string of pseudo-random bytes, with the number of bytes determined by the length parameter It also indicates if a cryptographically strong algorithm was used to produce the pseudo-random bytes, and does this via the optional crypto_strong parameter. It's rare for this to be FALSE, but some systems may be broken or old ] for creating my random token. it is more secure than using md5 or other random generating values. openssl must be installed in your php server. it provides a good enough of security. md5 isn’t the expect-able security protection

Then we have to call this static generate function on the value field inside the HTML hidden area that we have created earlier .

This field is invincible to the interface and value will be randomly changed when the user refresh the browser.

This token value is only valid for 10 seconds of time and it will be changed after that automatically when browser refreshed. And this value will be passed in a POST format variable to the welcome.php page.

There is an another form to fill. It will accept 2 parameters, such as Username and Password. Anyone can try to update it in any credentials that they like. when the type the username and the password, browser will check by the post method the username, the password, the csrf_token are valid. Then it will be proceed to the next step.

This is the function that check the validity of the csrf token

SO the token is valid. foe the first time. for surly our session will be destroyed because 10 sec, time was passed by now. If we try to refresh the browser the token will be updated and then this per-managed popup will be displayed to shoe that it is an invalid token and it cannot be changed.

This is the implementation of the code fragmentation of that part of the website back end.

Ajax Call

An Ajax call is a non-concurrent request started by the browser that does not straightforwardly result in a page transition. A servlet request could be a Java-specif term (servlets are a Java determination) for adjusting an HTTP request that may get a basic GET or POST (etc) or an Ajax request.

An Ajax (‘Asynchronous JavaScript and XML’) request is often named a XHR request (‘XmlHttpRequest’), which is the name most browsers assign to the entity used to submit an Ajax request, since at least initially Ajax calls included sending and receiving XML, but now it’s just as usual to submit or receive JSON, plain text or HTML.

A good example of an Ajax request is the Stack-overflow comment system. Instead the browser will send probably a POST request via XHR to the server and be notified of the response (hence “asynchronous”). But the server typically can’t distinguish between an Ajax request or a page transition because both simply come down to HTTP requests.

Instead, the client would possibly submit a POST request to the server via XHR and will be informed of the response (“asynchronous” therefore).

In my Web Form I made my ajax form like this,

it will take two variables one for token and one for session cookie. session cookie is splitting by delimiters and the ajax call type is post and its URL is getdata.php. it will display data the session ID on the console if the action preformed nicely. the action happening on getdata.php is taking session id for an array.

Get session ID and pass it trough sha1 algorithm and assign it to an array called id. Its is more secure.

Finally Result of the AJAX call….

So that's all. Nothing in this wold is secure. Specially cyber related themes. but taking precautions is good, because we don't know what will happen next. this total project i available on m git-hub repository.