Scribd
Upload
105 views10 pages

CSRF Presentation

This document discusses cross-site request forgery (CSRF), an attack that tricks a user into performing unwanted actions on a web application. It describes how CSRF works by forcing the victim's browser to execute malicious requests while they are authenticated to the target site. The document outlines GET and POST scenarios for CSRF attacks and provides prevention techniques, such as validating requests with cryptographic tokens.

Uploaded by

Mansoor Shar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
105 views10 pages

CSRF Presentation

This document discusses cross-site request forgery (CSRF), an attack that tricks a user into performing unwanted actions on a web application. It describes how CSRF works by forcing the victim's browser to execute malicious requests while they are authenticated to the target site. The document outlines GET and POST scenarios for CSRF attacks and provides prevention techniques, such as validating requests with cryptographic tokens.

Uploaded by

Mansoor Shar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 10

CROSS-SITE REQUEST

FORGERY (CSRF)
BY: MANSOOR ALI
BATCH 5: PGD CYBER SECURITY
SIR WAQAR AHMED KHAN / SIR WASI JUNAIDI
WHAT IS CROSS-SITE REQUEST FORGERY
(CSRF)?
• Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute
unwanted actions on a web application in which they’re currently authenticated.
With a little help of social engineering (such as sending a link via email or chat),
an attacker may trick the users of a web application into executing actions of the
attacker’s choosing. If the victim is a normal user, a successful CSRF attack can
force the user to perform state changing requests like transferring funds,
changing their email address, and so forth. If the victim is an administrative
account, CSRF can compromise the entire web application.
HOW DOES THE ATTACK WORK?

• There are numerous ways in which an end user can be tricked into loading information
from or submitting information to a web application. In order to execute an attack, we
must first understand how to generate a valid malicious request for our victim to execute.
Let us consider the following example: Alice wishes to transfer $100 to Bob using
the bank.com web application that is vulnerable to CSRF. Maria, an attacker, wants to trick
Alice into sending the money to Maria instead. The attack will comprise the following
steps:
1.Building an exploit URL or script
2.Tricking Alice into executing the action with Social Engineering
GET SCENARIO

• If the application was designed to primarily use GET requests to transfer parameters and execute
actions, the money transfer operation might be reduced to a request like:
“GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.” Maria now decides to
exploit this web application vulnerability using Alice as the victim. Maria first constructs the
following exploit URL which will transfer $100,000 from Alice’s account to Maria’s account. Maria
takes the original command URL and replaces the beneficiary name with herself, raising the transfer
amount significantly at the same time:
“http://bank.com/transfer.do?acct=MARIA&amount=100000”
GET SCENARIO… CONTINUE

• The social engineering aspect of the attack tricks Alice into loading this URL when Alice
is logged into the bank application. This is usually done with one of the following
techniques: sending an unsolicited email with HTML content planting an exploit URL or
script on pages that are likely to be visited by the victim while they are also doing online
banking The exploit URL can be disguised as an ordinary link, encouraging the victim to
click it: “<a href="http://bank.com/transfer.do?
acct=MARIA&amount=100000">View my Pictures!</a>”
GET SCENARIO… CONTINUE

• Or as a 0x0 fake image: <img


src="http://bank.com/transfer.do?acct=MARIA&amount=100000"
width="0" height="0" border="0"> If this image tag were included in the email, Alice
wouldn’t see anything. However, the browser will still submit the request to bank.com
without any visual indication that the transfer has taken place. A real life example of
CSRF attack on an application using GET was a uTorrent exploit from 2008 that was
used on a mass scale to download malware.
POST SCENARIO

• The only difference between GET and POST attacks is how the attack is being executed
by the victim. Let’s assume the bank now uses POST and the vulnerable request looks
like this: POST “http://bank.com/transfer.do HTTP/1.1
acct=BOB&amount=100” Such a request cannot be delivered using standard A or
IMG tags, but can be delivered using a FORM tags:
POST SCENARIO… CONTINUE

• <form action="http://bank.com/transfer.do" method="POST"> <input type="hidden"


name="acct" value="MARIA"/> <input type="hidden" name="amount"
value="100000"/> <input type="submit" value="View my pictures"/> </form> This form
will require the user to click on the submit button, but this can be also executed
automatically using JavaScript: <body onload="document.forms[0].submit()"> <form...
OTHER HTTP METHODS

• Modern web application APIs frequently use other HTTP methods, such as PUT or
DELETE.
• Every method has different vulnerabilities. So here in bWAPP over bee box we will apply
GET request method for manipulation purpose
CROSS-SITE REQUEST FORGERY PREVENTION
CHEAT SHEET
• https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_
Cheat_Sheet.html

You might also like