这是我参与「第四届青训营 」笔记创作活动的第6天
两个角度看Web安全
Hacker
XSS(Cross-Site Scripting)
在开发维护的页面中，攻击者通过一种方式将恶意脚本注入进来。
XSS主要利用了两点
- 开发者盲目信任用户提交的内容
- 前端工程师直接把用户提交的字符串转换成了DOM。如：
XSS的一些特点
- 通常难以从UI上感知
- 窃取用户信息
- 绘制UI，诱骗用户点击/填写表单
XSS可以分成几大类
- Strore XSS ：恶意脚本被存在数据库中；访问页面->读数据 被攻击；危害最大，对全部用户可见
- Reflected XSS ：不涉及数据库；从URL上攻击
- DOM-based XSS ：不需要服务器的参与；恶意攻击的发起+执行，全在浏览器完成
- Mutation-based XSS：利用了浏览器的渲染DOM的特性；不同浏览器，会有区别
CSRF(Cross-site request forgery)
CSRF最简单的实现方式是使用GET请求，如a标签，img标签等，当然也不只是可以用GET请求来实现CSRF攻击，通过构建表单使用POST请求也是可以实现的
Injection
最常见的注入攻击是SQL注入
注入不局限于SQL注入，除此之外还有CLI、OS Command等 此外还有SSRF(Server-Side Request Forgery)服务端伪造请求，与注入原理类似
DOS(Denial of Service)
通过某种方式（构造特定请求），导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩效应
正则表达式——贪婪模式
DOS分为几种：
- ReDoS：基于正则表达式的DoS
- DDoS(Distributed DoS) 短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应新请求。 攻击特点：直接访问IP；任意API；消耗大量带宽
基于传输层的攻击方式
中间人攻击
开发者
防御XSS
- 永远不信任用户的提交内容
- 不要将用户提交内容直接转换成DOM
防御XSS现成工具
前端：
- 主流框架默认防御XSS
- google-closure-library
服务端
- DOMPurify
CSP(内容安全策略)
- 哪些源（域名）被认为是安全的
- 来自安全源的脚本可以执行，否则直接抛错
- 对eval+inline script 说 🈲🈲🈲
CSRF的防御
Origin + Referrer
CSRF——token
iframe攻击
anti-pattern
GET != GET+POST，要把GET和POST请求区分开
SameSite Cookie
SameSite vs CORS
Injection
- 所有命令都不要通过sudo来执行，不要给root权限。
- 要建立一个白名单的机制，只允许指定命令执行
- 对参数类型进行协议、域名、ip等限制
如下图：
防御DOS
Regex Dos
DDoS
传输层防御中间人
HTTPS的一些特性
- 可靠性：加密
- 完整性：MAC验证
- 不可抵赖性：数字签名
完整性
数字签名
