blob: 60ca4a6cb6c1e9d3f023c79822b7a04aab7146f9 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
## Exploit
1. Did [banner grabbing](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server) and noticed an interesting cookie name:
```bash
❯ curl --head http://10.0.2.15
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Fri, 27 Mar 2026 10:31:26 GMT
Content-Type: text/html
Connection: keep-alive
X-Powered-By: PHP/5.5.9-1ubuntu4.29
Set-Cookie: I_am_admin=68934a3e9455fa72420237eb05902327; expires=Fri, 27-Mar-2026 11:31:26 GMT; Max-Age=3600
```
1. Reverse looked up the md5 value `68934a3e9455fa72420237eb05902327` → `false`
1. Intuited to send a request to the website with the cookie value set to the md5 hash value `true` to get the flag. Test it with `cookie_poison.bash` or directly in Firefox: **F12** → **Storage** → **Cookies**.
## Fix
[https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/06-Session_Management_Testing/01-Testing_for_Session_Management_Schema]()
Returning a cookie is not the problem, since cookies can be necessary, or useful for holding non-sensitive data (like settings). The problem is what the cookie contains. It is pretty obvious what the cookie is for by its name "I_am_admin". Cookies are stored client-side so they should not be trusted by the server for giving user privileges. A secure approach would be sending a "session_id" cookie with a random identifier and then look up in a database the privileges associated with the given session.
|
