如何保护ASP.NET或ASP.NET MVC免受相关域cookie攻击？

Question

在相关的域cookie的攻击(详细信息),允许在同一个DNS域中的计算机以添加也将在同一个域发送到其他计算机上的其他饼干.

这可能会导致身份验证问题,或者最糟糕的情况是混乱的副攻击中的一个组件.

题

如何保护ASP.NET或ASP.NET MVC免受此类攻击？

一种可能的攻击方案

1. 我登录了一个"安全"的网络应用程序
2. 我获得了帐户的凭据
3. 我欺骗用户访问我在同一DNS域上的网站
4. 我插入了cookie(我的信用卡)
5. 用户返回您的应用程序.
6. 两个cookie(或被覆盖的cookie)都被发送到服务器
7. 用户在我的帐户下做事

这是一个简化的例子,但这个想法可以移植到其他类型的攻击中,我只是选择看起来并不"太糟糕"的场景.

如果这是两步攻击的第一步,那么它是如何"变坏"的一个想法.假设用户上传了一个只能在他的帐户中访问的错误文件; 然后另一个用户无意中下载该文件,运行那里的任何可执行代码.

还有很多其他场景是可能的......而不是在这里列出所有场景我试图找出如何保护我的服务器免受此类攻击.

Answer 1

渠道限制饼干

以下提议的RFC来自Google员工,描述了客户端使用自签名浏览器证书的方式(因此不需要为最终用户提供令人困惑的"弹出"),这也可以解决称为"相关域"的cookie安全问题饼干"

下面是http://www.browserauth.net/的摘录,RFC的一部分,一些有趣的评论,以及对此扩展的一些批评.

通道绑定Cookie概述

一旦底层TLS通道使用TLS客户端身份验证(使用TLS-OBC扩展),服务器可以通过将其与客户端的公钥相关联来将其cookie绑定到TLS通道,并确保cookie仅在经过身份验证的TLS通道上使用使用该公共(客户端)密钥.

这意味着如果这样的通道绑定cookie从客户端的计算机上被盗,那么该cookie将无法从其他计算机验证到服务器的HTTP会话.这包括将自己注入客户端和服务器之间连接的中间人攻击者,可能是通过欺骗用户点击证书不匹配警告:这样的中间人将不得不生成自己的TLS会话与服务器,它将与cookie绑定它的通道不匹配.

通道绑定

由服务器决定是否将cookie绑定到TLS通道.如果客户端不支持TLS-OBC,或者它将要设置的cookie将在不同的源上使用,则服务器将不会对cookie进行通道绑定.如果确实决定对cookie进行通道绑定,则应将cookie与客户端的公钥相关联.这与RFC 5929类似,但不是客户端将数据绑定到服务器的公钥,在这种情况下,服务器将绑定数据(cookie)绑定到客户端的公钥.服务器可以通过简单地在后端数据库中存储某个HTTP会话预期使用某个客户端公钥进行身份验证的事实来实现这一点,或者它可以使用合适的加密来编码cookie本身哪个TLS客户端公共cookie绑定的密钥.

在上图中,服务器将客户端的公钥包含到加密签名的数据结构中,该数据结构还包括经过身份验证的用户ID.当服务器从客户端收回cookie时,它可以验证它确实发出了cookie(通过检查cookie上的签名),并验证cookie是否通过正确的通道发送(通过将TLS客户端密钥与cookie中提到的密钥).

在这里继续.... http://www.browserauth.net/channel-bound-cookies

RFC Snip

TLS Origin-Bound Certificates RFC草案

(摘抄)

4.3.Cookie强化

TLS-OBC可用于加强基于cookie的身份验证的一种方法是将cookie"绑定"到原始绑定证书.当为HTTP会话发出cookie时,服务器会将客户端的源自原始证书与会话相关联(通过在cookie中不可伪造地编码有关证书的信息,或通过其他方式将证书与cookie的会话相关联) .这样,如果cookie从客户端被盗,它就不能在不同客户端发起的TLS连接上使用 - cookie窃贼也必须窃取与客户端的原始绑定证书相关的私钥,这是一项任务特别是当我们假设存在可以存储
原始绑定证书的私钥的可信平台模块或其他安全元素时,会更加困难.

其他评论来自public-web-security@w3.org

此外,请注意,通道绑定cookie有点违反直觉,可以防止许多相关域攻击,即使客户证明它们受到约束的范围也比Web源更广.

想象一下,用户代理创建了一个单一的自签名证书,它用作所有服务器的所有连接的TLS客户端证书(在隐私方面不是一个好主意,但请跟我一起进行这个思想实验).然后,服务器在各自的顶级域上设置cookie,但将它们通道绑定到用户代理的一对一客户端证书.

所以,假设app app.heroku.com在我的浏览器上为域.heroku.com设置了一个(通道绑定)cookie,并且在attacker.heroku.com上有一个攻击者.我们可能关注的一个攻击是,攻击者只是通过引诱我到attacker.heroku.com从我的浏览器中收集.heroku.com cookie.但是,他们无法实际使用 cookie,因为cookie是通道绑定到我的浏览器的客户端证书,而不是攻击者的客户端证书.

我们可能关注的另一个攻击是,attacker.heroku.com 在我的用户代理上设置了一个.heroku.com cookie,以便让我自己登录app.heroku.com.同样,假设攻击者获取cookie的唯一方法是从app.heroku.com获取cookie,这意味着他拥有的cookie将通道绑定到他的客户端证书,而不是我的客户端证书 -因此,当我的浏览器将它们发送到app.heroku.com时,它们将无效.

当然,TLS-OBC提案假定客户端证书具有更细粒度的"范围".然而,其原因纯粹是为了防止在不相关的域之间进行跟踪.即使我们使用粗粒度客户端证书和粗粒度(即域)cookie,相关域攻击也已得到缓解.至少,我起初发现这有点违反直觉,因为另一个提议防御它完全禁止粗粒度cookie并使用原始cookie代替.

来自public-web-security@w3.org的批评

TLS-OBC需要考虑许多问题; 我会在这里强调一下我所知道的一对.

1. 某些SSL握手逻辑可能需要稍微修改; 有关技术讨论,请参阅https://bugzilla.mozilla.org/show_bug.cgi?id=681839.

2. 有潜在的隐私考虑; 特别是如果在主秘密协商之前以明文方式发送唯一客户端证书,则被动网络观察者可能能够唯一地识别客户端机器.攻击者已经拥有客户端的IP地址,因此如果在IP地址更改时重新生成证书,这不是一个大问题,但这会使许多身份验证优势无效.建议允许在进行主密钥协商后发送客户端证书.(现在找不到bug,对不起)

3. 关于#2如何解决的一个提议是:http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts

4. 与SPDY有棘手的互动.为此,browserauth.net上会有更新.

Answer 2

您可以在 web.config 中为您的应用程序设置一个唯一的machineKey 。这样，只有该应用程序发出的身份验证 cookie 才能被解密。如果用户访问同一域上的恶意站点，则该其他站点确实可能会添加具有相同名称但不同值的 cookie 身份验证 cookie，但它无法使用您使用的相同机器密钥对其进行加密和签名应用程序，当用户导航回来时，将引发异常。