Introduction
Web apps need to ensure that your account is safe from hackers, and some address this by requiring periodic re-authentication. However, that’s not the best solution. Proper session management can help apps keep users safe without the need to constantly log back in.
In this article we will discuss what session management is, the types of session management, the elements of implementing session management, and testing session management on OWASP.
What is Session Management?
Session management is the process of identifying and managing sessions established by a system or application. Sessions are a way to store and organize temporary data on an application or website. The data in the session can be username, user id, password, user preferences, shopping cart, etc.
Session Management Types
Session management can take two forms: short-lived and long-lived.
- Short-lived sessions last only as long as the user remains in the app. Every time they exit the app, they have to re-authenticate to log back in.
- Long-lived sessions keep users logged into the app even if they log out. It stores the session ID on the user’s device, so they can reopen the app and start using it without needing to re-authenticate.
Elements of Session Management Implementation
Proper implementation of session management involves three functions: creating a session ID, storing a cookie or session token, and enforcing a session expiration date.
Creating Session ID
When a user first logs into a website or application, the server creates a unique session ID associated with the authenticated user. However, with each new request, the server still needs a way to identify whether the request came from the authenticated user without the need for re-authentication. This is where cookie or token come in.
Storing Cookie vs Token
When the server creates a unique session ID, it also creates a cookie that is stored in the user’s browser. The information contained in the cookie is sent along with each new request so that the server understands that the request came from the same authenticated user.
A token is a string that is used as a unique session identifier in web applications. Token are usually issued by the server and received by the client, such as a browser, after a successful authentication process.
Some differences between cookie and token:
- Storage: Cookie are stored in the client’s browser, while token are stored on the server.
- Size: Cookie have a smaller size limit than token.
- Security: Token are more secure than cookie because they cannot be read by the client and can only be received by the server that created them.
- Duration: The lifetime of cookie can be specified in the client’s browser, while token can be issued with a definable expiration time.
- Features: Token have some additional features such as digital signatures to ensure the integrity of the information, while cookie only store data.
Session Expiration Date
A session is a temporary state and ends under certain circumstances, such as the mobile app being closed, a period of inactivity, or a maximum session duration that cannot be exceeded. A long-lived session may expire if the user has not interacted with the app in days or weeks. The cookie or token that stores the session ID will automatically delete itself at the end of that period.
Session Management Testing
OWASP provides session management testing, In this article we will try to test session management with Burp Suit tool and follow the OWASP session management testing guideline, the web used in this test is OWASP Muttillidae II.
1. Testing for Session Management Schema
One of the core components of any web-based application is the mechanism by which it controls and maintains the state for a user interacting with it. To avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan. These mechanisms are known as Session Management.
Test Objectives:
- Gather session tokens, for the same user and for different users where possible.
- Analyze and ensure that enough randomness exists to stop session forging attacks.
- Modify cookies that are not signed and contain information that can be manipulated.
Example test:
When logging in using a different account there is no change in the value of the cookie, this is certainly dangerous because the session will be easily taken over.
Testing by changing the cookie value will be done in the session fixation test.
2. Testing for Cookies Attributes
Cookie attributes are additional features to cookies that provide additional information on how cookies should be treated or how cookies can be used by servers and browsers. Some examples of cookie attributes include:
- Secure: The secure attribute tells the browser to only send the cookie over an HTTPS connection, thus increasing the security of the communication.
- HttpOnly: The HttpOnly attribute makes the cookie inaccessible via JavaScript, which can help prevent cross-site scripting (XSS) attacks.
- SameSite: The SameSite attribute controls how cookies are delivered on cross-site requests. The value of this attribute can be “Strict”, “Lax”, or “None”.
- Expires or Max-Age: This attribute controls how long the cookie will remain in the browser. If the cookie has an Expires or Max-Age attribute, the browser will delete the cookie after the specified time.
- Domain and Path: The domain and path attributes control the domain and path where the cookie can be used by the server. Cookies will only be sent to servers with the same domain or path as the domain or path attribute.
- Value: The value attribute is the value of the data stored in the cookie. This value can be a string, number or any other value that can be stored in text format.
- Size: Specifies the size of the cookie in bytes.
- Last Accessed: This attribute indicates the date and time when the cookie was last accessed by the client.
By using this cookie attribute, the server can control how cookies are used by the browser and protect users from security attacks that may occur through cookies.
Test Objectives:
- Ensure that the proper security configuration is set for cookies.
Example test:
To view cookie attributes, you can enter the web developer tools in the browser then select storage.
In the example above the available cookie attributes is Name, Value, Domain, Path, Expires/Max-Age, Size, HTTPOnly, Secure, SameSite, Last Accessed. Explanation of each cookie attribute:
Name: PHPSESSID, pma_lang, showhints, uid, username. The following is an explanation of the name of the cookies:
- PHPSESSID: the name attribute of this cookie stores the name of the cookie used to store the PHP session ID.
- pma_lang: the name attribute of this cookie stores the name of the cookie used to s tore the language used in the phpMyAdmin application. This cookie is often used in web applications that use MySQL databases.
- showhints: the name attribute of this cookie stores the name of the cookie used to store hint display settings in the phpMyAdmin application.
- uid: the name attribute of this cookie stores the name of the cookie used to store the ID of the user currently logged in to a particular web application.
- username: the name attribute of this cookie stores the name of the cookie used to store the username of the user currently logged in to a particular web application.
Value: A string of characters that contains the value of the cookie. The following is an explanation of the value of cookies:
- PHPSESSID: otslq715dql6rm20d6ta8f27hb. This value is the session ID used to identify the user’s session on the server and maintain the user’s login status.
- Pma_lang: en. This value indicates that the user selected the English language preference in phpMyAdmin.
- Showhints: 1. This value indicates that the user chose to display hints in the cPanel application.
- Uid: 24. This value is a unique user ID to identify the currently logged in user.
- Username: test. This value is the username of the logged in user.
Domain: localhost
Path: “/”. The path:/ attribute of a cookie indicates that the cookie is available on all paths or directories in the same domain as the cookie.
Expires/Max-Age: session, Fri, 31 Mar 2023 03:42:46 GMT
- Session: it means that the cookie will remain valid as long as the session or browser session is active. In this case, the cookie will be deleted when the user closes the browser or logs out of the website that website that uses the cookie.
- Fri, 31 Mar 2023 03:42:46 GMT: it means that the cookie will be valid until the specified date and time.
Size: 35, 10, 5, 12.
HttpOnly: false, true.
- false: indicates that cookies can be accessed through JavaScript scripts on the same web page. In other words, cookies can be retrieved or modified by JavaScript scripts executed on the same page as the cookie.
- true: indicates that cookies can only be accessed via HTTP or HTTPS protocols and cannot be accessed via JavaScript scripts executed on the same web page.
It is generally recommended to set the HTTPOnly attribute on cookies to “true”, so that cookies can only be accessed via HTTP or HTTPS protocols and cannot be accessed via JavaScript scripts. This can help increase the security of web applications from potentially damaging attacks.
Secure: false, indicates that the cookie can be accessed or transmitted via the HTTP protocol (not secure).
SameSite: Strict, Lax, None.
- Strict: the browser will only send cookies on HTTP requests sent from the same page as the domain from which the cookie originated. In other words, cookies with a value of SameSite=Strict will not be sent on requests originating from outside the same domain. This value provides strong protection against session evasion attacks.
- Lax: the browser will send cookies on HTTP requests originating from outside the same domain if the request is a regular navigation such as clicking a link or filling out a form. Other requests such as resource requests like images will not carry cookies. This value provides moderate protection against session evasion attacks.
- None: the browser will send a cookie on all HTTP requests including requests coming from outside the same domain. This value allows cookies to be used on cross-site requests such as iframe pages or resource requests. However, the use of the SameSite=None value should be used with caution as it may open the door to CSRF or XSS attacks.
Last Accessed: Thu, 02 Mar 2023 17:03:58 GMT, which indicates that the cookie was last accessed on March 2, 2023 at 17:03:58 GMT (Greenwich Mean Time).
3. Testing for Session Fixation
Session fixation is a security attack on web applications where the attacker tries to direct the victim to use a session ID that has been predetermined by the attacker. This attack can occur when the web application uses vulnerable authentication mechanisms that can be manipulated.
Test objectives:
- Analyze the authentication mechanism and its flow.
- Force cookies and assess the impact.
Example test:
The hacker sends a login form with a predefined session ID, this can be seen in the URL for login
When the victim logs in with the URL sent by the hacker then the hacker can take over the session, for example below the hacker accesses the profile edit page from the victim
The front end view can be seen on the right side of the response
4. Testing for Exposed Session Variables
Exposed session variables are conditions when session variables can be accessed by unauthorized parties through various means, such as data interception or web application attacks. Session variables are data stored by the server for use during a user session within a web application.
Test objectives:
- Ensure that proper encryption is implemented.
- Review the caching configuration.
- Assess the channel and methods’ security.
Example test:
As in the WSTG-SESS-01 test above, it can be seen that during the authentication process, the session ID obtained by the user is still the same as before, a different session ID is only obtained after the web application is launched from the browser. In addition, the session ID is sent without an encrypted channel or http.
For caching configuration, there is no problem because Cache-Control: no-store, no-cache, must-revalidate which means :
- no-store: this indicates that the response should not be cached. Each request should fetch the response from the original server. By using this value, the information sent through the response will not be cached, and will be more difficult for cybercriminals to access.
- no-cache: this indicates that the response may be stored in the cache, but should not be used as a direct response to subsequent requests. Any request containing the “Cache-Control: no-cache” header should fetch a new response from the original server.
- must-revalidate: this indicates that any response stored in the cache must be validated before use. If the response is out of date, then the request must be sent back to the server to retrieve a new response.
These three values are often used together to ensure that sensitive or important information is not stored in the cache, thereby increasing the security of web applications.
For GET & POST vulnerability testing, there is a vulnerability where the login process that should use POST can be changed to GET, and in session fixation testing the session ID can be included in the URL.
5. Testing for Cross Site Request Forgery
Cross-Site Request Forgery (CSRF), also known as XSRF or “sea surf”, is a security attack that utilizes the automatic authentication of users in browsers to force them to perform unintentional actions on targeted websites.
Test objectives:
- Determine whether it is possible to initiate requests on a user’s behalf that are not initiated by the user.
Example test:
If using Burp Suite there are tools that can be used for CSRF testing, right-click on the request and select Engagement tools / Generate CSRF PoC.
Click Test in the browser then copy the URL, then the submit request page will appear, and when you click sumbit request then the page gives a 200 response this means there is a vulnerability in CSRF, if there is no vulnerability there will be a response such as Invalid Header in the browser or an error notification on the website page.
6. Testing for Logout Functionality
Logout functionality is a feature in web applications that allows users to log out of their account. This functionality ensures that once the user has finished using the application, the user’s information, such as login credentials or session variables, cannot be accessed by other users.
Test objectives:
- Assess the logout UI.
- Analyze the session timeout and if the session is properly killed after logout.
Example test:
After clicking the logout button, it turns out that the function of session time and session shutdown after logout does not work properly, this is evident when clicking the back button on the browser the authentication process is not requested again.
7. Testing Session Timeout
Session timeout is a time limit set for the duration of a user session on a web application. After a certain time limit, the session will be automatically terminated or closed by the system, and the user will be asked to log in again if they want to continue using the web application.
Test objectives:
- Validate that a hard session timeout exists.
Example test:
As in the cookie attribute test on WSTG-SESS-02 where Expires/Max-Age is “session”, it means that the cookie will remain valid as long as the session or browser session is active. In this case, the cookie will be deleted when the user closes the browsThe following is an explanation of each value in the SameSite cookie attribute:er or logs out of the website that website that uses the cookie.
8. Testing for Session Puzzling
Session puzzling is a cyber attack technique that aims to steal or access session information from users in web applications. This attack usually occurs when the attacker tries to confuse or manipulate the session ID or token assigned by the server to the user, so as to access session information and perform unauthorized actions on the user’s account.
Test objectives:
- Identify all session variables.
- Break the logical flow of session generation.
Example test:
Authentication Bypass via Session Puzzling.
If the hacker can guess the session ID as below without passing the authentication process the hacker can enter the victim’s profile edit page.
9. Testing for Session Hijacking
Session hijacking is a security attack on web applications that aims to steal or take over a user’s active session by stealing session information or tokens. In this attack, the attacker takes control of a session that actually belongs to a legitimate user and can perform unauthorized actions within the web application.
Test objectives:
- Identify vulnerable session cookies.
- Hijack vulnerable cookies and assess the risk level.
Example test:
Because the following HTTP requests do not use the HTTPS protocol to encrypt data traffic between the server and the client, it is easy for hackers to access or copy the session ID. In addition, the cookies used to store session IDs do not have the Secure and HttpOnly attributes. The Secure attribute ensures that cookies can only be accessed through HTTPS connections, while the HttpOnly attribute limits cookies to only be accessed by the server and cannot be manipulated by JavaScript in the browser. In the example below, a hacker can enter the edit profile page without authentication because they have the victim’s session ID.
Conclusion
Session management keeps users and accounts secure by providing secure cookies or tokens, setting appropriate protocols and timeouts, and implementing anomaly detection.
Session management is a fundamental part of running secure and trustworthy web applications. Keeping control of user sessions can help users avoid the hassle of constant re-authentication without putting them at risk.
