《Web前端黑客技术揭秘》学习总结

一、Web安全的关键点

1、浏览器的同源策略

同源策略：不同域的客户端脚本在没明确授权的情况下，不能读写对方的资源。

http://www.baidu.com 的不同域/同域，如下表：

默认情况下是不允许跨域访问的，只有目标站点（http://www.baidu.com）明确返回 HTTP 响应头：Access-Control-Allow-Origin: http://www.google.com，那么 www.google.com 上的客户端脚本才有权通过 AJAX 对www.baidu.com 上的数据进行读写操作。

2、AJAX

Asynchronous JavaScript and XML（异步的 JavaScript 和 XML）。

AJAX 是在不重新加载整个页面的情况下，与服务器交换数据并更新部分网页的技术。

3、DOM

Document Object Mode （文档对象模型）

中立于平台和语言的接口，它允许程序和脚本动态地访问和更新文档的内容、结构和样式。

二、前端基础

Web安全事件的角色：W3C、浏览器厂商、Web厂商、攻击者、用户。

1、URI

URI, 全称为(Uniform Resource Identifier), 也就是统一资源标识符，它的作用很简单，就是区分互联网上不同的资源。

但是，它并不是我们常说的网址, 网址指的是 URL, 实际上 URI 包含了 URN 和 URL 两个部分，由于 URL 过于普及，就默认将 URI 视为 URL 了。

URI 真正最完整的结构是这样的：

• scheme 表示协议名，比如 http, https, file 等等。后面必须和 :// 连在一起。

• user:passwd@ 表示登录主机时的用户信息，不过很不安全，不推荐使用，也不常用。

• host:port 表示主机名和端口。

• path 表示请求路径，标记资源所在位置。

• query 表示查询参数，为 key=val 这种形式，多个键值对之间用 & 隔开。

• fragment 表示 URI 所定位的资源内的一个锚点，浏览器可以根据这个锚点跳转到对应的位置。

• 示例：https://www.baidu.com/s?wd=HTTP&rsv_spt=1

• 这个 URI 中，https 即 scheme 部分

• www.baidu.com为host:port部分（注意：http 和 https 的默认端口分别为 80、443）

• /s 为 path 部分

• wd=HTTP&rsv_spt=1 就是 query 部分

URI 只能使用 ASCII, ASCII 之外的字符是不支持显示的，而且还有一部分符号是界定符，如果不加以处理就会导致解析出错。因此，URI 引入了编码机制，将所有非 ASCII 码字符和界定符转为十六进制字节值，然后在前面加个%。如，空格被转义成了 %20，三元被转义成了 %E4%B8%89%E5%85%83。

URL有三类编码方式：escape、encodeURI、encodeURIComponent，对应着三个解码函数 unescape、decodeURI、decodeURIComponent。

2、HTTP

对于 TCP 而言，在传输的时候分为两个部分：TCP头和数据部分。而 HTTP 类似，也是 header + body 的结构，具体而言:

起始行 + 头部 + 空行 + 实体

由于 http 请求报文和响应报文是有一定区别，因此我们分开介绍。

（1）起始行

对于请求报文来说，起始行类似下面这样：

GET /home HTTP/1.1

也就是方法 + 路径 + http版本。

对于响应报文来说，起始行一般长这样：

HTTP/1.1 200 OK

响应报文的起始行也叫做状态行。由 http 版本、状态码和原因三部分组成。

值得注意的是，在起始行中，每两个部分之间用空格隔开，最后一个部分后面应该接一个换行，严格遵循 ABNF 语法规范。

（2）头部

展示一下请求头和响应头在报文中的位置:

不管是请求头还是响应头，其中的字段是相当多的，而且牵扯到 http 非常多的特性，这里就不一一列举的，重点看看这些头部字段的格式：

1. 字段名不区分大小写

2. 字段名不允许出现空格，不可以出现下划线 _

3. 字段名后面必须紧接着冒号 :

（3）空行

很重要，用来区分开头部和实体。

问: 如果说在头部中间故意加一个空行会怎么样？

那么空行后的内容全部被视为实体。

（4）实体

就是具体的数据了，也就是 body 部分。请求报文对应请求体, 响应报文对应响应体。

（5）有哪些请求方法？

http/1.1 规定了以下请求方法(注意，都是大写):

• GET: 通常用来获取资源

• HEAD: 获取资源的元信息

• POST: 提交数据，即上传数据

• PUT: 修改数据

• DELETE: 删除资源(几乎用不到)

• CONNECT: 建立连接隧道，用于代理服务器

• OPTIONS: 列出可对资源实行的请求方法，用来跨域请求

• TRACE: 追踪请求-响应的传输路径

（6）GET 和 POST 有什么区别？

首先最直观的是语义上的区别。而后又有这样一些具体的差别:

• 从缓存的角度，GET 请求会被浏览器主动缓存下来，留下历史记录，而 POST 默认不会。

• 从编码的角度，GET 只能进行 URL 编码，只能接收 ASCII 字符，而 POST 没有限制。

• 从参数的角度，GET 一般放在 URL 中，因此不安全，POST 放在请求体中，更适合传输敏感信息。

• 从幂等性的角度，GET 是幂等的，而 POST 不是。(幂等表示执行相同的操作，结果也是相同的)

• 从 TCP 的角度，GET 请求会把请求报文一次性发出去，而 POST 会分为两个 TCP 数据包，首先发 header 部分，如果服务器响应 100(continue)， 然后发 body 部分。

（7）如何理解 HTTP 代理？

我们知道在 HTTP 是基于请求-响应模型的协议，一般由客户端发请求，服务器来进行响应。当然，也有特殊情况，就是代理服务器的情况。引入代理之后，作为代理的服务器相当于一个中间人的角色，对于客户端而言，表现为服务器进行响应；而对于源服务器，表现为客户端发起请求，具有双重身份。那代理服务器到底是用来做什么的呢？

• 功能

1. 负载均衡。客户端的请求只会先到达代理服务器，后面到底有多少源服务器，IP 都是多少，客户端是不知道的。因此，这个代理服务器可以拿到这个请求之后，可以通过特定的算法分发给不同的源服务器，让各台源服务器的负载尽量平均。当然，这样的算法有很多，包括随机算法、轮询、一致性hash、LRU(最近最少使用)等等。
   

2. 保障安全。利用心跳机制监控后台的服务器，一旦发现故障机就将其踢出集群。并且对于上下行的数据进行过滤，对非法 IP 限流，这些都是代理服务器的工作。
   

3. 缓存代理。将内容缓存到代理服务器，使得客户端可以直接从代理服务器获得而不用到源服务器那里。下一节详细拆解。

• 相关头部字段

• Via

代理服务器需要标明自己的身份，在 HTTP 传输中留下自己的痕迹，怎么办呢？通过Via字段来记录。举个   例子，现在中间有两台代理服务器，在客户端发送请求后会经历这样一个过程:

客户端 -> 代理1 -> 代理2 -> 源服务器

在源服务器收到请求后，会在请求头拿到这个字段：

Via: proxy_server1, proxy_server2

而源服务器响应时，最终在客户端会拿到这样的响应头：

Via: proxy_server2, proxy_server1

可以看到，Via中代理的顺序即为在 HTTP 传输中报文传达的顺序。

• X-Forwarded-For

字面意思就是为谁转发, 它记录的是请求方的 IP 地址(注意，和 Via 区分开，X-Forwarded-For 记录的是请求方这一个IP)。

• X-Real-IP

是一种获取用户真实 IP 的字段，不管中间经过多少代理，这个字段始终记录最初的客户端的 IP。相应的，还有 X-Forwarded-Host 和 X-Forwarded-Proto，分别记录客户端(注意，不包括代理)的域名和协议名。

• X-Forwarded-For产生的问题

前面可以看到，X-Forwarded-For这个字段记录的是请求方的 IP，这意味着每经过一个不同的代理，这个字段的名字都要变，从客户端到代理1，这个字段是客户端的 IP，从代理1到代理2，这个字段就变为了代理1的 IP。但是这会产生两个问题:

1. 意味着代理必须解析 HTTP 请求头，然后修改，比直接转发数据性能下降。
   

2. 在 HTTPS 通信加密的过程中，原始报文是不允许修改的。
   

由此产生了代理协议，一般使用明文版本，只需要在 HTTP 请求行上面加上这样格式的文本即可// PROXY + TCP4/TCP6 + 请求方地址 + 接收方地址 + 请求端口 + 接收端口

PROXY TCP4 0.0.0.1 0.0.0.2 1111 2222
GET / HTTP/1.1
...

这样就可以解决 X-Forwarded-For 带来的问题了。

3、Cookie

前面说到了 HTTP 是一个无状态的协议，每次 http 请求都是独立、无关的，默认不需要保留状态信息。但有时候需要保存一些状态，怎么办呢？

HTTP 为此引入了 Cookie。Cookie 本质上就是浏览器里面存储的一个很小的文本文件，内部以键值对的方式来存储(在chrome开发者面板的Application这一栏可以看到)。向同一个域名下发送请求，都会携带相同的 Cookie，服务器拿到 Cookie 进行解析，便能拿到客户端的状态。而服务端可以通过响应头中的 Set-Cookie 字段来对客户端写入 Cookie。举例如下:

// 请求头
Cookie: a=xxx;b=xxx
// 响应头
Set-Cookie: a=xxx
set-Cookie: b=xxx

（1）Cookie 属性

• 生存周期

Cookie 的有效期可以通过 Expires 和 Max-Age 两个属性来设置。

• Expires 即过期时间

• Max-Age 用的是一段时间间隔，单位是秒，从浏览器收到报文开始计算。

若 Cookie 过期，则这个 Cookie 会被删除，并不会发送给服务端。

• 作用域

关于作用域也有两个属性：Domain 和path, 给 Cookie 绑定了域名和路径，在发送请求之前，发现域名或者路径和这两个属性不匹配，那么就不会带上 Cookie。值得注意的是，对于路径来说，/ 表示域名下的任意路径都允许使用 Cookie。

• 安全相关

如果带上Secure，说明只能通过 HTTPS 传输 cookie。

如果 cookie 字段带上HttpOnly，那么说明只能通过 HTTP 协议传输，不能通过 JS 访问，这也是预防 XSS 攻击的重要手段。

相应的，对于 CSRF 攻击的预防，也有 SameSite 属性。

SameSite 可以设置为三个值，Strict、Lax和 None。

a. 在 Strict 模式下，浏览器完全禁止第三方请求携带 Cookie。比如请求 baidu.com 网站只 baidu.com域名当中请求才能携带 Cookie，在其他网站请求都不能。

b. 在 Lax 模式，就宽松一点了，但是只能在 get 方法提交表单或者 a 标签发送 get 请求的情况下可以携带 Cookie，其他情况均不能。

c. 在 None 模式下，也就是默认模式，请求会自动携带上 Cookie。

（2）Cookie 的缺点

1. 容量缺陷。Cookie 的体积上限只有 4KB，只能用来存储少量的信息。
   

2. 性能缺陷。Cookie 紧跟域名，不管域名下面的某一个地址需不需要这个 Cookie ，请求都会携带上完整的 Cookie，这样随着请求数的增多，其实会造成巨大的性能浪费的，因为请求携带了很多不必要的内容。但可以通过 Domain 和 Path 指定作用域来解决。
   

3. 安全缺陷。由于 Cookie 以纯文本的形式在浏览器和服务器中传递，很容易被非法用户截获，然后进行一系列的篡改，在 Cookie 的有效期内重新发送给服务器，这是相当危险的。另外，在 HttpOnly 为 false 的情况下，Cookie 信息能直接通过 JS 脚本来读取。
   

三、前端黑客之XSS

Cross Site Script（跨站脚本），发生在目标网站中目标用户的浏览器层面上，当用户浏览器渲染整个HTML文档的过程中出现了不被预期的脚本指令并执行，XSS就会产生。

1、反射型XSS

发出请求时，XSS代码出现在URL中，作为输入提交到服务端，服务端解析后响应，在响应内容中出现这段XSS代码，最后浏览器解析执行。

2、存储型XSS

提交的XSS代码会存储在服务端，下次请求目标页面时不用再提交XSS代码。

3、DOM型XSS

DOM 型XSS的XSS代码不需要服务器解析响应的直接参与，触发XSS靠的是浏览器端的DOM解析，可以认为完全是客户端的事情。

常见的输入点：

document.URL
document.URLUnencoded
document.location
document.referrer
document.cookie
windows.location
windows.name

常见输出点：

直接输出HTML内容：
document.write()
document.writeln()
document.body.innerHtml=
直接修改DOM树：
document.forms[0].action=
document.attachEvent()
document.create()
document.execCommand()
document.body. ...()
替换document URL
document.location=
document.location.hostname=
document.location.replace()
document.location.asign()
document.URL=
window.navigate()
打开或修改新窗口
document.open()
window.open()
window.location.href=
直接执行脚本
eval()
window.execScript()
window.setInterval()
window.setTimeout()

XSS 危害：挂马、盗取用户 Cookie、Dos 客户端浏览器、钓鱼攻击、劫持用户 Web 行为、蠕虫式挂马刷广告等等。

四、前端黑客之CSRF

Cross-site request forgery（跨站请求伪造跨站的请求）

• 跨站点的请求：跨站点请求的来源一般为其他站点，但是也可以来自本站。

• 请求是伪造的：发出的请求不是用户的意愿的请求。

HTML CSRF

发起的 CSRF 请求都属于 HTML 元素发出的，HTML 中能设置 href/src 等连接的标签都可以发起一个 GET 请求，如：

<link href="">
<img src="">
<meta http-equiv="refresh" content="0; url=">
<iframe src="">
<script src="">
...
CSS中的：
@import ""
background:url("")

CSRF 危害：篡改目标网站上的用户数据、盗取用户隐私数据、作为其他攻击向量的辅助攻击手法、传播 CSRF 蠕虫。

五、前端黑客之界面操作劫持

界面操作劫持攻击是一种基于视觉欺骗的 Web 会话劫持攻击，它通过在网页的可见输入控件上覆盖一个不可见的框（iframe），让用户以为在操作可见控件，但是实际上用户的操作行为被其不可见的框所劫持，执行不可见框中的恶意劫持代码，从而完成在用户不知情的情况下窃取敏感信息，篡改数据等攻击。

1、分类

（1）点击劫持

劫持的是用户的鼠标点击操作，主要的劫持目标是有重要会话交互的页面，比如，银行交易页面、后台管理页面或者劫持用户的摄像头和麦克风。

（2）拖放劫持

在现在的 Web 应用中，有一些需要用户采用鼠标拖放完成的操作，而且用户也经常在浏览器中使用鼠标拖放操作来代替复制粘贴。因此，拖放操作劫持很大程度的扩展了点击劫持的攻击范围，也将劫持模式从单纯的鼠标点击扩展到了鼠标拖放行为。

通过劫持某个页面的拖放操作实现对其他页面链接的窃取，这些链接中可能会有 session key、token、password 等信息；或者可以把其他浏览器中的页面内容拖放到富文本编辑器模式中，这样就能够看到页面源代码了，而这些 HTML 源代码中可能会存在敏感信息。

（3）触屏劫持

移动智能终端设备由于体积限制，一般都没有鼠标、键盘这些输入设备，用户更多的操作是依靠手指在触屏上的点击或滑动等动作完成。在移动设备上，类似点击劫持的攻击模式，实现了对用户触摸屏操作的劫持攻击。

2、原理分析

点击劫持：CSS 透明层 +iframe

利用 CSS 中透明属性 opacity，取值范围 0~1，取值 0 时透明度最高

用 iframe 嵌入被劫持界面：<iframe id = "victim" src="www.victim.com" scrolling="no">

3、危害

界面操作劫持实际上突破了 CSRF 的防御策略，这是一种社工色彩很强的跨域操作，而这种跨域正好是浏览器自身的特性，带来的危害可以很大，比如，篡改与删除数据，偷取隐私甚至爆发蠕虫。

六、漏洞挖掘

1、CSRF 的漏洞挖掘

• 目标表单是否有有效的 token 随机串。

• 目标表单是否有验证码。

• 目标是否判断了 Refere 来源。

• 网站根目录下的 crossdomain.xml 的 "allow-access-from domain" 是否是通配符。

• 目标 JSON 是否可以自定义 callback 函数。

2、界面劫持的漏洞挖掘

• 目标的 HTTP 响应头是否设置了 X-Frame-Options 字段。

• 目标是否有 Javascript 的 Frame Busting 机制。

• 更简单的是用 iframe 嵌入目标网站试试。

3、反射型XSS漏洞挖掘

反射型XSS最常见的就是直接在URL中进行注入，URL的格式如下：

<scheme>://<netloc>/<path>?<query>#<fragment>

在完整的 URL 构成中，<path>、<query>、<fragment> 都是用户可控的。

一般情况下可以通过将payload加入到参数来测试XSS的存在与否。

<script>alert(1)</script>
'"><script>alert(1)</script>
<img/src=@ onerror=alert(1) />
' onmouseover=alert(1) x='
` onmouseover=alert(1) x=`
javascript:alert(1)//
'";alert(1)//
}x:expression(alert(1))
.....

根据请求后的反应看是否有弹出窗或浏览器脚本错误，如果有则说明目标存在XSS漏洞。

例如：www.test.com/xss.php?id=1，这里输入点为 id=1，既然有输入点，查看结果则依赖于输出点，可能是以下几处：

• HTML 标签之间，<div id="body">[输出]</div>

• HTML 标签内，<input type="text" value=[输出] />

• Javascript 代码的值，<script>a="[输出]";...</script>

• CSS 代码的值，<style>body{font-size:[输出]px;...}</style>

（1）HTML标签之间

有很多标签之间的脚本是无法执行的，如：<title>、<textarea>、<xmp>、<iframe>、<noscript>、<plaintext>，可以先闭合前面的标签，来使得脚本能够成功执行。如：</title><script>alert(1)</script>

（2）HTML标签内

• " onmouseover=alert(1) x=" 这种是闭合属性，然后使用 on 事件来触发脚本。

• "<script>alert(1)</script> 这种是闭合属性后又闭合标签，然后直接执行脚本。

• 细分为三种场景：

• 输出在src/href/action等属性内

• 输出在on*事件内

• 输出在style属性内

（3）Javascript代码的值

</script><script>alert(1)

（4）CSS代码的值

与“输出再在style属性内”类似，构造能执行的Javascript语句，闭合标签。

4、存储型XSS漏洞挖掘

与反射型 XSS 相比，存储型 XSS 漏洞挖掘的差别在于：存储型 XSS 一般都是基于表单的提交，然后进入服务端存储，最终在某个页面输出。

一般情况下，存储型 XSS 表单提交之后的输出点有以下几种可能：

• 表单提交后跳转到的页面可能是输出点。

• 表单所在的页面可能是输出点。

• 表单提交后不见了，整个网站的某个源文件是输出点，需要借助爬虫进行分析。

5、DOM型XSS漏洞挖掘

（1）静态方法

一旦发现可以特征就得中断下来人工分析。就工具化而言，静态方法可以使用正则表达式匹配输入点和输出点。

输入点：

/(location\s*[\[.])|([.\[]\s*["']?\s*(arguments|dialogArguments|innerHTML|write(ln)?|open(Dialog)?|showModalDialog|cookie|URL|documentURI|baseURI|referrer|name|opener|parent|top|content|self|frames)\W)|(localStorage|sessionStorage|Database)/

输出点：

/((src|href|data|location|code|value|action)\s*["'\]]*\s*\+?\s*=)|((replace|assign|navigate|getResponseHeader|open(Dialog)?|showModalDialog|eval|evaluate|execCommand|execScript|setTimeout|setInterval)\s*["'\]]*\s*\()/

（2）动态方法

与静态方法只需进行特征匹配不同，动态方法要对程序的执行流程进行跟踪，除了输入点和输出点外还要关心逻辑过程。

一种比较简单的方式是借用浏览器动态执行的优势，以DOM树的改变为判断依据，对输入点进行模糊测试，然后判断渲染后的DOM树中是否有期望的值，不过这种方法无法逻辑判断导致的误报。

6、字符集缺陷导致的XSS

（1）概念

1. 字符与字节
   肉眼看到的一个文字或符号单位就是一个字符（包括乱码），一个字符可能对应 1~n 字节。一个字节为 8 个 bit 位，每个 bit 位要么为 0 要么为 1。

2. 字符集
   一个字符对应1~n字节是由字符集及编码决定的，比如，ASCII 字符集就是一个字符对应一个字节，不过 1 字节只用了 7 位，最高位用于其他目的，所以 ASCII 字符集共有 2 的 7 次方（128）个字符。

3. 字符集编码
   这些字符集大都对应一种编码方式，不过 Unicode 字符集的编码方式有 UTF-8、UTF-16、UTF-32、UTF-7，常见的是 UTF-8 与 UTF-7。编码的目的是最终将这些字符正确地转换为计算机可理解的二进制，对应的解码就是将二进制最终解码为人类可读的字符。

（2）宽字节编码带来的安全问题

GB2312、GBK、GB18030、BIG5、Shift_JIS等这些都是常说的宽字节，实际上只有两字节。宽字节带来的安全问题主要是 ASCII 字符（一字节）的现象，比如，下面这个 PHP 示例，在 magic_quotes_gpc=On 的情况下，如何触发 XSS？

<?php header("Content-Type: text/html;charset=GBK"); ?>
<head>
<title>gb xss</title>
</head>
<script>
a="<?php echo $_GET['x'];?>";
</script>

我们会想到，需要闭合双引号才行，如果只是提交如下语句：gb.php?x=1";alert(1)//

双引号会被转义成 \"，导致闭合失败：a="1\";alert(1)//";

由于这个网页头部响应指明了这是 GBK 编码，GBK 编码第一字节（高字节）的范围是 0x81～0xFE，第二字节（低字节）的范围是 0x40～0x7E 与 0x80～0xFE，这样的十六进制表示。而 \ 符号的十六进制表示为 0x5C，正好在 GBK 的低字节中，如果之前有一个高字节，那么正好会被组成一个合法字符，于是提交如下：gb.php?x=1%81";alert(1)// 双引号会继续被转义成 \"，最终如下：a="1[0x81]\";alert(1)//"; [0x81]\ 组成了一个合法字符，于是之后的双引号就会产生闭合，这样我们就成功触发了XSS。

这些宽字节编码的高低位范围都不太相同，这里有一点要注意，GB2312 是被 GBK 兼容的，它的高位范围是0xA1～0xF7，低位范围是 0xA1～0xFE（0x5C 不在该范围内），把上面的 PHP 代码的 GBK 改为 GB2312，在浏览器中处理行为同 GBK，也许是由于 GBK 兼容 GB2312，浏览器都做了同样的兼容：把 GB2312 统一按 GBK行为处理。

上面这类宽字节编码问题的影响非常普遍，不仅是 XSS 这么简单，从前端到后端的流程中，字符集编码处理不一致可能导致 SQL 注入、命令执行等一系列安全问题。

7、绕过浏览器的XSS Filter

XSS Filter 主要针对反射型 XSS，大体采用的是启发式的检测，即根据用户提交的参数是否判断是否有潜在的XSS 特征，并重新渲染响应的内容保证潜在的 XSS 特征不会触发，IE 自动修改页面就是重新渲染的例子。

（1）响应头CRLF注入绕过

若目标网页存在响应头部 CRLF 注入，在 HTTP 响应头注入回车换行符，就可以注入头部：X-XSS-Protection: 0，用于关闭XSS Filter机制，

例如：

http://topo.com/xx.action?id=%0d%0aContent-Type:%20text/html%0d%0aX-XSS-Protection:%200%0d%0a%0d%0ax%3Cscript%3Ealert%28123%29%3B%3C%2fscript%3Ey

这段URL如果在 urldecode 后是如下内容：

http://x.com/xx.action?id=
Content-Type: text/html
X-XSS-Protection: 0
x<script>alert(1);</script>y

（2）针对同域的白名单

1. IE 会判断 Referer 来源是否是本域，如果是则 XSS Filter 不会生效，如：referer:<?php echo $_SERVER['HTTP_REFERER'] ?>

2. Chrome 则与 IE 不一样，如果 <script> 嵌入同域内的 js 文件，XSS Filter 便不会防御。http://www.foo.com/xss.php?x=<scriptsrc=alert.js></script>

8、混淆的代码

（1）浏览器的进制

HTML 属性中用的最多是十进制和十六进制，十进制在 HTML 中用形如 &#56; 的方式表示（前缀为，中间为十进制数字，后缀为半角分号;可以没有后缀）；十六进制则为 &#x5a; 的形式（比十进制多了个 x，进制码中也多了 a～f 这 6 个字符来表示 10~15）。

CSS 代码中只能用到十进制和十六进制，除了兼容 HTML 中的进制表示外，十六进制还可以使用 \6c 的形式表示（使用斜线作为进制数值前缀）。

JavaScript 代码中可直接通过 eval 执行的字符有八进制(\56)和十六进制(\x5c)两种编码方式，它们都不能给多字节字符编码，只能用十六进制的Unicode编码。

在线编解码工具：http://monyer.com/demo/monyerjs/

（2）浏览器的编码

JavaScript 中有三套编码/解码函数：

• escape / unescape

• encodeURL / decodeURL

• encodeURLComponent / decodeURLComponent

三种加密方法近乎相同，实际上它们还是有少许区别的:

escape不编码的字符有69个：
*、+、-、.、/、@、_、0～9、a～z、A～Z而且escape对0～255以外的unicode值进行编码时输出%u****格式。
encodeURI不编码的字符有82个：
!、#、$、&、'、(、)、*、+、,、-、.、/、:、;、=、?、@、_、~、0～9、a～z、A～Z
encodeURIComponent不编码的字符有71个：
!、'、(、)、*、-、.、_、~、0～9、a～z、A～Z

（3）HTML中的代码注入

完整的HTML代码分为：标签名、属性名、属性值、文本、注释。

• 标签

HTML 标签不区分大小写，所以可以构造 <ScrIPT> 的形式绕过对 <script> 的过滤，这对代码的运行没有丝毫的影响，但是这样会阻碍过滤器对关键词的识别。

由于现代浏览器对 XHTML 的支持，使得我们可以在某些浏览器的某些版本中插入 XML 代码、SVG 代码或未知标签。

如在 IE 6下可以构造如下代码：<XSS STYLE="xss:expression(alert('XSS'))"> 如果对方站点的 HTML 过滤器是基于黑名单的，很明显，<XSS> 标签不在名单之列，使得插入的代码得以被绕过。

有些过滤器的 HTML Parser 很强大，会判断当前代码是否存在于注释中，如是注释则忽略；反过来说，有些则不关心是否有注释，只关心 HTML 标签、属性、属性值是否有问题。由于注释的优先级较高，可以构造如下代码：<!--<a href="--><img src=x onerror=alert(1)//">test</a> 扫描器忽略了 HTML 注释后，会认为 <a href="<img src=x onerror=alert(1)//">test</a>是一个完整的HTML语句，<img src=x onerror=alert(1)//">则被认为是属性 href 的值，而对浏览器来说，<img src=x onerror=alert(1)//"> 是一个完整的 img 标签。

HTML 语法中标签同样有优先级的区别，<textarea>、<title>、<style>、<script>、<xmp> 等标签具有非常高的优先级，因此使其结束便可直接中断其他标签的属性，<style><a href="</style><img src=x onerror=alert(123)//>，这里 <style> 优先级高于 <a> ,因此 </style> 出现与前面闭合之后就会中断 <a> 锚标签。

• 属性

HTML 标签的属性同样不区分大小写，属性值可以用双引号、单引号括起来，不用引号语法上也可以接受，甚至在IE下还可以使用反引号 (`)，<img sRc = `#`> 标签和属性、属性名和等号、等号和属性名之间可用若干个空格、换行符(chr(13))、回车符(chr(10))、TAB(chr(9))。

另外，还可以在属性的头部和尾部插入系统控制符(ASCII值1~32)：<a &#8 href="&#32 javascript:alert(123)&#16">test</a>，不过要注意，不同浏览器、不同版本之间处理方式都存在差异，使用控制字符前最好有一个预期。

HTML 的属性按用途分大致可以分为：普通属性、时间属性、资源属性几种。对于普通属性我们可以控制属性值，应该尝试突破当前属性去构造新的属性或标签，常用的方法是构造闭合。

如果可以控制事件属性，那么除了上面说的突破当前属性，我们还可以插入代码等待用户触发。对于形如 <a href="#" onclick="function(\"<?=$_GET['a']?>\")">test code</a> 可以说得上是最爱了，因为用户可以完全控制输入代码，闭合函数构造自己的代码。有时候碰到匿名函数也是一件高兴的事，因为匿名函数具有可以在一个函数中执行另一个函数的特性，或多或少给了我们机会。

资源类属性，可以理解为属性值需要为URL的属性，通常属性名为 src 或 href，这类属性一般都支持浏览器的预定义协议：http、ftp、https（网络交互协议）、file、data（本地协议）、mailto、javascript、vbscript（伪协议）

常见支持资源属性的 HTML 标签：

applet,embed,frame,iframe,img
input type=image,
xml,a,link,area,
table\tr\td\th的background属性,
bgsound,audio,video,object,meta refresh,script,base,source

• 事件

HTML的事件有很多，包括鼠标事件、键盘事件、表单元素相关事件及内容编辑事件等。

9、CSS 中的代码注入

CSS 分为选择符、属性名、属性值、规则和声明。

@charset "UTF-8";
body{
    background:red;
    font-size:16px;
}
a{
    font-size:14px!important;
}   //body和a为选择符，background为属性名，为属性值，@charset为规则，!important为声明

CSS 中能利用进行 XSS 的只有属性值和@import规则。

CSS与 HTML类似，CSS 语法对大小写不敏感，属性值对单双引号不敏感，对资源类属性来说 URL 部分的引号也不敏感，同样空格、回车、tab等也能被浏览器解析。

10、Javascript 中的代码注入

当 XSS 点出现在 JavaScript 代码的变量中时，只要我们可以顺利闭合之前的变量，接下来就可以插入我们的代码了，示例如下：var a = "[userinput]"; 假设其中的[userinput]是用户可控变量，则可以尝试用引号来闭合变量，假如输入：123";alert(1);b=" 那么代码效果如下：var a = "123";alert(1);b=""; a 变量被闭合，alert(1) 得以逃脱出来，而 b 变量的存在是为了使语法保持正确，当然，我们也可以输入注释符“//”来忽略掉后面的错误语法：var a = "123";alert(1);//";

XSS 寻找注入点的过程其实便是寻找用户可控变量的过程，当然有时候并不是这么简单就能利用的。比如说：目标站点对输入变量使用了 addslashes（单引号、双引号和反斜线的前面都会增加一条反斜线），这样就无法通过闭合引号利用。如果处于宽字节环境，就可以通过构造 %81%5c 的方式进行绕过，</script>(</script>) 能用的话，也可以闭合 <script> 标签，</script> 闭合标签具有最高优先级。

11、突破 URL 过滤

我们注入 URL 时，可以参考如下一些技巧来绕过过滤：

• 正常：<a href="https://66.102.7.147/">XSS</a>

• URL 编码：

<a href="https://%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6F%6D">XSS</a>

• 十进制：<a href="https://1113982867/">XSS</a>

• 十六进制：<a href="https://0x42.0x0000066.0x7.0x93/">XSS</a>

• 八进制：<a href="https://0102.0146.0007.00000223/">XSS</a>

• 混合编码：<a href="http://6&#9;6.000146.0x7.147/">XSS</a>

• 不带 http: ：<a href="//www.google.com/">XSS</a>

• 最后加个点：<a href="https://www.google.com./">XSS</a>

七、漏洞利用

漏洞利用要完美，就得保证利用过程的原生态，本意就是让被攻击者区分不出，甚至被攻击后很长一段时间或者永远都不知道发生过这样的事情。

1、渗透前的准备

• 目标环境：对于开源 CMS 的渗透，可以通过白盒、黑盒 方式了解透，大大方便后续的渗透。而对于闭源的CMS，我们只能利用黑盒进行，会更麻烦，需多走几个步骤。

• 目标用户：目标用户的角色可以很多种，如：CMS 管理员、客服、普通用户、黑客/安全人员等。

• 预期效果：最后明确本次渗透过程中每一阶段的效果，如：获取 Cookie、添加一篇文章、传播网马、盗取密码、破坏数据等。

2、偷取隐私数据

• XSS 探针：xssprobe：通过它可以获取目标页面的通用数据；利用这些通用数据，有时能让我们直接获取目标用户的权限（通过 Cookies 利用）。

• referer 惹得祸：Referer 指请求来源，很多网站通过这个来判断用户是从哪个页面/网站过来的，Referer 是公开的，故不可在 Referer 中存在与身份认证或者其他隐私相关的信息，但很多网站设计之初没考虑到 Referer 的风险性，从而导致出现了安全问题。

• 浏览器记住的明文密码：2010 年时，各浏览器开始逐渐加入“记住密码”的功能（这些浏览器包括 Firefox、Chrome、IE、Opera、Safari 等），记住密码不同于老方式“记住登录状态”。“记住登录状态”主要是设置了持久型的 Cookie，这和浏览器没关系，而是 Web 服务自己设置的；与记住表单内容相比，记住密码更危险，因为通过 DOM 就能获取其中的密码，而且是明文；可以在 XSS 利用中使用该 POC 获取用户的明文密码，由于不同的 Web 环境下的密码表单项不太一样，此时只需要修改相关的表单项值就行。

• 键盘记录器：键盘记录器实际上用处并不大，还不如劫持表单项的各种事件方便。

3、内网渗透技术

• 内网渗透是一门独立的学问，通过 Web 层面（主要是 JavaScript）进行的内网渗透实际上是一种很浅的渗透，不过带来的威力有可能很大

• 获取内网 ip：目前，内网IP的获取还有一个比较好的方式，即通过 Java Applet，但需要 JRE 支持。

• 获取内网 ip 端口：Image 对象请求时，得到资源后就触发 onerror 事件（因为这个资源不是正常的图片），得不到就进入 timeout 机制，通过这个原理来判断目标 IP 与端口是否存在，不过这个功能不太稳定；还可以尝试通过跨域 AJAX 技巧或 Web Socket 方法实现IP端口的获取。

• 获取内网主机存活状态：主机存活状态的获取技巧很不错，本质是通过跨域 AJAX 请求进行的判断，比较稳定。

• 开启路由器的远程访问能力：默认的“远程管理IP地址”是 0.0.0.0，如果设置为 255.255.255.255，则允许互联网上任意 IP 进行远程 Web 方式的管理，即通过浏览器登录这台 FAST 的外网 IP，输入用户名与密码即可进行管理操作。

• 内网脆弱的 web 应用控制：通过 Referer 有可能泄露内网 Web 应用的地址，即通过对 Referer 的判断可能猜测出这个 Web 应用的类型，还可以通过 fuzzing 方式，猜测内网可能存在的 Web 应用；常见的内网 Web 应用类型有：BBS、Blog、Trac、Wiki、OA、WebMail、项目管理、客服后台、存在漏洞的 Web 应用环境等。

4、基于 CSRF 的攻击技术

• 基于 CSRF 的攻击技术也是一种比较通用的思想：基于 CSRF 的攻击技术也是一种比较通用的思想。

• 包括如下内容：基于 CSR F的 SQL 注入；基于 CSRF 的命令执行；基于 CSRF 的 XSS 攻击。

5、浏览器劫持技术

• 浏览器劫持技术是指通过劫持用户点击链接操作，在打开新窗口的时候注入攻击者的 JavaScript 脚本，以达到将 XSS 威胁延续到同域内的其他页面。

6、一些跨域操作技术

• ie res: 协议跨域

• css string injection 跨域：一个非常有趣的跨域技巧，@import 方式导入外域 CSS 文件本身是一个正常的行为，然后IE通过 document.body.currentStyle.fontFamily 方式访问目标样式的 font-family 属性，它的值是font-family 之后的所有内容，这是 CSS 高容错性导致的。

• 浏览器特权区域风险。

• 浏览器扩展风险：浏览器为了丰富自身的功能，允许第三方提供各类插件或扩展，但这些扩展的权限如果没控制好，就会带来严重的后果。

• 跨子域：document.domain 技术技巧：跨子域：document domain 技巧非常好用，属于浏览器的性质；有一个合法的性质是：这个页面可以设置 document.domain 为当前子域或比当前子域更高级的域，一般顶级就到了根域。

• 更多经典的跨域索引：

• 利用 UNC“跨域”：通过Internet域（http协议）的代码，比如 <iframe> 标签利用 file 协议调用本地的XSS 漏洞页面，并通过这个本地 XSS 执行任意的 JavaScript 代码，由于是 file 协议，权限会更大，比如，利用 AJAX 读取本地文。

• mhtml:协议跨域。

7、XSS Proxy 技术

• XSS Proxy 技术用到了基于浏览器的远程控制上，这是一种非常好的思想，现在很多。XSS。利用框架，如。XSS Shell、BeEF、Anehta 等远程控制都是基于 XSS Proxy 的。

• 要实现远程控制，必须具备以下两个条件：远控指令要在目标浏览器上“实时”执行；执行结果要能够让控制端看到。

• XSS Proxy 技术的 4 种思路，各有千秋：

• 浏览器 [script] 请求：<script> 标签请求内容可跨域，这是合法的功能，请求到的数据必须是合法的JavaScript 语法格式；包括请求回来的是 JSON+CallBack 函数这样的数据内容（这种跨域数据通信被称为 JSONP）。

• 浏览器跨域 AJAX 请求：跨域 AJAX 请求也需要浏览器 setInterval 去主动发起服务端指令接口请求。唯一的好处是，这种请求是异步发起的，会显得更加安静。

• 服务端 websocket 推送指令：严格地说，WebSocket 技术不属于 HTML5，这个技术是对 HTTP 无状态连接的一种革新，本质就是一种持久性 socket 连接，在浏览器客户端通过 JavaScript 进行初始化连接后，就可以监听相关的事件和调用 socket 方法来对服务端的消息进行读写操作。

• postMessage 方式推送指令：HTML5 的 postMessage 机制非常完美，是客户端最直接的跨文档传输方法，一般用在 iframe 中父页与子页之间的客户端跨域通信；这个技巧如果用于 XSS Proxy 上可能有些绕，攻击者需要动态生成，然后在客户端进行跨域传输指令。

八、HTML5 安全

HTML5 现在由 WHATWG、W3C、IETF 三个组织来共同开发制定。

1、新标签和新属性绕过黑名单策略

• 白名单和黑名单过滤器策略是防御XSS攻击的重要方法

• 跨站中的黑名单策略

• 新元素突破黑名单策略：要绕过这种黑名单策略，一种方法就是跨站使用变形后的代码绕过正则表达式的语义范围。另一种情况是下面将要提到的 HTML5 新标签和新属性。

• HTML5 中可以利用到的新标签有音频标签 <audio> 和视频标签 <video>。

• HTML5 中可以利用到的新属性有 formation、onformchange、onforminput、autofocus 等。

2、HistoryAPI 中的新方法

• pushstate() 和 replacestate()：HTML5 的 History API 中新增加了两个新方法 pushState() 和replaceState()。可以在不刷新页面的情况下添加和修改历史条目。

• 短地址 +history 新方法=完美隐藏url恶意代码：短地址服务是指把一个冗长的网址转换成一个简洁的网址；当用户点击短地址的时候，并不知道它指向哪里，此时攻击者就可以利用短地址这个特性，把注入恶意代码的网站转换为短地址，用户单击这个短地址后，就会遭到攻击；现在可以利用 History 的新方法 pushState() 和replaceState()，在无刷新页面的情况下改变地址栏中的 URL，用户就无法看到恶意代码。

• 伪造历史记录：使用 history.pushState 可以对浏览器的历史记录进行伪造，而且也可以对历史记录发起 Dos攻击。

3、HTML5 下的僵尸网络

• 僵尸网络（英文名为 Botnet）是指，通过各种手段在大量的计算机中植入特定的恶意程序，使控制着能够通过相对集中的若干计算机直接向大量计算机发送指令的攻击网络。

• web worker 的使用：HTML5 中的 Web Worker 可以让 Web 应用程序具备后台处理能力，比如，让 Worker进行并行计算、后台 I/O 操作等，而且对多线程支持非常好；Web Worker 不会导致浏览器UI停止响应，短暂的 Worker 操作不会让用户察觉，但如果是长时间大量的 Worker 运算操作，则会消耗 CPU 周期，使系统变慢，用户可能看到 CPU 始终保持在高位。

• cors 向任意网站发送跨域请求：CORS 的安全策略仅仅在于是否允许客户端获取服务器的返回数据，但并不会阻止客户端发送的请求。

• 一个 HTML5 僵尸网络实例：如何控制更多的僵尸节点？蠕虫可以将被感染的用户浏览器变成僵尸节点。

4、地理定位暴露你的位置

• 使用 HTML5 Geolocation API（地理定位 API），就可以请求用户共享自己的地理位置，如果用户同意，程序就可以定位到用户的地理位置。

• 隐私保护机制：这套隐私机制完全由浏览器控制；用户对于记住共享设置的功能需要注意，尤其是用户选择了允许共享地理位置，这有可能使用户一直暴露自己的地理位置。

• 通过 XSS 盗取地理位置：获取这类真实地理信息比较容易。同时，结合原生的社工技巧，攻击成功的概率会更高。

九、Web蠕虫

蠕虫的一个特性就是传播性，对于 Web 蠕虫来说，传播的媒介就是 Web2.0 网站的浏览器客户端，而传播的基石则是广大用户。

1、Web蠕虫思想

• Web蠕虫主要包括：XSS蠕虫、CSRF蠕虫、Clickjacking蠕虫，这三类蠕虫都与具体的漏洞风险有关系，从名字上很好区分

• Web蠕虫的思想很简单，就是用户参与，而Web2.0网站正好具备这个条件

• 从XSS蠕虫到CSRF蠕虫，再从Clickjacking蠕虫到文本蠕虫，越往后，社工的成分越大

2、XSS蠕虫

• 原理+一个故事：蠕虫具有的最主要的两个性质如下：传播性、病毒行为；XSS 蠕虫的发生需要具备以下条件（目标网站具备 Web2.0 的关键特性：内容由用户驱动；均存在 XSS 漏洞；被感染的用户是登录状态，这样XSS 的权限就是登录后的权限，能执行更多恶意的操作；XSS 蠕虫传播利用的关键功能本身具备内容传播性）

• 危害性：XSS 蠕虫的权限大（一般情况下，Web 用户有多大权限，它就有多大权限）：

• 对用户数据进行任意操作（XSS 蠕虫传播开后，可以批量对用户数据进行恶意操作）。

• 拒绝服务攻击（XSS 蠕虫可以对目标网站服务进行大面积的拒绝服务攻击，导致用户无法正常使用网站功能）。

• 分布式拒绝服务攻击（分布式拒绝服务攻击的目标是其他网站，XSS 蠕虫的每个被感染用户在地理位置上可能分布在全国各个位置，甚至世界各个位置）

• 散播广告。

• 传播网页木马（一般情况下，网马是利用浏览器与浏览器插件漏洞（最臭名远昭的就是 IE 的 ActiveX 控件）进行本地攻击，将网马内的二进制数据或脚本病毒植入操作系统本地执行，本来在 Web 层面上的威胁，通过这些漏洞蔓延到了操作系统层面。在操作系统层面上，病毒的权限至少就是操作系统用户账号的权限）。

• 传播舆情。

• 蠕虫需要追求原生态：框架封装了太多优秀的函数，对 XSS 来说，直接调用就好，可以省去许多自定义代码的麻烦，而且可以大大减少 XSS  蠕虫的大小，这样的 XSS 蠕虫就是原生态的：

• 代码的原生态：简单的几行代码就可以发起 GET 或 POST 请求，而且使用原生态的框架还有一个好处，它帮我们处理了各种浏览器兼容的问题。

• 攻击效果的原生态：那些 DIV 框、UI 组件都是可以直接调用一些高度封装的 JavaScript 函数来生成。

3、CSRF蠕虫

• 关于原理和危害性：CSRF 蠕虫的原理和 XSS 蠕虫基本类似，只是这里用到的是 CSRF，攻击代码存在于攻击者页面中，目标网站传播的内容都包含攻击者页面 URL，这样才能诱惑目标网站上的被攻击者打开攻击者页面，然后触发 CSRF，CSRF 会继续跨域发布含攻击者页面 URL 的内容进行传播；和 XSS 蠕虫不一样的是：XSS 蠕虫的攻击代码本质上是存放在目标网站上的，即使是 <script> 从攻击者域上引用进来，对 JavaScript上下文来说，也属于目标网站；CSRF 蠕虫的危害性大多与 XSS 蠕虫一样，如：获取用户隐私、对用户数据进行恶意操作、散播广告、传播网页木马、传播舆情等。

• 译言 CSRF 蠕虫：攻击代码可以做得非常隐蔽，顺便加上了 Referer 判断。而蠕虫代码就是靠得到的这个Referer 值进行后续操作的。由于 AJAX 无法跨域获取操作第三方服务器上的资源，于是使用了服务端代理来完全跨域获取数据的操作（Microsoft.XMLHTTP 控件的使用）；有一点要强调下，蠕虫传播的前提是目标用户登录了目标网站，然后才能看到消息并中招，之后的传播必定会带上目标用户的内存 Cookie，所以这个过程不受限于IE下的本地 CookieP3P 策略的声明。

• 饭否 CSRF 蠕虫-邪恶的Flash游戏：饭否 CSRF 蠕虫是利用 Flash 进行传播的，本质上是该 Flash 文件里的ActionScript 脚本向饭否发起 CSRF 请求；CSRF 请求有两种：一种是 Get 请求获取攻击者相关的隐私数据。第二种是 POST 请求提交数据，使得被攻击者自动发送一条微博消息并向自己的好友都发一条私信；这些 Web蠕虫都是基于用户群的，需要大量的用户参与，借用户交互之势而传播，而用户之间却存在一种信任关系，一般情况下，如果是自己的好友给自己发消息，都会去看，因为彼此很信任，饭否的这个蠕虫传播正是利用了这个特性。

• CSRF 蠕虫存在的可能性分析：顾名思义，CSRF 蠕虫就是利用 CSRF 技术进行传播的 Web 蠕虫，前者的译言CSRF 蠕虫以及相关分析文章说明了 CSRF 蠕虫存在的事实，译言网站的这个 CSRF 是由用户驱动的，蠕虫的代码都存放于另外一个网站上；要解决的最关键的问题就是 CSRF 蠕虫的传播性，即基于用户驱动的传播性（主动或者被动）；跨域获取数据的几种方式：CSRF 蠕虫传播必须面对的问题是如何获取各种必要的唯一值。这里有三种方式：服务端代理技术、FlashAS 跨域请求技术、JSONHijacking 技术；通过对 CSRF 蠕虫传播原理的分析，许多广泛存在 CSRF 漏洞的 Web2.0 网站都面临着 CSRF 蠕虫的威胁。Web2.0 蠕虫由用户驱动（被动的或主动的），加上一些社工技巧，这将很难防御。

4、ClickJacking 蠕虫

• ClickJacking 蠕虫的由来：2009 年初 Twitter 上发生的“Don't Click”蠕虫事件。

• ClickJacking 蠕虫技术原理分析：技术分析：首先，攻击者使用 ClickJacking 技术制作蠕虫页面，该页面的URL 地址使用 TINYUR L短地址转 http://tinyurl.com/amgzs6；设计要点：对 iframe 和 button 标签进行CSS 样式设定，放置 iframe 标签所在层为透明层，使 iframe 标签所在层位于 button 标签所在层的正上方；要发动 ClickJacking 蠕虫攻击，满足以下两点必要条件即可（在 SNS 社区网络中，找到一个可以直接使用HTTP 的 GET 方式提交数据的页面；这个页面可以被 <iframe> 标签包含；）。

• Facebook 的 LikeJacking 蠕虫：Facebook 遭遇的 LikeJacking 蠕虫攻击；Facebook 中有一项插件服务，叫“Like Button”。用户可以在自己的博客或自己的网站中加入“Like Button”，访客浏览时，可以单击这个按钮表示自己喜欢这篇文章。当单击结束后，访客点击的状态信息会在访客的 Facebook 页面上以状态更新的方式显示出来；攻击者可以使用 ClickJacking 技术欺骗访客单击这个“Like Button”。

• GoogleReader 的 ShareJacking 蠕虫：非常流行的“一键分享”功能插件；这种插件可以让用户把在网络中看到的好文章或好资源直接以广播消息的形式发布到自己的社区和好友们进行分享；除了发现 Google Reader 存在 ShareJacking 蠕虫攻击外，还发现国内 SNS 环境中腾讯微博、腾讯空间、腾讯朋友、搜狐微博、人人网、淘江湖均存在这种攻击。

• ClickJacking 蠕虫爆发的可能性：分享已经是当前 SNS 网络中一个很重要的社交内容。只要是带有共享性质的网络社区，都有可能会遭受到ClickJacking蠕虫的攻击；Twitter的一键分享页面http://twitter.com/intent/twe...，Facebook 的一键分享页面 http://www.facebook.com/share... Busting脚本来进行抵御。

十、关于防御

1、浏览器厂商的防御

• HTTP 响应的 X- 头部：HTTP 响应的扩展头部字段都以 X- 打头，用于区分标准的头部字段；与前端安全有关的头部字段有如下几个：X-Frame-Options、X-XSS-Protection、X-Content-Security-Policy：

• X-Frame-Options 的值有以下两个：DENY（禁止被加载进任何frame）、SAMEORIGIN（仅允许被加载进同域内的 frame）。

• X-XSS-Protection 的值有以下三个：0（表示禁用）、1（默认，对危险脚本做一些标志或修改，以阻止在浏览器上渲染执行，Chrome 和 IE 这方面的行为是有差异的）、1:mode=block（强制不渲染，在Chrome下直接跳转到空白页，在IE下返回一个#符号）。

• 迟到的 CSP 策略：前面提到 Web 前端混乱局面，比如 IE 下的 CSS 的 expression 可以写 JavaScript，再如，HTML 的标签 <script>、标签 on 事件、标签 style 属性、标签 src/href/action 等属性都可以内嵌JavaScript 执行；HTML 仅做 HTML 的事，JavaScript/CSS 都通过加载独立文件的方式被执行。JavaScript/CSS 独立文件所在的域可以配置为白名单，这样就能有效地防止加载攻击者域上的相关资源文件。这大大提高了 XSS 攻击的难度，这就是 CSP 策略的最大设计初衷；CSP 策略使得 Web 前端更有序，从而更安全，这是一个好趋势，W3C 已经在大力推进这样的策略；目前，Chrome 支持 CSP 策略的头部是 X-WebKit-CSP，而不是标准的 X-Content-Security-Policy；下面举几个应用 CSP 的场景：

• 不允许任何外部的资源加载，且允许内嵌脚本执行。

• 仅允许白名单的外部资源加载，不允许内嵌脚本执行。

2、Web厂商的防御

• 域分离：域分离做得好的可以参考 Google，Google 将一些业务关联性小的内容转移到了不相干的域中。

• 安全传输：Google 很多重要的业务都完美地支持 HTTPS 安全传输（包括搜索）。安全传输可以有效地防止局域内的明文抓包。

• 安全的 Cookie：可以学学 Google，某些身份认证相关的 Cookie 肯定严格设置为 HTTPS 传输，肯定是 HttpOnly 标志，这样 XSS 即使盗取了 Cookie，也无法正确使用。

• 优秀的验证码：验证码的出现肯定降低了用户体验，但是这个降低阈值是可以控制好的；Google 的验证码公认是比较安全的（字母连着、扭曲变形、线条平滑、无噪等），暴力破解很困难，这也带来了用户体验上的尴尬，经常会输错验证码，说明Google非常重视安全，宁可牺牲一点用户体验。

• 慎防第三方内容：第三方内容的安全性是经常被大家提起的，常见的有以下几种形式：<script> 引用第三方 js 文件；<iframe> 引用第三方HTML文件；<object> 等引用第三方 Flash 等资源。

• XSS 防御方案：一些防御策略（输入校验：长度限制、值类型是否正确、是否包含特殊字符等；输出编码：根据输出的位置进行相应的编码，如 HTML 编码、JavaScript 编码、URL 编码）。

• CSRF 防御方案：针对 CSRF 攻击的防御，目前常用的有以下几种策略（1.检查 HTTP Referer 字段是否同域；2.限制 Session Cookie 的生命周期；3.使用验证码；4.使用一次性 token）；一般防御 CSRF 有三种方法：判断 Referer、验证码、token；验证码的弊端很明显：会对用户造成影响；token 存在的问题是：时效性无法保证；token 防 CSRF 的原理是：无法通过 AJAX 等方式获得外域页面中的 token 值，XMLHttpRequest需要遵守浏览器同源策略；而临时 Cookie 的原理是：Cookie 只能在父域和子域之间设置，也遵守同源策略。

• 界面操作劫持防御：基于界面操作劫持的攻击模式是用巧妙的视觉欺骗的方式，对 Web 会话进行劫持；基于界面操作劫持的攻击模式是用巧妙的视觉欺骗的方式，对 Web 会话进行劫持；目前针对界面操作劫持的防御有以下几种（1.X-Frame-Options 防御：由微软提出来的防御界面操作劫持的一种方法，Web 开发人员可以在HTTP 响应头中加入一个X-Frame-Options头，浏览器会根据 X-Frame-Options 字段中的参数来判断页面是否可以被 iframe 嵌入；2.Frame Busting 脚本防御：使用 JavaScript 脚本来对页面进行控制，达到页面无法被iframe嵌入的目的，这样的防护脚本被称为 Frame Busting 脚本；3.使用 token 进行防御：在业界主流的防御界面操作劫持攻击的方法中，似乎并没有提及防御 CSRF 中的 token 也可以对其进行防御；）；X-Frame 和 Frame Busting 方法都可以做到对界面操作劫持的防御。相对而言，X-Frame-Options 的方式还是比 Frame Busting 更安全。X-Frame-Options 是在浏览器中嵌入的，而 Frame Busting 是脚本控制。这意味着 JavaScript 代码始终有被突破的可能性。

3、用户的防御

• 使用安全浏览器组合：Firefox 浏览器 +NoScript 插件：NoScript 插件是由Web前端安全牛人 Giorgio Maone 主力研发，众多该领域牛人的贡献可谓是安全插件的精品，能防御 DOM 与反射型 XSS、ClickJacking，能强制进行 HTTPS 请求等，还能默认拦截所有网站的 JavaScript、Flash、Java 等

• 自身安全意识 - 遵守信任最小原则。

4、邪恶的 SNS 社区

• SNS 里的攻击围绕着信任关系进行的，其特点是：人们往往信任自己熟悉的人，信任程度的高低一般取决于熟悉的程度与目标本身的信誉。