New Microsoft Word Document
docx
keyboard_arrow_up
School
Sir Syed College of Education, Kotli *
*We aren’t endorsed by this school
Course
CREATIVE W
Subject
Information Systems
Date
Nov 24, 2024
Type
docx
Pages
8
Uploaded by CaptainThunderArmadillo30
Cross-Site Request Forgery (CSRF) Attack Lab
Lab Objective:
The primary goal of this laboratory session is to provide students with hands-on experience in comprehending and executing a Cross-Site Request Forgery (CSRF) attack. This type of attack involves three key elements: a victim user, a trusted site, and a malicious site. The victim user, who is actively logged into a trusted site, unwittingly visits a malicious site that injects an unauthorized HTTP request into the user's session, potentially leading to harmful consequences.
Lab Scenario:
In this practical exercise, students will engage in a CSRF attack against a social networking web application. Specifically, the target is an open-source social networking platform known as Elgg, which has been pre-installed in our virtual machine (VM). Despite Elgg having built-in countermeasures against CSRF, we have deliberately disabled them for the purpose of this lab to allow students to explore and understand the mechanics of this type of attack.
Lab Environment Setup:
First, we have to setup the docker environment for this. First download the Labsetup.zip file and unzip it then open it and run the SEED terminal here. Now use dcbuild (builds the container images), dcup(starts the docker containers), dockps( to find the ID of containers). Now go into /etc/hosts and put (10.9.0.5 www.seed-server.com, 10.9.0.5 www.example32.com, 10.9.0.105 www.attacker32.com
) at the end of the file. Now the sites are activated and the server is correctly
configured. Lab Tasks: Attacks
Task 1: Observing HTTP Request:
For CSRF, we forge http requests, so for this we need to know a legit http request and its parameters. Go to seed-server.com and put in username and password for Alice given in the
document. Now run http header live in firefox and login to Alice’s account which captures the http request. Now click the login request which opens a Post request and gives parameters like username and password. .
Task 2: CSRF Attack using GET Request:
Two people Alice and Samy are using the same social network Elgg. Now Samy wants to add Alice to his friend list in Elgg but Alice does not want to add Samy. So Samy uses CSRF attack to achive his goal. He goes to the members in Elgg and searches for Alice and when he finds her,
he runs his http header live and sends friend request to Alice. This opens the Get request which then on clicking gives us the ID of Alice. Now check Alice’s ID and save the header somewhere and go check your ID by going in your profile and inspecting source which in case of Samy is 59. Now to perform the attack, go to terminal and check the ID of attacker container using dockps and then go to addfriend.html and edit it by putting the header of parameters that we saved earlier and just change the ID from Alice’s ID to Samy’s ID. This means that whenever Alice logins in her profile and clicks on any URL that Samy has sent, then immediately Samy is added to Alice’s friends because when Alice clicks on the URL there is a script that runs that accepts Samy’s request.
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
- Access to all documents
- Unlimited textbook solutions
- 24/7 expert homework help
Task 3: CSRF Attack using POST Request:
Now Samy has becomes friends with Alice but Samy does not stop here, he wants to do something more and post something from Alice’s profile. So Samy uses CSRF attack to achieve this. Now login to Samy’s profile and go to profile and write something in description. Before saving run the http header live and then save the profile. This captures the request and now click on it and save the header of the request. Now go to the terminal and check running containers id by dockps. Now go to editprofile.html and edit it and also add the header we just saved here too. Now login to Alice’s account and check the profile, it is empty. Now when Alice clicks the URL sent by Samy then Alice’s profile get updated and shows what Samy intended to show.
Question 1: Yes, Samy can find Alice’s guid by logging into his account and turning on the http live header, so when he sends request to Alice, it then captures the request and shows Alice’s guid.
Question 2:
No, if Bobby does not know the person’s guid then he cannot launch CSRF attack because if the guid in script does not match with the guid of any other user clicking on the URL, then the script is not run and Bobby cannot change the profile. Lab Tasks: Defense
Task 4: Enabling Elgg’s Countermeasure:
Now to counter the CSRF attack, we have the concept of tokens. Tokens are kind of like the ids that are assigned to each live session. So, if we want to counter CSRF attack then we can modify the security code by commenting the return statement so it can validate the token of session being run. So, if Alice clicks on any malicious link sent by anyone and Alice clicks it then the token will be invalid and the attack will not be performed because the token of the web page and Alice’s session token will not match. The attack now can only be performed if the link is on Alice’s profile and it is obvious that Alice would not click something posted on her profile by anyone other than her.
Task 5: Experimenting with the SameSite Cookie Method:
Different browsers now use SameSite cookies to counter the CSRF attacks. It uses three types of cookies (normal, lax, strict). So lax cookie is the one that can be opened in cross-site requests
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
- Access to all documents
- Unlimited textbook solutions
- 24/7 expert homework help
and strict is the one that can never be opened in cross-site requests just the same site requests. These strict cookies are the SameSite cookies because if any website wants to protect its user, then it can restrict some cookies to be only SameSite so they can never be sent to cross-site requests. We can also make the lax cookies SameSite by changing the values of parameters. So, in this scenario, we are given two links, A and B. Link A goes to example32.com while link B goes to attacker32.com, and both pages are identical, and both send three different requests to www.example32.com/showcookies.php
. So, whenever you click on any request from link A, it is
same-site request and it executes all three cookies. But if you click on any request from link B, it is cross-site request and strict are not executed. So, if you want to restrict some cookies then make them strict cookies so they cannot be accessed
by cross-site requests. If we want to help Elgg defend against the CSRF attacks then we can use strict cookies on the site so whenever someone tries to perform CSRF attack from any malicious link, the script would never be executed because the session on the Elgg site would not depend on any other session because of strict cookies.
References:
Lab manual:
https://seedsecuritylabs.org/Labs_20.04/Files/Web_CSRF_Elgg/Web_CSRF_Elgg.pdf
CSRF video:
https://www.youtube.com/watch?v=SF7p8ix6WnU