web安全相关知识

攻击篇
Cross-Site Scripting（XSS）
XSS主要利用了两部分内容：
（1）开发者盲目信任用户提交的内容
（2）作为前端开发工程师，直接把用户提交的string转换成DOM信息，
如：document.write element.innerHTML=anyString SSR(user_data)//伪代码
特点：
1.通常难以从UI上感知（暗地里执行脚本）
2.窃取用户信息（cookie,token）
3.绘制UI，（例如弹窗），诱骗用户点击、填写表单
类型：
（1）stored XSS
用户提交的内容到服务端，服务端存到数据库中，没有对用户提交的内容进行过滤
1.恶意脚本被存在数据库中
2.访问页面，读数据时，被攻击
3.危害最大，对所有用户可见
（2）Reflected XSS
URL带参数，服务器读取参数，将这个字段生成HTML片段，若攻击者把字段构造成恶意script标签，当用户访问页面就会被攻击
1.不涉及数据库
2.从URL上攻击
（3）DOM-based XSS
在浏览器中读取URL中的参数，将这个参数值写到innerHTML中
1.不需要服务器的参与
2.恶意攻击的发起+执行，全在浏览器完成
（2）和（3）一个是在服务器端注入，一个是在浏览器中完成的
（4)Mutation-based XSS
1.利用了浏览器渲染DOM的特性（独特优化）
2.不同浏览器，会有区别（按浏览器进行攻击）

Cross-site request forgery(CSRF)跨站伪造请求
用户在点击某个链接的时候，攻击者发起一个银行转账请求，银行服务器检测到有用户cookie,cookie是正确的，就会执行接下来的操作，常见的是get 请求方式，比如写一个a标签，用户点击；img标签，页面加载出来完成一次 get请求
1.在用户不知情的前提下
2.利用用户权限（cookie）
3.构造指定的HTTP请求，窃取或修改用户敏感信息

SQL injection
恶意注入SQL 攻击者可以修改删除数据，如服务器读取请求字段，直接以字符串的形式拼接SQL语句
Injection并不只有SQL，还有CLI，SSRF
Denial of Service(Dos)
通过某种妨害，导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩效应。

插播：正则表达式的贪婪模式
重复匹配 ？满足一个即可，不加？尽量多
ReDos基于正则表达式的DoS
服务器写了一个贪婪匹配，攻击者传入容易发生回溯行为的字符串进行攻击，响应时间会大大延长，接口吞吐量降低，响应用户的次数减少

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

中间人攻击
明文传输，信息篡改，浏览器和服务器都不知道，并且都没有对对方身份进行验证

防御篇
XSS
永远不信任用户提交内容，不要将用户提交内容直接转换成DOM
现成工具: 前端 ：主流框架Vue React默认防御XSS； google-closure-library
服务端 node DOMPurify
针对有些用户需求，应该怎么办？
若string直接生成DOM new DOMParser() 需要对string 进行转义
若允许用户上传SVG,对SVG 文件进行扫描，因为 SVG文件中可以插入 script
不要让用户自定义跳转链接
若允许自定义样式

插播：Same-origin- Policy 同源 协议 域名 端口号、

Content Security Policy CSP
哪些域名被认为是安全的 来自安全源的脚本可以执行，否则直接抛错，对eval inline script 说不
CSP 例子
服务器响应头部 Content-Security-Policy:script-src ‘self’ 同源
Content-Secutity-Policy:script-src ‘self’ https://domain.com
浏览器 meta

CSRF防御
伪造请求，异常来源
1.对请求来源进行校验 Origin (get head 不发送Origin字段) Referer
2.token
浏览器向服务器发起请求，服务器返回结果和token,浏览器携带token发起请求，服务器验证 token
token要与用户绑定，并且要有过期时间
3.iframe 绕过Origin限制的攻击，同源请求 ，比如一个按钮被包在iframe 中，点击按钮，iframe发起了请求
action frm
4.避免用get做post请求 用户隐私可能会泄露，信息也可能被修改
5. cookie SameSite
CSRF利用用户权限，用户权限在cookie 中，如果请求不带 cookie那么就从根源上解决了
限制的是cookie域名 和页面域名
依赖cookie的第三方服务怎么办？
如内嵌一个某站播放器，识别不了用户登录态，发不了弹幕
解决： set cookie SameSite=None； Secure；
SameSite VS CORS
sameSite 是 cookie 发送， 对于cookie的domain属性和当前页面域名 （限制在这个屋里）
CORS 对资源读写进行限制， 对比资源域名和页面域名 （类似于白名单）
CSRF防御的正确姿势 ：node做一个中间件

Injection防御
找到项目中查询SQL 的地点方，使用 prenared statement

防御DOS Code Review 代码扫描工具 正则性能测试， 拒绝用户提供正则

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

防御中间人
HTTPS
可靠性：加密
完整性：MAC校验 所有传输的加密信息，加一个hash 接收方对加密信息重新进行hash计算，根传递过来的hash进行比较，两者进行对比，一致则没有被篡改
不可抵赖性：数字签名 签名执行者 使用私钥对内容进行数学计算，生成对应的签名，拥有公钥的人，对签名进行校验，如果是对应的私钥生成的签名，则校验通过