CSRF:CROSS-SITE REQUEST

FORGERY

1-DENIZ A.
2-EKRMA A.
 DEFINITION

• Can be defined as a type of attack in which the attacker tricks the user to run a malicious action
through an application that the user is logged in .
• Most CSRF attacks trick users into clicking a malicious link. The link is often delivered via emails
and chat messages using social engineering techniques. 
• The link may include malicious Script o which contains a request. Once a user clicks on the link,
the code requests a specific task. If the attack is successful, the browser executes the task, letting
the attacker perform unauthorized actions using the user’s session
 1. Attacker observes URL request format
The attacker observes that purchase requests on the website are in this format. 
GET
https://examplebuy.com/shop/purchase?
productid=3441&amount=200&address=33&20Park%20Drive%20NY%20NY
HTTP/1.1
The request assumes that the user has an open session with the website. It uses an
EXAMPLE/USE address ID to reference an address defined by the legitimate user.
2. Attacker crafts a forged request URL
CASE The attacker now creates a forged URL that will purchase a product with a high
purchase price, using another user’s account.
GET
https://examplebuy.com/shop/purchase?
productid=5776&amount=2000&address=45%20Main%20Street%20NJ
%20NY HTTP/1.1
The attacker manipulates three parameters in the request—changing the product to a
product they want to buy, changing the amount, and using their own address.
3. Attacker hides the URL in an image
There are a number of ways to get the user to load the forged request URL. A common tactic is to
hide the URL in an image tag, and embed it in
an email sent to the victim, or a website they will visit. The image tag would look like this:<img
src  = “https://examplebuy.com/shop/purchase?
productid=5776&amount=2000&addres=45%20Main%20Street%20NJ%20NY” width=“0”
height= “0”>

4. Attacker uses social engineering to get the user to load the image
The attacker sends a phishing email to the victim, which either directly includes the image, or
includes a link to a web page that embeds the malicious image tag. The URL is loaded on the
user’s device.
5. Ecommerce site receives the forged request
Assuming that the user has an active session with the ecommerce site, when the URL is loaded,
the website receives the forged purchase request. The website cannot identify that the request was
not made directly by the legitimate user. It obeys the request and sends the goods to the attacker,
billing the legitimate user’s account. 
 HOW TO PROTECT OUR SYSTEM

• Check if your framework has built-in CSRF protection and use it

• If framework does not have built-in CSRF protection add CSRF tokens to all state
changing requests (requests that cause actions on the site) and validate them on backend
• For stateful software use the synchronizer token pattern
• For stateless software use double submit cookies
• Implement at least one mitigation from Defense in Depth Mitigations section
• Consider SameSite Cookie Attribute for session cookies but be careful to NOT set a
cookie specifically for a domain as that would introduce a security vulnerability that all
subdomains of that domain share the cookie. This is particularly an issue when a
subdomain has a CNAME to domains not in your control.
• Consider implementing user interaction based protection for highly sensitive operations
• Consider the use of custom request headers
• Consider verifying the origin with standard headers
• Remember that any Cross-Site Scripting (XSS) can be used to defeat all CSRF mitigation
techniques!
• See the OWASP XSS Prevention Cheat Sheet for detailed guidance on how to prevent
XSS flaws.
• Do not use GET requests for state changing operations.
• If for any reason you do it, protect those resources against CSRF