## 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.