Skip to content

Session Management Cheat Sheet / 会话管理速查表

Introduction / 介绍

Web Authentication, Session Management, and Access Control:

Web身份验证、会话管理和访问控制:

A web session is a sequence of network HTTP request and response transactions associated with the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web会话是与同一用户关联的一系列网络HTTP请求和响应事务。现代和复杂的Web应用程序需要在多个请求的持续时间内保留有关每个用户的信息或状态。因此，会话提供了建立变量的能力，例如访问权限和本地化设置，这些变量将在会话期间应用于用户与Web应用程序的每一次交互。

Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.

Web应用程序可以在第一个用户请求之后创建会话来跟踪匿名用户。例如，维护用户语言偏好。此外，一旦用户进行身份验证，Web应用程序将利用会话。这确保了在后续请求中识别用户的能力，以及能够应用安全访问控制、授权访问用户私有数据以及提高应用程序的可用性。因此，当前的Web应用程序可以在身份验证前后提供会话功能。

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet.

一旦建立了已验证的会话，会话ID（或令牌）临时等同于应用程序使用的最强身份验证方法，例如用户名和密码、密码短语、一次性密码（OTP）、基于客户端的数字证书、智能卡或生物识别（如指纹或眼视网膜）。参见OWASP 身份验证速查表。

HTTP is a stateless protocol (RFC2616 section 5), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:

HTTP是一种无状态协议(RFC2616第5节)，其中每个请求和响应对与其他Web交互独立。因此，为了引入会话的概念，需要实现会话管理功能，这些功能通常链接到Web应用程序中常见的身份验证和访问控制（或授权）模块：

SessionDiagram

会话图

The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer's hands (as web development frameworks do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

会话ID或令牌将用户身份验证凭据（以用户会话的形式）绑定到用户的HTTP流量和Web应用程序实施的适当访问控制。现代Web应用程序中这三个组件（身份验证、会话管理和访问控制）的复杂性，加上其实施和绑定位于Web开发者的手中（因为Web开发框架不提供这些模块之间的严格关系），使得安全会话管理模块的实现非常具有挑战性。

The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker's goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker's goal is to impersonate (or get access as) any valid or legitimate user in the web application.

会话ID的泄露、捕获、预测、暴力破解或固定将导致会话劫持（或侧劫持）攻击，攻击者能够完全模仿Web应用程序中的受害者用户。攻击者可以执行两种类型的会话劫持攻击，针对性强或通用。在针对性攻击中，攻击者的目标是模仿特定的（或受保护的）Web应用程序受害者用户。对于通用攻击，攻击者的目标是模仿（或获取）Web应用程序中的任何有效或合法用户。

Session ID Properties / 会话ID属性

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a name=value pair.

为了保持认证状态并跟踪用户在Web应用程序中的进度，应用程序在会话创建时为用户提供一个会话标识符（会话ID或令牌），该标识符在整个会话期间由用户和Web应用程序共享和交换（它会在每个HTTP请求中发送）。会话ID是一个name=value对。

With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties.

为了实现安全的会话ID，标识符（ID或令牌）的生成必须满足以下属性。

Session ID Name Fingerprinting / 会话ID名称指纹识别

The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

会话ID使用的名称不应过于描述性，也不应提供关于ID目的和含义的不必要细节。

The session ID names used by the most common web application development frameworks can be easily fingerprinted, such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

最常用的Web应用程序开发框架中使用的会话ID名称容易被指纹识别，例如PHPSESSID（PHP）、JSESSIONID（J2EE）、CFID & CFTOKEN（ColdFusion）、ASP.NET_SessionId（ASP .NET）等。因此，会话ID名称可能会泄露Web应用程序使用的技术和编程语言。

It is recommended to change the default session ID name of the web development framework to a generic name, such as id.

建议将Web开发框架的默认会话ID名称更改为通用名称，例如id。

Session ID Entropy / 会话ID熵

Session identifiers must have at least 64 bits of entropy to prevent brute-force session guessing attacks. Entropy refers to the amount of randomness or unpredictability in a value. Each “bit” of entropy doubles the number of possible outcomes, meaning a session ID with 64 bits of entropy can have 2^64 possible values.

会话标识符必须至少具有 64位 的熵，以防止暴力破解会话猜测攻击。熵是指一个值中的随机性或不可预测性的量。每个熵的“位”将可能的结果数量翻倍，这意味着具有64位熵的会话ID可以有 2^64 种可能值。

A strong CSPRNG (Cryptographically Secure Pseudorandom Number Generator) must be used to generate session IDs. This ensures the generated values are evenly distributed among all possible values. Otherwise, attackers may be able to use statistical analysis techniques to identify patterns in how the session IDs are created, effectively reducing the entropy and allowing the attacker to guess or predict valid session IDs more easily.

必须使用强大的 CSPRNG（密码学安全伪随机数生成器）来生成会话ID。这确保生成的值在所有可能值中均匀分布。否则，攻击者可能能够使用统计分析技术来识别会话ID创建中的模式，从而有效降低熵，使攻击者更容易猜测或预测有效的会话ID。

NOTE:

注意：

  • The expected time for an attacker to brute-force a valid session ID depends on factors such as the number of bits of entropy, the number of active sessions, session expiration times, and the attacker's guessing rate.
    中文：攻击者暴力破解有效会话ID的预期时间取决于熵的位数、活动会话的数量、会话过期时间以及攻击者的猜测速率。
  • If a web application generates session IDs with 64 bits of entropy, an attacker can expect to spend approximately 585 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the application.
    中文：如果一个Web应用程序使用64位熵生成会话ID，攻击者预计需要花费大约585年才能成功猜测一个有效的会话ID，假设攻击者每秒可以尝试10,000次猜测，并且应用程序中有100,000个有效的并发会话。
  • Further analysis of the expected time for an attacker to brute-force session identifiers is available here.
    中文：有关攻击者破解会话标识符所需时间的进一步分析，请参阅此处。

Session ID Length / 会话ID长度

As mentioned in the previous Session ID Entropy section, a primary security requirement for session IDs is that they contain at least 64 bits of entropy to prevent brute-force guessing attacks. Although session ID length matters, it's the entropy that ensures security. The session ID must be long enough to encode sufficient entropy, preventing brute force attacks where an attacker guesses valid session IDs.

如前文所述的 会话ID熵 部分，会话ID的主要安全要求是它们至少包含 64位 的熵，以防止暴力猜测攻击。尽管会话ID长度很重要，但确保安全的是熵。会话ID必须足够长，以编码足够的熵，防止攻击者猜测有效的会话ID。

Different encoding methods can result in different lengths for the same amount of entropy. Session IDs are often represented using hexadecimal encoding. When using hexadecimal encoding, a session ID must be at least 16 hexadecimal characters long to achieve the required 64 bits of entropy. When using different encodings (e.g. Base64 or Microsoft's encoding for ASP.NET session IDs) a different number of characters may be required to represent the minimum 64 bits of entropy.

不同的编码方法会导致相同熵量的不同长度。会话ID通常使用十六进制编码表示。当使用十六进制编码时，会话ID必须至少有16个十六进制字符长，才能达到所需的64位熵。当使用不同的编码（例如Base64或Microsoft为ASP.NET会话ID提供的编码）时，可能需要不同数量的字符来表示最小的64位熵。

It’s important to note that if any part of the session ID is fixed or predictable, the effective entropy is reduced, and the length may need to be increased to compensate. For example, if half of a 16-character hexadecimal session ID is fixed, only the remaining 8 characters are random, providing just 32 bits of entropy — which is insufficient for strong security. To maintain security, ensure that the entire session ID is randomly generated and unpredictable, or increase the overall length if parts of the ID are not random.

需要注意的是，如果会话ID的任何部分是固定的或可预测的，有效熵会减少，可能需要增加长度来补偿。例如，如果一个16位十六进制会话ID的一半是固定的，那么只剩下8个字符是随机的，只提供了32位的熵——这对于强大的安全性来说是不够的。为了保持安全性，确保整个会话ID是随机生成且不可预测的，或者如果ID的部分不是随机的，则增加整体长度。

NOTE:

注意：

  • More information about the relationship between Session ID Length and Session ID Entropy is available here.
    中文：关于会话ID长度与会话ID熵之间关系的更多信息，请参阅此处。

Session ID Content (or Value) / 会话ID内容（或值）

The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

会话ID的内容（或值）必须没有意义，以防止信息泄露攻击，攻击者能够解码ID的内容并提取用户、会话或Web应用的内部工作细节。

The session ID must simply be an identifier on the client side, and its value must never include sensitive information or Personally Identifiable Information (PII). To read more about PII, refer to Wikipedia or this post.

会话ID必须在客户端简单地作为一个标识符，其值不得包含敏感信息或个人信息（PII）。要了解更多关于PII的信息，请参阅Wikipedia或这篇文章。

The meaning and business or application logic associated with the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository.

与会话ID相关的意义以及业务或应用逻辑必须存储在服务器端，具体来说，在会话对象或会话管理数据库或存储库中。

The stored information can include the client IP address, User-Agent, email, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.

存储的信息可以包括客户端IP地址、User-Agent、电子邮件、用户名、用户ID、角色、权限级别、访问权限、语言偏好、账户ID、当前状态、最后登录、会话超时以及其他内部会话细节。如果会话对象和属性包含敏感信息，如信用卡号码，则必须对会话管理存储库进行适当的加密和保护。

It is recommended to use the session ID created by your language or framework. If you need to create your own sessionID, use a cryptographically secure pseudorandom number generator (CSPRNG) with a size of at least 128 bits and ensure that each sessionID is unique.

建议使用您语言或框架创建的会话ID。如果您需要创建自己的sessionID，请使用至少128位的加密安全伪随机数生成器（CSPRNG），并确保每个sessionID都是唯一的。

Session Management Implementation / 会话管理实现

The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers.

会话管理实现定义了用户与Web应用程序之间用于共享和持续交换会话ID的交换机制。HTTP中提供了多种机制来在Web应用程序中维护会话状态，例如cookies（标准HTTP头）、URL参数（URL重写 - RFC2396）、GET请求中的URL参数、POST请求中的body参数，如隐藏表单字段（HTML表单）或专有HTTP头。

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

首选的会话ID交换机制应允许定义高级令牌属性，例如令牌过期日期和时间，或细粒度的使用约束。这就是为什么cookies（RFCs 2109 & 2965 & 6265）成为最广泛使用的会话ID交换机制之一，提供了其他方法中不可用的高级功能。

The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks.

使用特定的会话ID交换机制，如ID包含在URL中，可能会泄露会话ID（在Web链接和日志、Web浏览器历史和书签、Referer头或搜索引擎中），以及方便其他攻击，如ID操纵或会话固定攻击。

Built-in Session Management Implementations / 内置会话管理实现

Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.

Web开发框架，如J2EE、ASP .NET、PHP等，提供自己的会话管理特性和相关实现。建议使用这些内置框架，而不是从头开始构建一个自定义框架，因为它们在全球多个Web环境中被使用，并且经过Web应用程序安全和开发社区的长期测试。

However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.

然而，请注意，这些框架在过去也暴露了漏洞和弱点，因此始终建议使用最新版本，该版本可能修复了所有已知的漏洞，并按照本文件中描述的建议审查和更改默认配置，以增强其安全性。

The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.

会话管理机制用于临时保存会话ID的存储能力或存储库必须安全，保护会话ID免受本地或远程意外泄露或未经授权访问。

Server-Side Session Token Storage / 服务器端会话令牌存储

Storing random session tokens verbatim can be acceptable in a tightly controlled session store, but anyone who can read it can reuse unexpired tokens. High entropy protects against guessing; it does not protect exposed tokens. If read-only disclosure of the store is in your threat model, store a one-way verifier instead. RFC 6819 recommends token hashes for the corresponding OAuth access-token database threat.

直接存储随机会话令牌在严格控制的环境中是可以接受的，但任何可以读取它的人都可以重复使用未过期的令牌。高熵可以防止猜测；但它不能保护暴露的令牌。如果存储的只读披露在你的威胁模型中，请存储单向验证器。RFC 6819建议令牌哈希以应对相应的OAuth访问令牌数据库威胁。

One approach is an identifier and secret verifier split. The cookie carries both values; the server stores the public lookup identifier and the full SHA-256 hash of the verifier. On every request, look up the session by identifier, hash the supplied verifier, and compare it with the stored hash using a constant-time comparison. Never accept the identifier alone as proof of authentication. Use a consistent verifier representation when creating and validating the session. A fast hash is sufficient for these random verifiers; password hashing algorithms are unnecessary.

一种方法是标识符和秘密验证器分离。cookie携带这两个值；服务器存储公共查找标识符和验证器的完整SHA-256哈希。在每次请求时，通过标识符查找会话，对提供的验证器进行哈希处理，并使用恒定时间比较将其与存储的哈希进行比较。永远不要单独接受标识符作为身份验证的证明。在创建和验证会话时使用一致的验证器表示形式。对于这些随机验证器，快速哈希就足够了；密码哈希算法是不必要的。

Generate the token, or the secret verifier in the split design, using a CSPRNG with at least 128 bits of entropy; prefer 160 bits or more, following OAuth's guidance for generated credentials. Generate the verifier independently of the identifier; the public identifier does not count toward the verifier's entropy.

使用至少128位熵的CSPRNG生成令牌，或分离设计中的秘密验证器；根据OAuth生成凭证的指南，优先使用160位或更多。独立于标识符生成验证器；公共标识符不计入验证器的熵。

One-way storage protects against read-only disclosure of session records and backups that contain only verifier hashes. It does not protect against stolen cookies, modification of session records, or compromise of the application. Do not persist the raw verifier alongside its hash.

单向存储可以防止只读披露会话记录和仅包含验证器哈希的备份。它不能防止被盗cookie、会话记录的修改或应用的泄露。不要将原始验证器与其哈希一起持久化。

In either design, restrict access to the session store and encrypt backups and replicas at rest. Follow the session logging protections and session renewal guidance.

在任一设计中，限制对会话存储的访问，并加密静态备份和副本。遵循会话日志保护和会话更新指南。

Used vs. Accepted Session ID Exchange Mechanisms / 已使用与已接受会话ID交换机制

A web application should make use of cookies for session ID exchange management. If a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application should avoid accepting it as part of a defensive strategy to stop session fixation.

Web应用应使用cookie进行会话ID交换管理。如果用户通过不同的交换机制提交会话ID，例如URL参数，Web应用应避免接受它作为防御策略的一部分，以阻止会话固定。

NOTE:

注意：

  • Even if a web application makes use of cookies as its default session ID exchange mechanism, it might accept other exchange mechanisms too.
    中文：即使Web应用使用cookie作为其默认的会话ID交换机制，它也可能接受其他交换机制。
  • It is therefore required to confirm via thorough testing all the different mechanisms currently accepted by the web application when processing and managing session IDs, and limit the accepted session ID tracking mechanisms to just cookies.
    中文：因此，需要通过彻底测试来确认当前网络应用程序在处理和管理会话ID时接受的所有不同机制，并将接受的会话ID跟踪机制仅限于cookie。
  • In the past, some web applications used URL parameters, or even switched from cookies to URL parameters (via automatic URL rewriting), if certain conditions are met (for example, the identification of web clients without support for cookies or not accepting cookies due to user privacy concerns).
    中文：在过去，一些网络应用程序使用URL参数，甚至在满足某些条件（例如，识别不支持cookie或因用户隐私问题不接受cookie的Web客户端）时，从cookie切换到URL参数（通过自动URL重写）。

Transport Layer Security / 传输层安全（TLS）

In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is essential to use an encrypted HTTPS (TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged. This may be mitigated by HTTP Strict Transport Security (HSTS) for a client that supports it.

为了保护会话ID在网络流量中的主动监听和被动泄露，必须在整个Web会话中使用加密的HTTPS（TLS）连接，而不仅仅是用于交换用户凭据的认证过程。对于支持它的客户端，可以通过HTTP严格传输安全（HSTS）来减轻这种影响。

Additionally, the Secure cookie attribute must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victim's web browser.

此外，必须使用Secure cookie属性来确保会话ID仅通过加密通道交换。使用加密通信通道还可以保护会话免受一些会话固定攻击，在这些攻击中，攻击者能够拦截和操纵Web流量，在受害者的Web浏览器中注入（或固定）会话ID。

The following set of best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:

以下最佳实践集合专注于保护会话ID（特别是当使用cookie时）并帮助在Web应用程序中集成HTTPS：

  • Do not switch a given session from HTTP to HTTPS, or vice-versa, as this will disclose the session ID in the clear through the network.
    中文：不要将给定的会话从HTTP切换到HTTPS，或反之，因为这将在网络中明文泄露会话ID。
    • When redirecting to HTTPS, ensure that the cookie is set or regenerated after the redirect has occurred.
      中文：在重定向到HTTPS时，确保在重定向发生后设置或重新生成cookie。
  • Do not mix encrypted and unencrypted contents (HTML pages, images, CSS, JavaScript files, etc) in the same page, or from the same domain.
  • Where possible, avoid offering public unencrypted contents and private encrypted contents from the same host. Where insecure content is required, consider hosting this on a separate insecure domain.
  • Implement HTTP Strict Transport Security (HSTS) to enforce HTTPS connections.

See the OWASP Transport Layer Security Cheat Sheet for more general guidance on implementing TLS securely.

It is important to emphasize that TLS does not protect against session ID prediction, brute force, client-side tampering or fixation; however, it does provide effective protection against an attacker intercepting or stealing session IDs through a man in the middle attack.

Cookies

The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:

Secure Attribute

The Secure cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.

Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the Secure cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.

强制Web应用程序仅使用HTTPS进行通信（即使Web应用程序主机中关闭了TCP/80端口、HTTP），如果没有设置Securecookie，则无法防止会话ID泄露 - 浏览器可能会被欺骗，通过未加密的HTTP连接泄露会话ID。攻击者可以拦截和操纵受害用户的流量，并注入一个未加密的HTTP引用到Web应用程序，这将迫使浏览器在明文状态下提交会话ID。

See also: SecureFlag

另请参阅：SecureFlag

HttpOnly Attribute / HttpOnly属性

The HttpOnly cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks. However, if an XSS attack is combined with a CSRF attack, the requests sent to the web application will include the session cookie, as the browser always includes the cookies when sending requests. The HttpOnly cookie only protects the confidentiality of the cookie; the attacker cannot use it offline, outside of the context of an XSS attack.

HttpOnlycookie属性指示浏览器不允许脚本（例如JavaScript或VBscript）通过DOM的document.cookie对象访问cookie。这种会话ID保护是防止通过XSS攻击窃取会话ID的强制要求。然而，如果XSS攻击与CSRF攻击结合，发送到Web应用程序的请求将包括会话cookie，因为浏览器在发送请求时始终包含cookie。HttpOnlycookie仅保护cookie的机密性；攻击者无法在XSS攻击的上下文之外离线使用它。

See the OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet.

请参阅OWASP的XSS（跨站脚本）预防备忘单。

See also: HttpOnly

另请参阅：HttpOnly

SameSite Attribute / SameSite属性

The SameSite attribute controls whether browsers send a cookie with cross-site requests. SameSite=Strict excludes cross-site requests, while SameSite=Lax permits top-level cross-site navigations that use safe HTTP methods. Treat SameSite as defense in depth against CSRF, not as a replacement for a CSRF token. Session cookies must explicitly set SameSite=Strict (preferred) or SameSite=Lax. Never use SameSite=None without Secure, and do not rely on the browser-default value, which varies across browsers and versions.

SameSite属性控制浏览器是否在跨站请求中发送cookie。SameSite=Strict排除跨站请求，而SameSite=Lax允许使用安全HTTP方法的顶级跨站导航。将SameSite视为针对CSRF的深度防御，而不是CSRF令牌的替代品。会话cookie必须显式设置SameSite=Strict（首选）或SameSite=Lax。切勿在没有Secure的情况下使用SameSite=None，并且不要依赖浏览器默认值，因为浏览器和版本之间的默认值各不相同。

See also: SameSite

另请参阅：SameSite

Use cookie name prefixes to bind cookies to security properties at the browser level (RFC 6265bis §4.1.3):

使用 cookie 名称前缀将 cookie 绑定到浏览器级别的安全属性（RFC 6265bis §4.1.3）：

  • __Host- — the cookie must be set with Secure, must not have a Domain attribute, and must use Path=/. Prevents subdomain forgery and HTTPS downgrade attacks. Recommended for session IDs.
    中文：__Host- — 该cookie必须使用Secure属性设置，不得有Domain属性，并使用Path=/。防止子域名伪造和HTTPS降级攻击。推荐用于会话ID。
  • __Secure- — the cookie must be set with Secure. Use only when subdomain sharing is required.
    中文：__Secure- —— cookie 必须使用 Secure 设置。仅在需要子域共享时使用。

Example:

示例：

Set-Cookie: __Host-SessionID=<value>; Secure; HttpOnly; SameSite=Strict; Path=/

Domain and Path Attributes / 域名和路径属性

The Domain cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The Path cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.

【Domain cookie 属性](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Directives)指示网络浏览器仅将 cookie 发送到指定的域名及其所有子域名。如果未设置此属性，则默认情况下，cookie 只会发送到源服务器。【Path cookie 属性](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Directives)指示网络浏览器仅将 cookie 发送到指定的目录或子目录（或路径或资源）内的网络应用程序。如果未设置此属性，则默认情况下，cookie 只会发送到请求的资源目录（或路径）和设置 cookie。

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the Domain attribute should not be set (restricting the cookie just to the origin server) and the Path attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

建议为这两个属性使用狭窄或受限的范围。这样，Domain 属性不应设置（仅将 cookie 限制在源服务器），而 Path 属性应尽可能严格地设置为使用会话 ID 的网络应用程序路径。

Setting the Domain attribute to a too permissive value, such as example.com allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.

将 Domain 属性设置为过于宽泛的值，例如 example.com，允许攻击者对同一域名下的不同主机和网络应用程序之间的会话 ID 发起攻击，这被称为跨子域 cookie。例如，www.example.com 中的漏洞可能允许攻击者获取 secure.example.com 的会话 ID。

Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive Domain attribute (such as example.com) which is a technique that can be used in session fixation attacks.

此外，建议不要在同一域名下混合不同安全级别的Web应用程序。一个Web应用程序中的漏洞允许攻击者通过使用宽泛的Domain属性（如example.com）来设置同一域名下另一个Web应用程序的会话ID，这是一种可用于会话固定攻击的技术。

Although the Path attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the document.cookie object. Also, any web application can set cookies for any path on that host.

尽管Path属性允许通过同一主机上的不同路径在不同Web应用程序之间隔离会话ID，但强烈建议不要在同一主机上运行不同的Web应用程序（尤其是来自不同安全级别或范围的）。这些应用程序可以使用其他方法来访问会话ID，例如document.cookie对象。此外，任何Web应用程序都可以在该主机上的任何路径设置cookie。

Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.

Cookies容易受到DNS欺骗/劫持/中毒攻击的影响，攻击者可以操纵DNS解析，迫使网络浏览器泄露给定主机或域的会话ID。

Expire and Max-Age Attributes / 过期和Max-Age属性

Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the Max-Age (that has preference over Expires) or Expires attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time.

基于cookie的会话管理机制可以使用两种类型的cookie，非持久性（或会话）cookie和持久cookie。如果一个cookie具有Max-Age（优先于Expires）或Expires属性，它将被视为持久cookie，并由网络浏览器根据过期时间存储在磁盘上。

Use non-persistent cookies when authentication does not need to persist across browser sessions, but do not rely on browser closure to end an authenticated session. Browsers with session restore can retain session cookies after they close. Enforce session expiration on the server and invalidate the session when the user logs out; deleting a cookie alone does not invalidate a stolen copy of the session ID.

当认证不需要在浏览器会话之间持久时，使用非持久cookie，但不要依赖于浏览器关闭来结束已认证的会话。具有会话恢复功能的浏览器在关闭后可以保留会话cookie。在服务器上强制[会话过期]，当用户注销时使会话无效；仅删除cookie并不能使被盗的会话ID副本无效。

  • Ensure that sensitive information is not compromised by ensuring that it is not persistent, encrypting it, and storing it only for the duration of the need
    中文：确保敏感信息不会泄露，方法是确保其非持久性，加密它，并且仅在需要的时间内存储它。
  • Ensure that unauthorized activities cannot take place via cookie manipulation
    中文：确保无法通过cookie操作进行未经授权的活动。
  • Ensure secure flag is set to prevent accidental transmission over the wire in a non-secure manner
    中文：确保安全标志被设置为防止以非安全方式在网络上意外传输
  • Determine if all state transitions in the application code properly check for the cookies and enforce their use
    中文：确定应用程序代码中的所有状态转换是否正确检查cookie并强制使用它们
  • Ensure entire cookie should be encrypted if sensitive data is persisted in the cookie
    中文：如果cookie中持久化敏感数据，则整个cookie应该被加密
  • Define all cookies being used by the application, their name and why they are needed
    中文：定义应用程序使用的所有cookie，包括它们的名称和为什么需要它们

HTML5 Web Storage API

The Web Hypertext Application Technology Working Group (WHATWG) describes the HTML5 Web Storage APIs, localStorage and sessionStorage, as mechanisms for storing name-value pairs client-side. Unlike HTTP cookies, the contents of localStorage and sessionStorage are not automatically shared within requests or responses by the browser and are used for storing data client-side.

Web超文本应用技术工作组(WHATWG)将HTML5 Web Storage API，localStorage和sessionStorage，描述为客户端存储键值对的机制。与HTTP cookies不同，localStorage和sessionStorage的内容不会被浏览器在请求或响应中自动共享，并且用于在客户端存储数据。

The localStorage API / localStorage API

[!WARNING]

中文：[!警告] Do not store authentication tokens, session IDs, JWTs, refresh tokens, or any credential in localStorage or sessionStorage. These APIs are accessible to any JavaScript executing in the origin, so a single XSS vulnerability discloses every token. Use HttpOnly; Secure; SameSite=Strict cookies (preferred) or a Backend-for-Frontend (BFF) pattern. See OAuth 2.0 for Browser-Based Apps.

中文：不要在localStorage或sessionStorage中存储身份验证令牌、会话ID、JWT、刷新令牌或任何凭证。这些API对在源中执行的任何JavaScript都是可访问的，因此单个XSS漏洞会泄露所有令牌。使用HttpOnly; Secure; SameSite=Strict的cookie（首选）或后端前端（BFF）模式。参见OAuth 2.0 for Browser-Based Apps。

Scope / 作用域

Data stored using the localStorage API is accessible by pages which are loaded from the same origin, which is defined as the scheme (https://), host (example.com), port (443) and domain/realm (example.com). This provides similar access to this data as would be achieved by using the secure flag on a cookie, meaning that data stored from https could not be retrieved via http. Due to potential concurrent access from separate windows/threads, data stored using localStorage may be susceptible to shared access issues (such as race-conditions) and should be considered non-locking (Web Storage API Spec).

使用 localStorage API 存储的数据可由来自同一源（定义为方案 https://）、主机 (example.com)、端口 (443) 以及域名/领域 (example.com) 的页面访问。这提供了与使用 cookie 上的 secure 标志类似的数据访问权限，意味着存储在 https 中的数据无法通过 http 获取。由于可能存在来自不同窗口/线程的并发访问，使用 localStorage 存储的数据可能容易受到共享访问问题（如竞争条件）的影响，应将其视为非锁定（Web Storage API 规范）

Duration / 持续时间

Data stored using the localStorage API is persisted across browsing sessions, extending the timeframe in which it may be accessible to other system users.

使用 localStorage API 存储的数据在浏览会话之间持久化，延长了可能被其他系统用户访问的时间范围。

Offline Access / 离线访问

The standards do not require localStorage data to be encrypted-at-rest, meaning it may be possible to directly access this data from disk.

标准并不要求 localStorage 数据在存储时加密，这意味着可能可以直接从磁盘访问这些数据。

Use Case / 用例

WHATWG suggests the use of localStorage for data that needs to be accessed across windows or tabs, across multiple sessions, and where large (multi-megabyte) volumes of data may need to be stored for performance reasons.

WHATWG 建议使用 localStorage 存储需要在多个窗口或标签页、多个会话之间访问的数据，以及可能需要存储大量（多兆字节）数据以优化性能的情况。

The sessionStorage API

Scope / 作用域

The sessionStorage API stores data within the window context from which it was called, meaning that Tab 1 cannot access data which was stored from Tab 2. Also, like the localStorage API, data stored using the sessionStorage API is accessible by pages which are loaded from the same origin, which is defined as the scheme (https://), host (example.com), port (443) and domain/realm (example.com). This provides similar access to this data as would be achieved by using the secure flag on a cookie, meaning that data stored from https could not be retrieved via http.

Duration / 持续时间

The sessionStorage API only stores data for the duration of the current browsing session. Once the tab is closed, that data is no longer retrievable. This does not necessarily prevent access, should a browser tab be reused or left open. Data may also persist in memory until a garbage collection event.

Offline Access / 离线访问

The standards do not require sessionStorage data to be encrypted-at-rest, meaning it may be possible to directly access this data from disk.

Use Case / 用例

WHATWG suggests the use of sessionStorage for data that is relevant for one-instance of a workflow, such as details for a ticket booking, but where multiple workflows could be performed in other tabs concurrently. The window/tab bound nature will keep the data from leaking between workflows in separate tabs.

References / 参考

Web Workers

Web Workers run JavaScript in a separate global context. The main window and worker communicate through messages using postMessage().

Web Workers 在独立的全局上下文中运行 JavaScript。主窗口和工作者通过使用 postMessage() 方法（https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers#sending_messages_to_and_from_a_dedicated_worker）进行通信。

Use Case / 用例

A worker can keep a secret in memory when persistence across page refresh is not required. To isolate the secret from the main window, obtain it within the worker, keep secret-dependent operations there, and never return the secret to the main window.

当不需要跨页面刷新持久化时，工作者可以在内存中保留秘密。为了将秘密与主窗口隔离，在工作者内部获取它，保持依赖秘密的操作在那里，并且永远不要将秘密返回给主窗口。

This isolation can reduce direct access to an existing secret, but it does not make the application safe against XSS. Malicious page code can still request secret-dependent operations and read their results. The OAuth browser-apps guidance also explains that isolating an existing refresh token does not prevent malicious code from obtaining new tokens through another authorization flow.

这种隔离可以减少对现有秘密的直接访问，但这并不使应用程序免受 XSS 的攻击。恶意页面代码仍然可以请求依赖秘密的操作并读取其结果。OAuth 浏览器应用程序指南（https://www.rfc-editor.org/rfc/rfc10017.html#section-8.3）也解释了，隔离现有的刷新令牌并不能防止恶意代码通过另一种授权流程获取新的令牌。

Use a worker only when browser-side code needs secret-dependent operations. Expose a narrow message interface and enforce authorization on the server. Worker isolation does not replace XSS prevention or server-side session controls; prefer an HttpOnly cookie or a backend that holds tokens when the browser does not need to handle them.

仅在浏览器端代码需要依赖秘密的操作时使用工作者。公开一个狭窄的消息接口并在服务器上执行授权。工作者隔离不能替代 XSS 防止或服务器端会话控制；当浏览器不需要处理它们时，优先选择 HttpOnly cookie 或后端存储令牌。

Session ID Life Cycle / 会话 ID 生命周期

Session ID Generation and Verification: Permissive and Strict Session Management / 会话 ID 生成和验证：宽容和严格会话管理

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allows the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application.

对于 Web 应用程序，存在两种类型的会话管理机制，宽容和严格，与会话固定漏洞相关。宽容机制允许 Web 应用程序最初接受用户设置的任何会话 ID 值作为有效值，并为它创建一个新的会话，而严格机制则强制 Web 应用程序只接受先前由 Web 应用程序生成的会话 ID 值。

The session tokens should be handled by the web server if possible or generated via a cryptographically secure random number generator.

会话令牌应尽可能由Web服务器处理，或者通过密码学安全的随机数生成器生成。

Although the most common mechanism in use today is the strict one (more secure), PHP defaults to permissive. Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.

尽管目前最常用的机制是严格的机制（更安全），PHP默认为宽松模式。开发者必须确保Web应用程序在特定情况下不使用宽松机制。Web应用程序永远不应接受从未生成过的会话ID，如果在接收会话ID的情况下，应生成并提供用户一个新的有效会话ID。此外，这种情况应被视为可疑活动，并生成警报。

Manage Session ID as Any Other User Input / 将会话ID视为任何其他用户输入

Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabilities, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application.

会话ID必须被视为不可信的，就像Web应用程序处理的其他任何用户输入一样，它们必须经过彻底的验证和确认。根据所使用的会话管理机制，会话ID将通过GET或POST参数、URL或HTTP头（例如cookies）接收。如果Web应用程序在处理之前不验证和过滤无效的会话ID值，它们可能会被用于利用其他Web漏洞，例如如果会话ID存储在关系型数据库中，则可能被用于SQL注入，或者如果会话ID在Web应用程序之后存储并反射回来，则可能被用于持久XSS。

Renew the Session ID After Any Privilege Level Change / 在权限级别更改后更新会话ID

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state though in some cases still not yet the authorized state. Common scenarios to consider include; password changes, permission changes, or switching from a regular user role to an administrator role within the web application. For all sensitive pages of the web application, any previous session IDs must be ignored, only the current session ID must be assigned to every new request received for the protected resource, and the old or previous session ID must be destroyed.

在关联用户会话中的任何权限级别更改后，Web应用程序必须更新或重新生成会话ID。会话ID重新生成强制性的最常见场景是在身份验证过程中，因为用户的权限级别从未认证（或匿名）状态变为认证状态，尽管在某些情况下还不是授权状态。应考虑的常见场景包括；密码更改、权限更改或从普通用户角色切换到Web应用程序中的管理员角色。对于Web应用程序的所有敏感页面，必须忽略任何以前的会话ID，只将当前会话ID分配给每个接收到的受保护资源的请求，并且必须销毁旧的或以前的会话ID。

The most common web development frameworks provide session functions and methods to renew the session ID, such as request.getSession(true) & HttpSession.invalidate() (J2EE), Session.Abandon() & Response.Cookies.Add(new...) (ASP .NET), or session_start() & session_regenerate_id(true) (PHP).

最常用的Web开发框架提供了会话函数和方法来更新会话ID，例如request.getSession(true) & HttpSession.invalidate()（J2EE），Session.Abandon() & Response.Cookies.Add(new...)（ASP .NET），或session_start() & session_regenerate_id(true)（PHP）。

The session ID regeneration is mandatory to prevent session fixation attacks, where an attacker sets the session ID on the victim user's web browser instead of gathering the victim's session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS (see here and here).

会话ID的重新生成是强制性的，以防止会话固定攻击，攻击者将会话ID设置在受害用户的Web浏览器上，而不是像大多数其他基于会话的攻击那样收集受害者的会话ID，并且独立于使用HTTP或HTTPS。这种保护减轻了其他可以用于发起会话固定攻击的基于Web的漏洞的影响，例如HTTP响应拆分或XSS（参见这里和这里）.

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

Reauthentication After Risk Events

Web applications should require reauthentication after high-risk events such as:

  • Changes to critical user information (e.g., password, email address)
  • Login attempts from new or suspicious IP addresses or devices
  • Account recovery flows (e.g., password reset or compromised-account detection)

For best practices on implementing reauthentication after these events, see the Reauthentication After Risk Events section in the Authentication Cheat Sheet

Additional Resources

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.

如果 Web 应用程序使用 Cookie 作为会话 ID 交换机制，并且为特定会话设置了多个 Cookie，则 Web 应用程序必须在允许访问用户会话之前验证所有 Cookie（并强制执行它们之间的关系）。

It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session (see here and here).

Web 应用程序在 HTTP 上设置用户 Cookie 以在预认证阶段跟踪未认证（或匿名）用户是非常常见的。一旦用户在 Web 应用程序中进行认证，就会通过 HTTPS 设置一个新的后认证安全 Cookie，并建立两个 Cookie 与用户会话之间的绑定。如果 Web 应用程序没有验证认证会话中的两个 Cookie，攻击者就可以利用预认证未受保护的 Cookie 来访问认证用户会话（参见这里和这里）。

Web applications should try to avoid the same cookie name for different paths or domain scopes within the same web application, as this increases the complexity of the solution and potentially introduces scoping issues.

Web 应用程序应尽量避免在同一个 Web 应用程序中为不同的路径或域作用域使用相同的 Cookie 名称，因为这会增加解决方案的复杂性，并可能引入作用域问题。

Session Expiration / 会话过期

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.

为了最小化攻击者可以针对活动会话发起攻击并劫持会话的时间段，为每个会话设置过期超时是强制性的，从而确定会话将保持活跃的时间。Web 应用程序会话过期不足会增加其他基于会话的攻击的暴露风险，因为攻击者要能够重用有效的会话 ID 并劫持相关的会话，它必须仍然处于活动状态。

The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without the session frequently expiring.

会话间隔越短，攻击者使用有效会话 ID 的时间就越少。会话过期超时值必须根据 Web 应用程序的目的和性质进行设置，并平衡安全性和可用性，以便用户可以在 Web 应用程序中舒适地完成操作，而不会频繁过期。

Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15-30 minutes for low risk applications. Absolute timeouts depend on how long a user usually uses the application. If the application is intended to be used by an office worker for a full day, an appropriate absolute timeout range could be between 4 and 8 hours.

空闲超时和绝对超时值高度依赖于Web应用程序及其数据的重要性。常见的空闲超时范围是高价值应用程序为2-5分钟，低风险应用程序为15-30分钟。绝对超时取决于用户通常使用应用程序的时间长度。如果应用程序旨在供办公室工作人员全天使用，则适当的绝对超时范围可能在4到8小时之间。

When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The latter is the most relevant and mandatory from a security perspective.

当会话过期时，Web应用程序必须采取主动措施在客户端和服务器两端使会话失效。从安全角度来看，后者最为相关且是强制性的。

For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the Expires (or Max-Age) attribute to a date from the past (in case a persistent cookie is being used): Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT

对于大多数会话交换机制，客户端使会话ID失效的操作基于清除令牌值。例如，为了使cookie失效，建议为会话ID提供一个空值（或无效值），并将Expires（或Max-Age）属性设置为过去的日期（如果使用持久cookie）：Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT

In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as HttpSession.invalidate() (J2EE), Session.Abandon() (ASP .NET) or session_destroy()/unset() (PHP).

为了在服务器端关闭和使会话失效，当会话过期或用户主动注销时，Web应用程序必须使用会话管理机制提供的函数和方法采取主动措施，例如HttpSession.invalidate()（J2EE）、Session.Abandon()（ASP .NET）或session_destroy()/unset()（PHP）。

Automatic Session Expiration / 自动会话过期

Idle Timeout / 空闲超时

All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.

所有会话应实现空闲或非活动超时。此超时定义了会话在没有活动的情况下将保持活跃的时间长度，在定义的空闲期间关闭并使会话失效，该空闲期间是从Web应用程序收到给定会话ID的最后HTTP请求以来。

The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker's actions, as they can generate activity on the session periodically to keep the session active for longer periods of time.

空闲超时限制了攻击者猜测并使用其他用户的有效会话ID的机会。然而，如果攻击者能够劫持特定的会话，空闲超时不会限制攻击者的行为，因为他们可以定期在会话上生成活动，以使会话保持活跃更长时间。

Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, for example using the session token or other client parameters to track time references (e.g. number of minutes since login time), an attacker could manipulate these to extend the session duration.

会话超时管理和过期必须在服务器端强制执行。如果客户端用于强制执行会话超时，例如使用会话令牌或其他客户端参数来跟踪时间参考（例如自登录时间以来的分钟数），攻击者可以操纵这些来延长会话持续时间。

Absolute Timeout / 绝对超时

All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session.

所有会话都应该实现绝对超时，无论会话活动如何。此超时定义了会话可以活跃的最大时间，在从给定会话由Web应用程序最初创建以来定义的绝对周期后关闭和使会话无效。在使会话无效后，用户被迫在Web应用程序中（重新）进行身份验证并建立新的会话。

The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user.

绝对会话限制了攻击者可以使用被劫持的会话来冒充受害者用户的时间。

Renewal Timeout / 续订超时

Alternatively, the web application can implement an additional renewal timeout after which the session ID is automatically renewed, in the middle of the user session, and independently of the session activity and, therefore, of the idle timeout.

或者，Web应用程序可以在会话ID自动续订后实施额外的续订超时，这发生在用户会话期间，独立于会话活动和，因此，独立于空闲超时。

After a specific amount of time since the session was initially created, the web application can regenerate a new ID for the user session and try to set it, or renew it, on the client. The previous session ID value would still be valid for some time, accommodating a safety interval, before the client is aware of the new ID and starts using it. At that time, when the client switches to the new ID inside the current session, the application invalidates the previous ID.

在会话最初创建后的一段时间内，Web应用程序可以重新生成用户会话的新ID，并尝试在客户端设置或续订它。之前的会话ID值在客户端意识到新ID并开始使用它之前仍然有效，为安全间隔留出时间。在此期间，当客户端在当前会话中切换到新ID时，应用程序使之前的ID无效。

This scenario minimizes the amount of time a given session ID value, potentially obtained by an attacker, can be reused to hijack the user session, even when the victim user session is still active. The user session remains alive and open on the legitimate client, although its associated session ID value is transparently renewed periodically during the session duration, every time the renewal timeout expires. Therefore, the renewal timeout complements the idle and absolute timeouts, specially when the absolute timeout value extends significantly over time (e.g. it is an application requirement to keep the user sessions open for long periods of time).

此场景最小化了给定会话ID值（可能由攻击者获得）被重用来劫持用户会话的时间，即使受害者用户会话仍然活跃。用户会话在合法客户端上保持活跃和打开，尽管其关联的会话ID值在会话期间定期透明地续订，每次续订超时到期时。因此，续订超时补充了空闲和绝对超时，特别是在绝对超时值随时间显著延长时（例如，应用程序要求长时间保持用户会话打开）。

Depending on the implementation, potentially there could be a race condition where the attacker with a still valid previous session ID sends a request before the victim user, right after the renewal timeout has just expired, and obtains first the value for the renewed session ID. At least in this scenario, the victim user might be aware of the attack as the session will be suddenly terminated because the associated session ID is not valid anymore.

根据实现方式，可能存在一种竞争条件，攻击者使用仍然有效的先前会话ID，在受害者用户在续订超时刚刚过期后发送请求，并首先获得续订的会话ID值。至少在这个场景中，受害者用户可能会意识到攻击，因为会话会突然终止，因为相关的会话ID不再有效。

Manual Session Expiration / 手动会话过期

Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application.

Web应用程序应提供机制，允许安全意识强的用户在完成使用Web应用程序后主动关闭他们的会话。

Logout Button / 注销按钮

Web applications must provide a visible and easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time. As described in Session_Expiration section, the web application must invalidate the session at least on server side.

Web应用程序必须提供一个可见且易于访问的注销（登出、退出或关闭会话）按钮，该按钮位于Web应用程序标题或菜单中，并且可以从Web应用程序的每个资源和页面上访问，以便用户可以在任何时候手动关闭会话。如会话过期部分所述，Web应用程序必须在服务器端至少使会话无效。

NOTE: Unfortunately, not all web applications facilitate users to close their current session. Thus, client-side enhancements allow conscientious users to protect their sessions by helping to close them diligently.

注意：遗憾的是，并非所有Web应用程序都方便用户关闭他们的当前会话。因此，客户端增强功能允许有责任感的用户通过帮助他们谨慎地关闭会话来保护他们的会话。

Web Content Caching and Clear-Site-Data / Web内容缓存和清除站点数据

Even after the session has ended, private or sensitive data exchanged during the session may still be accessible through the web browser's cache. Set the cache policy in HTTP response headers on sensitive pages. Do not treat HTML <meta http-equiv> tags as an equivalent cache-control mechanism: browsers support only specific processing instructions, and unsupported values can be ignored.

即使在会话结束之后，会话期间交换的私有或敏感数据仍然可以通过Web浏览器的缓存访问。在敏感页面上设置HTTP响应头中的缓存策略。不要将HTML <meta http-equiv>标签视为等效的缓存控制机制：浏览器只支持特定的处理指令，不支持的价值可以被忽略。

Use Cache-Control: no-store on responses containing session identifiers or sensitive session data. Unlike no-cache, which allows storage but requires revalidation before reuse, no-store directs private and shared HTTP caches not to store the request or response. It is not a privacy guarantee: malicious or compromised caches might ignore the directive.

在包含会话标识或敏感会话数据的响应中使用 Cache-Control: no-store。与允许存储但需要在重用前重新验证的 no-cache 不同，no-store 指示私有和共享 HTTP 缓存不要存储请求或响应（参见 https://www.rfc-editor.org/rfc/rfc9111.html#section-5.2.2.5）。这并不是隐私保证：恶意或受损的缓存可能会忽略此指令。

In addition to preventing future caching, applications should ensure that previously stored sensitive data is removed when a session ends. This can be achieved by returning the Clear-Site-Data response header (for example, Clear-Site-Data: "cache", "cookies", "storage") during logout or session termination. This instructs the browser to delete cached resources, cookies, and other client-side storage associated with the origin, helping ensure a complete session cleanup.

除了防止未来的缓存外，应用程序还应确保在会话结束时删除先前存储的敏感数据。这可以通过在注销或会话终止时返回 Clear-Site-Data 响应头（例如，Clear-Site-Data: "cache", "cookies", "storage"）来实现。这指示浏览器删除与源相关的缓存资源、cookie 和其他客户端存储，有助于确保会话完全清理。

Note: The directive Cache-Control: no-cache="Set-Cookie, Set-Cookie2" is sometimes suggested to prevent session ID caching. However, this syntax is not widely supported and may lead to unintended behavior. Instead, use Cache-Control: no-store for stronger protection. Clear-Site-Data: "cache" can be used to clear every stored response for a site in the browser cache, so use this with care. Note that this will not affect shared or intermediate caches.

中文：注意：指令Cache-Control: no-cache="Set-Cookie, Set-Cookie2"有时被建议用于防止会话ID缓存。然而，这种语法并不广泛支持，可能会导致意外的行为。相反，使用Cache-Control: no-store以获得更强的保护。Clear-Site-Data: "cache"可以用于清除浏览器缓存中网站的每个已存储响应，因此请谨慎使用。请注意，这不会影响共享或中间缓存。 Reference: MDN - Cache-Control and MDN - Clear-Site-Data header

中文：参考：MDN - Cache-Control 和 MDN - Clear-Site-Data header

Reauthentication After Risk Events

To ensure session integrity and account protection, applications should require reauthentication when specific high-risk events are detected. These may include:

为确保会话完整性和账户保护，当检测到特定高风险事件时，应用程序应要求重新认证。这些可能包括：

  • Attempted or completed password changes
    中文：尝试或完成的密码更改
  • Login from a new or suspicious IP address or device
    中文：来自新的或可疑的 IP 地址或设备的登录
  • Completion of account recovery or challenge flows (e.g., hacked-lock scenarios)
    中文：完成账户恢复或挑战流程（例如，被黑锁场景）

Requiring reauthentication helps mitigate session hijacking and unauthorized access—especially when long-lived sessions or external identity providers are in use.

要求重新认证有助于减轻会话劫持和未经授权的访问——尤其是在使用长期会话或外部身份提供者时。

Recommended Practices:

推荐实践：

  • Prompt users for primary credentials (e.g., password) or enforce MFA
    中文：提示用户输入主要凭证（例如，密码）或强制执行多因素认证
  • Provide clear messaging explaining the need to reauthenticate
    中文：提供清晰的说明，解释重新认证的需要

Additional Client-Side Defenses for Session Management / 会话管理的额外客户端防御措施

Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by intruders.

Web应用程序可以通过在客户端采取额外的对策来补充之前描述的会话管理防御措施。客户端保护措施，通常以JavaScript检查和验证的形式存在，并不是坚不可摧的，但可以引入另一层防御，入侵者必须绕过这一层才能成功攻击。

Initial Login Timeout / 初始登录超时

Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID.

Web应用程序可以使用JavaScript代码在登录页面中评估和测量自页面加载以来以及会话ID被授予的时间量。如果在特定时间后尝试登录，客户端代码可以通知用户登录的最大时间已过，并重新加载登录页面，从而获取一个新的会话ID。

This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks.

这种额外的保护机制试图在预认证之前强制更新会话ID，避免在会话固定攻击等场景中，之前使用过的（或手动设置的）会话ID被同一台电脑上的下一个受害者重新使用。

Limits of Logout on Browser Close / 浏览器关闭时注销的限制

Browser close events cannot reliably enforce logout. For example, beforeunload may not fire when a mobile browser is closed from the app manager. Use server-side idle and absolute timeouts and an explicit logout action to invalidate sessions. Client-side close handlers can supplement these controls but must not replace them.

浏览器关闭事件无法可靠地强制注销。例如，当从应用管理器关闭移动浏览器时，beforeunload 事件可能不会触发。请使用服务器端的空闲和绝对超时（#自动会话过期）以及显式的注销操作来使会话失效。客户端关闭处理程序可以补充这些控制，但不能替代它们。

Disable Web Browser Cross-Tab Sessions / 禁用网页浏览器跨标签页会话

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them.

一旦用户登录并建立会话，Web 应用程序可以使用 JavaScript 代码强制用户在打开新的网页标签页或窗口时重新认证，以防止多个网页浏览器标签页或窗口共享相同的会话。Web 应用程序不希望允许多个网页浏览器标签页或窗口共享相同的会话。因此，应用程序试图强制网页浏览器在它们之间不共享相同的会话 ID。

NOTE: This mechanism cannot be implemented if the session ID is exchanged through cookies, as cookies are shared by all web browser tabs/windows.

注意：如果会话 ID 通过 cookie 交换，则无法实现此机制，因为 cookie 在所有网页浏览器标签页/窗口之间是共享的。

Automatic Client Logout / 自动客户端注销

JavaScript code can be used by the web application in all (or critical) pages to automatically logout client sessions after the idle timeout expires, for example, by redirecting the user to the logout page (the same resource used by the logout button mentioned previously).

Web 应用程序可以使用 JavaScript 代码在所有（或关键）页面上自动注销客户端会话，在空闲超时到期后，例如，通过将用户重定向到注销页面（与之前提到的注销按钮使用的相同资源）。

The benefit of enhancing the server-side idle timeout functionality with client-side code is that the user can see that the session has finished due to inactivity, or even can be notified in advance that the session is about to expire through a count down timer and warning messages. This user-friendly approach helps to avoid loss of work in web pages that require extensive input data due to server-side silently expired sessions.

使用客户端代码增强服务器端空闲超时功能的好处是，用户可以看到会话因不活动而结束，甚至可以通过倒计时计时器和警告消息提前通知会话即将过期。这种用户友好的方法有助于避免因服务器端静默过期会话而在需要大量输入数据的网页中丢失工作。

Session Attacks Detection / 会话攻击检测

Session ID Guessing and Brute Force Detection / 会话ID猜测和暴力破解检测

If an attacker tries to guess or brute force a valid session ID, they need to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), they need to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs.

如果攻击者尝试猜测或暴力破解有效的会话ID，他们需要针对目标Web应用发起多个连续请求，使用单个（或一组）IP地址的不同会话ID。此外，如果攻击者尝试分析会话ID的可预测性（例如，使用统计分析），他们需要从单个（或一组）IP地址针对目标Web应用发起多个连续请求，以收集新的有效会话ID。

Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es).

Web应用必须能够根据尝试收集（或使用）不同会话ID的次数来检测这两种情况，并警告和/或阻止违规的IP地址。

Detecting Session ID Anomalies / 检测会话ID异常

Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session.

Web应用应专注于检测与会话ID相关的异常，例如其操纵。OWASP AppSensor项目提供了一个框架和方法，用于在Web应用中实现内置的入侵检测功能，重点关注检测异常和意外行为，以检测点和响应动作的形式。有时，业务逻辑细节和高级智能仅从Web应用内部获得，可以在其中建立多个与会话相关的检测点，例如，当现有的cookie被修改或删除，添加了新的cookie，另一个用户的会话ID被重复使用，或者当用户位置或User-Agent在会话中途发生变化时。

Binding the Session ID to Other User Properties / 将会话ID绑定到其他用户属性

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

为了检测（以及在某些场景中，保护）用户不当行为和会话劫持，强烈建议将会话ID绑定到其他用户或客户端属性，例如客户端IP地址、User-Agent或基于客户端的数字证书。如果Web应用检测到在建立的会话中这些不同属性之间的任何变化或异常，这是一个很好的会话操纵和劫持尝试的指标，并且这个简单的事实可以用来警告和/或终止可疑的会话。

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying the User-Agent to look exactly like the victim user's.

尽管这些属性不能被网络应用程序用来信任地防御会话攻击，但它们显著增强了网络应用程序的检测（和保护）能力。然而，熟练的攻击者可以通过共享相同的网络（如在NAT环境，如Wi-Fi热点中非常常见）分配给受害用户的同一IP地址，或者使用相同的出站Web代理（在企业环境中非常常见），或者通过手动修改User-Agent以使其看起来与受害用户的完全一样来绕过这些控制。

Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs / 会话生命周期日志：监控会话ID的创建、使用和销毁

Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.

网络应用程序应通过包括有关会话完整生命周期的信息来增强其日志记录能力。特别是，建议记录与会话相关的活动，例如会话ID的创建、更新和销毁，以及登录和注销操作中会话的使用详情，会话内权限级别的更改，超时过期，检测到的无效会话活动，以及会话期间的临界业务操作。

Log the timestamp, source IP address, requested resource, event type, result or error code, and user ID when needed for session monitoring. Record only selected header and parameter fields after excluding credentials and sensitive values, following the Logging Cheat Sheet. Do not log raw session IDs; use the session correlation approach described below.

在需要会话监控时，记录时间戳、源IP地址、请求的资源、事件类型、结果或错误代码和用户ID。在排除凭据和敏感值后，仅记录选定的头和参数字段，遵循日志作弊表。不要记录原始会话ID；使用以下描述的会话关联方法。

Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged in order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.

为了保护会话日志免遭会话ID本地或远程泄露或未经授权的访问，敏感数据如会话ID不应包含在日志中。然而，必须记录某种类型的特定会话信息，以便将日志条目关联到特定会话。建议记录会话ID的盐值散列，而不是会话ID本身，以便在不暴露会话ID的情况下进行特定会话的日志关联。

In particular, web applications must thoroughly protect administrative interfaces that allow to manage all the current active sessions. Frequently these are used by support personnel to solve session related issues, or even general issues, by impersonating the user and looking at the web application as the user does.

特别是，网络应用程序必须彻底保护允许管理所有当前活动会话的管理接口。这些通常被支持人员用来解决与会话相关的问题，甚至通过冒充用户并以用户的角度查看Web应用程序来解决一般问题。

The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.

会话日志成为主要的网络应用程序入侵检测数据源之一，也可以被入侵保护系统用来在检测到（一个或多个）攻击时自动终止会话和/或禁用用户账户。如果实施了主动保护，这些防御行为也必须被记录。

Simultaneous Session Logons / 同时会话登录

It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active.

确定是否允许同一用户从同一或不同客户端IP地址进行多个同时登录，是Web应用设计决策的一部分。如果Web应用不希望允许同时会话登录，它必须在每次新的认证事件之后采取有效措施，隐式地终止之前可用的会话，或者通过旧会话、新会话或两者询问用户必须保持活跃的会话。

It is recommended for web applications to add user capabilities that allow checking the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc.

建议Web应用添加允许在任何时间检查活跃会话详细信息的用户功能，监控并提醒用户关于并发登录，提供用户手动远程终止会话的功能，并通过记录多个客户端详细信息（如IP地址、User-Agent、登录日期和时间、空闲时间等）来跟踪账户活动历史（日志簿）。

Session Management WAF Protections / 会话管理WAF保护

There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term.

存在一些情况，Web应用源代码不可用或无法修改，或者实施上述详细描述的多个安全建议和最佳实践所需的变化意味着Web应用架构的全面重新设计，因此无法在短期内轻松实施。

In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described.

在这些场景中，或为了补充Web应用防御，并旨在使Web应用尽可能安全，建议使用外部保护措施，如可以减轻已描述的会话管理威胁的Web应用防火墙（WAF）。

Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the Secure and HttpOnly flags, applying basic rewriting rules on the Set-Cookie header for all the web application responses that set a new cookie.

Web应用防火墙提供针对基于会话的攻击的检测和保护功能。一方面，对于WAF来说，强制在cookie上使用安全属性（如Secure和HttpOnly标志）是微不足道的，它会在所有设置新cookie的Web应用响应的Set-Cookie头中应用基本的重写规则。

On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session).

另一方面，可以实现更高级的功能，允许WAF跟踪会话及其相应的会话ID，并应用各种保护措施来防止会话固定（通过在检测到权限更改时在客户端刷新会话ID）、强制粘性会话（通过验证会话ID与其他客户端属性（如IP地址或User-Agent）之间的关系）或管理会话过期（通过强制客户端和Web应用最终确定会话）。

The open-source ModSecurity WAF, plus the OWASP Core Rule Set, provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.

开源的ModSecurity WAF以及OWASP 核心规则集提供检测和应用安全cookie属性、针对会话固定攻击的对策以及会话跟踪功能，以强制执行粘性会话。

References / 参考