攻击篇

Cross-Site Scripting(XSS)(跨站脚本攻击)

攻击者想方设法的把他们的恶意脚本插到页面中，去执行，完成攻击。

主要是利用：

盲目信任用户的提交内容
string -> DOM
- document . write
- element . innerHTML = anyString ;
- SSR(user_ data) //伪代码

特点：

通通常难以从UI . 上感知(暗地执行脚本)
窃取用户信息(cookie/token)
绘制UI(例如弹窗)，诱骗用户点击/填写表单，提供更多的隐私信息

存储型XSS攻击(Stored XSS)

特点：

恶意脚本被存在数据库中
访问页面 -> 读数据 ===被攻击
危害最大，对全部用户可见

例子：如果你在看视频，你的账号密码被别人用XSS攻击得到了，那么从此电商网站多了一个爱奇艺共享账户

反射性XSS攻击(Reflecied XSS)

特点：

不涉及数据库
直接从URL上攻击

Demo：

基于DOM的XSS攻击(DOM – based XSS)

特点：

不需要服务器的参与
恶意攻击的发期+执行，全在浏览器完成

Demo：

Reflected vs DOM-based

两者不同点：注入脚本的位置不同

前者是在服务器注入脚本
后者是在浏览器注入脚本

基于Mutation的XSS攻击（Mutation-based XSS）

特点：

利用了浏览器渲染DOM的特性（独特优化）
不同浏览器，会有区别（按浏览器进行攻击）

Demo:

Cross-site request forgery(CSRF)(跨站伪造请求)

特点：

在用户不知情的前提下
利用用户权限(cookie)
构造指定HTTP请求,窃取或修改用户敏感信息

CSRF-GET（构造get请求）

主动：构造了一个A标签，用户点击A标签，就会造成请求，完成攻击

被动：访问页面就会发出get请求，完成攻击

CSRF-beyond GET

攻击者利用HTML的form表单，去构造任意请求，通过input type=”hidden”去构造各种值

Injection （注入攻击）

SQL Injection

Demo 1

①读取请求字段

②直接以字符串的形式拼接SQL语句

攻击者可以构造一个请求，传递一个username，内容是任意字符串+;+Drop table，执行时，就会变成：选择 -> 删表。被动删库跑路成就达成！

Injection不至于SQL

CL I
os command
Server- Side Request Forgery(SSRF), 服务端伪造请求
严格而言，SSRF不是injection, 但是原理类似

demo 2 — 执行

攻击者可以把options字段传递为：用&& 拼接rm -rf xxx，就是删除，然后执行时，服务器文件会被删除，项目直接无了。

读取+修改

Denial of Service(DoS)

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

插播：正则表达式-贪婪模式

概念：重复匹配一个模式的时候，会不会用到问号，如果用到的话，就是满足一个即可，如果没有问号，就是贪婪模式，问好越多越好

ReDoS：基于正则表达式的DoS

贪婪：n次不想？n-1次再试试？-回溯

Distributed DoS(DDoS)

短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应新请求。

【不用搞复杂的，量大就完事了】

特点：

直接访问IP
任意API
消耗大量带宽（耗尽）

SYN Flood洪水攻击

传输层

中间人攻击

为什么会遭受中间人攻击：

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

防御篇

XSS

核心防御理念：

永远不要信任用户提交的内容
不要将用户提交的内容直接转换成DOM

线程框架

前端

主流框架默认防御XSS
google-closure-library

服务端(Node)

DOMPurify

【用户需求】不讲武德，必须动态生成DOM

string -> DOM

一定要对string进行过滤

上传svg

也要进行过滤svg文件

自定义跳转链接

也要过滤，最好不要允许用户跳转链接

自定义样式

插播：same-origin Policy（同源策略）

同源：针对两个url，只有他们两个之间域名、协议、端口全部相同的时候，才叫同源，否则就是不同源

这三个都不是同源，域名不同，协议不同、端口也不同

Content Security Policy(CSP)(内容安全策略)

特点：

哪些源(域名)被认为是安全的
来自安全源的脚本可以执行，否则直接抛错
对eval + inline script说不

在服务器的响应头部

浏览器meta标签

CSRF的防御

if伪造请求= E异常来源

then限制请求来源→限制伪造请求

0rigin

-同源请求中，GET + HEAD不发送
一Rerefer

除了Origin+Rerefer，还有没有其他方式，帮助我们判断请求来源合法还是非法

if (请求来自合法页面)
then (服务器接收过页面请求)
then (服务器可以标识)

token

①用户绑定：攻击者也可以是注册用户===可以获取自己的token

②过期时间：[前向保密]

iframe攻击

CSRF anti-pattern

GET !== GET + POST

避免用户信息被携带：SameSite Cookie

含义：只有同源请求才能发送当前的Cookie，跨域不能。

三个值：None（上古），Lax（选择），Strict（最复杂）

防御CSRF的真确姿势

不是Case by Case的防御，应该在中间件中统一处理

Injection

找到项目中查询SQL的地方
使用prepared statement

njection beyond SQL

最小权限原则
- 不能sudo|| root
建立允许名单+过滤
- 不允许rm删除语句
对URL类型参数进行协议、域名、ip等限制
- 保证不能访问内网.

DDoS

流量治理
- 负载均衡（过滤）
- API网关（过滤）
- CDN（抗量）
快速自动扩容（抗量）
非核心服务降级（抗量）

DDoS攻击主要是运维方面的人员去防御，我们不用考虑太多

传输层–防御中间人

最新的HTTP3已经内置了TLS1.3

HTTPS的一些特征

可靠性:加密完整性
MAC验证
不可抵赖性:数字签名

TLS握手

有两个过程：非对称加密，对称加密

非对称加密

浏览器会先向服务器提供一些加密套件的选项，服务器进行选择，并且返回服务器的证书，浏览器访问到证书后，进行校验，如果通过，按照双方协商好的加密算法，算出一个sessionKey，非对称加密阶段结束。

对称加密阶段

双方会利用刚刚生成的sessionKey，对所有传输的内容进行加密。

完整性

在刚刚的对称加密阶段，双方传递的所有信息的是加密信息，除此之外，还会传递一个加密信息的hash（哈希）值，接收方接收到hash之后，会取出加密信息，按照协商好的哈希计算，之后和传递过来的哈希值进行对比，如果两者相同，则意味着没有被篡改，反之，则可能信息被篡改。

插播：数字签名

数字签名执行者：

私钥privateKey（自己藏好）
公钥publicKey（公开可见）

不可抵赖：数字签名

所有的证书都是由一个CA(Certificate Authority)的机构进行签发

数字签名在HTTPS中的工作

首先由服务的原信息+公钥经由CA提供的私钥，进行签名，签名的产物就是服务器的证书，在非对称加密的阶段，可以传送给浏览器，用于浏览器验证身份，浏览器会使用CA颁发的公钥对证书进行验证，若通过，则证书可用，会取出证书里服务器的公钥。

CA从哪里获得公钥？

浏览器会在本地内嵌大量CA签发的证书，CA签发的证书会含有CA的公钥，所以浏览器在验证的时候都是使用本地的公钥进行验证

成也证书，败也证书

当签名算法不够健壮时：

HTTP Strict-Transport-Security(HSTS)

将HTTP主动升级到HTTPS

浏览器先向服务器以HTTPS的协议请求一个资源，服务器接收到这个请求之后，返回一个Strict-Transport-Security头部，这个头部会有一个值：max-age=xxxx，这个头部的含义在此时是：这个时间范围内，凡是通过HTTP请求这个资源的话，浏览器全部升级到HTTPS协议，之后浏览器真的以HTTP协议访问到这个资源，会自动升级成HTTPS协议，保证了请求的安全性。