这是我参加青训营伴学笔记的第十一天
开发安全-攻击篇
安全问题很常见，会危害用户，公司，程序员
XSS
当用户访问页面时，xss脚本就会运行 一是用户隐私被泄露。二是用户的机器会被当成挖矿的机器
开发者盲目相信用户提交的内容也会导致收到XSS攻击
XSS的特点
- 通常难以从UI感知（暗地里执行脚本）
- 窃取用户信息（比如通过cookie/token的方式）
- 绘制UI（比如弹窗），诱骗用户点击/填写表单
XSS攻击类型
stored XSS(存储型)
恶意脚本被存在数据库中访问页面->读数据===被攻击危害最大，对全部用户可见
实例
比如说在爱奇艺界面投放一个带xss的视频，当用户访问这个视频的时候就会遭受到xss脚本的攻击，轻则泄露用户信息，重则账号被盗取
Reflected xss (反射型)
不涉及数据库 从URL上攻击
实例
攻击者把script构造成恶意的脚本，从服务端攻击
DOM-based XSS
不需要服务器参与
恶意攻击的发起+执行都在浏览器完成
不涉及数据库
从URL攻击
反射型和DOM的区别
反射型是基于服务器的攻击DOM型是基于浏览器的攻击，不会设计服务端
Mutation-based XSS渲染型
利用了浏览器渲染DOM的特性(独特优化)不同浏览器，会有区别(按浏览器进行攻击)
攻击方式很巧妙是最难防御的方式
Cross-site request forgery(CSRF) 跨站尾道请求
在用户不知情的情况下利用用户权限（cookie） 构造指定HTTP请求，进而窃取或修改用户敏感信息
实例
首先用户并没有访问银行页面，恶意者使用了用户的权限，构造HTTP请求，进而窃取到用户的银行账户
常见的CSRF请求方式
Get
比如写一个a标签，用户一点击就会被攻击，或者img，当用户一完成图片显示就会被攻击
也表示不是一定要构造get 它也可以是其他的
sQLinjettion (注入式)
假如有一个http请求有一个SQL参数(恶意注入)然后服务器保存该参数之后注入到数据库当中，运行sQL code之后会导致
获取其他数据
修改数据
删除数据
实例
完成“删库跑路成就
injection不止SQL
CLI
OS command
Sever-side request forgery(SSRF),服务端伪造请求严格来说SSRF不是injection 不过原理相似
实例
Dos (服务拒绝)
通过某种方式(构造特定请求)，导致服务器资源被显著消耗来不及响应更多请求，导致请求挤压，进而雪崩效应
贪婪模式
重复匹配
基于正则表达式的DOS (贪婪模式)
回溯行为
n次不行，n-1试试服务器端写的一个贪婪的正则，攻击者写一个容易产生回溯行为的字符串，导致服务器效率大大降低
DDos(常见的Dos攻击
短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩，无法响应新请求(及时流量特别大)
特点
耗时的同步操作(直接访问IP，)
数据库写入
SQL join
文件备份
循环执行逻辑
Demo
攻击者构造大量的TCP请求，服务器照常进行，但是攻击者不返回第三次ACK，导致服务器连接不能释放从而达到最大连接数
基于传输层的攻击
中间人攻击
为什么会遭受中间人攻击
1.文传输
2.信息篡改不可知(浏览器和服务端的信息被修改之后两边都不 知道)
3.对方身份未验证
中间人可能是恶意的服务器，路由器，甚至是服务供应商 这种攻击会造成
这种攻击会造成
窃取信息
修改请求，返回
...
防御篇
永远不信任用户提交的任何内容
不要将用户提交内容直接转换成DOM，最好是转换成string
防御xss现成工具
前端
主流框架默认防御xss
Google-closure-library (浏览器自带
服务端 (node)
DOMpurify
用户需求必须动态生成DOM
那么我们要注意
用户提交的string转化为DOM是很危险的操作
还包括
上传svg
就比如一个img什么的
blob动态生成script
用户的自定义跳转连接
用户的自定义样式发放get请求就会暴露信息
插播:same-origin policy (SOP) 同源策略协议，
域名，端口都相同才是同源同源的HTTP的请求是可以的，跨域的HTTP请求是需要注意的
Csp可以允许开发者设置
那些源被认为是认为是安全的来自安全源的脚本可以执行，否则直接抛错对eval内联的式子标签之间抛错
CSRF的防御(异常请求)
伪造请求===异常来源
限制请求来源===限制伪造请求
Origin+referrer
token防御
判断请求来自合法来源的其他方法需要有过期时间
iframe攻击
同源请求
受到点击而发起HTTP请求
如何防御
http响应同步
对所有页面都设置X-FrameDENY当前页面不能当成iframe
Sameorigin 必须是同源的页面才能访问iframe
CSRF Anti-pattern用户隐私泄露用户数据泄露
Get!==get+post
get和post请求不能放在同一个接口
Samesite cookie
避免用户信息被携带
从根源上解决了CRSF攻击
Samesite
cookie发送限制
domain和页面域名是否一致(出这屋不认这人)
CORS
限制资源读写HTTP资源域名和页面域名是否一致类似于白名单，让你访问才能访问
防御CSRF的正确姿势
针对注入式
Injection
Prepared satrement
针对其他的攻击访问措施最小权限原则建立允许名单+过滤
URLIP限制
Dos
不使用贪婪模式
代码扫描+正则性能测试拒绝使用用户提供的正则
DDos
过滤:
流量
负载
API
CDN
抗量:
快速自动扩容
所有的非核心业务功能降级(关闭)腾出资源应对
传输层
HTTPS特性
可靠性:加密避免了明文传输
完整性: MAC加密 确保信息不会被算改
不可抵赖性:数字签名确保双放身份
HTTPS过程
非对称和对称加密
完整性
加密+加密_hash (接收方会计算hash，如果hash相等，那么信息就没有被篡改)
插播数字签名
公钥
私钥
如果是和服务端对应的私钥就会通过
CA证书机构完成相关签名工作
主流浏览器会包含大量CA证书
当算法不够健壮
签名算法破解
但是现在的证书几乎不会被破解
将HTTP主动升级到HTTPS不会因为用户输入的是HTTP而导致出现中间人攻击
静态资源被算改
SRI
标签hash
Feature policy
针对一个源可以使用那种功能如果不小心被xss可以限制照相机什么的
Npminstall除了带来黑洞，还可以带来漏洞
攻击者的角度会越来越多，也需要不断的学习
