HTTP中的会话管理

HTTP是一种“无状态”的协议。 这意味着，并没有一个“内置”的标准来跟踪那些相互关联的请求。 每个请求都被视为独立的请求。 目前，大多数网络应用程序都使用的是HTTP 1.1协议。该协议是在1996年发布的。 这些网络应用程序非常先进，通常能够处理那些需要多对请求与响应才能完成的操作。因此，需要某种方式来跟踪当前操作的进展情况。 这些应用程序还会为每位用户提供个性化的内容。 这需要能够在多个请求中识别出某个用户。 因此，一定存在某种能够提升HTTP功能的机制或方法。有一些解决方案，其实都是网络程序员通过巧妙的构思而得出的结果。 HTTP采用客户端-服务器架构，其传输协议为TCP。多个请求可以通过一个TCP连接进行发送，不过这些请求在客户端和服务器看来都是独立的。 如上所述，HTTP中的会话有两个方面。 实现跨请求跟踪主要有两种方法。请求参数：代表多步骤过程当前状态的令牌，或者用于识别用户的令牌，可以被服务器存储在网页中的表单字段中。当用户执行某个操作时，这个令牌就会自动被提交到服务器上。 该令牌被作为输入字段的值来保存。 这个令牌可以作为 GET 请求参数或 POST 请求参数来提交。 在 GET 请求中，请求参数会被嵌入到 URL 中，并且这些参数会被记录在浏览器的历史记录中。 在 POST 请求中，参数会被作为请求体的一部分进行传输，因此它们不会被嵌入到 URL 中，也不会显示在浏览器的历史记录中。 显然，对于需要提交敏感信息的场景，应该使用 POST 请求。而对于那些不需要传输敏感信息的场景，则可以使用 GET 请求。 例如，如果该令牌是用户的标识符，那么它必须始终通过POST请求来发送。 那些不太敏感的数据项包括状态标识符、引用值等。 在 GET 请求中发送标识符还有另一种方式。 它使用的是路径名称，而不是参数。2. 饼干/ CookieCookie其实就是一种名称与值之间的关联，它们被存储在浏览器中，并在后续的请求中被自动传递出去。 服务器通过“set-cookie”HTTP头信息来生成这些Cookie，然后将其发送给客户端。 该Cookie是通过“cookie”头部来发送的。 Cookie头部中，名称与值之间用分号分隔。 Set-Cookie头部包含与Cookie相关的额外指令和参数。 这些参数有助于浏览器了解如何以及何时提交这些请求。最常见的参数包括：域名、路径以及过期时间。而相关的指令则包括“secure”和“httponly”。 该域参数指定了Cookie生效的域名。同时，该Cookie也适用于其所有子域名。 “Path”参数用于指定URL的路径。 “Expires”这一选项的含义很明确。 “Secure”指令指示浏览器仅通过HTTPS来发送Cookie；而“Httponly”则指示浏览器不允许网站中的JavaScript代码访问该Cookie。 这样做是为了防止XSS攻击对用户的Cookie数据进行窃取。因为，如果网站存在XSS漏洞的话，那么攻击者就有可能利用这种漏洞来窃取用户的Cookie数据。最佳实践/最佳做法在跟踪用户会话时，需要生成、传输和存储敏感信息。如果在任何阶段出现配置错误，都可能导致用户数据的安全性受到威胁。在开发用于维护用户会话的应用程序时，有一些要点需要注意。

• 切勿通过未加密的通道（如HTTP）传输任何令牌。
• 当用户登出时，服务器端的令牌会失效。仅仅清除用户浏览器中的Cookie是不够的，因为这可能会导致账户被永久夺走。
• 对于需要身份验证的敏感操作，务必实施CSRF保护机制。
• 切勿在 GET 请求中提交防 CSRF 令牌。更不用说在 GET 请求中提交会话令牌了。
• 在生成敏感令牌时，务必使用“nonce”和“padding”技术。同时，应避免使用像Base64这样的可逆编码方式。
• 请勿将密码以明文形式存储在服务器上。务必对密码进行哈希处理，并将哈希后的结果存储起来。这样就能在发生数据泄露等不幸事件时保护用户的隐私。