4.6 Session Management Testing

4.6.1 Testing for Session Management Schema

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 Testing for Cookies Attributes

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 Testing for Session Fixation

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 Testing for Exposed Session Variables

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 Testing for Cross Site Request Forgery

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 Testing for Logout Functionality

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 Testing Session Timeout

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 Testing for Session Puzzling

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 Testing for Session Hijacking

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:

4.6.10 Testing JSON Web Tokens

Evidence:

4.6.11 Testing for Concurrent Sessions

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

Evidence:

Last updated 1 year ago

hashtagSession Management Testingarrow-up-right

hashtag4.6.1 Testing for Session Management Schemaarrow-up-right

hashtag4.6.2 Testing for Cookies Attributesarrow-up-right

hashtag4.6.3 Testing for Session Fixationarrow-up-right

hashtag4.6.4 Testing for Exposed Session Variablesarrow-up-right

hashtag4.6.5 Testing for Cross Site Request Forgeryarrow-up-right

hashtag4.6.6 Testing for Logout Functionalityarrow-up-right

hashtag4.6.7 Testing Session Timeoutarrow-up-right

hashtag4.6.8 Testing for Session Puzzlingarrow-up-right

hashtag4.6.9 Testing for Session Hijackingarrow-up-right

hashtag4.6.10 Testing JSON Web Tokensarrow-up-right

hashtag4.6.11 Testing for Concurrent Sessionsarrow-up-right

Session Management Testing

4.6.1 Testing for Session Management Schema

4.6.2 Testing for Cookies Attributes

4.6.3 Testing for Session Fixation

4.6.4 Testing for Exposed Session Variables

4.6.5 Testing for Cross Site Request Forgery

4.6.6 Testing for Logout Functionality

4.6.7 Testing Session Timeout

4.6.8 Testing for Session Puzzling

4.6.9 Testing for Session Hijacking

4.6.10 Testing JSON Web Tokens

4.6.11 Testing for Concurrent Sessions