XSRF

XSRF
XSRF
XSRF = Cross Site Request

Forgery
Also called CSRF or Sea-surf

XSRF
This is a malicious exploit on a
website where unauthorized
commands are transmitted from a
user to the web server
These commands get the server to

perform actions which harm the
victim and benefit the attacker
XSRF
This is a malicious exploit on a
website where unauthorized
commands are transmitted from a
user to the web ser ver
The website trusts the user and

the attacker takes advantage
of this fact
XSRF
The website trusts the user and
the attacker takes advantage
of this fact
This is different from a XSS

attack which exploits the trust a
user has for a website
XSRF
This is different from a XSS
attack which exploits the trust a
user has for a website
XSRF exploits the trust the

website has for the user
XSRF
XSRF does not try and get data

from a website
Instead it focuses on the user

executing actions on a website
XSRF
Instead it focuses on the user
executing actions on a website
Actions such as transferring

funds, downloading malicious
soft ware, purchasing an item,
changing a users password
XSRF
XSS XSRF
Get data from the Get user to perform
web ser ver which actions on the
can be used to server to benefit the
benefit the attacker attacker
i.e session ids, login i.e transferring funds,
credentials etc buying something
XSRF
http://trustedbank.com/
The user might be logged into his

trusted bank site - he has a
session open
XSRF
He’s also bored and he’s browsing

some forums on another site
XSRF
The attacker has a post on that

forum
XSRF
Isn’t this a great

picture of Times Square?
<img src="http://trustedbank.com/
withdraw?amount=1000000&for=Fred">
XSRF
Browsers load the URL of images, this

means that the attacker can
implement actions specified by the URL!
XSRF
The user just needs to load the page

which has the embedded image
XSRF
He doesn’t even need to click on it!

XSRF
Note that the attacker was aware of

the exact form of a valid withdraw
request
XSRF
The user is obviously allowed to

transfer money from his own account
to any other
XSRF
The victim was tricked into sending a

request to his bank to transfer funds
XSRF
The withdraw URL performs an

action which benefits the attacker
XSRF
Characteristics of a XSRF attack
Involve sites which know a user’s identity
The user typically has to be logged in

and authenticated on a site and have
the authority to perform actions
XSRF
http://trustedbank.com/
The user might be logged into

his trusted bank site - he has a
session open
XSRF
Exploit the site’s trust in that identity
The ser ver trusts and allows the

authenticated and authorized user
to perform actions
XSRF
The user is obviously allowed to transfer

money from his own account to any other
XSRF
Tricks the browser into sending an

HTTP request to the site
The victim inadvertently performs an

action on the ser ver he is logged into
XSRF
The victim was tricked into sending a

request to his bank to transfer funds
XSRF Tricks the browser into sending an
Involve HTTP requests which perform actions
The action will harm the victim

and benefit the attacker
XSRF
The withdraw URL performs an

action which benefits the attacker
XSRF

XSRF
What does a successful attack need?
An authenticated session
Knowledge of URLs which perform actions
Session management which relies
only on the browser
HTML tags which access a resource e.g.
the img tag
XSRF
Example15-XSRF-embeddedImage.php
Example15-XSRF-transferFunds.php
XSRF
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>XSRF</title>
</head>
<body>
<h3>Here is a pic you might like!</h3>
<img src="http://localhost/security/Example15-XSRF-transferFunds.php/?from_id=3333&to_id=1234&amount=1000">
</body>
</html>
Browsers load the URL which

pretends to be an image
XSRF
<!DOCTYPE html>
<html lang="en">
<head>
<title>XSRF</title>
</head>
<body>
</body>
</html>
It’s a page which transfers funds

XSRF
<!DOCTYPE html>
<html lang="en">
<head>
<title>XSRF</title>
</head>
<body>
</body>
</html>
And here is the from account, the

to account and the amount to
transfer
XSRF
<!DOCTYPE html>
<html lang="en">
<head>
<title>XSRF</title>
</head>
<body>
</body>
</html>
Obviously the pic

does not load - but
this is common, as
users we’re trained
to ignore this
XSRF
http://localhost/security/Example16-
XSRF-transferFunds.php/?
from_id=3333&to_id=1234&amount=1000
This particular page which performs

the transfer funds action gets many
things wrong
XSRF
http://localhost/security/Example16-
XSRF-transferFunds.php/?
from_id=3333&to_id=1234&amount=1000
First of all why is such an important

page performing this action on a GET
request?
XSRF
There is of course a whole bunch of

other stuff which we’ll discuss when
talking about XSRF mitigation
XSRF
$conn = getDatabaseConnection();
echo "Transferring funds <br>";

$from_id = $conn->real_escape_string($_GET['from_id']);
$to_id = $conn->real_escape_string($_GET['to_id']);
$amount = $conn->real_escape_string($_GET['amount']);
echo "From: $from_id, To: $to_id, Amount: $amount <br>";
if (!empty($from_id) && !empty($to_id) && !empty($amount)) {

$subtract_query =
"UPDATE BankAccounts SET account_balance = account_balance - $amount where account_id = $from_id";
echo $subtract_query;
$conn->query($subtract_query);
$add_query =
"UPDATE BankAccounts SET account_balance = account_balance + $amount where account_id = $to_id";
echo $add_query;
$conn->query($add_query);
$conn->close();
}
XSRF


$subtract_query =
$add_query =
Some useless escaping here:-)

echo $add_query;
$conn->close();
}
XSRF

$subtract_query =
$add_query =
echo $add_query;
$conn->close();
}
This is not typically the way the SQL

queries will be written
XSRF

$subtract_query =
$add_query =
echo $add_query;
$conn->close();
}
This should be in a stored procedure and

the execution should be atomic
XSRF


$subtract_query =
$add_query =
echo $add_query;
$conn->close();
}
XSRF
Remember that this requires the user

to be logged in and authenticated to his
bank site
XSRF
There is an aspect of social engineering

involved as well, in order to get the user
to load a blog page or click on a link
XSRF
social engineering
Sending an email with a link to the user

or setting up an image on pages the
user visits while banking
XSRF
Let’s say that the bank uses POST

rather than GET, a little more secure
XSRF
Such a request cannot be

delivered using <img> or <a> links
But can be submitted using a

form!
XSRF
<form action="http://trustedbank.com/transfer.php" method="POST">
<input type="hidden" name=“from_id" value="3333"/>
<input type="hidden" name=“to_id" value="1234"/>
<input type="hidden" name="amount" value="1000"/>
<input type="submit" value="View my pictures"/>
</form>
Note that all of these are hidden

fields
XSRF
</form>
All the user sees is the “view my

pictures” button
XSRF
</form>
These become POST params to

this page
XSRF
</form>
Forms can also be submitted

automatically - so even the
clicking can be done away with
XSRF
</form>
<body onload="document.forms[0].submit()">
A little bit of Javascript to submit

the first form of the page
XSRF
Mitigation
XSRF
Mitigation
1. Referer header
2. Origin header
3. Challenge response
4. Synchronizer token
XSRF
Mitigation - Referer header
This is an HTTP header which

identifies the URL of the webpage
which linked to the current webpage
XSRF
This allows a page to identify

where the request to this page
came from
XSRF
A page can check the referer and

only allow those requests which
come from pages it trusts
My website trusts links from the

www.nyt.com but not from www.evil.com
XSRF
A page can check the referer and
only allow those requests which
come from pages it trusts
e.g. allow referers only from the

same domain
XSRF
This is a reasonable way to protect

against XSRF but not foolproof
It’s considered one of the weaker

forms of protection
XSRF
If an XSRF attack originates

from an HTTPS domain then the
referer will be omitted
XSRF
Mitigation
1. Referer header
2. Origin header
XSRF
Mitigation - Origin header
This is a special header the browser
adds when the request is made to a
domain which is different from the
page making the request
www.evil.com makes a request to

www.trustedbank.com - this will have the origin
header saying the request came from evil.com
XSRF
Mitigation - Origin header
The header will indicate the

protocol, domain and port of the
page from which the request was
made
i.e. evil.com. The trusted bank should be
able to test for this!
XSRF
Mitigation
1. Referer header
2. Origin header
XSRF
Mitigation - Challenge response
If a request performs any state

changing operation challenge it to
ensure that it’s doesn’t go through
automatically!
XSRF
This could involve the use of a

CAPTCHA code to ensure a human is
behind the keyboard
XSRF
This could involve the use of a
CAPTCHA code to ensure a human is
behind the keyboard
XSRF
The user could be asked to re-

authenticate before any critical
action is performed
XSRF
The user could be asked to re-
authenticate before any critical
action is performed
Re-entering passwords is painful

but much much safer
XSRF
Or the user could be prompted to

enter a OTP (One Time Password)
XSRF
One Time Password
This is a one time token sent to the

user’s mobile phone or secure
device
XSRF
One Time Password
It’s often used to confirm sensitive

and state-changing operations like
transfer of funds
XSRF
Mitigation
1. Referer header
2. Origin header
XSRF
Mitigation - Synchronizer token
This method of XSRF protection

involves using a secure random
token to ensure that the request
comes from the trusted website
XSRF
secure random token
On sensitive operations this

challenge token should be sent
along with the request
XSRF
secure random token
The ser ver then verifies that this

token exists and is correct before
performing the action
SIGNING UP USERS
Example16-signupWithToken.php
SIGNING UP USERS
Users sign up using a simple
form which has a user name
and password field
We know how to do this!

SIGNING UP USERS
<h3> Sign up to our new Top Secret Club! </h3> 
<form method="POST" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>"> 
<span style="color: red"><?php echo $error_message;?></span> 
<br> 
<br> 
Email address: 
<br> 
<input type="text" name="user_email" maxlength="100"> 
<br> 
<br> 
Password: 
<br> 
<input type="text" name="user_password" maxlength="20"> 
<br> 
<br> 
<input type="submit" value="Sign up"> 
 
<input type="hidden" name="form_token" value="<?php echo $form_token; ?>" /> 
</form> 
<br>
SIGNING UP USERS
<br> 
<br> 
Email address: 
<br> 
Users who sign up to our Top
<br> 
Secret Club need to fill up this

<br> 
Password: 
<br> 
<br> 
<br>  form!
 
</form> 
<br> 
SIGNING UP USERS
<br> 
<br> 
Email address: 
<br> 
The data is POST’ed to the
<br> 
ser ver and processed in this

<br> 
Password: 
<br> 
<br> 
<br>  same PHP file!
 
</form> 
<br> 
SIGNING UP USERS
<br> 
<br> 
Email address: 
<br> 
<br> 
<br> 
Password: 
<br> 
<br> 
<br> 
 
</form> 
<br> 
SIGNING UP USERS
<br> 
<br> 
Email address: 
<br> 
Limit the
<br> 
<br> 
character lengths
Password: 
<br> 
of the field to
what you expect
<br> 
<br> 
 
</form> 
<br> 
<a href="Example26-login.php"> Already a member? Login </a>
in the database
SIGNING UP USERS
<br> 
<br> 
Hmm… everything looks
familiar except for this one

Email address: 
<br> 
<br> 
<br> 
Password: 
<br> 
little thing here…
<br> 
<br> 
 
</form> 
<br> 
SIGNING UP USERS
A hidden input field which

<br> 
<br> 
Email address: 
<br> 
sends to the ser ver a
<br> 
$form_token
<br> 
Password: 
<br> 
<br> 
<br> 
 
</form> 
<br> 
SIGNING UP USERS
This token protects our site from Cross

Site Request Forgery or CSRF attacks!
SIGNING UP USERS
A malicious site can cause the

browser to send requests to perform
unwanted actions on a trusted site
SIGNING UP USERS
In our case we only want our own
site to fill out the form to access the
Top Secret Club
No other site should be able to embed

that form and sign up new users
SIGNING UP USERS
In our case we only want our own No other site should be able to embed
site to fill out the form to access the that form and sign up new users
Top Secret Club
We should be able to uniquely

identify requests from our own site
SIGNING UP USERS
In our case we only want our own No other site should be able to embed
site to fill out the form to access the that form and sign up new users
Top Secret Club
Create a random per-session

identifier on the ser ver and store it
in a session variable
SIGNING UP USERS
identifier on the server and store it
Send this random identifier to the

ser ver along with every form submit
SIGNING UP USERS
Send this random identifier to the
The ser ver compares this random

identifier with the one stored in the
session to validate that the submit is
from a trusted site!
SIGNING UP USERS

This token need be generated only
Sendonce
this per
random session
identifier to the
The server compares this random

SIGNING UP USERS

The token can be reused for all
requests
Send across
this random that
identifier to session
the
The server compares this random

SIGNING UP USERS
<?php 
session_start(); 
 
$form_token = md5(uniqid('auth', true)); 
$_SESSION['form_token'] = $form_token; 
?>
Generate a random number which

will ser ve as a token for this session
SIGNING UP USERS
<?php 
session_start(); 
 
?>
This generates a unique id based on

the current time - the prefix for this
id will be “auth”
SIGNING UP USERS
<?php 
session_start(); 
 
?>
The more_entropy field is true which

means the id will be 23 characters
long rather than 13
SIGNING UP USERS
<?php 
session_start(); 
 
?>
The unique id is not secure by itself -

the md5 hash is a cryptographically
secure hash
SIGNING UP USERS
<?php 
session_start(); 
 
?>
Store it in the current session so it’s

accessible to all pages
SIGNING UP USERS
<br> 
<br> 
Make sure you always send
along the token at the time of

Email address: 
<br> 
<br> 
<br> 
Password: 
<br> 
form submit
<br> 
<br> 
 
</form> 
<br> 
SIGNING UP USERS
Now at the ser ver end we

want to add the newly signed
up user to the database
SIGNING UP USERS
$error_message = "";
if ($_SERVER["REQUEST_METHOD"] == "POST") {
$error_message = validate_inputs($_POST['user_email'], $_POST['user_password'], $form_token);
// If no errors then add the user to the database.
if (empty($error_message)) {
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$user_email = filter_var($_POST['user_email'], FILTER_SANITIZE_STRING);

$user_password = filter_var($_POST['user_password'], FILTER_SANITIZE_STRING);
try {
$stmt = $conn->prepare(
"INSERT INTO `Users` (user_email, user_password) VALUES (?, ?)"
);
$stmt->bind_param("ss", $user_email, sha1($user_password));
$stmt->execute();
$stmt->close();
$conn->close();
} catch (Exception $e) {
// Duplicate entry for key is error 1062
if($e->getCode() == 1062) {
$error_message =
'Username already exists, please sign in or choose a different user name';
}
else {
$error_message =
'We are unable to process your request. Please try again later';
}
}
}
}
SIGNING UP USERS
Make sure the form inputs are valid

by calling the validate_inputs()
function from the included file
SIGNING UP USERS
Checking whether the token received

is the same as the current session
token is part of the validation
SIGNING UP USERS
$user_email = filter_var($_POST['user_email'], FILTER_SANITIZE_STRING);
$user_password = filter_var($_POST['user_password'], FILTER_SANITIZE_STRING);
try {
$stmt = $conn->prepare(
"INSERT INTO `Users` (user_email, user_password) VALUES (?, ?)"
);
$stmt->bind_param("ss", $user_email, sha1($user_password));
$stmt->execute();
$stmt->close();
$conn->close();
} catch (Exception $e) {
// Duplicate entry for key is error 1062
if($e->getCode() == 1062) {
$error_message =
'Username already exists, please sign in or choose a different user name';
}
else {
$error_message =
'We are unable to process your request. Please try again later';
}
}
}
We simply insert the new user into the

}
Users table
SIGNING UP USERS
The validation of inputs now

needs to check the form
token as well
SIGNING UP USERS
function validate_inputs($user_email, $user_password, $form_token) {
$error = "";
if (!isset($user_email, $user_password, $form_token)) {

$error = 'Please enter a valid username and password';
} elseif ($form_token != $_SESSION['form_token']) {
$error = 'The form submission is invalid';
} elseif (strlen($user_password) < 6 || strlen($user_password) > 20) {
$error = 'The password length should be between 6 and 20 characters';
} elseif (!filter_var($user_email, FILTER_VALIDATE_EMAIL)) {
$error = 'The user name should be a valid email address';
} elseif (!ctype_alnum($user_password)) {
$error = 'The password should only have alphabets or numbers';
}
return $error;
}
SIGNING UP USERS
$error = "";
This is pretty self-

explanatory except for one

}
part
return $error;
}
SIGNING UP USERS
$error = "";

}
}Check that the form token is the

return $error;
same token that was generated in

this session
XSRF
Mitigation
1. Referer header
2. Origin header

XSRF

Uploaded by

Copyright:

Available Formats

XSRF

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

XSRF

Uploaded by

Copyright:

Available Formats

XSRF

XSRF = Cross Site Request

Also called CSRF or Sea-surf

These commands get the server to

The website trusts the user and

This is different from a XSS

XSRF exploits the trust the

XSRF does not try and get data

Instead it focuses on the user

Actions such as transferring

The user might be logged into his

He’s also bored and he’s browsing

The attacker has a post on that

Isn’t this a great

Browsers load the URL of images, this

The user just needs to load the page

He doesn’t even need to click on it!

Note that the attacker was aware of

The user is obviously allowed to

The victim was tricked into sending a

The withdraw URL performs an

Involve sites which know a user’s identity

The user typically has to be logged in

The user might be logged into

Exploit the site’s trust in that identity

The ser ver trusts and allows the

The user is obviously allowed to transfer

Characteristics of a XSRF attack

Tricks the browser into sending an

The victim inadvertently performs an

The victim was tricked into sending a

Characteristics of a XSRF attack

Involve HTTP requests which perform actions

The action will harm the victim

The withdraw URL performs an

Involve HTTP requests which perform actions

Browsers load the URL which

It’s a page which transfers funds

And here is the from account, the

Obviously the pic

This particular page which performs

First of all why is such an important

There is of course a whole bunch of

echo "Transferring funds <br>";

if (!empty($from_id) && !empty($to_id) && !empty($amount)) {

echo "Transferring funds <br>";

if (!empty($from_id) && !empty($to_id) && !empty($amount)) {

Some useless escaping here:-)

if (!empty($from_id) && !empty($to_id) && !empty($amount)) {

This is not typically the way the SQL

if (!empty($from_id) && !empty($to_id) && !empty($amount)) {

This should be in a stored procedure and

echo "Transferring funds <br>";

if (!empty($from_id) && !empty($to_id) && !empty($amount)) {

Remember that this requires the user

There is an aspect of social engineering

Sending an email with a link to the user

Let’s say that the bank uses POST

Such a request cannot be

But can be submitted using a