httpCookie与Cookie安全
Web 应用程序使用的 Cookie
个人认为这里设置的cookie与访问cookie的安全性关联大一点，配置节如下
<httpCookies domain="String" httpOnlyCookies="true|false" requireSSL="true|false" />
httpOnlyCookies：默认是false，作用是是否禁用浏览器脚本访问cookie。在Form认证时会颁发一个认证票写在cookie，最开始我以为这里设置了则可以访问，结果并不是，个人推断是这个配置节的设置和Form节点里的配置无关。
下面来弄个测试一下代码
服务端添加代码
Response.SetCookie(new HttpCookie("testcookie", "test"));
浏览器端添加脚本
$(function myfunction() { alert(document.cookie); });
如无意外运行结果
接着把httpOnlyCookies设成true
<httpCookies httpOnlyCookies="true" />
运行结果
另外HttpCookie类中有个属性是HttpOnly,把它设成true,结果一样如上图所示，空的，估计在验证票中的cookie也是把HttpOnly设成了true,使得就算在配置中设置了仍然无效
Response.SetCookie(new HttpCookie("testcookie", "test") { HttpOnly=true});
查看源码得知生成验证票的代码中FormsAuthentication.GetAuthCookie方法生成HttpCookie
下面一篇摘自MSDN的老外文章说的就是跨站点脚本攻击的，记忆中好像看蒋金楠老师的《ASP.NET MVC 4 框架揭秘》也提到过相关的东西，现在看就更明白他说得是啥了，只不过文章比较旧了，老是在提IE6 SP1升级了啥啥啥。
Mitigating Cross-site Scripting With HTTP-only Cookies
One of the more common security problems plaguing（脆弱的） Web servers is cross-site scripting. Cross-site scripting is a server-side vulnerability（漏洞） that is often created when rendering user input as HTML. Cross-site scripting attacks can expose sensitive information about the users of the Web site. In order to help mitigate the risk of cross-site scripting, a new feature has been introduced in Microsoft Internet Explorer 6. This feature is a new attribute for cookies which prevents them from being accessed through client-side script. A cookie with this attribute is called an HTTP-only cookie. Any information contained in an HTTP-only cookie is less likely to be disclosed to a hacker or a malicious Web site. The following example is a header that sets an HTTP-only cookie.
Set-Cookie: USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly
This topic briefly explains cross-site scripting, the potential risk of a cookie that can be accessed through script, and how this risk has been mitigated by HTTP-only cookies in Internet Explorer 6 Service Pack 1 (SP1).
Cross-site Scripting
Cross-site scripting is a common server-side vulnerability which allows a hacker to trick a user into disclosing sensitive information that is normally reserved for a specific Web site. The various steps of a cross-site scripting attack can best be explained with a simple example.
An Example of Cross-site Scripting
To understand how cross-site scripting is typically exploited, consider the following hypothetical example.
The A. Datum Corporation runs a Web site that allows you to track the latest price of your stock portfolio. To add a friendly touch, after logging in to the A. Datum Web site, you are redirected to www.adatum.com/default.asp?name=Brian and a server-side script generates a welcome page that says "Welcome Back Brian!". The stocks in your portfolio are stored in a database, and the Web site places a cookie on your computer containing a key to that database. The cookie is retrieved anytime you visit the A. Datum Web site.
A hacker realizes that the A. Datum Web site suffers from a cross-site scripting bug and decides to exploit this to gather some information about you that you'd rather not disclose; the names of the stocks in your portfolio. The hacker sends you an e-mail that claims you've just won a vacation getaway and all you have to do is "click here" to claim your prize. The URL for the hypertext link iswww.adatum.com/default.asp?name=<script>evilScript()</script>. When you click this link, the Web site tries to be friendly by greeting you, but instead displays, "Welcome Back !". What happened to your name? By clicking the link in the e-mail, you've told the A. Datum Web site that your name is <script>evilScript()</script>. The Web server generated HTML with this "name" embedded and sent it to your browser. Your browser correctly interprets this as script, and because client-side script is typical browser functionality, runs the script without prompting you. If this script instructs the browser to send a cookie containing your stock portfolio to the hacker's computer, it quickly complies. After all, the instruction came from the A. Datum Web site which owns that cookie.
The following image demonstrates this concept visually by showing the process in five steps. First, the user clicks a link embedded in e-mail from the hacker (step 1). This generates a request to a Web site (step 2) which, because of a cross-site scripting bug, complies with the request and sends malicious script back to the user's browser (step 3). The script host executes the malicious code (step 4) and sends the sensitive data to the hacker's computer (step 5).
There are many variations on this example of cross-site scripting. For more examples and further details see Cross-site Scripting.
Protecting Data with HTTP-only Cookies
To mitigate the risk of information disclosure with a cross-site scripting attack, a new attribute is introduced to cookies for Internet Explorer 6 SP1. This attribute specifies that a cookie is not accessible through script. By using HTTP-only cookies, a Web site eliminates the possibility that sensitive information contained in the cookie can be sent to a hacker's computer or Web site with script.
A cookie is set on the client with an HTTP response header. The following example shows the syntax used in this header.
Set-Cookie: <name>=<value>[; <name>=<value>]
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]
Note The HttpOnly attribute is not case sensitive.
If the HttpOnly attribute is included in the response header, the cookie is still sent when the user browses to a Web site in the valid domain. The cookie cannot be accessed through script in Internet Explorer 6 SP1, even by the Web site that set the cookie in the first place. This means that even if a cross-site scripting bug exists, and the user is tricked into clicking a link that exploits this bug, Windows Internet Explorer does not send the cookie to a third party. The information is safe.
Note The use of HTTP-only cookies is one of several techniques that, when used together, can mitigate the risk of cross-site scripting. Used alone, it cannot completely eliminate the danger of cross-site scripting.
Browser Support for HTTP-only Cookies
If a Web site sets an HTTP-only cookie on a browser that does not support HTTP-only cookies, the cookie is either ignored or downgraded to a traditional, scriptable cookie. This leaves information vulnerable to attack for users of some browsers.
For a company intranet Web page, administrators could require the use of a browser that recognizes HTTP-only cookies for all users. This ensures that information is not disclosed with a cross-site scripting bug.
For a public Web site where it is important to support multiple browsers, consider using client-side script to determine the browser version for each visitor. The Web site can restrict sensitive information to visitors using browsers that mitigate cross-site scripting attacks for cookies. Visitors with browsers that do not support HTTP-only cookies can be given limited information or functionality along with a request to upgrade their software.
When determining the browser version of Internet Explorer, it is important to keep in mind that the user agent string for Internet Explorer 6 SP1 is identical to the user agent string for Internet Explorer 6. Client-side script must also check the minor version number with theappMinorVersion property of the navigator object to determine whether Internet Explorer 6 SP1 is installed.
