Cookies 基于cookie的会话管理的改进

“服务器操作员可能不使用cookies进行授权 希望通过治疗来考虑纠缠指定和授权 作为功能的URL。这不是在Cookie中存储机密，而是 这种方法在URL中存储秘密，要求远程实体 提供秘密本身。虽然这种方法不是万灵药， 明智地应用这些原则可以带来更强大的安全性 “A.巴特

---

在URL中存储秘密意味着什么？在实践中如何做到这一点？

我认为符合这一描述的一种技术是要求客户提出请求。AmazonWebServices为一些操作提供了这种技术，我也看到它在Web公司的内部API中实现。可以使用此技术或类似技术在服务器端对URL进行签名，并将它们安全地（通过HTTPS）传递到嵌入HTML的客户端，或根据API响应XMLHttpRequests

作为会话cookie的替代方案，我不确定这种技术会带来什么好处。但是，在某些情况下，它是方便的，或者通常是解决问题的最佳方法。例如，我在以下情况下使用了类似的技术：

跨域

您需要向浏览器授予对另一个域上的URL的访问权限，因此Cookie没有用处，并且您可以在URL服务器端签名以授予访问权限，无论是重定向还是足够长的过期时间，以便浏览器有时间加载URL

示例：从S3下载文件。从CloudFront渐进式播放视频

封闭源限制

除了URL之外，您无法控制浏览器或其他客户端发送的内容，因为您使用的是某种封闭源代码插件，无法更改其行为。再次对URL服务器端进行签名，这样客户端所要做的就是获取URL

示例：通过WEBVTT将视频字幕和/或精灵文件加载到封闭源代码的Flash视频播放器中。当您需要确保有效负载在传输过程中不能更改时，将有效负载与联邦单一登录回调URL一起发送

无凭证任务工作者

您正在向浏览器以外的其他对象发送URL，而该对象需要访问该URL上的资源，除此之外，您不希望为其提供实际凭据

---

示例：您正在运行队列使用者或基于任务的工作进程守护程序，或者可能是AWS Lambda函数，需要下载文件、处理文件并发送电子邮件。只需对它将使用的所有URL进行预签名，并具有合理的过期期限，这样它就可以执行它需要的所有请求，而无需任何额外的凭据。

类似于这样的内容：实际上，您链接到的论文中的技术与我上面描述的有很大不同。该论文称之为SecSess的技术，在客户端使用共享秘密对URL进行签名。在我的例子中，我建议只在服务器上对URL进行签名。我不认为链接纸张的SecSess技术“在URL中存储机密”，因为浏览器将共享机密存储在某个地方（他们只是说“存储在浏览器中”），即使只是在内存中，在你的链接中，他们还讨论了计算客户端请求主体的HMAC。我研究了AWS S3，它向请求中添加了HMAC。它在实现上类似于secses，但使用了预共享的秘密。还有，为什么您认为RFC中的这句话意味着URL的服务器端签名？我不完全理解你的答案。我不认为这个评论特别指的是HMAC技术，但短语“此方法在URL中存储机密”排除了预共享机密，或将机密存储在URL以外的其他地方（例如，内存、cookie、本地存储等）。我认为作者所指的是一种技术，其中服务器向客户端提供一个URL，该URL包含一个秘密，因此不仅仅是一个资源指针，还包含对该资源执行操作的能力（“将URL视为功能”）。服务器端签名符合这一描述。