浅谈前端安全

前端安全的范围

将Web安全问题按照发生的区域来分类，发生在浏览器、Web页面中的安全问题就是前端安全问题。

同源策略

同源：URL由协议、域名、端口和路径组成，如果两个URL的协议、域名和端口相同，则表示他们同源。

URL	是否同源	原因
http://test.test.com/dir2/other.html	是
http://test.test.com/dir/test.html	是
https://test.test.com/test.html	否	协议不同
http://test.test.com:8080/test.html	否	端口不同
http://test123.test.com/test.html	否	域名不同

浏览器的同源策略，限制了来自不同源的document或脚本，对当前document读取或设置某些属性。从一个域上加载的脚本不允许访问另外一个域的文档属性。

如果没有同源限制存在，浏览器中的cookie等其他数据可以任意读取，不同域下DOM可以任意操作，ajax可以任意请求。如果浏览了恶意网站那么就会泄漏这些隐私数据

在浏览器中，<script>、<img>、<iframe>、<link>等标签都可以加载跨域资源，而不受同源限制。

这些带src属性的标签每次加载时，实际上是由浏览器发起了一次GET请求。不同于XMLHttpRequest的是，通过src属性加载的资源，浏览器限制了JavaScript的权限，使其不能读、写返回的内容。

跨站脚本攻击（XSS）

XSS，即Cross Site Script（跨站脚本攻击）；为了和层叠样式表(Cascading Style Sheet)做出区分，在安全领域叫做 XSS。

XSS 攻击是指攻击者在网站上注入恶意的客户端代码，利用恶意脚本对客户端网页进行篡改，从而在用户浏览网页时，对用户浏览器进行控制或者获取用户隐私数据的一种攻击方式。有很多种方式进行 XSS 攻击，但它们的共同点为：将一些隐私数据像cookie、session发送给攻击者，将受害者重定向到一个由攻击者控制的网站，在受害者的机器上进行一些恶意操作。

攻击方式

反射型XSS

恶意代码并没有保存在目标网站，通过引诱用户点击一个链接到目标网站的恶意链接来实施攻击。

攻击流程：

1. A给B发送一个恶意构造的URL
2. B点击URL后跳转到具有漏洞的HTML页面
3. HTML页面在B浏览器中执行JavaScript，可以执行B所具有权限下的命令

存储型XSS

恶意代码被保存到目标网站的服务器中，这种攻击具有较强的稳定性和持久性，比较常见场景是在博客，论坛、OA、CRM等社交网站上。

攻击流程：

1. 攻击者提交一条包含XSS代码的留言或其他数据到数据库
2. 当目标用户查询时，XSS的内容会从服务器解析之后加载出来
3. 浏览器将恶意代码当作正常脚本解析执行，可以执行浏览器所具有权限下的命令

DOM Based XSS

基于DOM的XSS攻击是指通过恶意脚本修改页面的DOM结构，是纯粹发生在客户端的攻击。DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端JavaScript自身的安全漏洞。

攻击流程：

1. A给B发送一个恶意构造的URL
2. B点击URL后HTML页面获取攻击性的代码，如通过location.hash获取的参数等
3. 攻击性代码当作HTML代码写入页面
4. HTML页面在B浏览器中执行JavaScript，可以执行B所具有权限下的命令

防范手段

• 输入检查

  在源头控制，把用户输入的一些不合法的东西都过滤或者编码掉，从而保证安全性。如移除用户提交的的DOM属性如onerror，移除用户上传的节点，<iframe>，<script>，<a>节点等。

  一般业务中是对客户端和服务端中同时进行输入检查。

• 输出检查

  利用转义库对 HTML 模板各处节点进行充分的转义。

• 使用HttpOnly

  通过设置HttpOnly，浏览器可以禁止页面的JavaScript访问带有HttpOnly属性的Cookie。它的目的并非是为了对抗XSS，而是对抗XSS之后的Cookie劫持攻击。

  Cookie的使用过程：

  1. 浏览器向服务器发起请求，此时没有Cookie
  2. 服务器返回Set-Cookie头，向浏览器写入Cookie
  3. 在Cookie到期之前，浏览器访问该域下的所有页面，都将发送该Cookie

  HttpOnly是在Set-Cookie的时候进行标记的

  Set-Cookie： <name>=<value>[; <Max-Age>=<age>]
  [; expires=<date>][; domain=<domain_name>]
  [; path=<some_path>][; secure][; HttpOnly]

• 输入内容长度限制

  对输入的内容限定合理长度，可以增加XSS攻击的难度

• 避免拼接HTML或者使用内联事件

  前端使用拼接HTML或者内联事件的情况比较危险，建议替换为createElement、setAttribute及addEventListener的实现方法，或者采用成熟的框架进行渲染，如vue/react等

• 开启CSP网页安全政策（Content Security Policy）

  一种由开发者定义的安全性政策申明，通过CSP所约束的责任指定可信的内容来源，（内容可以是指脚本、图片、style 等远程资源）。

  CSP 的实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。

  开启方式：

  • 通过HTTP头信息的Content-Security-Policy字段
  • 在网页中设置<meta>标签

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">

跨站点请求伪造（CSRF）

跨站请求伪造攻击，原理就是攻击者构造出一个后端请求地址，诱导用户点击或者通过某些途径自动发起请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，冒充用户执行某些操作。

攻击流程

1. 被攻击者登录A站点，并保留了登陆凭证
2. 攻击者诱使被攻击者访问B站点
3. B站点向A站点发起请求，浏览器会默认携带A站点的Cookie
4. A站点接收请求后会对其进行验证，而且会误认为是被攻击者发起的请求，同时以被攻击者的身份执行相应的操作

攻击方式

• GET类型

  一般是利用<img>标签等发起

  <img src="http://test.com/test?test=test">

  在被攻击者访问页面时，浏览器会自动向src指向的地址发出请求

• POST类型

  通常是构造一个自动提交的表单在页面上，模拟用户完成了一次POST操作

• 链接类型

  通常是需要诱骗用户点击才会触发

攻击特点

• 攻击一般发生在第三方站点，被攻击站点无法防止攻击发生
• 攻击手段为冒充受害者提交操作，而非直接窃取数据
• 攻击过程中攻击者并不能获取到用户的登陆凭证，而只是冒充

防范手段

• 验证码

  通过增加网站A的验证手段，例如增加图形验证码或短信验证码等等，只有通过验证的请求才算合法。但是这种方案拥有两个局限性，一个是增加开发成本，另外一个是降低用户体验。

• 验证Referer

  根据 HTTP 协议，在 HTTP 头中有一个字段叫Referer，它记录了该 HTTP 请求的来源地址。通过验证Referer，可以检查请求是否来自合法的"源"。

• 验证Token

  服务端随机生成token，保存在服务端session中，同时保存到客户端中，客户端发送请求时，把token带到HTTP请求头或参数中，服务端接收到请求，验证请求中的token与session中的是否一致。如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

电脑刺绣绣花厂 http://www.szhdn.com 广州品牌设计公司https://www.houdianzi.com

点击劫持

在一个Web页面下隐藏了一个透明的iframe（opacity：0），用外层假页面诱导用户点击，实际上是在隐藏的frame上触发了点击事件进行一些用户不知情的操作。

攻击流程

1. 攻击者构造一个诱导用户点击的内容，将页面放入到<iframe>
2. 利用z-index和opacity将<iframe>叠加到实际页面上方并透明化
3. 受害者访问到欺骗页面后，实际看到的是诱使点击的内容，点击之后则是有害页面

攻击方式

• 盗取用户资金
• 获得用户敏感信息
• 与XSS或者CSRF相配合，诱骗用户点击恶意链接

防范手段

• 设置X-FRAME-OPTIONS

  服务器端可设置HTTP头X-Frame-Options：DENY来让浏览器主动禁止<iframe>内嵌，但是这种方式需要结合HTTPS来实现，因为HTTP不可靠，容易被窃听篡改内容