HTTP 是一种“无状态”协议。这意味着没有“内置”标准来跟踪相关请求。每个请求都被视为独立的。目前，大多数 Web 应用程序都使用 1996 年发布的 HTTP 1.1。这些 Web 应用程序非常先进，通常处理需要一对以上请求/响应才能完成的复杂操作，这需要一些东西来跟踪当前状态手术。这些应用程序还为每个用户提供量身定制的内容。这需要在多个请求中识别用户。所以一定有一些东西可以为 HTTP 添加“增强”。
有一些解决方案是网络程序员聪明思考的结果。
HTTP 使用客户端-服务器架构，并使用 TCP 作为其传输协议，可以通过一个 TCP 连接发送多个请求，但客户端和服务器也认为这些请求是独立的。如上所述，HTTP 中的会话有两个方面。实现跨请求跟踪主要有两种方式。
1. 请求参数：
代表多步骤过程的当前状态或标识用户的令牌可以由服务器存储在网页上的表单字段中，每次用户执行操作时都会自动提交。令牌包含为输入字段的值。此令牌可以作为 GET 请求参数或 POST 请求参数提交。 GET 请求中的请求参数嵌入在 URL 中，并记录在浏览器历史记录中。虽然 POST 将参数作为请求正文提交，因此它不会嵌入到 URL 中，也不会显示在浏览器历史记录中。显然，对于提交敏感信息应该使用 POST 请求，而对于敏感信息可以使用 GET 请求。例如，如果令牌是用户的标识符，则必须始终在 POST 请求中发送。令牌的非敏感示例包括状态标识符、引用值等。
还有另一种在 GET 请求中发送标识符的方法。它使用路径名而不是参数。
2. 饼干
Cookie 是存储在浏览器中并在后续请求中自动提交的名称-值对。服务器生成它们并使用“set-cookie”HTTP 标头将它们发送到客户端。使用“cookie”标头提交 cookie。
cookie 标头发送以分号分隔的名称-值对。 set-cookie 标头包含用于 cookie 的额外指令和参数。这些有助于浏览器了解如何以及何时提交它们。
最常见的参数是 – 域、路径和过期时间，而指令是 – “安全”和“httponly”。 domain 参数指定 cookie 有效的域，cookie 也将对其所有子域有效。 path 参数指定 URL 路径。过期是不言自明的。
“secure”指令指示浏览器仅通过 HTTPS 发送 cookie，而“httponly”指示浏览器不允许网站 JavaScript 访问 cookie。这样做是为了防止利用 XSS 窃取 cookie，以防网站易受 XSS 攻击。
最佳实践
跟踪会话需要敏感令牌的生成、传输和存储。任何阶段的任何错误配置都可能危及用户数据的安全。在开发维护用户会话的应用程序时，应牢记一些要点。
- 切勿通过未加密的通道 (HTTP) 发送任何令牌。
- 用户登出时使服务器端的token失效，仅仅在用户浏览器上清除cookies是不够的，可能会导致账户永久被接管。
- 始终对需要身份验证的敏感操作实施 CSRF 保护。
- 永远不要在 GET 请求中提交反 CSRF 令牌（甚至不要考虑在 GET 请求中提交会话令牌）
- 在生成敏感令牌时始终使用 nonce 和 padding，并避免使用可逆编码方案，如 Base64。
- 不要将密码以明文形式存储在服务器上。始终散列它们并存储散列。这将保护用户免受不幸的数据泄露事件的影响。