6.0 Session Management Testing

  • 6.1 Testing for Session Management Schema

    • Cookie Collection

      The first step required to manipulate the cookie is to understand how the application creates and manages cookies. For this task, testers have to try to answer the following questions:

      • How many cookies are used by the application?

        Surf the application. Note when cookies are created. Make a list of received cookies, the page that sets them (with the set-cookie directive), the domain for which they are valid, their value, and their characteristics.

      • Which parts of the application generate or modify the cookie?

        Surfing the application, find which cookies remain constant and which get modified. What events modify the cookie?

      • Which parts of the application require this cookie in order to be accessed and utilized?

        Find out which parts of the application need a cookie. Access a page, then try again without the cookie, or with a modified value of it. Try to map which cookies are used where.

      A spreadsheet mapping each cookie to the corresponding application parts and the related information can be a valuable output of this phase.

    • Session Analysis

      The session tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage.

      • Token Structure & Information Leakage

      The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data server-side.

      If the Session ID is clear-text, the structure and pertinent data may be immediately obvious such as 192.168.100.1:owaspuser:password:15:58.

      If part or the entire token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation. For example the string 192.168.100.1:owaspuser:password:15:58 is represented in Hex, Base64, and as an MD5 hash:

      • Hex: 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538

      • Base64: MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=

      • MD5: 01c2fc4f0a817afd8366689bd29dd40a

      Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.

      Hybrid tokens may include information such as IP address or User ID together with an encoded portion, such as owaspuser:192.168.100.1:a7656fafe94dae72b1e1487670148412.

      Having analyzed a single session token, the representative sample should be examined. A simple analysis of the tokens should immediately reveal any obvious patterns. For example, a 32 bit token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address. If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the token generation. See examples.

      If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, log in attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the session token.

      The following areas should be addressed during the single and multiple Session ID structure testing:

      • What parts of the Session ID are static?

      • What clear-text confidential information is stored in the Session ID? E.g. usernames/UID, IP addresses

      • What easily decoded confidential information is stored?

      • What information can be deduced from the structure of the Session ID?

      • What portions of the Session ID are static for the same log in conditions?

      • What obvious patterns are present in the Session ID as a whole, or individual portions?

    • Session ID Predictability and Randomness

      Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns. These analyses may be performed manually and with bespoke or OTS statistical or cryptanalytic tools to deduce any patterns in the Session ID content. Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g., the same username, password, and IP address.

      Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.

      Variable elements should be analyzed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo-random elements. Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.

      In analyzing Session ID sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.

      • Are the Session IDs provably random in nature? Can the resulting values be reproduced?

      • Do the same input conditions produce the same ID on a subsequent run?

      • Are the Session IDs provably resistant to statistical or cryptanalysis?

      • What elements of the Session IDs are time-linked?

      • What portions of the Session IDs are predictable?

      • Can the next ID be deduced, given full knowledge of the generation algorithm and previous IDs?

    • Cookie Reverse Engineering

      Now that the tester has enumerated the cookies and has a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies is the tester interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed at protecting the cookie from a different class of attacks.

      These characteristics are summarized below:

      1. Unpredictability: a cookie must contain some amount of hard-to-guess data. The harder it is to forge a valid cookie, the harder is to break into legitimate user’s session. If an attacker can guess the cookie used in an active session of a legitimate user, they will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values or cryptography can be used.

      2. Tamper resistance: a cookie must resist malicious attempts of modification. If the tester receives a cookie like IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value)

      3. Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from the disk or memory afterwards to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel).

      4. Secure flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.

      The approach here is to collect a sufficient number of instances of a cookie and start looking for patterns in their value. The exact meaning of “sufficient” can vary from a handful of samples, if the cookie generation method is very easy to break, to several thousands, if the tester needs to proceed with some mathematical analysis (e.g., chi-squares, attractors. See later for more information).

      It is important to pay particular attention to the workflow of the application, as the state of a session can have a heavy impact on collected cookies. A cookie collected before being authenticated can be very different from a cookie obtained after the authentication.

      Another aspect to keep into consideration is time. Always record the exact time when a cookie has been obtained, when there is the possibility that time plays a role in the value of the cookie (the server could use a timestamp as part of the cookie value). The time recorded could be the local time or the server’s tiemstamp included in the HTTP response (or both).

      When analyzing the collected values, the tester should try to figure out all variables that could have influenced the cookie value and try to vary them one at the time. Passing to the server modified versions of the same cookie can be very helpful in understanding how the application reads and processes the cookie.

      Examples of checks to be performed at this stage include:

      • What character set is used in the cookie? Has the cookie a numeric value? alphanumeric? hexadecimal? What happens if the tester inserts in a cookie characters that do not belong to the expected charset?

      • Is the cookie composed of different sub-parts carrying different pieces of information? How are the different parts separated? With which delimiters? Some parts of the cookie could have a higher variance, others might be constant, others could assume only a limited set of values. Breaking down the cookie to its base components is the first and fundamental step.

      An example of an easy-to-spot structured cookie is the following:

      ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q

      This example shows 5 different fields, carrying different types of data:

      • ID – hexadecimal

      • CR – small integer

      • TM and LM – large integer. (And curiously they hold the same value. Worth to see what happens modifying one of them)

      • S – alphanumeric

      Even when no delimiters are used, having enough samples can help understand the structure.

    • Brute Force Attacks

      Brute force attacks inevitably lead on from questions relating to predictability and randomness. The variance within the Session IDs must be considered together with application session duration and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.

      A long Session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.

      • How long would a brute-force attack on all possible Session IDs take?

      • Is the Session ID space large enough to prevent brute forcing? For example, is the length of the key sufficient when compared to the valid life-span?

      • Do delays between connection attempts with different Session IDs mitigate the risk of this attack?

  • 6.2 Testing for Cookies Attributes

    • Cookie Attributes

      • Secure Attribute

      • HttpOnly Attribute

      • Domain Attribute

      • Path Attribute

      • Expires Attribute

      • SameSite Attribute

        The [SameSite](<https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_cookies>) attribute is used to assert that a cookie ought not to be sent along with cross-site requests. This feature allows the server to mitigate the risk of cross-orgin information leakage. In some cases, it is used too as a risk reduction (or defense in depth mechanism) strategy to prevent cross-site request forgery attacks. This attribute can be configured in three different modes:

        • Strict

        • Lax

        • None

        Strict Value

        The Strict value is the most restrictive usage of SameSite, allowing the browser to send the cookie only to first-party context without top-level navigation. In other words, the data associated with the cookie will only be sent on requests matching the current site shown on the browser URL bar. The cookie will not be sent on requests generated by third-party websites. This value is especially recommended for actions performed at the same domain. However, it can have some limitations with some session management systems negatively affecting the user navigation experience. Since the browser would not send the cookie on any requests generated from a third-party domain or email, the user would be required to sign in again even if they already have an authenticated session.

        Lax Value

        The Lax value is less restrictive than Strict. The cookie will be sent if the URL equals the cookie’s domain (first-party) even if the link is coming from a third-party domain. This value is considered by most browsers the default behavior since it provides a better user experience than the Strict value. It doesn’t trigger for assets, such as images, where cookies might not be needed to access them.

        None Value

        The None value specifies that the browser will send the cookie on cross-site requests (the normal behavior before the implementation of SamseSite) only if the Secure attribute is also used, e.g. SameSite=None; Secure. It is a recommended value, instead of not specifying any SameSite value, as it forces the use of the [secure attribute](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/06-Session_Management_Testing/02-Testing_for_Cookies_Attributes#secure-attribute).

    • Cookie Prefixes

  • 6.3 Testing for Session Fixation

    • Analyze the authentication mechanism and its flow

      In this section we give an explanation of the testing strategy that will be shown in the next section.

      The first step is to make a request to the site to be tested (e.g. www.example.com). If the tester requests the following:

      GET / HTTP/1.1 Host: www.example.com

      They will obtain the following response:

      HTTP/1.1 200 OK Date: Wed, 14 Aug 2008 08:45:11 GMT Server: IBM_HTTP_Server Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure Cache-Control: no-cache="set-cookie,set-cookie2" Expires: Thu, 01 Dec 1994 16:00:00 GMT Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html;charset=Cp1254 Content-Language: en-US

      The application sets a new session identifier, JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1, for the client.

      Next, if the tester successfully authenticates to the application with the following POST to https://www.example.com/authentication.php:

      `POST /authentication.php HTTP/1.1 Host: www.example.com [...] Referer: http://www.example.com Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 Content-Type: application/x-www-form-urlencoded Content-length: 57

      Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in`

      The tester observes the following response from the server:

      HTTP/1.1 200 OK Date: Thu, 14 Aug 2008 14:52:58 GMT Server: Apache/2.2.2 (Fedora) X-Powered-By: PHP/5.1.6 Content-language: en Cache-Control: private, must-revalidate, max-age=0 X-Content-Encoding: gzip Content-length: 4090 Connection: close Content-Type: text/html; charset=UTF-8 ... HTML data ...

      As no new cookie has been issued upon a successful authentication, the tester knows that it is possible to perform session hijacking unless the integrity of the session cookie is ensured.

      The 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.

    • Test with Forced Cookies

      This testing strategy is targeted at network attackers, hence it only needs to be applied to sites without full HSTS adoption (sites with full HSTS adoption are secure, since all their cookies have integrity). We assume to have two testing accounts on the website under test, one to act as the victim and one to act as the attacker. We simulate a scenario where the attacker forces in the victim’s browser all the cookies which are not freshly issued after login and do not have integrity. After the victim’s login, the attacker presents the forced cookies to the website to access the victim’s account: if they are enough to act on the victim’s behalf, session fixation is possible.

      Here are the steps for executing this test:

      1. Reach the login page of the website.

      2. Save a snapshot of the cookie jar before logging in, excluding cookies which contain the __Host- or __Secure- prefix in their name.

      3. Login to the website as the victim and reach any page offering a secure function requiring authentication.

      4. Set the cookie jar to the snapshot taken at step 2.

      5. Trigger the secure function identified at step 3.

      6. Observe whether the operation at step 5 has been performed successfully. If so, the attack was successful.

      7. Clear the cookie jar, login as the attacker and reach the page at step 3.

      8. Write in the cookie jar, one by one, the cookies saved at step 2.

      9. Trigger again the secure function identified at step 3.

      10. Clear the cookie jar and login again as the victim.

      11. Observe whether the operation at step 9 has been performed successfully in the victim’s account. If so, the attack was successful; otherwise, the site is secure against session fixation.

      We recommend using two different machines or browsers for the victim and the attacker. This allows you to decrease the number of false positives if the web application does fingerprinting to verify access enabled from a given cookie. A shorter but less precise variant of the testing strategy only requires one testing account. It follows the same steps, but it halts at step 6.

  • 6.4 Testing for Exposed Session Variables

    • Testing for Encryption & Reuse of Session Tokens Vulnerabilities

      Protection from eavesdropping is often provided by SSL encryption, but may incorporate other tunneling or encryption. It should be noted that encryption or cryptographic hashing of the Session ID should be considered separately from transport encryption, as it is the Session ID itself being protected, not the data that may be represented by it.

      If the Session ID could be presented by an attacker to the application to gain access, then it must be protected in transit to mitigate that risk. It should therefore be ensured that encryption is both the default and enforced for any request or response where the Session ID is passed, regardless of the mechanism used (e.g., a hidden form field). Simple checks such as replacing https:// with http:// during interaction with the application should be performed, together with modification of form posts to determine if adequate segregation between the secure and non-secure sites is implemented.

      Note that if there is also an element to the site where the user is tracked with Session IDs but security is not present (e.g., noting which public documents a registered user downloads) it is essential that a different Session ID is used. The Session ID should therefore be monitored as the client switches from the secure to non-secure elements to ensure a different one is used.

      Every time the authentication is successful, the user should expect to receive:A different session tokenA token sent via encrypted channel every time they make an HTTP Request

    • Testing for Proxies & Caching Vulnerabilities

      Proxies must also be considered when reviewing application security. In many cases, clients will access the application through corporate, ISP, or other proxies or protocol aware gateways (e.g., Firewalls). The HTTP protocol provides directives to control the behavior of downstream proxies, and the correct implementation of these directives should also be assessed.

      In general, the Session ID should never be sent over unencrypted transport and should never be cached. The application should be examined to ensure that encrypted communications are both the default and enforced for any transfer of Session IDs. Furthermore, whenever the Session ID is passed, directives should be in place to prevent its caching by intermediate and even local caches.

      The application should also be configured to secure data in caches over both HTTP/1.0 and HTTP/1.1 – RFC 2616 discusses the appropriate controls with reference to HTTP. HTTP/1.1 provides a number of cache control mechanisms. Cache-Control: no-cache indicates that a proxy must not re-use any data. Whilst Cache-Control: Private appears to be a suitable directive, this still allows a non-shared proxy to cache data. In the case of web-cafes or other shared systems, this presents a clear risk. Even with single-user workstations the cached Session ID may be exposed through a compromise of the file-system or where network stores are used. HTTP/1.0 caches do not recognise the Cache-Control: no-cache directive.

      The Expires: 0 and Cache-Control: max-age=0 directives should be used to further ensure caches do not expose the data. Each request/response passing Session ID data should be examined to ensure appropriate cache directives are in use.

    • Testing for GET & POST Vulnerabilities

      In general, GET requests should not be used, as the Session ID may be exposed in Proxy or Firewall logs. They are also far more easily manipulated than other types of transport, although it should be noted that almost any mechanism can be manipulated by the client with the right tools. Furthermore, Cross-site Scripting (XSS) attacks are most easily exploited by sending a specially constructed link to the victim. This is far less likely if data is sent from the client as POSTs.

      All server-side code receiving data from POST requests should be tested to ensure it does not accept the data if sent as a GET. For example, consider the following POST request (http://owaspapp.com/login.asp) generated by a log in page.

      `POST /login.asp HTTP/1.1 Host: owaspapp.com [...] Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG Content-Length: 51

      Login=Username&password=Password&SessionID=12345678`

      If login.asp is badly implemented, it may be possible to log in using the following URL: http://owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678

      Potentially insecure server-side scripts may be identified by checking each POST in this way.

    • Testing for Transport Vulnerabilities

      All interaction between the Client and Application should be tested at least against the following criteria.

      • How are Session IDs transferred? e.g., GET, POST, Form Field (including hidden fields)

      • Are Session IDs always sent over encrypted transport by default?

      • Is it possible to manipulate the application to send Session IDs unencrypted? e.g., by changing HTTP to HTTPS?

      • What cache-control directives are applied to requests/responses passing Session IDs?

      • Are these directives always present? If not, where are the exceptions?

      • Are GET requests incorporating the Session ID used?

      • If POST is used, can it be interchanged with GET?

  • 6.5 Testing for Cross Site Request Forgery

    Audit the application to ascertain if its session management is vulnerable. If session management relies only on client-side values (information available to the browser), then the application is vulnerable. “Client-side values” refers to cookies and HTTP authentication credentials (Basic Authentication and other forms of HTTP authentication; not form-based authentication, which is an application-level authentication).

    Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be automated via JavaScript and are vulnerable as well; therefore, the use of POST alone is not enough to correct the occurrence of CSRF vulnerabilities.

    In case of POST, the following sample can be used.

    1. Create an HTML page similar to that shown below

    2. Host the HTML on a malicious or third-party site

    3. Send the link for the page to the victim(s) and induce them to click it.

    `<html> <body onload='document.CSRF.submit()'>

    <form action='http://targetWebsite/Authenticate.jsp' method='POST' name='CSRF'> <input type='hidden' name='name' value='Hacked'> <input type='hidden' name='password' value='Hacked'> </form>

    </body> </html>`

    In case of web applications in which developers are utilizing JSON for browser to server communication, a problem may arise with the fact that there are no query parameters with the JSON format, which are a must with self-submitting forms. To bypass this case, we can use a self-submitting form with JSON payloads including hidden input to exploit CSRF. We’ll have to change the encoding type (enctype) to text/plain to ensure the payload is delivered as-is. The exploit code will look like the following:

    <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>

    The POST request will be as follow:

    `POST / HTTP/1.1 Host: victimsite.com Content-Type: text/plain

    {"name":"hacked","password":"hacked","padding":"=something"}`

    When this data is sent as a POST request, the server will happily accept the name and password fields and ignore the one with the name padding as it does not need it.

  • 6.6 Testing for Logout Functionality

    • Testing for Log Out User Interface

      Verify the appearance and visibility of the log out functionality in the user interface. For this purpose, view each page from the perspective of a user who has the intention to log out from the web application.

      There are some properties which indicate a good log out user interface:A log out button is present on all pages of the web application.The log out button should be identified quickly by a user who wants to log out from the web application.After loading a page the log out button should be visible without scrolling.Ideally the log out button is placed in an area of the page that is fixed in the view port of the browser and not affected by scrolling of the content.

    • Testing for Server-Side Session Termination

      First, store the values of cookies that are used to identify a session. Invoke the log out function and observe the behavior of the application, especially regarding session cookies. Try to navigate to a page that is only visible in an authenticated session, e.g. by usage of the back button of the browser. If a cached version of the page is displayed, use the reload button to refresh the page from the server. If the log out function causes session cookies to be set to a new value, restore the old value of the session cookies and reload a page from the authenticated area of the application. If these test don’t show any vulnerabilities on a particular page, try at least some further pages of the application that are considered as security-critical, to ensure that session termination is recognized properly by these areas of the application.

      No data that should be visible only by authenticated users should be visible on the examined pages while performing the tests. Ideally the application redirects to a public area or a log in form while accessing authenticated areas after termination of the session. It should be not necessary for the security of the application, but setting session cookies to new values after log out is generally considered as good practice.

    • Testing for Session Timeout

      Try to determine a session timeout by performing requests to a page in the authenticated area of the web application with increasing delays. If the log out behavior appears, the used delay matches approximately the session timeout value.

      The same results as for server-side session termination testing described before are excepted by a log out caused by an inactivity timeout.The proper value for the session timeout depends on the purpose of the application and should be a balance of security and usability. In a banking applications it makes no sense to keep an inactive session more than 15 minutes. On the other side a short timeout in a wiki or forum could annoy users which are typing lengthy articles with unnecessary log in requests. There timeouts of an hour and more can be acceptable.

    • Testing for Session Termination in Single Sign-On Environments (Single Sign-Off)

      Perform a log out in the tested application. Verify if there is a central portal or application directory which allows the user to log back in to the application without authentication. Test if the application requests the user to authenticate, if the URL of an entry point to the application is requested. While logged in in the tested application, perform a log out in the SSO system. Then try to access an authenticated area of the tested application.

      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.

  • 6.7 Testing Session Timeout

    • Black-Box Testing

      The same approach seen in the Testing for logout functionality section can be applied when measuring the timeout log out. The testing methodology is very similar. First, testers have to check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. As in the log out function, after the timeout has passed, all session tokens should be destroyed or be unusable.

      Then, if the timeout is configured, testers need to understand whether the timeout is enforced by the client or by the server (or both). If the session cookie is non-persistent (or, more in general, the session cookie does not store any data about the time), testers can assume that the timeout is enforced by the server. If the session cookie contains some time related data (e.g., log in time, or last access time, or expiration date for a persistent cookie), then it’s possible that the client is involved in the timeout enforcing. In this case, testers could try to modify the cookie (if it’s not cryptographically protected) and see what happens to the session. For instance, testers can set the cookie expiration date far in the future and see whether the session can be prolonged.

      As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.

    • Gray-Box Testing

      The tester needs to check that:

      • The log out function effectively destroys all session token, or at least renders them unusable,

      • The server performs proper checks on the session state, disallowing an attacker to replay previously destroyed session identifiers

      • A timeout is enforced and it is properly enforced by the server. If the server uses an expiration time that is read from a session token that is sent by the client (but this is not advisable), then the token must be cryptographically protected from tampering.

      Note that the most important thing is for the application to invalidate the session on the server-side. Generally this means that the code must invoke the appropriate methods, e.g. HttpSession.invalidate() in Java and Session.abandon() in .NET. Clearing the cookies from the browser is advisable, but is not strictly necessary, since if the session is properly invalidated on the server, having the cookie in the browser will not help an attacker.

  • 6.8 Testing for Session Puzzling

    This vulnerability can be detected and exploited by enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points and then examining exit points. In case of black-box testing this procedure is difficult and requires some luck since every different sequence could lead to a different result.

    Examples :

    A very simple example could be the password reset functionality that, in the entry point, could request the user to provide some identifying information such as the username or the email address. This page might then populate the session with these identifying values, which are received directly from the client-side, or obtained from queries or calculations based on the received input. At this point there may be some pages in the application that show private data based on this session object. In this manner the attacker could bypass the authentication process.

  • 6.9 Testing for Session Hijacking

    1. Login to the website as the victim and reach any page offering a secure function requiring authentication.

    2. Delete from the cookie jar all the cookies which satisfy any of the following conditions.

      • in case there is no HSTS adoption: the Secure attribute is set.

      • in case there is partial HSTS adoption: the Secure attribute is set or the Domain attribute is not set.

    3. Save a snapshot of the cookie jar.

    4. Trigger the secure function identified at step 1.

    5. Observe whether the operation at step 4 has been performed successfully. If so, the attack was successful.

    6. Clear the cookie jar, login as the attacker and reach the page at step 1.

    7. Write in the cookie jar, one by one, the cookies saved at step 3.

    8. Trigger again the secure function identified at step 1.

    9. Clear the cookie jar and login again as the victim.

    10. Observe whether the operation at step 8 has been performed successfully in the victim’s account. If so, the attack was successful; otherwise, the site is secure against session hijacking.

  • https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/10-Testing_JSON_Web_Tokens

Previous5.0 Authorization TestingNext7.0 Input Validation Testing

Last updated