OWASP Web Session Management cheat Sheet Read notes

Https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_ID_Properties

Introduction to Sessions

HTTP is a stateless protocol, each pair of requests and responses and other web interaction is independent of each other, if you want to track the user's access state, you need to introduce a session mechanism to manage the user's access sequence.

Session management, which connects authentication and access control (also called authorization), may have unauthenticated sessions before authentication, and a session destruction mechanism after access control.

Once the authenticated session is established, the session ID is equivalent to the strongest authentication method, equivalent to the user name and password.

Disclosure, capture, prediction, and brute force will cause the session ID to be hijacked so that the attacker can impersonate the user to manipulate the Web.

Session ID Property

In order to maintain user authentication status and to track user operation status, the Web application provides a user session ID, when the session is created, the session ID is shared by the user and the application, and is sent by each HTTP request during the duration of the session, and the session ID is the Name=value name value pair. For the purpose of implementing a secure session ID, the session ID generation must meet the following properties.

session ID Name thumbprint

The session ID name cannot provide extreme descriptive or non-essential details about the purpose and meaning of this ID.

For example, the name of the session ID provided by some development framework, the technology and programming language, such as PHPSESSID (PHP), Jsessionid (Java ee), Cfid & Cftoken (ColdFusion), Asp.net_sessionid (ASP. NET),

It is recommended to modify these names to a more generic name, such as ID

Session ID Length

The session ID length must be long enough to prevent brute-force attacks, and an attacker can traverse all session IDs to verify the existence of legitimate IDs.

It is recommended that the session ID be at least 128bit,16 bytes long.

session ID Information Entropy

The session ID must be unpredictable, which is enough random to prevent guessing attacks. The attacker is able to predict and guess the legal session ID through statistical techniques. To achieve this, the pseudo-random generator must be used.

The session ID value must provide information entropy above 64bit, and if a good pseudo-random generation is used, this value is estimated to be half the length of the session ID.

Session ID Value

The session ID value must be meaningless to prevent an information disclosure attack. An attacker could decode the session ID and extract information about the user, session, and internal work of the Web App.

We recommend using the cryptographic hash function to create a password-type session ID, such as SHA.

Session Management Implementation

There are multiple mechanisms for implementing session state maintenance in the HTTP protocol, Cookies,url rewrite, get requests in parameters, and post requests implicitly form fields.

Cookies are the most popular.

Framework built-in session management implementation

It is recommended to use the industry-mature framework, Java EE, ASP. NET, PHP, as they are tested by security software, and the community's repair, is proven to be safe,

But the framework used to be a weakness, so it is recommended to use the latest version and fix well-known vulnerabilities.

Transport Layer Security

In order to prevent the session ID Exchange process, in the network traffic is stolen or leaked, it is necessary to use HTTPS for session interaction, not only in the authentication process, the user private information transfer process.

The secure attribute of the cookie should be used to ensure that cookie information is passed over an HTTPS connection.

Encrypted communication also prevents some form of fixed-session attacks (session fixation), which intercepts and operates sessions during session transfer, injecting the scheduled session ID into the user's Web browser.

The following best practices focus on protecting session IDs and helping to integrate HTTPS into your Web app:

1. Web apps should not support switching between HTTPS and HTTP access, because this switch will burst the session ID into the network data.

2. Web apps should not support HTTPS and HTTP access to different resources under the same domain name because unencrypted channels reveal the session ID.

3 Web applications should not be under the same domain name, support for public resource access and private resource access, it is recommended to use a different domain name access, public resource access using a domain name only support 80 ports, private resource access using another domain name only support 443 port.

Importantly, HTTPS does not prevent session ID predictions, brute force cracking, client tampering, and hardening.

However, capturing and leaking session IDs over network traffic is still the most prevalent means of attack today.

Cookies

The cookie-based session ID switch system provides multiple security features that can be used to protect the session ID Exchange process in the form of cookie attributes.

Secure Property

The Secure property instructs the browser to send cookie information only in HTTPS connections.

The session protection mechanism is necessary to prevent a man-in-the-middle attack and to ensure that an attacker cannot simply capture the session ID from the browser's network.

Simply enforce that the Web app can only use HTTPS connections, does not fundamentally protect the session ID is not compromised, the browser may be spoofed to send a request for an encrypted connection, thereby sending the session ID in clear text.

HttpOnly Property

The HttpOnly attribute specifies that this cookie cannot be accessed by a script, such as Document.cookie. This type of protection is necessary to prevent the session ID from being stolen by XSS attack methods.

domain and Path properties

The domain property specifies that the browser can only send cookies to hosts on this domain and all child domain, and if this property is not set, the original server is assumed to be the default.

The Path property specifies that the browser can only send cookies to this path and all sub-paths, and if this property is not set, the default is to request the resource and set the path of the cookie.

It is recommended that these two properties be set to a narrow and tightly constrained range, that the domain property should not be set (to ensure that the cookie belongs to the original server), and that the path property should be set as strictly as possible for the path of the Web app that uses it.

expire and Max-age properties

Session management mechanism, the use of cookies to achieve, divided into two, one is durable, the other is non-persistent,

If the expire or Max-age attribute is set, the cookie is stored on the browser side to disk until it is extended.

Typically, the session ID after authentication, which is generally non-persistent, has the advantage that if the browser instance is closed, the session ID is lost and the session is invalidated, which minimizes the time window where the hacker gets the session ID.

session ID life cyclesession ID generation and validation: admissibility and strict session management

There are two types of session management mechanisms, one of which is a kind of strictness of admissibility

A permissive session that can accept client-specified content as a session ID, strictly accepting only the session ID generated by the web App itself

Despite the strict management of modern times, programmers need to ensure that, in the case of features, the program does not allow the admissibility of the situation,

A web app should not accept a session ID that it has not produced, and when it receives such a session ID, it needs to provide a new session ID that it generates, and in this case, the application should be detected as suspicious activity and an alarm should be generated.

manage the session ID like any other user input

The session ID, like other user input, needs to be verified by the background, due to the management mechanism of the session, the session ID is obtained from the client's request, get post URL parameters or cookies, so the client's send needs to be verified.

If the server side does not validate the session ID, it processes the request, and the attacker exploits the Web vulnerability, for example, if the session ID is stored in the database, he attempts SQL injection.

Update session ID after permission level is modified

The session ID should be updated or generated and changed at the user session level.

The most common scenario is that when a user has never authenticated to a status switch to the authentication state, the session ID must be changed during the authentication process.

Other common scenarios, including password changes, change of permissions, change of User level (switch from normal user to administrator),

For the critical resources of the Web application, when the request arrives, it is necessary to invalidate the previous session ID and generate a new session ID to the client, which is the authorization management mechanism for the critical resource.

considerations when using multiple cookies

If a web app uses a cookie as a session ID switch, and multiple cookies are set to a given session, the Web app must validate all cookies and then allow access to the user's session.

A very common phenomenon is that when the user is not logged in, the session is not equipped with a session ID to the user, when the user logs on, assign a new user ID to the user, the relationship between the two cookies is determined, if you do not check two cookies, the attacker is likely to use A cookie that is not logged in accesses an authorized resource.

Session Extended

To reduce the attack time of an attacker, an attacker could send an attack or hijack a session, and the session time-out must be set for each session.

Insufficient session time-outs, increasing the level of other attacks based on a session attack, where an attacker can attack or hijack a session ID that is in effect.

The less session time period, the less time it takes for attackers to attack. But for the user experience, also need to consider the balance, not for security, so that users often encounter time-out phenomenon, keep landing.

For sessions with high-risk values, the general setting time-out is 2-5 minutes and the low-risk value session is set to 15 to half an hour.

When the session is extended, the application needs to actively destroy the session ID of the client and server segments, and the destruction actions in the background are more critical.

Automatic Session ExtendedIdle Timeout

No request time-out time is required to destroy all extended sessions to this time-out since the last page access.

This mechanism can limit the likelihood of an attacker guessing the correct session ID.

However, if the user hijacked the session, the idle timeout does not take effect and the session can be updated by the attacker, causing the session to take effect.

Absolute Timeout

Absolute timeout time, defines the maximum active time period of the session, the time, regardless of user time activity, need to destroy the current session, require users to re-provide authentication information.

This mechanism is able to limit the time that an attacker can attack and hijack a session, impersonating a user.

Renewal Timeout

The update time-out period, after which the session ID is automatically updated after this time-out, regardless of session activity and timeout during user sessions.

After the new session ID is generated, the old session ID is not immediately invalidated, waiting for the new ID to be requested for the first time, then the new ID becomes effective and the old ID expires.

This scenario reduces the time to live for a given session ID without affecting the lifetime of the user's session,

Reduce the time that an attacker hijacked a session.

Manual session expiration mechanism

Web apps should provide a mechanism for security-sensitive users to opt out of the session with active action.

Exit button

Web apps should provide visible, easy-to-access exit buttons on any resource page, allowing users to exit at any time.

Web content Caching

After the session is over, the client may still have resources sent back by the server and need to ensure that the cache type of these resources is not cached

At the same time, depending on the cache policy, some content needs to be cached, but make sure that the session ID must not be cached.

Recommended:

Cache-control:no-cache= "Set-cookie, Set-cookie2

additional client-side protection for session management mechanisms

The protection mechanism of the client can enhance security, although the protection of the front-end, usually JS checksum verification, is very limited, for experienced attackers can bypass, but for intruders, can increase its difficulty.

Initial Login Timeout

For the landing page, you also need to set the time-out period, if the time-out is reached, you need to refresh the landing page, re-get the new session ID

This can reduce the session attack, if the previous attacker, using the wrong user name and password login failed, remember the session ID, and then a legitimate user came to log in, and its login using the same session ID, so that illegal users will use the same session ID, phishing legitimate users to operate the page.

forcing the session to log out when the browser window is closed

Using JS can detect the closing event of the browser window, when the event occurs, can imitate the user exit action, actively destroy the current session,

Allow background session state to be destroyed with the foreground.

Close Browser Cross tab session

User Login in a tab, if the user wants to open another tab access, then use JS to make access to the status of not logged in.

This method does not apply to cookies, because cookies are common to different tabs.

Automatic Client Exit

Use JS code in all pages, once the session is extended, automatically jump to the landing page, so that the background session with the foreground disappears.

The advantage is that the user can realize that the foreground time-out means the background is also extended, is one, security is very.

At the same time, you can avoid users to fill out a large number of forms, and then click Submit, data loss users are not easy to use the problem.

Session Attack Detectionsession ID guessing and brute force detection

In order to guess and brute force to crack the session ID, it is bound to pass the same IP, will launch multiple requests, using a different session ID to try.

If too many sessions are found on the same IP, the IP attacker is alerted or locked.

Detecting session ID Exceptions

When a legitimate session occurs, an exception is detected through the Web program's internal logic to help protect against attacks, existing cookies are deleted, or modified

The session ID is reused on another user, such as using user-agent to aid detection.

record the session life cycle

Session creation, destruction, and execution of important actions, as well as session ID updates.

Concurrent Session Login

Concurrent login is a design strategy, if not supported, need to take a valid action, when the new session check, or implicitly destroy the previous session, or ask the user whether to destroy.

If supported, it is recommended to provide user-ready, multi-user simultaneous access to the checksum, detection and alerting capabilities.

Enables users to manually end sessions remotely, track account activity history, record IP user-agent time for multiple clients,

Session Management WAF

When the code for the Web app cannot be modified, introduce the Web application firewall

OWASP Web Session Management cheat sheet read notes