浏览器安全简介

浏览器进程：

浏览器进程，渲染进程，插件进程，扩展进程

浏览器安全发展史

IE8 推出 XSS filter（修改其中的关键字符使得攻击无效）
firefox4 推出 content security policy。（由服务器返回一个 http 头，并在其中描述页面应该遵守的安全策略）

X-content-security-policy:allow 'self' ;img-src *;media-src media.com

跨站脚本攻击（XSS）

xss预防方式

cookie 设置 HttpOnly

在没有设置 HttpOnly 的 cookie 中，攻击者可以通过 document.cookie 得到网站的 cookie。HttpOnly 是在 Set-Cookie 时服务端标记的。

输入检查

输入检查一般是检查用户输入的数据中是否包含一些特殊的字符，如 <,> 等。如果发现特殊符号，则将这些字符过滤或者编码。

比较智能的“输入检查”，可能会匹配 XSS 的特征。比如查找用户数据中是否包含<script>,javascript 等敏感字符。这种输入检查，叫做“XSS filter”

输出检查
- 安全的编码函数
防御 DOM Based XSS

事实上，DOM Based XSS 是从 javascript 中输出数据到 html 页面里。而前面的防御手段是针对从服务器应用输出到 html 页面的xss 漏洞。

解决方法：从 javascript 输出到 html 页面，相当于一次 xss 输出的过程，需要分语境使用不同的编码函数。（javascriptencode，htmlencode）

会触发DOm based xss 的地方：

document.write()
document.writeln()
xxx.innerHTML()
xxx.outerHTML()
innerHTML.replace()
document.attachEvent()
window.attachEvent()
document.location.replace()
document.locaion.assign()

跨站点请求伪造（CSRF）

概念：是攻击者利用用户身份操作账户的一种攻击方式。

CSRF 进阶

浏览器的 cookie 策略

浏览器所持有的 cookie 分为两类：一种是“session cookie”，也称为“临时 cookie”。另一种是“ third-party cookie”，也称为 “本地 cookie”。

两者的区别在于，third-party cookie 在 set-cookie 时设置了 expire 过期时间，到达过期时间时，cookie 才会失效。session cookie 没有设置过期时间，浏览器关闭，session cookie 就会过期。

session cookie 保存在浏览器进程中。而 third-party cookie 保存在本地。

如果浏览器从一个域的页面中，要加载另一个域的资源。由于安全原因，某些浏览器会阻止 third-party cookie 的发送。

P3P 头的副作用

P3P Header 是 W3C 制定的一项关于隐私的标准，全称是 The Platform for Privacy Preferences。

如果网站返回给浏览器的 http 头中包含 P3P 投，则在某种程度上来说，将允许浏览器发送第三方 cookie 。在 IE 下即便是 <iframe>,<script> 等标签也将不再拦截第三方 cookie 的发送。

CSRF 的防御

1 验证码

验证码被认为是对抗 CSRF 攻击最简洁而有效的防御方法。但是由于处于用户体验考虑，不可能每个请求都加上验证码的。

2 Referer Check

referer check 在互联网中最常见的应用就是“防止图片盗链”。同理，referer check也可以被用于检查是否来自合法的“源”

即使我们可以通过检查 referer 是否合法来判断用户是否被 csrf 攻击，也仅仅是满足了防御的充分条件。

referer check 的缺陷在于，服务器并不是什么时候都能去到 referer。（很多用户出于隐私保护的考虑，限制了 referer 的发送。在某些情况下，浏览器也不会发送referer，比如从 https 跳转到 http ，出于安全的考虑，浏览器也不会发送 referer）

3 Anti CSRF Token

CSRF 的本质

CSRF 能够攻击成功，其本质的原因是重要操作的所有参数都是可以被攻击者猜测到的。

出于这个原因，可以通过，把参数加密，或者使用一些随机数，从而让攻击者无法猜测到参数值。

但是由于加密或混淆猴的 URL 将变得非常难读，对于用户体验来说不是很好。对于数据分析工作来说，会带来很大的困扰。

所以，请求携带一个 token（一个随机值）是最好的方法。

Token 的使用原则（保密性和随机性）

防御 CSRF 的 Token，是根据 “不可预测性原则”设计的方案，所以 Token 的生成一定要足够随机，需要使用安全的随机数生成器生成 Token。

在使用 Token 时，应该尽量把 Token 放在表单中。把敏感操作由 GET 变成 POST，以 form 表单（或者 ajax）的形式提交，避免 token 泄露。

浏览器安全