SESSION SECURITY

SESSION HIJACKING

What kind of session identifier does the application employ? Answer options (without quotation marks): "URL parameter", "URL argument", "body argument", "cookie" or "proprietary solution"

#
root@htb:~$ IP=10.129.235.124
root@htb:~$ printf "%s\t%s\n\n" "$IP" "xss.htb.net csrf.htb.net oredirect.htb.net minilab.htb.net" | sudo tee -a /etc/hosts

root@htb:~$ BROWSER > http://xss.htb.net/
 Email: heavycat106
 Password: rocknrol
 
root@htb:~$ BROWSER > http://xss.htb.net/ > F12 > Storage > Cookies
 http://xss.htb.net/
 Name: auth-session
 Value: s%3Ac0m4nIkY17kFNu66H7cagVDcN5lH9ibG.yGcm8fEAhExhH5PFttYLOMw1FavpeBn0dwddeUXAJiU
 
root@htb:~$ BROWSER > New Private Window > http://xss.htb.net/ > F12 > Storage > Cookies
 http://xss.htb.net/
 Name: auth-session
 Value: s%3Ac0m4nIkY17kFNu66H7cagVDcN5lH9ibG.yGcm8fEAhExhH5PFttYLOMw1FavpeBn0dwddeUXAJiU

 * reload the page to bypass the login page
 * ANSWER: cookie

SESSION FIXATION

If the HttpOnly flag was set, would the application still be vulnerable to session fixation? Answer Format: Yes or No

Yes
 * Setting the HttpOnly flag on cookies prevents JavaScript from accessing 
   the cookie, but it does not mitigate session fixation. Session fixation 
   occurs when an attacker sets a user's session ID before the user logs in, 
   allowing them to hijack the session once the user authenticates. 
   To prevent session fixation, the application should regenerate the 
   session ID after the user logs in and ensure that session IDs are securely 
   managed.

OBTAINING SESSION IDENTIFIERS W/O USER INTERACTION

If xss.htb.net was an intranet application, would an attacker still be able to capture cookies via sniffing traffic if he/she got access to the company's VPN? Suppose that any user connected to the VPN can interact with xss.htb.net. Answer format: Yes or No

Yes
 * If the attacker has access to the company's VPN and can interact with the
   intranet application (xss.htb.net), they may be able to sniff traffic 
   within the VPN network. This could allow them to capture cookies or 
   other sensitive data, unless the traffic is encrypted (e.g., via SSL/TLS). 
   However, if SSL encryption is properly implemented (HTTPS), the attacker 
   would not be able to directly sniff the content of the traffic. But, 
   if SSL is not used or the attacker can perform a man-in-the-middle (MITM) 
   attack, they could capture cookies or other sensitive information.

CROSS-SITE SCRIPTING (XSS)

If xss.htb.net was utilizing SSL encryption, would an attacker still be able to capture cookies through XSS? Answer format: Yes or No

Yes
 * XSS is a JavaScript vulnerability and is not affected by encryption
 * SSL encryption (HTTPS) secures data in transit but does not prevent 
   Cross-Site Scripting (XSS) attacks. If a website is vulnerable to XSS, an 
   attacker could inject malicious scripts that execute in the victim’s 
   browser, allowing them to steal cookies, session tokens, or other 
   sensitive data. To mitigate this, websites should implement proper 
   input sanitization, Content Security Policy (CSP), and set the HttpOnly 
   flag on cookies to prevent JavaScript access.

CROSS-SITE REQUEST FORGERY (CSRF/XSRF)

If the update-profile request was GET-based and no anti-CSRF protections existed, would you still be able to update Ela Stienen's profile through CSRF? Answer format: Yes or No

Yes
 * Yes, because CSRF (Cross-Site Request Forgery) exploits the trust a 
   website has in an authenticated user’s browser. If the update-profile 
   request is GET-based and there are no anti-CSRF protections, an attacker 
   could craft a malicious link such as https://csrf.htb.net/update-profile?name=Hacked
   and trick an authenticated user into visiting it. Since browsers 
   automatically send cookies (including authentication cookies) with 
   GET requests, the request would be processed as if it came from the 
   legitimate user, updating Ela Stienen’s profile without her consent.
    - a mitigation could be using "Use SameSite cookies" to restrict cookie 
      sending to same-origin requests.

CROSS-SITE REQUEST FORGERY (GET-BASED)

If csrf.htb.net was utilizing SSL encryption, would an attacker still be able to alter Julie Rogers' profile through CSRF? Answer format: Yes or No

Yes
 * SSL encryption (HTTPS) ensures secure communication between the client and 
   the server but does not prevent Cross-Site Request Forgery (CSRF) attacks. 
   CSRF exploits the trust a website has in the user's browser by making 
   unauthorized requests on behalf of an authenticated user.
    - To mitigate CSRF, proper protections such as anti-CSRF tokens should 
      be implemented

CROSS-SITE REQUEST FORGERY (POST-BASED)

If csrf.htb.net was utilizing secure cookies, would an attacker still be able to leak Julie Roger's CSRF token? Answer format: Yes or No

Yes
 * Yes because the site is using HTTP not HTTPS; when the site is using HTTPS then it's No!
    - When a cookie has the Secure flag set, it can only be transmitted over HTTPS connections.
    - This ensures that the cookie (which may contain session information, CSRF tokens, or other sensitive data) is never sent in plaintext over an insecure HTTP connection, which prevents eavesdropping by attackers using Man-in-the-Middle (MITM) attacks.

XSS & CSRF CHAINING

Same Origin Policy cannot prevent an attacker from changing the visibility of @goldenpeacock467's profile. Answer Format: Yes or No

Yes
 * The Same Origin Policy (SOP) is a security measure that prevents web pages 
   from making requests to a different domain than the one that served them. 
   It restricts scripts running in one origin (domain, protocol, and port) 
   from interacting with resources on another origin, protecting against 
   cross-origin attacks like Cross-Site Scripting (XSS) and 
   Cross-Site Request Forgery (CSRF).

   However, SOP does not control what an attacker can do if they already have
   access to a user's account or if they exploit vulnerabilities in the 
   application itself. If an attacker gains access to @goldenpeacock467's 
   account through stolen credentials, social engineering, or other methods,
   they can change the visibility settings just like the legitimate user would.

   Thus, SOP cannot prevent such an attack,

EXPLOITING WEAK CSRF TOKENS

Our malicious page included a user-triggered event handler (onclick). To evade what kind of security measure did we do that? Answer options (without quotation marks): "Same-Origin Policy", "Popup Blockers", "XSS Filters"

Popup Blockers

OPEN REDIRECT

If the request to complete.html was GET-based, would you still be able to obtain the token via exploiting the open redirect vulnerability? Answer format: Yes or No

Yes
 * if the token is included in the URL as a query parameter (e.g., complete.html?token=xyz123), the open redirect could send the request to an attacker-controlled domain, leaking the token via the Referer header or direct URL exposure. However, if the token is stored in a cookie with HttpOnly and Secure flags, it would not be exposed this way.