SSL会话持久性和安全cookie

Question

我目前拥有自己的应用程序安全服务，该服务在我的企业中运行，并且 - 在很大程度上 - 满足业务需求。

我目前面临的问题是，该服务传统上（天真地）依赖用户的源IP保持不变作为对抗会话劫持的对冲 - 企业中的Web应用程序不能直接向公众提供，而且它在过去完全可以接受，要求用户的地址在给定的会话期间保持不变。

不幸的是，情况不再如此，因此我不得不切换到不依赖源IP的解决方案。我更倾向于实现一个实际完成原始设计者意图的解决方案（即阻止会话劫持）。

到目前为止，我的研究已经出现this，其实质上是说“使用SSL会话密钥对您的身份验证令牌哈希加盐。”

从表面上看，这似乎是一个完美的解决方案，但我仍然怀疑这个方案的实际实施是不切实际的，因为客户端和服务器可能随时 - 有效地任意 - 选择重新协商SSL会话，从而更改密钥。

这是我想象的场景：

1. 已建立SSL会话并已达成一致意见。
2. 客户端在应用程序级别对服务器进行身份验证（即通过用户名和密码）。
3. 服务器写入包含SSL会话密钥的安全cookie。
4. 发生了一些会导致会话重新协商。例如，我认为IE在有或没有理由的计时器上执行此操作。
5. 客户端向包含旧会话密钥的服务器提交请求（因为没有应用程序级别的重新协商知识，因此没有机会将新的，更新的散列写入客户端）。
6. 由于哈希匹配失败等原因，服务器拒绝客户端的凭据

这是一个真正的问题，还是由于（至少可以说）对SSL的工作方式不太完美的理解，这是我的误解？

Answer 1

查看与SSL persistence相关的所有主题。这是负载平衡器领域中一个经过深入研究的问题。

简短的回答是：您不能依赖SSLID - 大多数浏览器重新协商，您仍然需要使用源IP。如果IP地址可能在会话期间发生变化，那么您可以强制进行软重新认证，或者使用SSLID作为两个IP更改之间的桥梁（反之亦然，即仅假设两者都是劫持 IP地址和SSLID同时发生变化，如服务器所示。）

2014年更新

只需强制使用https并确保您不会受到session fixation或CRIME的攻击。不要费心用任何客户端信息来限制你的身份验证令牌，因为如果攻击者能够获得令牌（前提是所说的令牌不是一般的猜测），那么无论使用什么方法来获取它（例如{{3}或者，客户端系统的完全妥协）也将允许攻击者轻松获取可能已经进入令牌的任何客户端信息（并在需要时复制辅助系统上的那些信息）。

如果客户端可能只从几个系统连接，那么您可以cross-site scripting可能是客户端连接的每个新客户端系统（公共部分提交到您的服务器并且私有部分仍然存在）在希望安全客户端存储中）并重定向到使用generate an RSA keypair in the browser代替基于密码的身份验证的虚拟主机。

Answer 2

我想知道为什么仅仅

就不够了

1. 在运输中要求ssl
2. 编码输入（html / url / attribute）以防止跨站点脚本
3. 仅对所有更改信息的请求和
要求POST
4. 尽可能地阻止CSRF（取决于您的平台支持的内容）。
5. 将您的Cookie设置为HTTPOnly

Answer 3

是的，但您可以采取一些措施。最简单的方法是简单地缓存您用作salt（每个用户）的会话密钥，并接受它们中的任何一个。即使重新协商会话，您仍然会在缓存中使用它。有详细信息 - 过期策略等 - 但除非你运行的东西需要milspec强化，否则没有什么是不可克服的，在这种情况下你不应该首先这样做。

- MarkusQ