Cookies are small pieces of data sent from websites and stored in the user's web browser. They contain information relative to such browser or to some specific web application's user. In modern web applications, cookies are used to keep track of the user's session. By saving session identifiers on the server and on the user's computer, the server is able to distinguish between different requests made from different clients at the same time. When any request is sent to the server, the browser adds a cookie and then sends the request; the server can identify the session based on that cookie.
In this recipe, we will learn how to identify a couple of vulnerabilities that will allow an attacker to hijack the session of a valid user.
- Navigate to
http://192.168.56.102/mutillidae/. - Open Cookie Manager+ and delete all the cookies. This is to prevent being confused with the previous ones.
- Now, in Mutillidae II, navigate to OWASP Top 10 | A3 – Broken Authentication and Session Management | Cookies.
- In Cookies Manager+ we will see two new cookies appear,
PHPSESSIDandshowhints. Select the former and click Edit to see all its parameters.
PHPSESSID is the default name for session cookies in PHP-based web applications. By looking at the parameter's values in this cookie, we can see that it can be sent by secure and insecure channels indistinctly (HTTP and HTTPS). Also, it can be read by the server and also by the client through the scripting code, as it doesn't have the Secure and HTTPOnly flags enabled. This means, the sessions in this application can be hijacked.
In this recipe, we have just checked some values of a cookie, although not as spectacular as the previous one. It is important to check the cookies configuration in every penetration test we perform; an incorrectly set session cookie opens the door to a session hijacking attack and the misuse of a trusted user's account.
If a cookie doesn't have the HTTPOnly flag enabled, it can be read by scripting; so, if there is a cross-site scripting vulnerability, the attacker will be able to get the identifier of a valid session and use that value to impersonate the real user in the application.
The Secure attribute or Send For Encrypted Connections Only option in Cookies Manager+ tells the browser to only send or receive this cookie by encrypted channels (that is, only by an HTTPS connection). If this flag is not set, an attacker can perform a man in the middle (MiTM) attack and get the session cookie via HTTP, which gives it in plain text because HTTP is a clear text protocol. This takes us again to the scenario where he/she can impersonate a valid user by having the session identifier.
Just like
PHPSESSID is the default name for PHP session cookies, other platforms also have names, such as:
ASP.NET_SessionIdis the name for a ASP.NET session cookie.JSESSIONIDis the session cookie for JSP implementations.
OWASP has a very thorough article on securing session IDs and session cookies:
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet