这是我参与「第五届青训营」伴学笔记创作活动的第 11 天

本堂课主要讲解的重点内容

对讲解的部分知识点进行介绍

二防御

1 XSS

方案：

永远不信任用户的提交内容
不把用户提交内容直接转换成DOM

现成工具：

前端：

主流框架默认防御XSS
google-closure-library
服务端(Node)：

DOMPurify

2 CSRF

2.1 同源政策

浏览器的同源政策：A网页设置的 Cookie，B网页不能打开，除非这两个网页"同源"。所谓"同源"指的是以下的"三个相同"：

协议相同
域名相同
端口相同

同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。

2.2 CSP

CSP(Content Security Policy)：内容安全策略

决定好哪些源(域名)是安全的
来自安全源的脚本可以执行，否则直接报错
对于eval / inline script 直接禁止

两种形式：

服务器的响应头部以及浏览器meta

2.3 CSRF防御(token)

2.4 SameSite Cookie

避免用户信息被携带，利用Cookie的SameSite属性用来限制第三方Cookie，从而减少安全风险。

可以设置成三个值：

Strict：最严格。完全禁止第三方Cookie，跨站点时，任何情况都不会发送Cookie
```
Set-Cookie: CookieName=CookieValue; SameSite=Strict;
复制代码
```
用户体验不会很好。比如访问别人的项目网站时，有个fork me链接到github，然后点击跳转不会带有github的token，所以跳转过后，都会是未登录状态
Lax：大多数情况不发送第三方Cookie，但是导航到目标地址的GET请求会发送。
```
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
复制代码
```
导航到目标地址的GET请求：链接、预加载、GET表单

设置了Strict或Lax之后，基本杜绝了CSRF攻击。
None：显示关闭SameSite属性。前提是需要同时设置Secure属性(Cookie只能通过HTTPS协议发送)，否则无效
```
Set-Cookie: widget_session=abc123; SameSite=None; Secure	
复制代码
```
应用场景是依赖Cookie的第三方服务：如网站内嵌其他网站的播放器，开启SameSite属性后，就识别不了用户的登录态，也就发不了弹幕了

2.5 SameSite和CORS的区别

3 Injection

在SQL语句外做的防御：

4 Dos

4.1 ReDoS

Review代码
代码扫描 + 正则性能测试
拒绝使用用户提供的正则

4.2 DDoS

5 防御中间人攻击

HTTPS防止中间人攻击

HTTPS 其实是SSL+HTTP的简称,当然现在SSL基本已经被TLS取代了

HTTPS的一些特性：

可靠性：加密(非明文)
完整性：MAC验证(防篡改)，通过hash算法来实现，所以就算只有很小的改变，hash输出结果也会变化很大
不可抵赖性：数字签名(确定身份)

个人总结

不错，学习到了很多之前没有接触过的知识，因为近期家里的安排时间比较紧张，语言组织上比较简单，没来得及截图视频内容，稍后会根据讲解内容进行补充，另外👇 文章参考：Web开发安全

Web 开发安全 - 防御篇 | 青训营笔记