CSRF

Cross Site Request Forgery

 AGENDA

1. What is CSRF ?

2. How do you find it ?

3. Automated Exploitation Tools .

4. How do you prevent it ?

 What is CSRF ?
Before under standing csrf you have
to first understand session
management and what are cookies?

Session Management –

Imagine that user wants to access a banking website he

logins to the website , now the application sets a cookie in
user ‘s website.
Cookie – is some text file that contains some information that
identifies user to the backend , it’s a long string which is not
easy to guess. The user will be identified through this cookie
for further reference .
Backend process –

• When the user access the website which he has

accessed before ,the browser check the cookie jar the
browser ask the cookie jar “do you have any cookie
related to this website ?” if the ans is yes then the
cookie assigns it .
• Now when the backend receive this cookie it checks
which user is assigned to this cookie .
• The application checks the permission the user has if it
has the permission then it allows it or else it denies .
CROSS SITE REQUEST FORGERY(CSRF)

CSRF is an attack where the attack causes the victim user to

carry out an action unintentionally while that user is
authenticated .

For this attack to happen the user has to be

logged in to the application.

STEPS –

1. The attacker has to send a email with malicious link to

the victim .
For example –

The attacker sends an email in which he asks victim to

click on it , now here the link which the attacker sent is
 malicious by which he can change the user’s email id to
attackers email id .
(https://bank.com/email/change?=email=attacker@gma
il.ca)

2. Now for this attack to be successful you have to make

sure that the user is already logged in to the website
which you want to attack , once the victim is logged in
send the email with malicious link.

3. Suppose the victim clicks on the link emailed by the

attacker the browser will direct it to cookie jar , cookie
jar finds a similar authentication but the link which the
attacker sent is to change the email of the victim to
his(Attacker) email.

4. Now once that is successful the attacker can request for

forgot password ,change the password and use the
account .
 How will you make the victim click on the link ???

• The attacker will develop a malicious website that the

victim has interest on.
• In the background there is a script that is executing with
in an invisible <iframe> that you can’t see
• This script changes the email address and you can gain
access if the victim is logged in to the website .

CSRF CONDITIONS –
Now before you attack you have to make sure that the
sight is vulnerable to CSRF , for CSRF attack there are three
main condition –
1) Relevant action.
2) Cookie-based session handling.
3) No unpredictable request parameters .
How To Find CSRF
Vulnerabilities –

Depends on perspective of
testing –
Black box & White box testing.

Black Box Testing –

• You get the URL of the application , credentials of
application.
• Map the application.
• Review all the key functionality in the application .
• Identify all application functionality that satisfy the 3
conditions –
• Relevant action.
• Cookie-based session handling.
• No unpredictable request parameters

Create a POC(proof of concept) script to exploit CSRF.

 BLACK BOX Methods -
GET Request - <img> tag with src attribute set the vulnerable
URL
POST Request -
Form with hidden fields for all the required parameters and
the target set to vulnerable URL

WHITE BOX TESTING –

• You have access to URL as well as SOURCE CODE
• Try to identify frame work that’s being used in the
application because all the modern frame work can
defend CSRF attack.
• Find out how the frame work defend the CSRF attack
• Make sure that built in defends are not disabled
• Review all the sensitive functionality to ensure that the
CSRF defense has been applied .
Automated Exploitation Tools Web
Application
Vulnerability Scanners (WAVS).
 HOW TO PREVENT CSRF ??
Preventing CSRF Vulnerabilities
• Primary Defense
• Use a CSRF token in relevant requests.
• Additional Defense
• Use of SameSite cookies
• Inadequate Defense
• Use of Referer header

PRIMARY DEFENSE –
CSRF Tokens - is a randomly generated string that is passed
as a parameter in the request and tied to user session.
How should CSRF tokens be generated?
• Unpredictable with high entropy, similar to session tokens
• Tied to the user's session
• Validated before the relevant action is executed .
How should CSRF tokens be transmitted?

Hidden field of an HTML form that is

submitted using a POST method .
• Custom request header .
• Tokens submitted in the URL query string
are less secure.
• Tokens generally should not be
transmitted within cookies.
How should CSRF tokens be validated?
• Generated tokens should be stored server-side within the
user’s session data .
• When performing a request, a validation should be
performed that verifies that the submitted token matches the
value that is stored in the user’s session .
• Validation should be performed regardless of HTTP method
or content type of the request.
• If a token is not submitted, the request should be rejected.

Additional Defense – SameSite Cookies The SameSite

attribute can be used to control whether cookies are
submitted in cross-site requests.

Strict – the cookie will only be sent in first party content and
not be sent along with request initiated by third party
website.
LAX – request should use GET method the result has to be
generated when clicked on link .
Inadequate Defense – Referer Header The Referer HTTP
request header contains an absolute or partial address of the
page making the request.
• Referer headers can be spoofed
• The defense can usually be bypassed:
• Example #1 –if it’s not present, the application does not
check for it
• Example #2 –the referrer header is only checked to see if it
contains the domain and exact
Resources
• Web Security Academy - CSRF
https://portswigger.net/web-security/csrf

• Web Application Hacker’s Handbook

Chapter 13 - Attacking Users: Other Techniques (pgs. 504–
511)

• OWASP –CSRF
https:// owasp.org/www-community/attacks/csrf

• Cross-Site Request Forgery Prevention Cheat Sheet

https:// cheatsheetseries.owasp.org/cheatsheets/Cross-
Site_Request_Forgery_Prevention_Cheat_Sheet.html

• Reviewing Code for Cross-Site Request Forgery Issues

Overview
https://owasp.org/www-project-code-review-
guide/reviewing-code-for-csrf-issues
PRATICAL IMPLEMENTATION OF CSRF

CSRF - Lab #1 CSRF vulnerability with

no defenses.

Exploiting a CSRF vulnerability in a web application by

changing a user's email address. It covers using Burp Suite
for the attack and scripting a manual exploit. This explains
the necessary conditions for CSRF attacks and showcases
how attackers can manipulate users without their
knowledge.
Vulnerable parameter – email change functionality
Goal – exploit the CSRF vulnerability and change the email
address.
CREDS – wiener : peter
Login with the credentials –
Now try to change the email address by burpsuite

Try to intercept the email id change in burp

Send that to repeater and turn of the interceptor

The mail is changed to [email protected]

Now check whether the website is vulnerable to all the 3

conditions of CSRF , this particular website is vulnerable to
all 3 conditions .
IF you are using burp suite pro it will automatically generate
the scrf script just right click , click on engagement tools
then select generate CSRF POC

Copy the html and click on go to exploit server

Exploit server will host the script for us

Now click on View exploit