DVWA Walkthrough IX - Weak Session IDs

To further your understanding of DVWA, explore the comprehensive DVWA walkthrough or browse the full DVWA series to master every vulnerability level.

Weak Session IDs

What’s this?

Weak session ID vulnerabilities occur when session tokens lack sufficient randomness, length, or entropy, making them predictable or guessable by attackers. PortSwigger Academy explains that flawed generation (e.g., sequential numbers, timestamps, or weak hashes like MD5) enables session hijacking via prediction or brute force. In DVWA, this module demonstrates predictable session cookies across security levels, from incrementing counters to time-based values.

Weak sessions enable unauthorized account access, data theft, or privilege escalation without credentials, compromising user sessions entirely.

Objective

The main goal of this module is to work out how the ID is generated.

Security: Low

Help
The cookie value should be very obviously predictable.

Check the source code here.

Clicking Generate sets a new session cookie each time. If we take a look at Burp’s HTTP history, we can see these cookies and verify that they are simply sequential numbers:

Security: Medium

Help
The value looks a little more random than on low but if you collect a few you should start to see a pattern.

Check the source code here.

At this security level, the session cookie looks slightly more elaborate, but also familiar. If we click Generate several times, we can see that the cookie value keeps incrementing. This is because it is based on the Unix epoch timestamp.

If we inspect the cookie value, we can correlate it with the exact time the cookie was generated, which matches the response timestamp:

Security: High

Help
First work out what format the value is in and then try to work out what is being used as the input to generate the values.
Extra flags are also being added to the cookie, this does not affect the challenge but highlights extra protections that can be added to protect the cookies.

Check the source code here.

Now the cookie looks even more complex:

However, we can verify that it is an MD5 hash:

Using Burp’s Sequencer, we can collect multiple cookie values for further analysis:
Finally, using John the Ripper, we can crack the hashes and confirm that the original value is still just a sequential number, this time MD5-hashed:

Wanna talk? Contact me here!