这是我参与[第四届青训营]笔记创作活动的第5天。此笔记用于记录课上所讲内容。
一、Web安全一窥
安全问题很常见，会危害用户、公司、程序员
二、两个角度看web安全
1、假如你是一个hacker——攻击
①、XSS跨站脚本攻击：可能会造成用户隐私泄露
主要利用了盲目信任用户的提交内容，直接将用户提交的字符串转换成了DOM
特点：通常难以从UI上感知，窃取用户信息（cookie/token）、绘制UI，诱骗用户点击
分类：
Stored XSS：恶意脚本被存在数据库中；访问页面-》读数据==被攻击；危害最大，对全部用户可见
Reflected:不涉及数据库，从URL方面攻击
DOM-based XSS：不需要服务器的参与；恶意攻击的发起+执行，全在浏览器完成
Mutation-based XSS：利用了浏览器渲染DOM的特性（独特优化）；不同浏览器，会有区别（按浏览器进行攻击）
②Cross-site request forgery（跨站伪造请求）：在用户不知情的情况下，利用用户权限（cookie），构造指定HTTP请求，窃取或修改用户敏感信息
③SQL Injection
具体流程：SQL参数恶意注入请求，请求到达服务器端后，从HTTP请求中读参数形成SQL语句，运行SQL语句后导致攻击者获取了数据，可对数据进行恶意操作
Injection不止于SQL，还有CLI，OS command，Server-Side Request Forgery(SSRF),严格来讲，SSRF不是injection，但原理类似
Denial of Service（DoS）:通过某种方式（构造特定请求），导致服务器资源被显著消耗，来不及相应更多请求，导致请求挤压，进而雪崩效应
Distributed DoS（DDoS）：短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩效应，无法响应新请求\
攻击特点：直接访问IP，任意API，消耗带宽
基于传输层的攻击：
中间人攻击利用明文传输，信息篡改不可知，对方身份未验证进行攻击。
2、假如你是一个开发者——防御
针对XSS攻击：永远不信任用户提交的内容，不要讲用户提交的内容直接转成DOM
现成工具：前端：主流框架默认防御XSS，Google-closure-library
服务端：DOMPurify
如果用户需求必须动态生成DOM，那就要求上传svg，尽量不要让用户自定义跳转链接，自定义样式
Same-origin Policy(同源策略)：协议，域名，端口号全部一致则称为同源
Content Security Policy（CSP）：哪些源被认为是安全的，来自安全源的脚本可以执行，否则直接抛错；对eval+inline script禁止
CSRF的防御：
其他判断请求安全的方式：
CSRF的iframe攻击：
CRSF的anti-pattern：
避免用户信息被携带：SameSite Cookie
SameSite和CORS的比较：
注入相关的防御：找到项目中查询SQL的地方，使用prepared statement
Injection beyond SQL：最小权限原则，建立允许名单+过滤，对URL类型参数进行协议、域名、IP的等限制
DOS防御：正则表达式防御，代码扫描+正则性能测试、禁止使用用户提供的正则
DDoS防御：
传输层的防御中间人：使用HTTP
HTTPS的一些特点：可靠性：加密；完整性：MAC验证；不可抵赖性：数字签名
