上一篇我们介绍了一些常见的攻击方式，今天我们来探索探索如何进行防御，防止我们的用户信息被泄露，防止我们的服务器被攻击~

防御XSS

我们知道XSS的攻击原理之后，就知道我们千万不能相信用户的输入！！！

过滤用户的输入，我们不用自己造轮子呀~ 前人已经创造了很多工具可以给我们使用

前端

服务端

如果用户真的有这样的需求，必须动态⽣成 DOM，那我们要注意在以下几个地方做好过滤

① string -> DOM

将字符串转换成DOM，我们一定要对这个字符串string进行过滤

new DOMParser()

用户上传svg，可以内嵌script标签，所以对用户上传的所有svg文件，也要进行过滤

<svg>
    <script>alert('xss')</script>
</svg>

用户可以自定义跳转链接的话，对跳转的链接也要进行过滤

<a href="javascript:alert('xss')" >点我</a>

这种方式很厉害，通过一个表单，用户点击到指定的按钮，就会添加一个样式，这个样式修改背景图片url，这个url就是一个恶意链接，当用户选中就会将用户选中的信息带到恶意第三方，用户信息就泄露了

所以要尽量不要让用户自定义修改样式，如果非要这样，一定要做好过滤

我们知道浏览器有同源策略的限制，只有协议、域名、端口号三者都相同，才满足同源，不满足的我们称之为跨域

同源策略是一个重要的安全策略，它用于限制一个源的文档或者它加载的脚本如何能与另一个源的资源进行交互。这是浏览器安全性的考虑，可以帮助阻隔恶意文档，减少可能被攻击的媒介

同源策略大家应该都很熟悉，那你知道什么是内容安全策略吗

如何配置CSP呢？

在服务器配置两个响应头

浏览器meta标签中也可以写类似的代码关于meta标签更多细节，可以看我之前的博文 HTML基础

跨站请求伪造，他的请求都是伪造的，请求来源是异常的，所以我们可以通过限制请求来源，来限制伪造的请求

在请求头信息中可以查看到Origin信息和Referer信息

但是，在同源请求中，GET请求和HEAD请求不会发送Origin，所以我们要思考除了查看Origin和Referer知道请求的源，还可以通过什么方式来判断请求来自合法来源的方式呢？

看到这里，你应该想到了，我们可以使用token的机制，来识别源和用户

差不多了吧~

不，你看他（请求）的源，攻击者直接给你来同源请求

在iframe中嵌入一个按钮，用户点击，就会发送请求

此时可以使用这个响应头

X-Frame-Options：DENY/SAMEORIGIN

如果设置为 deny，不光在别人的网站 frame 嵌入时会无法加载，在同域名页面中同样会无法加载。

如果设置为sameorigin，那么页面就可以在同域名页面的 frame 中嵌套。

日常开发中，经常把GET请求和POST请求都当成GET请求来出来，其实这是不好的习惯，以后记得要分清楚，不然GET请求的接口被攻击了，就可以使用POST进行添加数据了！！！

避免⽤户信息被携带：SameSite Cookie

Cookie 的SameSite属性用来限制第三方 Cookie，从而减少安全风险。

SameSite 属性有三个值

Strict Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。
Lax Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。
None Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。