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

---

theme: channing-cyan

这是我参与「第四届青训营 」笔记创作活动的第8天

Web开发安全-防御篇

面对网络上的一些攻击，我们需要做出一些应对的措施来防止一些恶意代码，为企业、用户带来安全的网络环境。

防御XSS

我们从XSS的特点来说，他是通过用户提交的内容注入恶意代码进行攻击的，而我们却将用户提交的内容数据直 接挂载在DOM上。

所以，我们应该怎么防御XSS呢？

• 不要信任用户提交的内容和数据
• 不要将用户提交的内容直接转换成DOM
• 我们应该先把用户提交的数据内容使用string承载
• 使用现成工具： 前端： -一般主流的框架会默认防御XSS -谷歌的google-closure-library 服务端： <ul> <li>node中有DOMPurify可以防御XSS

  Content Scurtiy Policy (CSP)防御

根据CSP的特点，我们应该怎么防御呢？、 - 判断哪些域名被认为是安全的 - 来自安全原得脚本可以执行，否则直接抛出错误 - 对eval+inline script说no

举例： - 服务器的响应头部 //服务器的响应头部 Content-Security-Policy:script-src 'self' //同源 Content-Securty-Policy:script-src 'self' http://baidu.com //除了同源外，还可以添加外部链接(白名单) - 浏览器meta ```html

```

CSRF的防御

如果黑客申请了一个伪造请求，然后后台检测到异常来源，然后我们限制请求来源来限制伪造请求。

请求头部： - Origin - 同源请求中，GET+HEAD不发送 - Referer

CSRF---token

除了Origin+Referer，还可以使用其他判断请求来自合法来源的方式。 - 先有页面，后有请求： ``` if(请求来自合法页面) then(服务器接受过页面请求) then(服务器可以标识)

`` 我们通过url请求页面到服务器，服务器就发送页面+token发送到浏览器，浏览器向服务器请求API+token`，服务器验证token+数据传到浏览器。服务器判断token OK不OK。 - 用户绑定：攻击者也可以是注册用户===可以获取自己的token - 过期时间：前向保密(token需要有过期时间)