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>

httpCookie与Cookie安全的更多相关文章

  1. asp.net中HttpCookie操作cookie的方法

    微软对HttpCookie的定义为"提供创建和操作各 HTTP Cookie 的类型安全方法." HttpCookie的构造函数一共有两个 1.HttpCookie(String) ...

  2. safari cookie设置中文失败

    最近用H5进行手机端开发,由于是window操作系统,为了方便开发和调试,直接在chrome浏览器上进行测试,然后在android机上进行手机端测试,当功能基本完工后,原来在android上运行正常的 ...

  3. 【.NET】Cookie操作类

    public static class CookiesHelper { /// <summary> /// Cookies赋值 /// </summary> /// <p ...

  4. asp.net,cookie,写cookie,取cookie

    Cookie是一段文本信息,在客户端存储 Cookie 是 ASP.NET 的会话状态将请求与会话关联的方法之一.Cookie 也可以直接用于在请求之间保持数据,但数据随后将存储在客户端并随每个请求一 ...

  5. 细说Cookie

    阅读目录 开始 Cookie 概述 Cookie的写.读过程 使用Cookie保存复杂对象 Js中读写Cookie Cookie在Session中的应用 Cookie在身份验证中的应用 Cookie的 ...

  6. .NET的Cookie相关操作

    using System; using System.Collections.Generic; using System.Text; using System.Web; namespace Comm ...

  7. asp.net各种cookie代码和解析

    Cookie是一段文本信息,在客户端存储 Cookie 是 ASP.NET 的会话状态将请求与会话关联的方法之一.Cookie 也可以直接用于在请求之间保持数据,但数据随后将存储在客户端并随每个请求一 ...

  8. [转]ASP.Net篇之Session与Cookie

    本文转自:http://www.cnblogs.com/japanbbq/archive/2011/08/31/2160494.html Session: Session是“会话”的意思,然而,因为h ...

  9. C# Cookie工具类

    /// <summary> /// Cookies赋值 /// </summary> /// <param name="strName">主键& ...

随机推荐

  1. 在VMWare中建立Hadoop虚拟集群的详细步骤(使用CentOS)

    最近在学习Hadoop,于是想使用VMWare建立一个虚拟的集群环境.网上有很多参考资料,但参照其步骤进行设置时却还是遇到了不少问题,所以在这里详细写一下我的配置过程,以及其中遇到的问题及相应的解决方 ...

  2. Eclipse代码格式化规范

    附件()是Eclipse代码格式文件,根据以下步骤导入到Eclipse中,帮助规范代码格式. 导入步骤:1. Window -> Performances2. Java -> Code S ...

  3. 《Entity Framework 6 Recipes》中文翻译系列 (6) -----第二章 实体数据建模基础之使用Code First建模自引用关系

    2-5 使用Code First建模自引用关系 问题 你的数据库中一张自引用的表,你想使用Code First 将其建模成一个包含自关联的实体. 解决方案 我们假设你有如图2-14所示的数据库关系图的 ...

  4. js中的DOM事件与对象

    概念图 document.getElementById("bb"); 根据id找到bb,只能找一个哦 var aa = document.getElementById(" ...

  5. Android开发学习之路-让注解帮你简化代码,彻底抛弃findViewById

    本文主要是记录注解的使用的学习笔记,如有错误请提出. 在通常的情况下,我们在Activity中有一个View,我们要获得这个View的实例是要通过findViewById这个方法,然后这个方法返回的是 ...

  6. Java内部类的定义和使用

    为什么要用到内部类: 在java开发学习中我们经常会碰到内部类.内部类又有很多的优势:首先举一个简单的例子,如果你想实现一个接口,但是这个接口中的一个方法和你构想的这个类中的一个方法名称参数相同,你应 ...

  7. SQL Server中使用Check约束提升性能

        在SQL Server中,SQL语句的执行是依赖查询优化器生成的执行计划,而执行计划的好坏直接关乎执行性能.     在查询优化器生成执行计划过程中,需要参考元数据来尽可能生成高效的执行计划, ...

  8. Windows phone重写返回键

    protected override void OnBackKeyPress(System.ComponentModel.CancelEventArgs e) {//需要设置这个属性 e.Cancel ...

  9. [转]浏览器退出之后php还会继续执行么?

    原文链接:http://www.cnblogs.com/yjf512/p/5362025.html 前提:这里说的是典型的lnmp结构,nginx+php-fpm的模式 如果我有个php程序执行地非常 ...

  10. 前端学PHP之变量

    × 目录 [1]变量定义 [2]关键字 [3]变量赋值[4]可变变量[5]变量函数 前面的话 变量是用于临时存储值的容器.这些值可以是数字.文本,或者复杂得多的排列组合.变量在任何编程语言中都居于核心 ...