前端安全—常见的攻击方式及防御方法

Cookie挟持

HTTP是无状态的协议，为了维持和跟踪用户的状态，引入了Cookie和Session。 Cookie包含了浏览器客户端的用户凭证，相对较小。Session则维护在服务器，用于维护相对较大的用户信息。可以把Cookie当成密码，而Session是保险柜。由于HTTP是明文传输，Cookie很容易被盗取，如果被盗取，别人就可以冒充你的身份，打开你的保险柜，获取你的信息，动用你的资金，这是很危险的。

Cookie和Session的关系可以看这篇：浅谈session和cookie的关系

1.危害

盗取cookie信息，冒充他人身份，盗取信息。

2.防御

• 给cookie添加HttpOnly属性，该属性设置后，只能在http请求中传递，在脚本中，document.cookie无法获取到该cookie值，对XSS攻击有防御作用，但对网络拦截还是会泄露。
• 在cookie中添加校验信息，这个校验信息和当前用户外置环境有些关系，比如ip、user agent等有关.这样当cookie被人劫持冒用时，在服务器端校验的时候，发现校验值发生了变化，因此会要求用户重新登录，可以规避cookie劫持。
• cookie中session id的定时更换，让session id按一定频率变换，同时对用户而言，该操作是透明的，这样保证了服务体验的一致性。

XSS跨站脚本攻击

攻击者在web页面恶意插入HTML或script标签，当用户浏览该页面时，恶意代码就会被执行，从而达到攻击的目的。XSS利用的是用户对指定网站的信任。

1.类型

• 反射型(非持久)：攻击者事先制作好攻击链接,需要欺骗用户自己去点击链接才能触发XSS代码，所谓反射型XSS就是将恶意用户输入的js脚本，反射到浏览器执行。

• 储存型(持久型)：会把攻击者的数据储存到服务端，攻击行为将伴随攻击数据一直存在，每当用户访问该页面就会触发代码执行。

• DOM型：基于文档对象模型的漏洞。 最经典的存储型XSS漏洞是留言板，当用户A在留言板留言一段JS代码<script>alert("run javascript");</script>,后端未经过滤直接存储到数据库，当正常用户浏览到他的留言后，这段JS代码就会被执行，可以借此来盗取cookie。

2.危害

• 盗取网页浏览中的cookie值，盗用cookie实现无密码登录，盗取用户信息。
• 劫持访问，实现恶意跳转。
• 配合CSRF攻击完成恶意请求。

3.防御方法

• 标签过滤，如<script>、<img>、<a>标签等
• 编码，对字符< 、>、&、" 、' 、+、/等进行转义。
• cookie防盗，将cookie设置为http-only,js脚本将无法读取到cookie信息。
• 纯前端渲染，明确innerText、setAttribute、style，将代码与数据分隔开。
• 避免不可信的数据拼接到字符串中传递给这些API，如DOM中的内联事件监听器，location、onclick、onload、onmouseover等，<a>标签的href属性，JavaScript的eval()、setTimeout()、setInterval()等，都能把字符串作为代码运行。

CSRF跨站点请求伪造

顾名思义就是通过伪造连接请求，在用户不知情的情况下，让用户以自己的身份来完成非本意操作的攻击方法。CSRF利用的是网站对浏览器的信任。

1.原理

1. 用户C浏览并登录信任网站A,产生cookie
2. 用户C未退出网站A，在同一个浏览器危险访问网站B
3. 网站B的页面存有一些攻击性的代码，会发出访问A的请求
4. 浏览器收到请求后，在用户不知情的情况下携带cookie访问网站A
5. A不知道请求是谁发的，浏览器会带上用户的cookie，所以A会根据用户的权限处理B发出的请求。这样就达到了攻击的目的。

2.防御

• 验证码：对敏感操作加入验证码，强制用户与网站进行交互
• 对Cookie设置SameSite属性。该属性表示Cookie不随着跨域请求发送，可以很大程度减少CSRF的攻击，但是该属性目前并不是所有浏览器都兼容。
• 使用POST请求，避免使用GET，降低攻击风险，post请求攻击方需要构造一个form表单才可以发起请求，比get请求（img的src，a标签的href等等）的攻击方式复杂了一些，相对来说能降低风险，但不能阻止。
• 检查HTTP中的referer字段，该字段记录了HTTP请求的来源地址
• 在请求头中加入token验证字段，浏览器并不会自动携带Token去请求，且Token可以携带一段加密的jwt用作身份认证，这样进行CSRF的时候仅传递了cookie，并不能表明用户身份，网站即拒绝攻击请求。
• 在http中自定义属性并验证。

点击挟持

• ClickJacking点击劫持

当访问某网站时，利用CSS将攻击者实际想让你点击的页面进行透明化隐藏，然后在页面后显示 一些东西诱导让你点击，点击后则会在用户毫不知情的情况下做了某些操作，这就是点击劫持ClickJacking。
案例：当我们点击弹窗右上角的"X"想关闭弹窗事，跳转到其他页面。

• iframe覆盖

第三方网站通过iframe内嵌某一个网站，并且将iframe设置为透明不可见，将其覆盖在其他经过伪装的DOM上，伪装的可点击DOM（按钮等）与实际内嵌网站的可点击DOM位置相同，当用户点击伪装的DOM时，实际上点击的是iframe中内嵌的网页的DOM从而触发请求操作。

防御

• Javascript禁止内嵌：当网页没有被使用iframe内嵌时，top和window是相等的；当网页被内嵌时，top和window是不相等的；可以在本网站的页面中添加如下判断：

  <script> if (top.location != window.location) { //如果不相等，说明使用了iframe，可进行相关的操作 } </script>
  

  但是这种方式并不是万能的，因为iframe标签中的属性sandbox属性是可以禁用内嵌网页的脚本的：

  <iframe sandbox='allow-forms' src='...'></iframe>
  

• 设置http响应头X-FRAME-OPTIONS是目前最可靠的方法。X-FRAME-OPTIONS是微软提出的一个HTTP头，专门用来防御利用iframe嵌套的点击劫持攻击。

DENY // 禁止内嵌
SAMEORIGIN // 只允许同域名内嵌
ALLOW-FROM // 指定可以内嵌的地址

• 一些辅助手段，比如添加验证码，提高用户的防范意识

中间人攻击(MITM攻击)

中间人攻击(man-in-the-middle attack, abbreviated to MITM)，简单的讲，就是黑客悄悄的躲在通信双方之间，窃听甚至篡改通信信息。而通信双方的对方已经变成中间人了，不是原本的通信对方，但它们并不知道消息已经被截获甚至篡改了。

Https协议简析及中间人攻击原理

URL漏洞跳转

定义：借助未验证的URL跳转，将应用程序引导到不安全的第三方区域，从而导致的安全问题。

1.原理

原理：黑客构建恶意链接(链接需要进行伪装,尽可能迷惑),发在QQ群或者是浏览量多的贴吧/论坛中。安全意识低的用户点击后,经过服务器或者浏览器解析后，跳到恶意的网站中。

恶意链接需要进行伪装,经常的做法是熟悉的链接后面加上一个恶意的网址，这样才迷惑用户。

2.防御

• 检查HTTP中的referer字段，该字段记录了HTTP请求的来源地址，可以验证该URL的有效性
• 在请求头中加入token验证字段，浏览器并不会自动携带Token去请求，且Token可以携带一段加密的jwt用作身份认证，这样进行

SQL注入

SQL注入是一种常见的Web安全漏洞，攻击者利用这个漏洞，可以访问或修改数据，或者利用潜在的数据库漏洞进行攻击。

1.原理

我们先举一个万能钥匙的例子来说明其原理：

后端的 SQL 语句可能是如下这样的：

SELECT * FROM user WHERE username='admin' AND psw='password'

但是恶意攻击者用奇怪用户名将你的SQL语句变成了如下形式：

SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'

在SQL中, ' --是闭合和注释的意思，– 是注释后面的内容的意思，所以查询语句就变成了：

SELECT * FROM user WHERE username='admin'

所谓的万能密码,本质上就是SQL注入的一种利用方式。

一次SQL注入的过程包括以下几个过程：

• 获取用户请求参数
• 拼接到代码当中
• SQL语句按照我们构造参数的语义执行成功

SQL注入的必备条件：
1.可以控制输入的数据
2.服务器要执行的代码拼接了控制的数据。

我们会发现SQL注入流程中与正常请求服务器类似，只是黑客控制了数据，构造了SQL查询，而正常的请求不会SQL查询这一步，SQL注入的本质:数据和代码未分离，即数据当做了代码来执行。

2.危害

• 获取数据库信息

  • 管理员后台用户名和密码
  • 获取其他数据库敏感信息：用户名、密码、手机号码、身份证、银行卡信息……
  • 整个数据库：脱裤

• 获取服务器权限

• 植入Webshell，获取服务器后门

• 读取服务器敏感文件

3.如何防御

• 严格限制Web应用的数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而最大限度的减少注入攻击对数据库的危害
• 后端代码检查输入的数据是否符合预期，严格限制变量的类型，例如使用正则表达式进行一些匹配处理。
• 对进入数据库的特殊字符（’，”，，<，>，&，*，; 等）进行转义处理，或编码转换。基本上所有的后端语言都有对字符串进行转义处理的方法，比如 lodash 的 lodash._escapehtmlchar 库。
• 所有的查询语句建议使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中，即不要直接拼接 SQL 语句。例如 Node.js 中的 mysqljs 库的 query 方法中的 ? 占位参数。

OS命令注入攻击

OS命令注入和SQL注入差不多，只不过SQL注入是针对数据库的，而OS命令注入是针对操作系统的。OS命令注入攻击指通过Web应用，执行非法的操作系统命令达到攻击的目的。只要在能调用Shell函数的地方就有存在被攻击的风险。倘若调用Shell时存在疏漏，就可以执行插入的非法命令。

命令注入攻击可以向Shell发送命令，让Windows或Linux操作系统的命令行启动程序。也就是说，通过命令注入攻击可执行操作系统上安装着的各种程序。

1.原理

黑客构造命令提交给web应用程序，web应用程序提取黑客构造的命令，拼接到被执行的命令中，因黑客注入的命令打破了原有命令结构，导致web应用执行了额外的命令，最后web应用程序将执行的结果输出到响应页面中。

我们通过一个例子来说明其原理，假如需要实现一个需求：用户提交一些内容到服务器，然后在服务器执行一些系统命令去返回一个结果给用户

// 以 Node.js 为例，假如在接口中需要从 github 下载用户指定的 repo
const exec = require('mz/child_process').exec;
let params = {/* 用户输入的参数 */};
exec(`git clone ${params.repo} /some/path`);

如果 params.repo 传入的是 https://github.com/admin/admin.github.io.git 确实能从指定的 git repo 上下载到想要的代码。
但是如果 params.repo 传入的是 https://github.com/xx/xx.git && rm -rf /* && 恰好你的服务是用 root 权限起的就糟糕了。

2.如何防御

• 后端对前端提交内容进行规则限制（比如正则表达式）。
• 在调用系统命令前对所有传入参数进行命令行参数转义过滤。
• 不要直接拼接命令语句，借助一些工具做拼接、转义预处理，例如 Node.js 的 shell-escape npm包

参考文档：常见六大Web安全攻防解析