Using Token to resolve CSRF Vulnerability

Introduction:

The CSRF (Cross Site Request Forgery) vulnerability: If the attacker gets target to follow a malicious URL, the attacker can then get the user to perform an operation they had not intended to do.

Example code: $operation=$_REQUEST['operation']; (Without token usage to validate the ID).

How the attacker exploits this: The attacker creates forged HTTP requests and tricks a victim into submitting them via image tags, XSS, or numerous other techniques. If the user is authenticated, the attack then succeeds.

Impact: CIAaa and details:
I: Attacker can forge the URL that will perform malicious actions like delete an expression that will change the information without the user's agreement and authorization if the user clicks on it.

A: User's added expressions can be removed from the server by clicking on the attacker's forged URL without user's permission or intention and lost that information from the server and database.

How does the Token work:

1. After authenticating when logged in, save the Token in current session SESSION["user_token"]
2. Add the field hidden and set its value to the Token from the backend
3. After submitting, validate whether the Token is correct

Demo:

How to validate the token:

# Add a check token here A4
# Grab the user_token and compare via REQUEST
if($_SESSION["user_token"] != $_REQUEST["user_token"]){
    echo "Failed to verify the token!";
    exit();
}

How does the session work:

1. First use session_start() variable to initialize
2. While running the PHP script, using $_SESSION static variable to register the session variable
3. After PHP script finishes, the existing session variable will be saved at local session library. The path can go through the session.save_path in the file php.ini, so that it can be loaded next time when visiting the application

What does session_start() have initialized:

1. Read PHPSESSID's cookie value
2. If able to read PHPSESSID cookie, create the $_SESSION variable and read SESS_cookie from the corresponding path, load the char to the $_SESSION variable. If unable to read, then $_SESSION variable will be created alongside with a cookie session file, and return the cookie as the PHPSESSID value to the browser

$_SESSION variable's usage:

• Through creating the unique session ID to every user, storage of every user's functionaility can be achieved. Session can be used to share and store among multiple web applications. Gernerally, Session ID will be send to the browser as the cookie, and as the session ID to get the session data from the server. If the request does not contain session ID information, then PHP will be creating a new session and distribute new ID to the session.
  When starting a new session, PHP will attempt to find the existing session ID and if it is not contained, PHP will be creating a new session. After the session starts, PHP will set the value from the session to the $_SESSION variable. When PHP ends, it will automatically read the value of the $_SESSION and sequence it, then send to the session to store.
  Variable session_start() can be used to manually start a new session. If session.auto_start is set to 1, then the session will automatically start at the time when requesting.
  After PHP script finishes, the session will be automatically ended. We can also use the variable session_write_close() to manually end the session.

---

The vulnerability visualized:

Vulnerable application, the user manipulates her own data

Vulnerable url appeared

The fix:

function token_generate(){...}
$token = token_generate();
<input type="hidden" name="user_token" value="<?php echo $token;?>">
if($_SESSION["user_token"] != $_REQUEST["user_token"]){...}

How the fix resolves the issue:

• We are now using a token system that each user will generate a token based on the time and bind to SESSION, now that the operations will also check the user_token by using the REQUEST and compare with the token stored in SESSION. This way the server will provide an only authenticated token to the user and for each operation this token will be checked and validated. If they do not match the operation will not be performed. The genreated token will be written to the value of the hidden section and submitted along with the operation. With this generated and encrypted token the attacker can not acquire thus the attack will not be succeeded.

The fix visualized:

Vulnerable url encrypted

PHPSESSID and its cookie