这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天
攻击篇
Cross-Site Scripting(XSS)
XSS主要利用了：
- 开发者盲目信任用户的提交内容
- 开发者直接把用户提交的字符串转化成了DOM
XSS的特点
- 通常难以从UI上感知（暗地执行脚本）
- 切勿用户信息(cookie/token)
- 绘制UI，诱骗用户点击/填写表单
XSS demo
Stored XSS
- 恶意脚本被存在数据库中
- 访问页面 + 读数据 = 被攻击
- 危害最大，对全部用户可见
Reflected XSS
- 不涉及数据库
- 从URL上攻击
DOM-based XSS
- 不需要服务器的参与
- 恶意攻击的发起和执行全在浏览器完成
Mutation-based XSS
- 利用了浏览器渲染DOM的特性（独特优化）
- 不同浏览器会有区别（按浏览器进行攻击）
跨站请求伪造(CSRF)
- 在用户不知情的前提下
- 利用用户权限 （如cookie）
- 构造指定HTTP请求，窃取或修改用户敏感信息
跨站请求伪造 demo
Injection
SQL Injection
注入其实并不局限于SQL注入，还有诸如：
- CLI
- OS Command
- Server-Side Request Forgery(SSRF) 服务端伪造请求
Denial of Service(DoS)
ReDos：利用正则表达式，通过构造容易发生回溯行为的字符串，导致服务器响应时间大大延长，响应用户请求的次数大大下降。
DDoS：短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求导致请求堆积，进而雪崩效应，无法响应新请求。
防御篇
XSS
- 永远不信任用户的提交内容
- 不要将用户提交内容直接转换成D0M
XSS现成工具
-
前端
- 主流框架默认防御XSS
- google-closure-library
-
服务端(Node)
- DOMPurify
插播：Same-origin Policy
- 协议
- 域名
- 端口
CSP
- 哪些源（域名）被认为是安全的
- 来自安全源的脚本可以执行，否则直接抛错
- 对eval+inline script说
CSRF的防御
尾声
-
安全无小事
-
使用的依赖(npm package,甚至是NodeJS)可能成为最薄弱的一环
- left-pad事件
- eslint--scope事件
- event-stream事件
-
npm install除了带来了黑洞，还可以带来漏洞
-
保持学习心态
