这是我参与「第四届青训营 」笔记创作活动的第7天。
前言
前端开发需要学习网络安全的知识，这门课详细了给我们讲解了web开发如何进行防御，安全问题很常见，网络黑客无处不在，需要掌握。
Web安全一窥
安全问题“很常见”，会危害
- 用户
- 公司
- 程序员（祭天）
两个角度看web安全
- 假如你是一个hacker-一一攻击
- 假如你是一个开发者一一防御
XSS的一些特点
CSRF demo
- 用户没有访问银行页面
- 银行页而中的特定接口被请求
- 请求执行成功
Injection demo2一一读取+修改
- 流量转发到真实第三方
- 第三方扛不住新增流量
- 第三方服务挂掉
- 您的竞争对手已下线
SSRF demo
- 请求【用户自定义】的callback URL
- web server通常有内网访问权限
public async webhook(ctx){
//callback可随是内网url
/e.g http://secret.com/get_employ_payrolls
ctx.body await fetch(ctx.query.callback);
}
ReDoS:基于正则表达式的DoS
贪婪：n次不行？n-1次再试试？一回溯
Distributed DoS(DDoS)
短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成 全部请求，导致请求堆积，进而雪崩效应，无法响应新请求。
中间人攻击
- 明文传输
- 信息篡改不可知
- 对方身份未验证
防御篇
XSS一一现成工具
前端
- 主流框架默认防御XSS
- google-closure-library 服务端(Node)
- DOMPurify
Content Security Policy(CSP)
CSP
- 那些源（域名）被认为是安全的
- 来自安全源的脚本可以执行，否则直接抛错措
- 对eval+inline script说OO
CSP
服务器的响应头部
Content-Security-Policy:script-src"self同源
Content-Security-Policy:script-src 'self'https://domatn.com
浏览器meta
cmeta http-equiv="Content-Security-Policy"content="script-src self">
CSRF的防御
if伪造请求三异常来源
then限制请求来源>限制伪造请求
-Origin
-同源请求中，GET+HEAD不发送
-Referer
总结
以上就是我这节课的所学整理的笔记，如有问题可在评论区指出，感兴趣的话可以关注我。
本人水平有限，请见谅，谢谢浏览。
