Cookie安全漫谈（转）

add by zhj: 我也赞成做者的观点，JavaScript 操做 Cookie 是一种不正常的作法；能够用 JavaScript 操做 Cookie 完成的功能，同样能够在服务端来完成。

js操做cookie会带来的风险，好比xss，用户篡改cookie等。在django的csrf防护机制中，模板中的表单，若是是post请求，都要加上{%csrf_token%}标签，

这其实就是在服务端从cookie中取出csrftoken，而后给表单增长一个隐藏input，name="crsrmiddlewaretoken" value="{{ csrf_token }}"，这个

变量csrf_token=request.COOKIES['csrftoken']。另外，在模板的js代码中，也支持渲染时传入的变量，因此django的csrf防护机制中，当发送ajax时，要

加x-csrftoken这个header，能够在渲染模板时传入request.COOKIES['csrftoken']给x-csrftoken，从而就不用在前端js获取cookie去赋值了。

正如做者所说，js在前端操做cookie能完成的事，经过request.COOKIES均可以在服务端完成。因此设置cookie时建议使用httponly=true

 

须要注意两点：

1. views.py中返回的函数中的值要用 json.dumps()处理

2. 在网页上要加一个 safe 过滤器。

views.py

# -*- coding: utf-8 -*-
 
from __future__ import unicode_literals
 
import json
from django.shortcuts import render
 
def home(request):
    List = ['自强学堂', '渲染Json到模板']
    Dict = {'site': '自强学堂', 'author': '涂伟忠'}
    return render(request, 'home.html', {
            'List': json.dumps(List),
            'Dict': json.dumps(Dict)
        })

home.html 只给出了 js 核心部分：

//列表
var List = {{ List|safe }};
//字典
var Dict = {{ Dict|safe }};

固然，你也能够将 django的模板数据放在html代码里，好比你能够搞一个隐藏的字段

<input type="hidden"/> 把数据扔里面而后在 js文件去 $("#").val() 去拿数据进行操做，

这样能够作到 js代码与 django代码分离解耦，适合开发和扩展、调试。

 

原文：http://www.infoq.com/cn/articles/cookie-security

　　在 Web 应用中，Cookie 很容易成为安全问题的一部分。从以往的经验来看，对 Cookie 在开发过程当中的使用，不少开发团队并无造成共识或者必定的规范，这也使得不少应用中的 Cookie 成为潜在的易受攻击点。在给 Web 应用作安全架构评审（Security architecture review）的时候，我一般会问设计人员如下几个问题：

1. 你的应用中，有使用 JavaScript 来操做客户端 Cookie 吗？若是有，那么是否必须使用 JavaScript 才能完成此应用场景？若是没有，你的 Cookie 容许 JavaScript 来访问吗？
2. 你的网站（可能包含多个 Web 应用）中，对于 Cookie 的域（Domain）和路径（Path）设置是如何制定策略的？为什么这样划分？
3. 在有 SSL 的应用中，你的 Cookie 是否能够在 HTTP 请求和 HTTPS 请求中通用？

　　在实际的应用场景中，Cookie 被用来作得最多的一件事是保持身份认证的服务端状态。这种保持多是基于会话（Session）的，也有多是持久性的。无论哪种，身份认证 Cookie 中包含的服务端票据（Ticket）一旦泄露，那么服务端将很难区分带有此票据的用户请求是来自于真实的用户，或者是来自恶意的攻击者。在实际案例中，形成 Cookie 泄露最多的途径，是经过跨站脚本（XSS, Cross Site Script）漏洞。攻击者能够经过一小段 JavaScript 代码，偷窃到表明用户身份的重要的 Cookie 标示。因为跨站脚本漏洞是如此的广泛（不要觉得简单的 HTML Encode 就能够避免被跨站，跨站是一门很深的学问，以致于在业界衍生出一个专用的名词：跨站师），几乎每个网站都没法避免，因此这种方式是实际攻防中被广泛使用的一种手段。

　　避免出现这种问题的首要秘诀就是尽全部的可能，给你的 Cookie 加上 HttpOnly 的标签。HttpOnly 的具体使用不在本文的讨论范围内，不然做者略有骗 InfoQ 稿酬的嫌疑。一个你们所不太熟悉的事实是，HttpOnly 是由微软在 2000 年 IE6 Sp1 中率先发明并予以支持的。截止如今，HttpOnly 仍然只是一个厂商标准，可是在过去的十余年中，它获得了众多浏览器的普遍支持。

　　下表是 OWASP 整理的关于主流浏览器对 HttpOnly 支持状况的一个总结。从表中能够看出，目前主流的浏览器，除了 Android 以外，几乎都无一例外对这一属性予以了支持。

　　固然对于中国开发者来讲，须要考虑的问题更加复杂一些：在这个神奇的地方，有大量的用户使用的浏览器并不在如下的列表中，他们使用的是如下面浏览器中的一种或者数种为内核的“精装版”浏览器。这些浏览器厂商对于同源策略、HttpOnly Cookie、证书管理等安全规范的支持状况，有待于进一步调查。

Browser	Version	Prevents Reads	Prevents Writes
Microsoft Internet Explorer	10	Yes	Yes
Microsoft Internet Explorer	9	Yes	Yes
Microsoft Internet Explorer	8	Yes	Yes
Microsoft Internet Explorer	7	Yes	Yes
Microsoft Internet Explorer	6 (SP1)	Yes	No
Microsoft Internet Explorer	6 (fully patched)	Yes	Unknown
Mozilla Firefox	3. 0.0.6+	Yes	Yes
Netscape Navigator	9. 0b3	Yes	Yes
Opera	9. 23	No	No
Opera	9. 5	Yes	No
Opera	11	Yes	Unknown
Safari	3	No	No
Safari	5	Yes	Yes
iPhone (Safari)	iOS 4	Yes	Yes
Google's Chrome	Beta (initial public release)	Yes	No
Google's Chrome	12	Yes	Yes
Android	Android 2.3	Unknown	Unknown

　　在我看来，一个 Web 应用的每个 Cookie 都应该带上 HttpOnly 的标签。我没有看到这个决定可能带来的负面做用，若是必定要说有的话，那么就是你的应用将不能再经过 JavaScript 来读写 Cookie 了。但是这真有必要吗？我的认为，JavaScript 操做 Cookie 是一种不正常的作法；能够用 JavaScript 操做 Cookie 完成的功能，同样能够用服务端响应 Http 头设置 Cookie 来完成。相反，设置全部的 Cookie 为 HttpOnly 带来的巨大好处则很是明显：尽管你须要继续修复 XSS 漏洞，可是这些漏洞至少暂时不会让你的用户遭受大规模的帐户损失。

　　关于 Cookie 的第二个话题是域设置。

　　浏览器在选择发送哪些本地 Cookie 到本次请求的服务端时，有一系列的比较和甄别。这些甄别中最重要的部分是 Domain 和 Path 的吻合。Domain 形如 .abc.com 的 Cookie，会被发送给全部 abc.com 在 80 端口上的子域请求。可是反之则不行，这就是 Cookie 的域匹配（domain match）原则。

　　在一个大型 Web 站点中，每每有多个应用，生存在不一样的子域名或路径下。这些应用之间因为共享同一个域名，因此每每可能会彼此有操做对方应用 Cookie 的能力。这种状况下，设计好 Cookie 的 Domain 和 Path 尤其重要。在实际设计工做中，最重要的一个安全原则就是：最小化受权。这意味着，你须要将本身的 Cookie 可被访问到的范围降至最低。应用之间传递数据和共享信息的解决方案很是多，而经过 Cookie 这种用户输入（User input）来共享数据，是最不安全的解决方案之一。

　　Cookie 另一个不太常被使用的属性是 Secure. 这个属性启用时，浏览器仅仅会在 HTTPS 请求中向服务端发送 Cookie 内容。若是你的应用中有一处很是敏感的业务，好比登陆或者付款，须要使用 HTTPS 来保证内容的传输安全；而在用户成功得到受权以后，得到的客户端身份 Cookie 若是没有设置为 Secure，那么颇有可能会被非 HTTPS 页面中拿到，从而形成重要的身份泄露。因此，在你的 Web 站点中，若是使用了 SSL，那么你须要仔细检查在 SSL 的请求中返回的 Cookie 值，是否指定了 Secure 属性。

　　除此以外还值得特别指出的是，一些 Web 应用除了本身的程序代码中生成的 Cookie，每每还会从其余途径生成一些 Cookie。例如由 Web Server 或者应用容器自动生成的会话 Cookie，由第三方库或者框架生成的 Cookie 等等。这些都须要进行有针对性的加固处理。

　　几乎每一个站点都难以离开 Cookie，但 Cookie 的使用因其貌似简单，而很容易被人轻视。从新审视应用中的 Cookie 代码，几乎只须要很小的代价就能够得到巨大的安全收益。

　　参考文章

• http://en.wikipedia.org/wiki/HTTP_cookie
• https://www.owasp.org/index.php/HttpOnly