如何ASP。净或ASP。NET MVC是否受到相关领域cookie攻击的保护?

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.

相关的域cookie攻击(more info)允许相同DNS域中的机器添加额外的cookie，这些cookie也将发送到相同域中的其他计算机。

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?

如何保护ASP。净或ASP。NET MVC受到这种类型的攻击?

One possible attack scenario

一个可能的攻击场景

1. I log into a "secure" web app
2. 我登录了一个“安全”的网络应用
3. I get the credentials for my account
4. 我得到我账户的凭证
5. I trick the user into visiting my site on the same DNS domain
6. 我欺骗用户访问我的站点在相同的DNS域。
7. I insert the cookie (of my creds)
8. 我插入饼干(奶油蛋糕)
9. the user goes back to your app.
10. 用户回到你的应用。
11. Both cookies (or an overwritten one) is sent to the server
12. 两个cookie(或重写的cookie)都被发送到服务器
13. User is doing things under my account
14. 用户在我的账户下做事情

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.

还有很多其他可能的情况……我不是在这里列出所有这些，而是想弄清楚如何保护我的服务器不受这种类型的攻击。

9 个解决方案

#1

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"

以下建议的RFC来自于谷歌员工，它描述了一种客户端使用自签名浏览器证书的方式(因此不需要终端用户出现混淆的“弹出”)，该证书还可以解决被称为“相关域cookie”的cookie安全问题

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.

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

Overview of Channel Bound Cookies

通道绑定cookie的概述。

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.

一旦底层的TLS通道使用TLS客户端身份验证(带有TLS- obc扩展)，服务器就可以将其cookie绑定到TLS通道，方法是将它们与客户端的公钥相关联，并确保这些cookie只在经过公钥(客户端)认证的TLS通道上使用。

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.

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

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.

由服务器决定是否将cookie绑定到TLS通道。如果客户端不支持TLS-OBC，或者即将设置的cookie将跨不同的源使用，那么服务器将不会对该cookie进行通道绑定。如果它决定将cookie绑定在一起，那么它应该将cookie与客户端的公钥联系起来。这类似于RFC 5929，但是客户机将数据绑定到服务器的公钥，在这种情况下，服务器将把数据(cookie)绑定到客户机的公钥。服务器可以通过简单地存储在后台数据库中,一个特定的HTTP会话预计将与某个客户端公钥认证,也可以使用适当的加密编码在饼干本身TLS客户端公钥绑定到饼干。

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).

在上图中,服务器包括客户端的公钥密码地签署了数据结构,还包括身份验证的用户的id。当服务器从客户端接收cookie,它可以确认它确实发布了曲奇饼干(通过检查签名),并验证cookie发送正确的渠道(通过匹配TLS客户机cookie中提到的键的键)。

To be continued here.... http://www.browserauth.net/channel-bound-cookies

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

---

RFC Snip

RFC剪断

TLS Origin-Bound Certificates RFC Draft

TLS的原产地证书RFC草稿

(Excerpt)

(摘录)

4.3. Cookie Hardening

4.3。饼干硬化

One way TLS-OBC can be used to strengthen cookie-based authentication is by "binding" cookies to an origin-bound certificate. The server, when issuing a cookie for an HTTP session, would associate the client's origin-bound certificate with the session (either by encoding information about the certificate unforgeably in the cookie, or by associating the certificate with the cookie's session through some other means). That way, if and when a cookie gets stolen from a client, it cannot be used over a TLS connection initiated by a different client - the cookie thief would also have to steal the private key associated with the client's origin-bound certificate, a task considerably harder especially when we assume the existence of a Trusted Platform Module or other Secure Element that can store the
origin-bound-certificate's private key.

可以使用TLS-OBC增强基于cookie的身份验证的一种方法是将cookie“绑定”到源绑定的证书。服务器在为HTTP会话发出cookie时，会将客户端绑定的证书与会话相关联(或者通过不可饶恕地在cookie中编码关于证书的信息，或者通过其他方法将证书与cookie的会话相关联)。这样,如果一个cookie被盗,从客户机,它不能通过TLS连接使用不同的客户端发起饼干小偷也偷与客户相关联的私钥origin-bound证书,任务相当困难,尤其是当我们假设存在一个可信平台模块或其他安全元素,可以存储origin-bound-certificate的私钥。

---

Additional Commentary from [e-mail]

额外的评论从[e-mail]

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.

另外，请注意，与直觉相反，绑定通道的cookie可以防止许多相关域攻击，即使它们绑定的客户端证书的范围比web源更广。

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.

试想一下，用户代理创建了一个单独的自签名证书，作为TLS客户机证书，用于所有与所有服务器的连接(在隐私方面不是一个好主意，但请跟随我进行这个思想实验)。然后，服务器在各自的*域上设置cookie，但将它们绑定到用户代理的唯一客户端证书。

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.

所以，让我们假设一个app.heroku.com在我的浏览器上设置了一个(频道绑定的)cookie，用于域。heroku.com，并且有攻击者在攻击。我们可能担心的一个攻击是，攻击者通过引诱我攻击来从我的浏览器中获取.heroku.com cookie。但是，他们不能实际使用cookie，因为cookie绑定到浏览器的客户端证书，而不是攻击者的客户端证书。

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.

我们可能关心的另一个攻击是攻击者。heroku.com在我的用户代理上设置了一个.heroku.com cookie，以便让我登录到app.heroku.com。再次,假设攻击者可以获得饼干的唯一方法就是通过让他们从app.heroku.com,这意味着饼干他在他的处置将channel-bound客户机证书,不是我的客户证书,因此当我的浏览器发送到app.heroku.com他们不会有效。

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.

当然，TLS-OBC提议假设客户端证书具有更细粒度的“范围”。然而，这样做的原因纯粹是为了防止跨不相关域的跟踪。即使我们使用粗粒度的客户端证书和粗粒度的(例如域),饼干。至少，我一开始觉得这有点反直觉，因为另一个人提出了辩护，禁止粗粒度的cookie，而是使用原始cookie。

---

Criticism from [e-mail]

批评从[e-mail]

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.

对于TLS-OBC，有许多问题需要考虑;我将在这里突出显示我所知道的一对。

1. Some SSL handshake logic may need to be modified slightly; see https://bugzilla.mozilla.org/show_bug.cgi?id=681839 for technical discussion.

   一些SSL握手逻辑可能需要稍微修改;参见https://bugzilla.mozilla.org/show_bug.cgi?id = 681839技术讨论。

2. 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)

   有潜在的隐私考虑;特别是，如果在主密钥协商之前以明文形式发送唯一的客户端证书，则被动网络观察者可以惟一地标识客户端机器。攻击者将已经拥有客户端的IP地址，因此如果证书在IP地址更改时重新生成，那么这不是一个大问题，但这将抵消大部分认证好处。一项建议，允许在主秘密协商之后发送客户端证书。(现在找不到bug，抱歉)

3. One proposal how #2 could be addressed is here: http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts

   一个建议是如何解决#2的问题:http://tools.ietf.org/html/draft.agl -tls-encryptedclientcerts。

4. There are tricky interactions with SPDY. There will be updates on browserauth.net for this.

   与SPDY的交互比较复杂。这里将会有关于browserauth.net的更新。

#2

Fix the RFCs

修复rfc

The core issue here seems to be that any host can write a cookie that can be overwritten by any other host in the same domain. What if there is a way to write a value to the client that absolutely can not be overwritten by any other host? I haven't found anything like that is also automatically included in the HTTP header (like a cookie)

这里的核心问题似乎是，任何主机都可以编写一个可以被同一域中的任何其他主机覆盖的cookie。如果有一种方法可以向客户端写入任何其他主机都不能覆盖的值，该怎么办?我还没有发现类似的东西也自动包含在HTTP报头中(比如cookie)

Here are three solutions that might work, though I like Solution 2 or #3 if browsers implement it correctly

这里有三种可能有效的解决方案，尽管我喜欢解决方案2或3，如果浏览器正确地实现了它

---

Solution 1: Add more information when uploading cookies to the server

解决方案1:在向服务器上传cookie时添加更多信息

When the client sends cookies to the server, also include the domain of the cookie that was sent. The server then knows what domain and path to look for. This means the client adds a new HTTP header Cookie-Details on every request:

当客户端向服务器发送cookie时，还要包含发送的cookie的域。然后服务器知道要查找的域和路径。这意味着客户端会在每个请求上添加一个新的HTTP标题cookie -详细信息:

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Cookie-Details: name="value":"domain":"path":"IsSecure":"IsHTTPOnly"; name2="value2":"domain2":"path2":"IsSecure":"IsHTTPOnly"
Accept: */*

The server can then ignore the details field, or prefer it over the one that doesn't provide the details. The reason I included the "value" field in the details section is because the server would not be able to tell the difference between two cookies that have the domain set to example.com and secure.example.com if they both cookies have the same name. Most browsers will send the values in a random order.

然后，服务器可以忽略details字段，或者宁愿忽略不提供详细信息的字段。我在details部分中包含“value”字段的原因是，如果两个cookie都有相同的名称，服务器将无法区分两个将域设置为example.com和secure.example.com的cookie。大多数浏览器将以随机顺序发送值。

Perhaps this can be optimized so that the server can tell the client if this new cookie format is supported or not, and the client can respond accordingly.

也许可以对其进行优化，以便服务器能够告诉客户端是否支持这种新的cookie格式，客户端可以相应地做出响应。

---

Solution 2: Extend HTML5 LocalStorage so that data is (optionally) automatically inserted into the HTTP header

解决方案2:扩展HTML5 LocalStorage，使数据(可选地)自动插入到HTTP头中

If we could extend HTML5's LocalStorage to allow a Secure/HTTPOnly data, we can imitate what is done in Solution #1 above, but have the change driven by the HTML5 LocalStorage W3C Working Group

如果我们可以扩展HTML5的LocalStorage以允许一个安全/HTTPOnly数据，我们可以模拟上面的解决方案#1中所做的工作，但是有一个由HTML5 LocalStorage W3C工作组驱动的变化。

The benefit of this is that there is less overhead than solution #1, since the more verbose cookie details are only sent to the server when its needed. In other words if a sensitive value is saved using the "new cookie details" format into LocalStorage, then there is a clear separation of what data needs to be sent, and in what format.

这样做的好处是，与解决方案#1相比，开销更少，因为更详细的cookie细节只在需要时发送给服务器。换句话说，如果使用“新cookie详细信息”格式将敏感值保存到LocalStorage，那么需要发送哪些数据以及以何种格式发送的数据就有了清晰的分离。

---

Solution 3 "Cookie validation"

解决方案3“Cookie验证”

1. A user visits a web app that has this "special" validation mode enabled.
2. 用户访问启用了这种“特殊”验证模式的web应用程序。
3. On the HTTP response some cookies are sent to the browser. The cookies can be HTTP Only, Secure, ...anything)
4. 在HTTP响应中，一些cookie被发送到浏览器。cookie只能是HTTP，安全，等等)
5. A alongside the cookies, another header is sent to the cookies: Set-CookieValidationHash. It contains A JSON array of SHA-256 hashed cookie keys and values, and specifies the expiration of the value
6. 在cookie旁边，另一个header被发送到cookie: Set-CookieValidationHash。它包含SHA-256散列cookie键和值的JSON数组，并指定值的过期时间
7. The browser then logically ties this header to the cookies with the following behavior
   • This header is placed into a "Cookie Validation Jar" that can only be written to by the same DNS Domain, and DNS Scope
   • 这个头被放在一个“Cookie验证Jar”中，该Jar只能由相同的DNS域和DNS范围写入
8. 然后，浏览器在逻辑上将该标头与Cookie绑定到以下行为:将该标头放置到“Cookie验证Jar”中，该“Cookie验证Jar”只能由相同的DNS域和DNS范围写入
9. This header is opaque to the client and is returned to the server on every HTTP request (like a cookie)
10. 该头对客户端不透明，并在每个HTTP请求(如cookie)上返回给服务器
11. The server will use this field to validate the cookies that are sent, and issue an error (or whatever) if the checksum fails.
12. 服务器将使用此字段来验证发送的cookie，并在校验失败时发出错误(或其他错误)。

#3

Sourced from: http://www.w2spconf.com/2011/papers/session-integrity.pdf

来自:http://www.w2spconf.com/2011/papers/session-integrity.pdf

5.2. Integrity through Custom Headers

5.2。完整性通过自定义标题

Instead of securing cookies, we can achieve session integrity by choosing a new method of storing and transmitting session state. While this could be done using special browser plugins like Flash, we would rather choose a design with the fewest dependencies, so we will focus only on basic HTTP tools. The basic form of an HTTP request has very few places that are suitable for sending data with integrity. Data in the URL or entity body of HTTP requests has no integrity, because those parts of the HTTP request are writable across origins and thus spoofable by an attacker. Cookies are also weak in this regard, as they can be overwritten by the attacker in our threat model. However, through the use of a JavaScript API called XMLHttpRequest (XHR), we can send data in a custom header.

我们可以通过选择一种存储和传输会话状态的新方法来实现会话完整性，而不是保护cookie。虽然可以使用特殊的浏览器插件(如Flash)来实现这一点，但我们宁愿选择具有最少依赖关系的设计，因此我们将只关注基本的HTTP工具。HTTP请求的基本形式很少有适合完整地发送数据的地方。HTTP请求的URL或实体体中的数据没有完整性，因为HTTP请求的这些部分是可写的，因此会被攻击者欺骗。在这方面，cookie也很弱，因为在我们的威胁模型中，攻击者可以覆盖它们。但是，通过使用名为XMLHttpRequest (XHR)的JavaScript API，我们可以在自定义头中发送数据。

Background. XMLHttpRequest (XHR) allows HTTP requests containing custom headers to be made, and the responses read, but only to the origin of the executing JavaScript.(See Note5) As a result, requests made via XHR can be distinguished by a server as necessarily originating from the site itself.

背景。XMLHttpRequest (XHR)允许发出包含自定义标头的HTTP请求，并读取响应，但只能发送到正在执行的JavaScript的起点。(请参阅Note5)因此，通过XHR发出的请求可以通过服务器区分，因为这些请求必须来自站点本身。

Design. We will not use cookies at all, and instead pass a session identifying token in a custom HTTP header which is only written via XMLHttpRequest. The server should treat all requests lacking this custom header, or containing an invalid token, as belonging to a new, anonymous session. In order to persist this session identifying token across browser restarts and between different pages of the same application, the token can be stored in HTML5 localStorage by JavaScript upon successful authentication.

设计。我们根本不会使用cookie，而是在一个定制的HTTP报头中传递一个会话标识符，该报头仅通过XMLHttpRequest编写。服务器应该将所有缺少此自定义头或包含无效令牌的请求视为属于新的匿名会话。为了在浏览器重新启动和同一应用程序的不同页面之间持久化此会话标识符，在成功的身份验证之后，该标记可以通过JavaScript在HTML5 localStorage中存储。

Security. Observe that in this model, the session identifying token will only be sent to the origin server, and will not be included in the URL or entity body. These properties provide confidentiality and integrity, respectively. Unlike with cookies, the token cannot be overwritten by the attacker, since localStorage completely partitions data between origins in most browsers (See Note 6). A site using HTTPS can ensure that the token is only sent over HTTPS, thus ensuring the secrecy of the token even in the presence of an active network attacker. In addition, because this token is not sent automatically by the browser, it also serves to protect against CSRF attacks.

安全。请注意，在这个模型中，会话标识令牌将只发送到源服务器，而不会包含在URL或实体主体中。这些属性分别提供了机密性和完整性。与饼干,令牌不能被攻击者,覆盖从localStorage完全分区之间数据起源在大多数浏览器(参见注6)。一个网站使用HTTPS可以确保只有通过HTTPS发送令牌,从而确保保密的令牌,即使在一个活跃的网络攻击者的存在。此外，由于这个令牌不是由浏览器自动发送的，所以它还可以防止CSRF攻击。

Disadvantages. This approach, however, has several disadvantages. First, it requires all requests requiring access to a user’s session to be made using XMLHttpRequest. Merely adding a session identifying token explicitly to all requests, much less doing them over XHR, would require major changes to most existing websites, and would be cumbersome and difficult to implement correctly without a framework. This is even further complicated if requests for sub-resources like images require access to session state, since it is not trivial to load images via XHR. Third, since this design depends on the presence and security of HTML5 localStorage, it will be impossible to implement on some legacy browsers

缺点。然而，这种方法有几个缺点。首先，它要求所有请求都需要使用XMLHttpRequest来访问用户的会话。仅仅为所有请求添加一个明确标识的会话令牌(更不用说通过XHR进行标识)，就需要对大多数现有网站进行重大更改，而且如果没有框架，要正确地实现这些操作将非常麻烦，而且也非常困难。如果对像映像这样的子资源的请求需要访问会话状态，这就更加复杂了，因为通过XHR加载映像是非常重要的。第三，由于这种设计依赖于HTML5 localStorage的存在和安全性，因此在一些遗留浏览器上实现是不可能的

(Note 5) Sites may make cross-site requests using XHR if supported by the browser and authorized by the target server

(注5)站点可以使用XHR进行跨站点请求，如果浏览器支持并得到目标服务器的授权

(Note 6) True in Chrome, Firefox, Safari, and Opera on OS X, several Linux distributions, and Windows 7. Internet Explorer 8 does not partition HTTP and HTTPS, but Internet Explorer 9 does.

(注6)在Chrome、Firefox、Safari和Opera上，在OS X、几个Linux发行版和Windows 7上都是如此。Internet Explorer 8不划分HTTP和HTTPS，但是Internet Explorer 9可以。

#4

Main Points

1. Not give permission for run in the upload directories (an attacker can be from inside).
2. 不允许在上传目录中运行(攻击者可以来自内部)。
3. Get all possible user information's that is connect to the server (cookie is only one).
4. 获取连接到服务器的所有可能的用户信息(cookie只有一个)。
5. Monitor the server and alerts (found/see him, stop him, close the door).
6. 监视服务器并发出警报(发现/看到他，阻止他，关上门)。

Answer to

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.

假设用户上传了一个只有他的帐户才能访问的坏文件;另一个用户则在不知不觉中下载该文件，运行任何可执行的代码。

First of all you must not allow to run anything on your uploaded directories, because even your regular users can upload an aspx page and run it and browse your files. The first step for this is to add on your upload directories this web.config (but also set the permissions to not allow to run anything).

首先，你不能允许在你上传的目录上运行任何东西，因为即使你的常规用户也可以上传一个aspx页面并运行它并浏览你的文件。第一步是在您的上传目录中添加这个web。配置(但也设置了不允许运行任何东西的权限)。

<configuration>
    <system.web>
      <authorization>
        <deny users="*" />
      </authorization>
    </system.web>
</configuration>

relative : I've been hacked. Evil aspx file uploaded called AspxSpy. They're still trying. Help me trap them‼

亲戚:我被黑了。邪恶的aspx文件上传称为AspxSpy。他们仍然努力。帮我‼陷阱

Stealing the cookies

Lets see how we can identify the user.

让我们看看如何识别用户。

1. Cookie
2. 饼干
3. Browser ID
4. 浏览器ID
5. Ip including proxy and forward ips.
6. Ip包括代理和转发Ip。
7. Browser have javascript enable (or not).
8. 浏览器启用(或不启用)javascript。
9. Direct ask for password.
10. 直接询问密码。
11. Other file stored on client.
12. 客户端上存储的其他文件。

Now, for every logged in session, we can connect the first four information's together, and if any of them change we can log him out and ask again to sign in.

现在，对于每一个登录会话，我们可以将前四个信息连接在一起，如果其中任何一个发生了更改，我们可以将他注销并再次请求登录。

Also is critical to connect some how (with a line on the database) the cookie with the logged in status of the user, so if the user log out, no matter if some steal his cookie, not to be able to see the pages - what I mean is the cookie that let him log in must not the only one that we rely on, but also our data to track the status of the user.

也联想到一些至关重要(与上一行数据库)饼干与用户的登录状态,如果用户注销时,无论他偷一些饼干,不能够看到的页面——我的意思是饼干,让他登录必须不是唯一一个依靠,而且我们的数据跟踪用户的状态。

In this case even if some steal the cookie, if the user log out after some actions, the cookie is not useful any more.

在这种情况下，即使一些人偷了cookie，如果用户在某些操作之后退出，cookie就不再有用了。

So what we do is that we connect the cookie+ip+browser id+javascript information's per login, and if any of them change, we not trust him any more, until log in again.

我们所做的就是每次登录时连接cookie+ip+浏览器id+javascript信息，如果其中任何一个改变了，我们就不再信任他，直到再次登录。

Cookies

One cookie is not enough. We need at least two cookies, one that work only on secure pages, and is required to be https secure and one that work on all pages. This two cookies must be connected together and this connection must also be hold on server.

一块饼干是不够的。我们需要至少两个cookie，一个只能在安全页面上工作，并且必须是https安全的，另一个可以在所有页面上工作。这两个cookie必须连接在一起，这个连接也必须保持在服务器上。

So if one of this cookie not exist, or the connection is not match, then user again not have permission and need to log in again (with alert to us)

如果其中一个cookie不存在，或者连接不匹配，那么用户再次没有权限，需要再次登录(警告)

relative: Can some hacker steal the cookie from a user and login with that name on a web site?

相对:某个黑客能从用户那里盗取cookie并在网站上登录吗?

An idea to connect cookies together. With this idea I connect the session cookie with the authentication cookie.

把饼干连在一起的想法。有了这个想法，我将会话cookie与身份验证cookie连接起来。

If all fails

There are some steps (or actions) that a hacker follow (do) when get to a site so be able to gain from this window opportunity and left a back door open.

当黑客进入一个站点时，他们会遵循一些步骤(或操作)，这样就可以从这个窗口机会中获益，并留下一个后门。

1. Create a new administrator account.
2. 创建一个新的管理员帐户。
3. Upload a file to run as browser and executable.
4. 上传一个文件作为浏览器和可执行文件运行。

As I say we never allow to be able to upload a file that can be run, so this is easy. The other to create a new administrator account is the one that we need to add an extra password that is not saved to any cookie, or nether exist anyway on client.

正如我所说，我们从不允许上传可以运行的文件，所以这很简单。另一个创建新的管理员帐户的方法是，我们需要添加一个额外的密码，而不是保存到任何cookie中，或者在客户机上存在。

So for rare actions like, New User from backoffice, change the privilege of the users, delete a user, etc, we need to request a second password every time that only the administrator knows.

因此，对于一些罕见的操作，比如后台的新用户、更改用户权限、删除用户等，我们需要在只有管理员知道的情况下，每次请求第二个密码。

So second password is the final messure.

第二个密码是最终的密码。

One final idea

One idea that I have not made, is to store some how information's on the client other than the cookie, the can not be stolen like the cookies, or even if he can be stolen is hidden somewhere on all the data that is impossible to find it.

我没有做的一个想法是，在客户端上存储一些信息，而不是cookie，不能像cookie一样被偷，即使他可能被偷，也隐藏在所有不可能找到的数据上。

This infomation's can be an extra id of the user together with the cookie, browser data, IP.

这种信息可以是用户的额外id，以及cookie、浏览器数据和IP。

I am thing some possible places but not have tested or try them yet in real life. So this is some placed.

我是一些可能的地方，但在现实生活中没有测试或尝试过。这是某个位置。

1. Custom extension, or plugin, unfortunately different for every browser that have the ability to save data and then we can use them to communicate with the server. This is required action from the user, to install this plugin - and for regular users this can make him afraid and go.
2. 自定义扩展或插件，不幸的是，对于每个有能力保存数据的浏览器来说都是不同的，然后我们可以使用它们与服务器通信。这是用户需要的操作，安装这个插件——对于普通用户来说，这可能会让他害怕并离开。
3. Hidden code inside a good cached image, on the header of it, eg on etag. This also is easy to not work because we can not be sure that the image request to reload...
4. 隐藏的代码在一个好的缓存图像中，在它的头部，如在etag上。这也很容易不工作，因为我们不能确定图像请求要重新加载…
5. Some other browser abilities, eg to read and use a client certificate, that can be used to exchange encrypted data with the server. This request action from the user to install this certificate, and from our part to create them different for every user. Good for bank accounts but not for simple users.
6. 其他一些浏览器功能(如读取和使用客户端证书)可以用来与服务器交换加密数据。此请求将由用户来安装此证书，并从我们的角色中为每个用户创建不同的证书。对银行账户来说很好，但对简单的用户来说就不行了。

So this is my ideas... any critic, or a solution (for how to store small information's on client other than the cookie) is welcome.

这就是我的想法……任何评论家或解决方案(关于如何在客户端上存储除cookie之外的小信息)都是受欢迎的。

Implementation

To make it real secure we need to keep track of the user on the server, and on database. A table that connect the user, with the ip, with the browser id, and other status, like if now is log in or not, is a measure that we can use to take decisions.

为了确保安全，我们需要跟踪服务器和数据库上的用户。一个连接用户、ip、浏览器id和其他状态(比如if now是否登录)的表是我们可以用来做决定的度量。

If not be able to use a database, or not like to make it difficult, then the connection can be bu hashing some data together and check if this hash is the same.

如果不能使用数据库，或者不喜欢使其变得困难，那么连接可以将一些数据合并到一起，并检查这个散列是否相同。

For example we can set a cookie with the hash of (Ip+BrowserID) and check if this much or not.

例如，我们可以设置一个带有(Ip+BrowserID)哈希的cookie，并检查它是否有这么多。

Alerts - Log

All the above they try to be automate. How ever I suggest also to show to the user and to the administrator some information's to diagnose and prevent an attack. This information's can be.

以上这些都是自动化的。我还建议向用户和管理员展示一些信息，以诊断和防止攻击。这个信息的。

To the user

给用户

• Last 10 sign in information's (IP, DateTime, Success or not)
• 信息的最后10个符号(IP, DateTime, Success or not)
• Send email on user about some actions (for high security sites), like log in, log out, critical actions.
• 向用户发送一些操作(对于高安全性站点)的电子邮件，比如登录、注销、关键操作。

To the administrator.

管理员。

• Log and show any fail of the connection on the four parametres Cookie+IP+BroserID+Javascript Enable). The more the fail in short time, the more attention required.
• 日志和显示在四个parametres Cookie+IP+BroserID+Javascript启用的连接失败。失败的时间越短，就越需要关注。
• Check for fail login.
• 检查登录失败。
• Check for page read from user with out cookie enable (or save) and javascript is disabled, because this is how scanner identified from my experience.
• 用out cookie enable(或save)检查从用户读取的页面，并禁用javascript，因为这是扫描程序根据我的经验识别的方式。

#5

Source: Origin Cookies Proposal from Web 2.0 Security and Privacy Conference

源:来自Web 2.0安全和隐私会议的源cookie提案

.

。

6. Session Integrity in Future Browsers Neither of the previous solutions, nor others considered using existing browser technologies, provide sufficient security while remaining deployable for existing sites. Therefore, we propose an extension to cookies called origin cookies. Origin cookies allow existing web applications to secure themselves against the described attacks, with very little complexity of implementation on the part of either the web application or the browser, with transparent backwards compatibility for browsers that do not yet implement origin cookies, including legacy browsers that may never support them, and imposing no burden on existing web sites that have not enabled origin cookies. This is not a trivial problem to solve, as evidenced by existing proposals that fail to meet one or more of the above desired properties. For example, sending the origin of every cookie on each request is one common idea. This is much more complicated than necessary, and imposes a much larger burden on web sites, including ones that don’t even know how to effectively use this information.

6。在未来的浏览器中，无论是以前的解决方案，还是其他考虑使用现有浏览器技术的解决方案，都没有提供足够的安全性，而对现有站点仍可部署。因此，我们建议扩展一个名为“源cookie”的cookie。起源饼干允许现有的web应用程序来保护自己免受所描述的攻击,很少实现的复杂性的web应用程序或者浏览器,与透明的向后兼容的浏览器还没有实现起源饼干,包括遗留的浏览器可能永远支持他们,给现有的web站点,没有负担没有启用起源饼干。这并不是一个需要解决的小问题，因为现有的建议不能满足上述的一个或多个期望属性。例如，向每个请求发送每个cookie的起源是一个常见的想法。这比必要的要复杂得多，并且给web站点带来了更大的负担，包括那些甚至不知道如何有效地使用这些信息的站点。

6.1. Origin Cookies The real problem with using cookies for session management is lack of integrity, specifically due to the ability of other origins to clear and overwrite cookies. While we cannot disable this functionality from cookies without breaking many existing sites, we can introduce new cookie-like functionality that does not allow such cross-site modification.

6.1。在会话管理中使用cookie的真正问题是缺乏完整性，特别是由于其他来源能够清除和覆盖cookie。虽然我们不能在不破坏许多现有站点的情况下禁用cookie功能，但是我们可以引入新的类似cookie的功能，不允许这种跨站点修改。

Design. Origin cookies are cookies that are only sent and only modifiable by requests to and responses from an exact origin. They are set in HTTP responses in the same way as existing cookies (using the Set-Cookie header), but with a new attribute named ‘Origin’. In order to enable web applications to distinguish origin cookies from normal cookies, origin cookies will be sent in an HTTP request in a new header ‘OriginCookie’, while normal cookies will continue to be sent in the existing header ‘Cookie’.

设计。源cookie是只发送的cookie，只能通过请求和来自确切源的响应进行修改。它们以与现有cookie(使用set - cookie头)相同的方式在HTTP响应中设置，但是使用一个名为“Origin”的新属性。为了使web应用程序能够区分源Cookie和普通Cookie，源Cookie将以HTTP请求的形式发送到一个新的标头“OriginCookie”中，而普通Cookie将继续发送到现有标头“Cookie”中。

HTTP/1.1 200 OK
...
Set-Cookie: foo=bar; Origin
...
Fig. 2. An HTTP response setting an origin cookie.
GET / HTTP/1.1
Host: www.example.com
...
Origin-Cookie: foo=bar
...

Fig. 3. An HTTP request to a URI for which an origin cookie has been set.

图3所示。一种HTTP请求，用于设置一个原始cookie的URI。

For example, if in response to a GET request for http://www.example.com/, a response as in Figure 2 is received, then an origin cookie would be set with the key ‘foo’ and the value ‘bar’ for the origin http://www.example.com, and would be sent on subsequent requests to that origin. A subsequent GET request for http://www.example.com/ would look like Figure 3. Requests made to any other origin, even https://www.example.com and http://example.com would be made exactly as if the origin cookie for http://www.example.com was never set. The Origin attribute extending the semantics of Set-Cookie itself is subtle and implies several semantic changes to other settable attributes of cookies. If the Origin attribute is set, the Domain attribute is no longer appropriate, and therefore should be ignored. Similarly, the Secure attribute is no longer appropriate, since it is implied by the scheme of the origin for the cookie: if the scheme is https, the the origin cookie effectively has the attribute – since it will only be sent over a secure channel – and if the scheme is anything else, the cookie does not have the attribute. Because the same-origin policy considers different paths to be part of the same origin, the Path attribute of cookies provides no security and should also be ignored. The semantics of other attributes, such as HttpOnly, Max-Age, Expires, etc. remain unchanged for origin cookies. Normal cookies are uniquely identified by their key, the value of the Domain attribute, and the value of the Path attribute: this means that setting a cookie with a key, Domain, and Path that is already set does not add a new cookie, but instead replaces that existing cookie. Origin cookies should occupy a separate namespace, and be uniquely identified by their key and the full origin that set it. This prevents sites from accidentally or maliciously deleting origin cookies, in addition to the other protections against reading and modifying, and makes server-side use of origin cookies significantly easier.

例如，如果响应http://www.example.com/的GET请求，收到如图2所示的响应，那么源cookie将被设置为key ' foo '和源http://www.example.com的值' bar '，并将在随后的请求中发送到该源。http://www.example.com/的后续GET请求如图3所示。即使是https://www.example.com和http://example.com也会像从未设置http://www.example.com的源cookie一样请求。扩展set - cookie本身语义的origin属性很微妙，它暗示了对其他可设置的cookie属性的一些语义变化。如果设置了Origin属性，则域属性不再合适，因此应该忽略。同样,安全属性不再是合适的,因为它是计划的起源所暗示的饼干:如果该计划是https,原点cookie有效属性,因为它只会送到一个安全的通道,如果该计划是什么,饼干没有属性。由于同源策略认为不同的路径是同一源的一部分，所以cookie的Path属性没有提供任何安全性，也应该被忽略。其他属性(如HttpOnly、Max-Age、Expires等)的语义对于源cookie保持不变。普通cookie是通过它们的键、域属性的值和Path属性的值唯一标识的:这意味着使用已设置的键、域和路径设置cookie并不添加新的cookie，而是替换现有的cookie。起源cookie应该使用一个单独的名称空间，并通过它们的键和设置它的完整起源惟一地标识出来。这可以防止站点意外或恶意地删除源cookie，以及其他防止读取和修改的保护，并使服务器端更容易使用源cookie。

Security. Because origin cookies are isolated between origins, the additional powers of the related-domain attacker and active network attacker in overwriting cookies are no longer effective, since they were specifically exploiting the lack of origin isolation with existing cookies, whether the ‘confusion’ was due to the scheme or domain of the origin. Absent these additional powers, the related-domain attacker and active network attacker are equivalent to the web attacker, who cannot break the security of existing session management based on the combination of cookies and secret tokens.

安全。起源饼干之间是隔离的起源,因为额外的权力相关领域攻击和主动攻击者在网络覆盖曲奇不再有效,因为他们是专门利用缺乏起源的隔离与现有饼干,是否“混乱”是由于计划或域原点。如果没有这些附加功能，相关域攻击者和活动网络攻击者相当于web攻击者，后者不能基于cookie和秘密令牌的组合来破坏现有会话管理的安全性。

Implementation. Integrating origin cookies into existing browsers will not involve significant modifications. As a proof of concept, we implemented origin cookies in Chrome. The patch totals only 573 lines

实现。将源cookie集成到现有浏览器中不会涉及重大修改。作为概念的证明，我们在Chrome中实现了源cookie。补丁总共只有573行

#6

Source: W3C Mailing Lists

来源:W3C邮件列表

IETF TLS working group has a proposal to bind cookies to TLS client certificates, so as long as the private key corresponding to the cert is only on one machine, the cookie can only be used on one machine.

IETF TLS工作组建议将cookie绑定到TLS客户端证书，因此只要与cert对应的私钥仅在一台机器上，那么cookie只能在一台机器上使用。

If you want to emulate the TLS client cert approach, you could use localStorage to store a private key, and use JS crypto 1 to replace document.cookie with a signed version. It's a little clunky, but it might be made to work. (Obviously, would be better with web crypto 2)

如果希望模拟TLS客户机cert方法，可以使用localStorage来存储一个私钥，并使用JS crypto 1替换文档。带有签名版本的cookie。它有点笨重，但它可能是用来工作的。(显然，使用web crypto 2会更好)

1 for example: http://www.ohdave.com/rsa/

例如:http://www.ohdave.com/rsa/

2 http://www.w3.org/community/webcryptoapi/

2 http://www.w3.org/community/webcryptoapi/

#7

From http://www.codeproject.com/Articles/16645/ASP-NET-machineKey-Generator

从http://www.codeproject.com/Articles/16645/ASP-NET-machineKey-Generator

Whenever you make use of ViewState, Session, Forms authentication, or other encrypted and/or secured values, ASP.NET uses a set of keys to do the encryption and decryption. Normally, these keys are hidden and automatically generated by ASP.NET every time your application recycles

当您使用ViewState、会话、窗体身份验证或其他加密和/或安全值时，ASP。NET使用一组密钥来进行加密和解密。通常，这些键是隐藏的，由ASP自动生成。在每次应用程序回收时使用NET

If the two websites are different web applications, by default they will have different keys so one will not be able to read encrypted tokens generated by the other. The exception to this is if they are using common values in a global web.config or machine.config.

如果这两个网站是不同的web应用程序，默认情况下，它们将具有不同的密钥，因此其中一个无法读取另一个生成的加密令牌。例外的情况是，它们在全局web中使用公共值。配置或machine.config。

From machineKey Element, decryptionKey: http://msdn.microsoft.com/en-us/library/w8h3skw9.aspx

来自machineKey元素，decryptionKey: http://msdn.microsoft.com/en-us/library/w8h3skw9.aspx

AutoGenerate, IsolateApps Specifies that the key is automatically generated. This is the default value. The AutoGenerate modifier specifies that ASP.NET generates a random key and stores it in the Local Security Authority (LSA). The IsolateApps modifier specifies that ASP.NET generates a unique encrypted key for each application using the application ID of each application.

AutoGenerate、IsolateApps指定密钥是自动生成的。这是默认值。自动生成修饰符指定ASP。NET生成一个随机密钥并将其存储在本地安全权限(LSA)中。IsolateApps修改器指定这个ASP。NET使用每个应用程序的应用程序ID为每个应用程序生成一个惟一的加密密钥。

So unless the machineKey element is being used to set the decryptionKey at a global level, the method you described should not work. If it is set, you could override at application level using the web.config file.

因此，除非使用machineKey元素在全局级别设置解密密钥，否则您所描述的方法不应该工作。如果设置了，您可以使用web在应用程序级别上重写。配置文件。

#8

You could set a unique machineKey in the web.config for your application. This way only authentication cookies emitted by that application can be decrypted. If the user visits a malicious site on the same domain, this other site might indeed add an cookie authentication cookie with the same name but different value, but it won't be able to encrypt and sign it with the same machine key used by your application and when the user navigates back an exception will be thrown.

您可以在web中设置一个唯一的machineKey。为您的应用程序配置。通过这种方式，只能对应用程序发出的身份验证cookie进行解密。如果用户访问恶意网站在同一领域,这确实其他网站可能会添加一个cookie验证cookie的名称相同但不同的值,但它无法用同一台机器关键加密和签名所使用的应用程序,当用户导航回就会抛出一个异常。

#9

The answer is simple: Always bind sessions to a specific client IP (this should be done in any modern web application anyway) and do not use cookies for any other purpose.

答案很简单:始终将会话绑定到特定的客户端IP(无论如何，在任何现代web应用程序中都应该这样做)，并且不要将cookie用于任何其他目的。

Explanation: you always send a single SESSIONID cookie back to the client, which holds no information - its just a very long random string. You store the SESSIONID along with the authenticated user IP within your webapps scope - like i.e. the database. Although the related cookie attack can be used to swap SESSIONID cookies around between different clients, no client can ever masquerade as another user or perform any actions, as the SESSIONID is only considered valid and the privileges are only granted, if its send from the associated IP address.

说明:您总是将一个单独的SESSIONID cookie发送回客户端，该客户端没有任何信息——它只是一个非常长的随机字符串。您将SESSIONID与经过身份验证的用户IP一起存储在webapps范围内——比如数据库。尽管相关的cookie攻击可以用来在不同的客户机之间交换SESSIONID cookie，但是任何客户端都不能伪装成另一个用户或执行任何操作，因为SESSIONID只被认为是有效的，并且只有当它从关联的IP地址发送时才被授予特权。

As long as you do not store actual data which is considered private into the cookie itself, but into the session state on the server side (which is selected solely by the SESSIONID cookie) the related cookie problem should be no problem for you.

只要您不将被视为私有的实际数据存储到cookie本身中，而是存储到服务器端会话状态(仅由SESSIONID cookie选择)中，那么相关的cookie问题对您来说应该没有问题。