Understanding CSRF Attacks: A Lab Report Guide

Lab Report-2 CSRF Attack: One kind of security vulnerability is called a Cross-Site Request Forgery (CSRF) attack, in which an unauthorized user is tricked into doing operations on a web application while they are authenticated. Another name for it is a session riding or one-click attack.Usually, the way the attack operates is by taking advantage of the faith a web application has in the user's browser. The perpetrator creates a malicious image, script, or link that, when clicked by an authenticated victim on the target website, sends a request to the target application using the victim's credentials or current session. For example, while a victim is signed into their bank account, they may click on a seemingly innocent link (in an email or on a website, for example), but it's actually a ruse to request a password change or money transfer. These activities would be carried out without the victim's knowledge or consent if the CSRF attempt is successful and the victim has the required permissions on the target site. Here are is the procedure for performing the csrf attacks which are in given in the form of task in the folder. For this csrf attack we will be using the 3 different websites make sure that we will be add there domains for correct functionality below screenshots are the webpages screenshots.

Fig 1. www.seed-server.com

Fig 2. www.attacker32.com Fig 3. www.example32.com

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

Prior starting the tasks the pre requirements for the tasks are adding HTTP Header Live and the above shown websites are the pre requirements now in the vnc open terminal download the labset from the seedlabs and then click on folder and open in terminal and build the labsetup. TASK 1:Observing HTTP Request The aim of this task is to use the HTTP Header live addon in this task we have to capture what parameters are passed when we login into the account firstly enter the credential before enter login press the add-on and observe what parameters are passed here is the screenshoot of this activity. In this screenshot it clearly visible that name and password parameters

TASK 2:CSRF Attack Using GET Request In this task the attacker i.e samy tries to add as a friend to perform this task firstly we need to know the guid of the both samy and the alice we can obtain the guid of the samy easily as we know the credentials of the samy login into account and click on view page source you will find the guid pf samy in this code snippet shown below and the guid of samy is 59 Now to get the guid of the alice try to add as a friend from samy account before clicking on add friend use the HTTP Header Live in the requests you can see the guid of alice shown below 56 save the link for next step.

Now we will inject the code in the other website and make the alice to click on the website when alice clicks the link without interference samy was added as her friend here is the changed code.

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

When alice clicks the link here is the action happens. TASK 3:CSRF Attack using POST Request In this attack,attacker will change the description of alice.samy will overwrite the alice description as “Samy is my hero” the logic behind this attack is as same as the previous task the attacker tricks the alice that makes clicks on malicious the malicious code was encrypted in the clicked link that makes change in the description of alice here is the updated script.

Here is the tracking of the request Here is the updated code.

When alice logged in into her attack and clicked the link without the interference of alice the descriptuion will be changed as shown un the figure here is the proof of change. • Question 1: The forged HTTP request needs Alice’s user id (guid) to work properly. If Boby targets Alice specifically, before the attack, he can find ways to get Alice’s user id. Boby does not know Alice’s Elgg password, so he cannot log into Alice’s account to get the information. Please describe how Boby can solve this problem. Boby can use his own account to add Alice as a friend. He may watch the outgoing request using an application such as HTTP Header Live before he sends the request. One of the parameters in the friend request will be Alice's user ID (GUID). Boby may retrieve Alice's GUID by examining this request instead than logging into her account. This makes use of the fact that Elgg makes user IDs available through the buddy request mechanism. This allows Boby to get any other user's GUID for the CSRF attack without ever having their password, provided he has an account on the same Elgg instance.

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

• Question 2: If Boby would like to launch the attack to anybody who visits his malicious web page. In this case, he does not know who is visiting the web page beforehand. Can he still launch the CSRF attack to modify the victim’s Elgg profile? Please explain. We have a Guid in the case of the elgg profile. This scenario does not work since the attack is unsuccessful when it is performed and the guid is left blank. It also does not change the request. TASK 4:Enabling Elgg’s Countermeasure In this task we will be perform some actions that prevents the CSRF Attack to we will be remove some function in the code in this script we will be removing the return function in the code by removing the return function from the code it prevents the attacker to perform the CSRF Attacker we will be using the secret tokens here they are __elg_ts and __elg_tokens. Before accepting updates to a user's profile, the server must check these, which are created at random on each page view. I am unable to get or infer these token values from the victim's website as an attacker. They are dynamically appended to answers and are created server-side. My fake requests without the appropriate tokens are blocked from completing by the validation. The CSRF assault has now stopped. An infinite cycle of unsuccessful modifications and page reloads happens when testing the attack. It ends when you kill the browser tab. By limiting the use of valid tokens to requests from the same origin, the secret tokens serve as CSRF prevention. Tokens cannot be guessed or reused by cross-site requests.

By this change when we tried to perform the previous tasks now the attacker cannot perform the CSRF Attacker whenever the attacker performs the attack it shows the error shown below.

TASK 5:Experminting with Samesite Cookie Method In this website we will be using our third website when ever we launch the third website in our intwrnet three types of cookies where loaded namely they are the normal-cookie,lax-cookie and the strict-cookie. When we click on the experiment 1and done any REQUESTS then all three types of cookies where executed.

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

When we redirect back and click on the second link and perform the GET Request only two types of cookies where executed those are normal-cookies and the lax-cookies but when we click on POST request only normal-cookies will be executed. Fig shows when clicked on GET Request

Fig shows when clicked on POST Request. SameSite cookies shield critical cookies like session IDs against CSRF attacks and provide servers with insight into the origin of requests. Elgg may use this as an extra defense against CSRF. To use this with Elgg: To stop the session cookie from being transmitted on any CSRF requests, Elgg might set it to Strict SameSite. Due to the absence of the session cookie, request validation would be able to identify counterfeit CSRF and reject them. Beyond random tokens, SameSite offers an additional degree of security in depth.

CSRF_Attack

Related Documents