Web常见攻击的防御手段 | 青训营笔记

Elma417
183 阅读5分钟

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

我们知道XSS的攻击原理之后，就知道我们永远不能相信用户的输入，对一切的输入都要进行过滤，最好不要让用户输入js文件抑或SVG文件。

image.png

前端

  1. 主流框架默认防御XSS（Babel转译等）
  2. google-closure-library（如果需要可以使用这个第三方库）

服务端

  1. DOMPurify

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

string -> DOM

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

new DOMParser()
复制代码

上传svg

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

<svg>
    <script>alert('xss')</script>
</svg>
复制代码

自定义跳转链接

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

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

自定义样式

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

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

image.png

补充知识

浏览器同源策略 Same-origin Policy

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

image.png

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

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

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

  1. 那些源（域名）被认为是安全的
  2. 来自安全源的脚本可以执行，否则直接报错
  3. 对 eval + inline script 说🚫

如何配置CSP呢？

在服务器配置两个响应头

image.png

防御CSRF

请求来源异常应对方式

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

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

image.png

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

image.png

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

image.png

  1. 为什么要用户绑定：攻击者也可以是注册用户，可以获取自己的token
  2. 为什么要设置过期时间：前向保密，保证攻击者获取到历史的token也不奏效

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

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

image.png

此时可以使用这个响应头

X-Frame-Options：DENY/SAMEORIGIN
复制代码

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

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

image.png

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

利用用户敏感信息 应对方式

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

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

image.png

image.png

SameSite 属性有三个值

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

防御 CSRF 的正确姿势

CSRF是攻击一个个接口，我们不可能一个接口一个接口的进行防御，这样肯定不够优雅

我们应该在中间件中处理防御CSRF，比如验证token

防御Injection

  1. 找到项目中查询SQL的地方
  2. 使用prepared statement

image.png

对操作进行一些限制

  • 最小权限原则

    • 禁止 sudo || root

  • 建立允许名单 + 过滤

    • 禁止 rm

  • 对URL类型参数进行协议、域名、ip等限制

    • 禁止 访问内网

防御 DoS

一般是运维人员进行预防

image.png

对一些代码进行Review，遇到贪婪正则就给他禁止掉；进行一些正则的性能测试；直接禁止用户提供的正则

image.png 对一些恶意攻击代码使用负载均衡、API网关进行过滤，对一些恶意流量使用CDN、自动扩容、非核心服务降级进行扛量

防御中间人攻击

image.png 防御中间人攻击就要引出传输层的的防御方案了，使用HTTPS协议

小结

与上一篇攻击篇攻防结合，浑然一体。 防御篇更多的是提供了比较好的最佳实践，在自己搭建项目，编写业务的代码的时候，可以更加细致地注意安全方面，在保证产品可用性的同时，做好web安全，更好地保证产品的稳定性。 在整理笔记的时候感觉自己好像又重新上了一次老师的课程，反复回味，收获良多。

avatar
文章
阅读
粉丝