4.6 Session Management Testing

4.6.1

Analyze and ensure that enough randomness exists to stop session forging attacks. (Burp Suite Sequencer)
What Expires times are used on persistent cookies, and are they reasonable? (Vulnerable if it is more than 8 hours)
Check the Cache-Control header.

Evidence:

4.6.2

Check that session cookies have the directives Secure and httpOnly.
Check the values for the domain attribute has secured values with respect of the application.
Check the values for the path attribute has secured values with respect of the application.
Check the expiration time in the Expire attribute.
Check the SameSite attribute has secured values with respect of the application.

Evidence:

Analyze the authentication mechanism and its flow.
Perform an unauthenticated request to the website checking if a session cookie is set. If so a tester can send a valid session identifier to a user (possibly using a social engineering trick), wait for them to authenticate, and subsequently verify that privileges have been assigned to this cookie.
Check if a new session cookie is set once the user is logged into the application.
Check if the session cookie can be predicted.

Evidence:

Check that session IDs are send over POST request instead of URL parameters.
If POST is used, can it be interchanged with GET?
Check that session IDs are send over encrypting transport by default.
What cache-control directives are applied to requests/responses passing Session IDs?
Check if the session cookie can be predicted.

Evidence:

Analyze the CSRF Token. If there is not, the web might be vulnerable to CSRF.
Can be used only once?
Is it binded to the session or any user can use the same token?
Is it binded to the function?
Check for the Same-Origin Policy, SameSite=Lax or SameSite=Strict can prevent the browser from sending cookies along with cross-site requests.
Determine whether it is possible to initiate requests on a user’s behalf that are not initiated by the user.
Create an HTML page to perform a certain function in the web, similar to that shown below: (You can use Burp Engagement Tools to create a CSRF website)
Host the HTML on a malicious or third-party site
Send the link for the page to the victim(s) and induce them to click it.

We’ll have to change the encoding type (enctype) to text/plain to ensure the payload is delivered as-is.

<html>
 <body>
  <script>history.pushState('', '', '/')</script>
   <form action='http://victimsite.com' method='POST' enctype='text/plain'>
     <input type='hidden' name='{"name":"hacked","password":"hacked","padding":"'value='something"}' />
     <input type='submit' value='Submit request' />
   </form>
 </body>
</html>

Evidence:

Check if the application has a logout functionality
Check session termination after a given amount of time without activity (session timeout).
Does the session ID gets invalidated or just simply removed from the browsers storage.
It is expected that the invocation of a log out function in a web application connected to a SSO system or in the SSO system itself causes global termination of all sessions. An authentication of the user should be required to gain access to the application after log out in the SSO system and connected application.

Evidence:

Check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. Try to perform the same action, with the same cookie, every X hours until it expires or up to a maximum of 8.
Understand whether the timeout is enforced by the client or by the server (or both).

Evidence:

This vulnerability occurs when an application uses the same session variable for more than one purpose. An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set in one context and then used in another.

An authentication bypass attack vector could be executed by accessing a publicly accessible entry point (e.g. a password recovery page) that populates the session with an identical session variable, based on fixed values or on user originating input.

Evidence:

Check that session cookies have the directives Secure and httpOnly.
Check that the attribute Domain is set and well defined.
Check that the header Strict-Transport-Security is well configured like max-age=31536000; includeSubDomains; preload

Evidence:

Evaluate the application’s session management by assessing the handling of multiple active sessions for a single user account.

Evidence:

Last updated 4 months ago

4.6.1

Analyze and ensure that enough randomness exists to stop session forging attacks. (Burp Suite Sequencer)
What Expires times are used on persistent cookies, and are they reasonable? (Vulnerable if it is more than 8 hours)
Check the Cache-Control header.

Evidence:

4.6.2

Check that session cookies have the directives Secure and httpOnly.
Check the values for the domain attribute has secured values with respect of the application.
Check the values for the path attribute has secured values with respect of the application.
Check the expiration time in the Expire attribute.
Check the SameSite attribute has secured values with respect of the application.

Evidence:

4.6.3

Analyze the authentication mechanism and its flow.
Perform an unauthenticated request to the website checking if a session cookie is set. If so a tester can send a valid session identifier to a user (possibly using a social engineering trick), wait for them to authenticate, and subsequently verify that privileges have been assigned to this cookie.
Check if a new session cookie is set once the user is logged into the application.
Check if the session cookie can be predicted.

Evidence:

4.6.4

Check that session IDs are send over POST request instead of URL parameters.
If POST is used, can it be interchanged with GET?
Check that session IDs are send over encrypting transport by default.
What cache-control directives are applied to requests/responses passing Session IDs?
Check if the session cookie can be predicted.

Evidence:

4.6.5

Analyze the CSRF Token. If there is not, the web might be vulnerable to CSRF.
Can be used only once?
Is it binded to the session or any user can use the same token?
Is it binded to the function?
Check for the Same-Origin Policy, SameSite=Lax or SameSite=Strict can prevent the browser from sending cookies along with cross-site requests.
Determine whether it is possible to initiate requests on a user’s behalf that are not initiated by the user.
Create an HTML page to perform a certain function in the web, similar to that shown below: (You can use Burp Engagement Tools to create a CSRF website)
Host the HTML on a malicious or third-party site
Send the link for the page to the victim(s) and induce them to click it.

We’ll have to change the encoding type (enctype) to text/plain to ensure the payload is delivered as-is.

<html>
 <body>
  <script>history.pushState('', '', '/')</script>
   <form action='http://victimsite.com' method='POST' enctype='text/plain'>
     <input type='hidden' name='{"name":"hacked","password":"hacked","padding":"'value='something"}' />
     <input type='submit' value='Submit request' />
   </form>
 </body>
</html>

Evidence:

4.6.6

Check if the application has a logout functionality
Check session termination after a given amount of time without activity (session timeout).
Does the session ID gets invalidated or just simply removed from the browsers storage.
It is expected that the invocation of a log out function in a web application connected to a SSO system or in the SSO system itself causes global termination of all sessions. An authentication of the user should be required to gain access to the application after log out in the SSO system and connected application.

Evidence:

4.6.7

Check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. Try to perform the same action, with the same cookie, every X hours until it expires or up to a maximum of 8.
Understand whether the timeout is enforced by the client or by the server (or both).

Evidence:

4.6.8

This vulnerability occurs when an application uses the same session variable for more than one purpose. An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set in one context and then used in another.

An authentication bypass attack vector could be executed by accessing a publicly accessible entry point (e.g. a password recovery page) that populates the session with an identical session variable, based on fixed values or on user originating input.

Evidence:

4.6.9

Check that session cookies have the directives Secure and httpOnly.
Check that the attribute Domain is set and well defined.
Check that the header Strict-Transport-Security is well configured like max-age=31536000; includeSubDomains; preload