Comment on page
The browser makes a POST request to the server that contains the user’s identification and password. The server responds with a cookie, which is set on the user’s browser using the HTTP header
Set-Cookie, and includes a session ID to identify the user. On every subsequent request, the server needs to find that session and deserialize it, because user data is stored on the server (source).
First of all, testers need to analyze the cookies used by the application. Instead of using random values, some implementations encode intelligible values like usernames, roles, secrets and so on. Since cookies are stored in the browser, attackers could decode them, encode different values and try to impersonate roles or users.
The following tests can help identify insecure cookies (lacking security).
- Trying to decode cookies and forging new ones based on the values decoded (encoding usually is base64 or hex)
- Logging out and being able to use the same session-cookie to log in
- Creating several accounts with almost the same username, and noticing similarities in the session-cookies value
- Changing password and realizing the old session cookies is still valid and hasn't been revoked
Cookies have a key/value pair along with attributes too. The attributes tell the browser how to handle the cookies. Some security attributes help protect the cookies. Testers need to make sure that sensitive cookies make use of these attributes. If they don't, they are considered as unsecured cookies (lacking protection).
- Secure: cookies can only be sent through HTTPS sessions, hence mitigating MITM (Man In The Middle) attacks allowing attackers to eavesdrop on unencrypted communications and stealing cookies
- SameSite: cookies can only be sent with requests initiated from the same registrable domain, hence mitigating the risk of CSRF (Cross-Site Request Forgery) and Information leakage attacks.