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.
來自 <https://msdn.microsoft.com/zh-CN/Library/ms533046.aspx>
