Session Security
Notes from Hack The Box Academy Session Security Module
Security Considerations
A security token should be...
Random;
Valid for a specific scope;
Expired after a certain amount of time
Where session token are located?
URL
HTML
Cookies
LocalStorage
SessionStorage
How a session token can be known by an attacker?
An attacker can retrieve the victim session token in many ways. Some of the techniques might require user interaction as others may not.
Traffic sniffing (if on the same network and unencrypted traffic)
Database compromise
CSRF
XSS
Open Redirect
Session vulnerabilities
Session Fixation
When the session token pre and post authentication, a valid session token can be fixated by the attacker and sent to the victim, so when the victim is tricked to log in to the application, an attacker can proceed to session hijacking since the session token is known by the attacker.
Check if a value is being fixated in the URL and then propagated in a session token.
Check if you can control the value of session token.
Check for pre and post login token values. Are they the same?
An attacker can use different techniques to fixate the session token and tricks the user to log in with that session token.
Send a malicious URL to the client with a fixated session token
Uses client-side script (ex: XSS) to set the victim session token (
document.cookie
= XXX)Manipulate the
Set-Cookie
HTTP response header.
Cross-Site Scripting
The session token should be accessible via client-side JavaScript (cookies are not protected with HTTPOnly).
The session token is carried with all HTTP requests.
We can use the function
btoa()
in Js to base64 encode the session token. The functionatob()
will decode the encoded string.
It is possible to steal the user session cookie even if the SSL encryption is enabled. Cookies are stored in the browser.
Examples of JS XSS payloads that aiming at retreiving the user's session token
We can capture the session token using Project Interactsh or Burp Collaborator. Those two tools acts as a web server.
Cross Site Request Forgery
For more information about CSRF see here.
Criteria
When all parameters of a request can be known by an attacker
Session management is based on HTTP session cookies only.
The user needs to be logged on the application when the request is issued.
The use of a CSRF token can prevent CSRF attack. However, the CSRF token should stay unknown from the attacker. For example, a CSRF token would be useless if an attacker can sniff the traffic and capture that token.
✅If any, the tester should validate the proper implementation of the CSRF token. See here.
Dangling markup (HTML) injection
HTML injection can be used to leak the CSRF token. The dangling markup technique is explained in details here and here. This technique can be used to bypasss CSP protection or when a full XSS attack is not possible to extract sensitive information from the response.
In the Hack The Box example, the following payload is inserted to the injection point:
The payload above inserts a table in the HTML page and load the background from an external URL. The URL provided point to the attacker server. Since a dangling markup vulnerability exists on the application, everything between the two single quote will be treated as the URL and returned to the attacker server.
In the image below, we can observe that the email is reflected on the page. We can try to injection HTML tag instead of Julie's email and check if it get parsed by the browser.
Using this payload, we confirmed that HTML injection is possible.
Inspecting the page source, we observed that the injection point is before a single quote.
We can use the payload mentioned above to inject a table tag within the HTML document that will make a cross site request to load the table background. Everything between the two single '
(quote) will be treated as the URL and then send to the attacker server.
XSS and CSRF Chaining
This Hack the Box section features the chaining of an XSS and CSRF attack in order to bypass the Same Origin Policy and the anti-CSRF protection! In this situation, a classical CSRF where a user will click on a link pointing to an external domain won't work since any requests coming from other origin are blocked. The attacker has to find a way for the request to be sent from the legitimate origin.
By chaining a stored XSS vulnerability that will execute a script once the user visit the page, an attacker will be able to bypass both the CSRF and Same Origin Policy. What the script will do is to send a POST
request to change the account visibility of the user. Since the POST
request will be issued from the same domain as the web application, the Same Origin policy could be bypassed.
When a user want to switch from a private to a public profile, he is invited to click on the Change Visibility button. This make a GET request to the change visibility page.
We can observe that a CSRF token can be found in a hidden input form in the web page. This CRSF token will be sent via a POST
request when the user will click on the Make Public/Make Private button.
The image below shows the POST request that is made to the server to make the profile public or private. The body of the request contains two parameters: the CSRF token and the change parameter.
This piece of code will be inserted in the Country field of the user profile which is vulnerable to stored XSS. When a user will visit the infected user profile, the script will get executed What this piece of code is doing is:
Make a
GET
request to the /app/change-visibilityRetrieve the value of the CSRF token within hidden input field.
Send a
POST
request to the server to change the visibility of the victim user profile. The request will contain the value of the CSRF token.
Injecting the script into the Country field of the Ela Stienen profile.
To simulate the victim, we can connect as the GoldenPeacock user and visit the Ela Stienen profile which is infected by the stored XSS. Once, the GoldenPeacock user will visit the infected profile, this will trigger the script and should change the visibility state of its profile.
At first, the profile of the GoldenPeacock is private since no Share button is visible.
However, the testers observed that the Share button appears on the GoldenPeacock user profile when that user visited the Ela profile page.
Variation - Delete User profile
In a similar manner, the payload above can be adapted to delete the account of a user. To adapt the payload properly, the tester needs to inspect how are crafted the requests to delete a user account. The testers observed that two requests are made. The first request is a GET
request when the user click on the Delete button from its profile account.
We can observe that the last part of the URL also contains the user email address linked to the user profile to delete. Also, we can notice that a CSRF is returned by the server within a hidden input tag.
Then, on a second request, the user has to confirm the deletion of the account by clicking another time on a Delete button. Once the user confirmed, a POST
request is sent to the server with the body containing the CSRF token.
Having a better understanding of how the requests are sent and the server response returned by the server to delete a user profile, we can modify our payload accordingly to make the GoldenPeacock user our victim.
Last updated