问题描述
RFC 片段
(摘录)
4.3.Cookie 强化
TLS-OBC 可用于加强基于 cookie 的一种方式认证是通过绑定"进行的cookie 到起源绑定证书.服务器，当为 HTTP 发出 cookie 时会话，将客户端的原始绑定证书与会话(通过编码有关证书的信息不可伪造地在 cookie 中，或通过将证书与cookie 的会话通过其他方式).这样，如果和当 cookie 从客户端被盗时，它不能被使用由不同客户端发起的 TLS 连接 - cookie 窃贼还必须窃取与客户的原始绑定证书，这是一项相当困难的任务特别是当我们假设存在可信平台时可以存储
的模块或其他安全元件origin-bound-certificate 的私钥.
另外，请注意，有点违反直觉，通道绑定 cookie 可以防止许多相关域攻击，即使它们绑定的客户端证书的范围比网络源更广.
想象一下，一个用户代理创建了一个自签名证书，它用作所有服务器的所有连接的 TLS 客户端证书(就隐私而言，这不是一个好主意，但请跟我来这个思想实验).然后，服务器在各自的顶级域上设置 cookie，但将它们通过通道绑定到用户代理的唯一客户端证书.
因此，假设应用程序 app.heroku.com 在我的浏览器上为域 .heroku.com 设置了一个(通道绑定的)cookie，并且存在攻击者 atattack.heroku.com.我们可能会担心的一种攻击是，攻击者只是通过引诱我访问attacker.heroku.com 来从我的浏览器中获取.heroku.com cookie.然而，他们实际上无法使用cookie，因为cookie是绑定到我的浏览器客户端证书的通道，而不是攻击者的客户端证书.>
我们可能担心的另一种攻击是attacker.heroku.com 在我的用户代理上设置一个.heroku.com cookie，以便让我以他自己的身份登录app.heroku.com.同样，假设攻击者获取 cookie 的唯一方法是从 app.heroku.com 获取它们，这意味着他可以使用的 cookie 将通过通道绑定到他的客户端证书，而不是我的客户端证书 - 因此当我的浏览器将它们发送到 app.heroku.com 时，它们将无效.
当然，TLS-OBC 提案假设了更细粒度的范围".对于客户端证书.然而，这样做的原因纯粹是为了防止跨不相关的域进行跟踪.即使我们使用粗粒度客户端证书和粗粒度(即域)cookie，相关域攻击也已经得到缓解.至少，我一开始发现这有点违反直觉，因为另一个人提议防御它完全禁止粗粒度 cookie 并使用原始 cookie.
TLS-OBC 需要考虑许多问题；我将在这里重点介绍一些我知道的.
部分SSL握手逻辑可能需要稍微修改；参见 https://bugzilla.mozilla.org/show_bug.cgi?id=681839 用于技术讨论.
存在潜在的隐私考虑；特别是如果在协商主密钥之前以明文形式发送唯一客户端证书，则被动网络观察者可能能够唯一地识别客户端机器.攻击者已经拥有客户端的 IP 地址，因此如果在 IP 地址更改时重新生成证书，这不是一个大问题，但这会抵消大部分身份验证优势.允许在进行主密钥协商后发送客户端证书的提议.(暂时找不到bug，抱歉)
如何解决 #2 的一个建议在这里:https://datatracker.ietf.org/doc/html/draft-agl-tls-encryptedclientcerts
与 SPDY 之间存在棘手的互动.browserauth.net 上会有更新.
The related domain cookie attack (more info) allows machines in the same DNS domain to add additional cookies that will also be sent to other computers in the same domain.
This can cause issues with authentication, or at worst be a component in a confused deputy attack.
Question
How can I protect ASP.NET or ASP.NET MVC from this type of attack?
One possible attack scenario
- I log into a "secure" web app
- I get the credentials for my account
- I trick the user into visiting my site on the same DNS domain
- I insert the cookie (of my creds)
- the user goes back to your app.
- Both cookies (or an overwritten one) is sent to the server
- User is doing things under my account
That is a simplified example, but the idea can be ported other style of attacks, Im just picking the scenario that doesn't seem "too bad".
One idea how it can "get bad" is if this was step 1 of a two-step attack. Suppose the user uploaded a bad file that was accessible only in his account; the other user then unwittingly downloads that file, running any executable code that is there.
There are a ton of other scenarios that are possible... rather than list them all here I'm trying to figure out how I can protect my server from this type of attack.
Channel Bound Cookies
The following Proposed RFC comes from a Google employee and describes a way for Clients use a self-signed Browser Certificate (thus requiring no confusing "pop-up" for the end user) which can also address the cookie security issue known as "Related Domain Cookies"
What follows below is an extract of http://www.browserauth.net/ , a section of the RFC, some interesting commentary, and some criticism on this extension.
Overview of Channel Bound Cookies
Once the underlying TLS channel uses TLS client authentication (with the TLS-OBC extension), the server can bind its cookies to the TLS channel by associating them with the client's public key, and ensuring that the cookies are only ever used over TLS channels authenticated with that public (client) key.
This means that if such a channel-bound cookie is ever stolen off a client's machine, that cookie won't be able to authenticate an HTTP session to the server from other machines. This includes man-in-the-middle attackers that inject themselves into the connection between client and server, perhaps by tricking users into clicking through certificate-mismatch warnings: such a man-in-the-middle will have to generate its own TLS session with the server, which won't match the channel that the cookie is bound it.
Channel Binding
It's up to the server to decide whether to bind cookies to TLS channels. If the client doesn't support TLS-OBC, or if the cookie it's about to set will be used across different origins, then the server will not channel-bind the cookie. If it does decide to channel-bind the cookie, it should associate the cookie with the client's public key. This is similar to RFC 5929, but instead of the client binding data to the server's public key, in this case the server would be binding data (the cookie) to the client's public key. The server can do this either by simply storing, in a backend database, the fact that a certain HTTP session is expected to be authenticated with a certain client public key, or it can use suitable cryptography to encode in the cookie itself which TLS client public key that cookie is bound to.
In the figure above, the server includes the client's public key into a cryptographically signed datastructure that also includes the authenticated user's id. When the server receives the cookie back from the client, it can verify that it indeed issued the cookie (by checking the signature on the cookie), and verify that the cookie was sent over the correct channel (by matching the TLS client key with the key mentioned in the cookie).
To be continued here.... http://www.browserauth.net/channel-bound-cookies
RFC Snip
Also, note that somewhat counter-intuitively, channel-bound cookies protect against many related-domain attacks even if the client cert that they are bound to has broader scope than a web origin.
Imagine, for a moment, that a user-agent creates a single self-signed certificate that it uses as a TLS client cert for all connections to all servers (not a good idea in terms of privacy, but follow me along for this thought experiment). The servers then set cookies on their respective top-level domains, but channel-bind them to the user-agent's one-and-only client cert.
So, let's say that an app app.heroku.com sets a (channel-bound) cookie on my browser for domain .heroku.com, and that there is an attacker on attacker.heroku.com. One attack we might be concerned about is that the attacker simply harvests the .heroku.com cookie from my browser by luring me to attacker.heroku.com. They won't be able to actually use the cookie, however, because the cookie is channel-bound to my browser's client cert, not to the attacker's client cert.
Another attack we might be concerned about is that attacker.heroku.com sets an .heroku.com cookie on my user agent in order to make me log into app.heroku.com as himself. Again, assuming that the only way the attacker can obtain the cookies is by getting them from app.heroku.com, this means that the cookies he has at his disposal will be channel-bound to his client cert, not to my client cert - thus when my browser sends them to app.heroku.com they won't be valid.
The TLS-OBC proposal, of course, assumes more fine-grained "scopes" for the client certificates. The reason for that, however, is purely to prevent tracking across unrelated domains. Related-domain attacks are already mitigated even if we used coarse-grained client certificates and coarse-grained (i.e., domain) cookies. I, at least, found this a little counter-intuitive at first, since the other proposed defense it to forbid coarse-grained cookies altogether and use origin cookies instead.
There are a number of issues that need to be considered for TLS-OBC; I'll highlight a couple here that I'm aware of.
Some SSL handshake logic may need to be modified slightly; see https://bugzilla.mozilla.org/show_bug.cgi?id=681839 for technical discussion.
There are potential privacy considerations; in particular if the unique client certificate is sent in cleartext before the negotiation of the master secret, a passive network observer may be able to uniquely identify a client machine. The attacker would already have the client's IP address, so this isn't a huge problem if the certificate is regenerated on an IP address change, but that would nullify much of the authentication benefit. A proposal to allow a client certificate to be sent after the master secret negotiation has been made. (can't find the bug right now, sorry)
One proposal how #2 could be addressed is here: https://datatracker.ietf.org/doc/html/draft-agl-tls-encryptedclientcerts
There are tricky interactions with SPDY. There will be updates on browserauth.net for this.
这篇关于如何保护 ASP.NET 或 ASP.NET MVC 免受相关域 cookie 攻击?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！