我目前拥有自己的应用程序安全服务,该服务在我的企业中运行,并且 - 在很大程度上 - 满足业务需求。
我目前面临的问题是,该服务传统上(天真地)依赖用户的源IP保持不变作为对抗会话劫持的对冲 - 企业中的Web应用程序不能直接向公众提供,而且它在过去完全可以接受,要求用户的地址在给定的会话期间保持不变。
不幸的是,情况不再如此,因此我不得不切换到不依赖源IP的解决方案。我更倾向于实现一个实际完成原始设计者意图的解决方案(即阻止会话劫持)。
到目前为止,我的研究已经出现this,其实质上是说“使用SSL会话密钥对您的身份验证令牌哈希加盐。”
从表面上看,这似乎是一个完美的解决方案,但我仍然怀疑这个方案的实际实施是不切实际的,因为客户端和服务器可能随时 - 有效地任意 - 选择重新协商SSL会话,从而更改密钥。
这是我想象的场景:
这是一个真正的问题,还是由于(至少可以说)对SSL的工作方式不太完美的理解,这是我的误解?
答案 0 :(得分:5)
查看与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代替基于密码的身份验证的虚拟主机。
答案 1 :(得分:3)
我想知道为什么仅仅
就不够了答案 2 :(得分:1)
是的,但您可以采取一些措施。最简单的方法是简单地缓存您用作salt(每个用户)的会话密钥,并接受它们中的任何一个。即使重新协商会话,您仍然会在缓存中使用它。有详细信息 - 过期策略等 - 但除非你运行的东西需要milspec强化,否则没有什么是不可克服的,在这种情况下你不应该首先这样做。
- MarkusQ