blob: b3720422aab42c13a6134a207c4abaacbd1cfbd5 (
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
❯ printf 'HEAD / HTTP/1.0\r\n\r\n' | nc 10.0.2.15 80
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Fri, 27 Mar 2026 09:43:20 GMT
Content-Type: text/html
Connection: close
X-Powered-By: PHP/5.5.9-1ubuntu4.29
Set-Cookie: I_am_admin=68934a3e9455fa72420237eb05902327; expires=Fri, 27-Mar-2026 10:43:20 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.
|
