Web开发安全

这是我参与「第四届青训营」笔记创作活动的第1天，今天的课程是从攻击者和防御者两个角度，分析理解前端工程师面对的一些Web安全防护知识

攻击篇

1.Cross-Site Scripting（XSS）:

主要是工程师把用户提交的字符串，转为 DOM。

特点：
1.难以从 UI 上感知；
2.窃取用户消息（cookie/token）
3.绘制 UI （例如弹窗）,诱骗用户点击

$~~~~~$ XSS攻击分为好几类：

Stored XSS（存储型 XSS 攻击）：其危害性最大，对全部用户可见。该恶意脚本存在数据库里面，而我们访问页面时，服务端就会读写数据，然后把数据写到我们的浏览器中，只要有这个过程，我们就会收到攻击。

Reflected XSS（反射型 XSS 攻击）：从 URL 上攻击。简单说就是在 URL 中的 param 中插入一段 script ，而这段 script 是一段恶意的字段，当我们访问页面时，就会受到攻击，这是基于把恶意字段插入到服务器，进而发起的攻击。

DOM-based XSS（基于浏览器的 XSS 攻击）：不需要服务器，直接在浏览器中攻击。跟反射型 XSS 有点相似的是，可以从 param 中插入一段恶意的 script ，当读取到这段 script 时，就会创建一个 HTML 标签，并且把恶意字段对应的值，写入 HTML 标签中，再把这个 HTML 插入到 innerHTML ，最后插入到页面的 body 中，这是基于把恶意字段插入到浏览器，发起的攻击。

Mutation-based XSS（基于 Mutation 的 XSS 攻击）：不同浏览器渲染的机制有所区别，有时候一段代码在一个浏览器可以正常渲染，但是在另外一个浏览器渲染时，会出现语法错误，报出error，攻击者利用这一特性，发起 XSS 攻击。

2.Cross-Site request forgery（CSRF）:

特点：
1.在用户不知情的前提下；
2.利用用户权限（cookie）
3.构造指定 HTTP 请求，窃取或修改用户敏感信息

$~~~~~~~$ 简单举个例子，我们收到一份恶意邮件，点击后访问了一个恶意页面，而页面的构造者在页面中写了一个 HTTP，向银行发起请（当然啦，这个请求是在另外一个域名），因为我们之前点击加入过这个页面，所以里面会获取我们的 cookie，所以攻击者通过这个页面，获取了我们的 cookie，并且向银行发起请求，银行验证通过 cookie 后，就可以拿走我们的存款了。我们可能没有访问银行页面，可是我们银行的 cookie 被获取了，所以一样被骗钱。

3.Injection :

分为以下几类：

SQL Injection：攻击者发送 SQL 请求，其中一些 SQL 语句是直接以字符串的形式拼接的，里面涉及一些恶意命令（删除、修改数据库信息的命令等）。好比，通过发送一个用户名属性给服务器，但是攻击者会在属性后面，加上其他语句，当数据库解析到这个属性时，也会解析到后面的恶意命令。

CLI

OS command

SSRF（严格来说，这不是 injection，但是原理类似）

4.Denial of Service（Dos）:

通过某种方式（构造特定请求），导致服务器资源被大量消耗，来不及响应更多请求，导致请求挤压，进而服务器雪崩。

ReDoS：如果服务器中有一个贪婪正则表达式，那么攻击者可以植入一个容易发生回溯行为的字符串，让服务器的响应时间长，进而让接口吞吐量变小，导致服务器响应用户的数量降低。

DDoS：短时间内大量僵尸设备的请求流量，服务器无法及时完成全部请求，导致请求堆积，进而雪崩效应，无法请求新响应。（通过大量僵尸设备请求，把服务器搞卡）下图所表：攻击者发送大量 TCP 请求，这时 TCP 会发送 SYN 给服务器，服务器接收到 SYN 之后，会返回 ACK 和 SYN ，但此时，攻击者不返回 ACK，这会导致三次握手未完成，连接数不能被释放，如果越来越多连接数不能被释放，会达到一个最大连接数，这个时候，就没办法接收新的请求了。攻击特点是：直接访问 IP、任意 API 、消耗大量带宽

5.基于传输层的攻击，最主要的就是中间人攻击

被攻击的主要原因是：

明文传输
信息篡改不可知
对方身份未验证

防御篇

1.防御XSS

不要相信用户提交的内容，更不能把用户提交的内容直接转为 DOM，如果真是必须把用户的内容（图片，自定义跳转、Blob 动态生成 script等等）转为 DOM，则必须对内容进行扫描

2.防御 CSRF

通过 CSP 对服务器的响应头部进行限制。最主要的是对请求头部中的 Origin 和 Referrer 来判断请求是否来自于合法来源。 注：self 表示同源，下面一行表示 URL 为 https：//domain.com 才是同源
除了上面说的，从 Origin 和 Referrer 进行判断外，还有其他的，如：从 token 进行判断。这种防御方式，在服务器与用户进行信息传输中，先有页面，后有请求。

原理：服务器接收到请求后，先判断请求是否来自合法页面，如果合法，就把页面和 token 发送给用户，之后当用户请求页面中的接口 API 时，会把请求的 API 和 token 一同发送给服务器，服务器会验证再次发送过来的 token ，合法则发送验证后的 token 和用户请求的数据。

以上是防御那些来自不合法 URL 的请求，可是对于来自那些合法 URL 的攻击（攻击者自己是注册用户，用自己的 token 攻击），该怎么办呢？

攻击者通过在 button 标签嵌入 iframe 进行攻击（类似我们输入账号和密码后点击登录按钮，但是此时的登录按钮上面覆盖了 iframe ），我们可以在 X-Frame-Options 这个属性中进行设置，就可以很好地避免这一攻击。

3.防御 Injection

对于 SQL 的防御：
找到项目中查询 SQL 的地方，使用 prepared statement 进行预解析，虽然开销会大一些。

对于 SQL 以外的防御：

最小权限原则：避免使用 sudo || root 命令
建立IP白名单：拒绝异常 rm 操作
对 URL 类型参数进行协议、域名、IP 等限制：防止内网被突破

4.防御 Dos

从两个方面入手：
（1）过滤：在负载均衡和 API 网关层进行识别，对于有恶意攻击的进行过滤。
（2）抗量：所以流量必须经过 CDN 才能进行具体服务，快速自动扩容、非核心服务降级也是有效的措施。

5.防御中间人

基于传输层的防御，最有名的是 HTTPS

HTTPS 的特性：

可靠性：有对称加密和非对称加密两个部分
完整性（MAC验证）：传输内容除了有加密信息外，还包括加密信息的 hash，接收方会对加密信息再进行一个 hash 计算，并把计算后得到的 hash 跟发送过来的 hash 进行对比，对比后相同的，说明信息没被篡改。
不可抵赖性：数字签名

学习心得：

$~~~~~~~$ 本次课程的学习，让我的对 Web 安全的认识起了很大的推进作用，最开始，我对 Web 安全的了解是微乎其微的，把大量时间都投入到网页的开发上，对于 Web 的安全可以说是没有一个大概的意识。看完那天的课后，让我很快意识到 Web 的安全，也是一个前端开发工程师职务的重要部分，所以对于上面提到的常见的攻击和防御手段，我是参考了资料后，用自己可以理解的方式描述出来，可能会有些啰嗦，但对于我这种，在安全方面还是小白的人，还是可以容易接收的。

参考文献：CSDN

Web 安全防护开发 | 青训营笔记