HttpCookie and Cookie Security

Cookies used by WEB applications

Personally, the cookie set here is more relevant to the security of the access cookie, and the configuration section is as follows

<domain= "String"  httponlycookies= "True|false"  requireSSL= "True|false"/>

httponlycookies: The default is False, which is whether the browser script access cookie is disabled. In the form of certification will be issued a certification ticket written in the cookie, at first I thought it was set up to be accessible, the result is not, the personal inference is that the configuration section settings and the configuration of the form node is irrelevant.

Let's get a test code here.

Add code to the service side

Response.setcookie (new HttpCookie ("testcookie""test" ));

Browser-side Add script

$ (function  myfunction () {alert (document.cookie);});

If no unexpected results are run

Then set the Httponlycookies to true.

< httpcookies httponlycookies = "true" />

Run results

also HttpCookie class has a property is HttpOnly, set it to true, the result is as shown, empty, the estimate of the cookie in the validation ticket is also the HttpOnly set to true, so that even if the configuration is still invalid

Response.setcookie (new HttpCookie ("testcookie""test  ") {httponly=true});

Check the source code that generates a validation ticket in the Formsauthentication.getauthcookie method generated HttpCookie

The following article from MSDN on the Foreigner article is said to cross-site scripting attack, memory as if to see Jing Jinnan Teacher's "ASP. NET MVC 4 framework revealed" also mentioned related things, now see more understand what he said, but the article is older, always in mention IE6 SP1 upgrade what what.

Mitigating Cross-site Scripting with http-only Cookies

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 have been mitigated by http-only Cookie in Internet Explorer 6 Service Pack 1 (SP1).

• Cross-site Scripting
  • An Example of Cross-site Scripting
• Protecting Data with Http-only Cookies
• Browser Support for Http-only Cookies
• Related Topics

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's normally reserved for a specific Web site. The various steps of a cross-site scripting attack can best being explained with a simple example.

An Example of Cross-site Scripting

To understand how cross-site scripting is typically exploited, consider the following hypothetical.

the A. Datum Corporation runs a Web site, that allows, 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 B Ack brian! ". The stocks in your portfolio is 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 bugs and decides to exploit this to gather Some information about you ' d rather not disclose; The names of the stocks in your portfolio. The hacker sends you a e-mail that claims you ' ve just won a vacation getaway and all of you has to do are "click here" to CL Aim your prize. The URL for the Hypertext Link iswww.adatum.com/default.asp?name=<script>evilscript () </script>. When you click on this link, the Web site tries is friendly by greeting and 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 () &lt ;/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 th e 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 bugs, complies with the request an D 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 is 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 are introduced to cookies S for Internet Explorer 6 SP1. This attribute specifies, a cookie is the not accessible through script. By using http-only cookies, a Web site eliminates the possibility that sensitive information contained in the cookie can B E 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 a case sensitive.

If the HttpOnly attribute is included in the header of the response, the cookie is still sent when the user browses to a Web site In the valid domain. The cookie cannot is accessed through script in Internet Explorer 6 SP1, even by the WEB site that set the cookie in the F Irst Place. This means, even if a cross-site scripting bug exists, and the user was tricked into clicking a link to exploits this Bug, Windows Internet Explorer does not send the cookies to a third party. The information is safe.

Note The use of http-only cookies are one of several techniques that, when used together, can mitigate the risk of Cross-site SC Ripting. 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 in 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 cookie for a ll users. This ensures, information is not the 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 Visito R. The Web site can restrict sensitive information to visitors using browsers that mitigate Cross-site scripting attacks F or cookies. Visitors with browsers this do not support http-only cookie can be given limited information or functionality along with A request to upgrade their software.

When determining the browser version of Internet Explorer, it's important to keep on 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.

from <https://msdn.microsoft.com/zh-CN/Library/ms533046.aspx>

HttpCookie and Cookie Security