这是我参与「第四届青训营」笔记创作活动的的第4天
标题：「Web 开发的安全之旅」第四届字节跳动青训营 - 前端专场
攻击
Cross-Site Scripting（XSS）
盲目信任用户的提交内容
XSS的特点： -通常难以从UI上感知（暗地执行脚本） -窃取用户信息（cookie/token） -绘制UI（例如弹窗），诱骗用户点击/填写表单
可以直接提交恶意脚本
Stored XSS
恶意脚本被存在数据库中 访问页面 -> 读数据 = 被攻击 危害最大，对全部用户可见
eg. Reflected XSS Demo
host/path/?param=<script>alert('123')</scrpit>
DOM-based XSS demo
const concent = new URL(localtion.href)searchParams.get("param");
const div = document.creatElement("div");
//恶意脚本注入
div.innerHTML = content;
document.body.append(div);
Mutation-based XSS
利用了浏览器渲染DOM的特性（独特欧化） 不同浏览器会有区别（按浏览器进行攻击）
最难防御的方式
Cross-site request forgery(CSRF) 跨站伪造请求
SQL Injection
CLI; OS command;
Server-Slide Request Forgery(SSRF)， 服务器伪造请求（严格来说不是Injection)
DoS Denial of Service
通过某种方式（构造特定请求），导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩效应。
正则表达式--贪婪模式
ReDos:基于正则表达式的DoS
DDos Distributed DoS 量大 攻击特点： 直接访问IP 任意API 消耗大量带宽
SYN FLood
传输层攻击
中间人攻击出现的原因： 明文传输 信息篡改不可知 对方身份未验证
防御篇
XSS
永远不要相信用户提交的内容，不要直接转换成DOM，当成String对待
现成方式：
如果用户需求必须动态生成DOM： 对String转义 对svg图片扫描 小心自定义跳转链接 自定义样式
播插：Same-origin-Policy 协议 域名 端口通通相等
Content Security Policy（CSP） 那些源是被认为安全的 来自安全源的脚本可以执行，否则直接抛错 对eval + inline script说no
CSRF的防御
CSRF-token
CSRF-iframe攻击
避免用户信息被携带：SameSite Cookie
限制的是Cookie Domain和页面域名
依赖Cookie的第三方服务怎么办？
Set-Cookie: SameSite = None; Secure;
SameSite VS CORS
SameSite demo
FirstPartyCookie 3PartyCookie
防御CSRF的正确姿势 Middlewares：专门生成各种防御CSRF的策略
Injection beyond SQL
防御中间人
HTTPS的一些特性
插播：数字签名
HTTPS-不可抵赖：数字签名
HTTP Strict-Transport-Security(HSTS)
SRI-demo
