HttpCookie and Cookie security, httpcookiecookie

HttpCookie and Cookie security, httpcookiecookie

Cookie used by Web Applications

I personally think that the cookie set here is more closely related to the security of the access cookie. The configuration section is as follows:

HttpOnlyCookies: The default value is false, which indicates whether to disable cookie Access by browser scripts. During Form authentication, an authentication ticket will be issued in the cookie. At first I thought it was accessible if it was set here. The result is not, I personally infer that the configuration in this configuration section is irrelevant to the configuration in the Form node.
Let's test the code.
Add code on the server
Response.SetCookie(new HttpCookie("testcookie", "test"));
Add a script to the browser
$(function myfunction() {alert(document.cookie);}); 
Without unexpected running results

Set httpOnlyCookies to true.
Running result

In addition, the HttpCookie class has an attribute HttpOnly, which is set to true, as shown in the result. If it is null, it is estimated that the cookie in the verification ticket also sets HttpOnly to true, this makes the configuration still invalid.
Response.SetCookie(new HttpCookie("testcookie", "test") { HttpOnly=true});
View the source code. The FormsAuthentication. GetAuthCookie method is used to generate an HttpCookie.

 

The following is an article from a foreigner in MSDN that describes cross-site scripting attacks. In my memory, it seems that I have read ASP from instructor Jiang Jinnan. net mvc 4 Framework secrets also mentioned related things. Now I can better understand what he said, but the article is old, i'm always talking about IE6 SP1 upgrades.
Mitigating Cross-site Scripting With HTTP-only Cookies
One of the more common security problems plaguing (fragile) Web servers is cross-site scripting. cross-site scripting is a server-side vulnerability (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 
    
 
     
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 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. 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. 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. datum Web site.
A hacker realizes that. 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. a Datum.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. 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. 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 permitted 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]
NoteThe HttpOnly attribute is not case sensitive.
If the HttpOnly attribute is wrongly ded 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.
NoteThe 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 cocould 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.

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