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

无闻
212 阅读3分钟

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

昨天的笔记写了Web开发的安全之旅--攻击篇(Web开发的安全之旅--攻击篇 | 青训营笔记 - 掘金 (juejin.cn))，今天，接着昨天的内容来写针对各类攻击我们有哪些防御技巧。

针对XSS的防御

对于XSS攻击，我们首先要做的就是以下两点：

  • 永远不信任用户所提交的内容
  • 不要将用户提交的内容直接转换成DOM

当下大多数主流框架都默认防御XSS，谷歌也提供了google-closure-library来防御XSS；从服务端（Node）来看，shi也有DOMPurify这样现成的工具

当然，现实开发中，免不了遇到要求我们必须动态生成DOM的客户，我们要注意以下几点，尽可能的避免“杯具”发生🤐

  1. 如果要把string直接生成DOM，这时我们需要对string进行转义
  2. 如果我们允许用户上传svg文件（例如：图片），我们也需要对svg进行一次扫描
  3. 尽量不要做让用户自定义跳转行为，如果要做，一定要做好过滤
  4. 如果我们允许用户自定义样式，也可能导致XSS攻击，所以要额外留意

CSP（内容安全策略）

允许开发者去定义哪些源/域名是安全的，来自这些安全源的脚本可以执行，否则直接报错，此外，可以直接拒绝任何eval标签或者任何内联script（inline script）标签

针对CSRF的防御

如果请求来源是异常来源，那么限制伪造来源就能限制这种攻击

CSRF--token防御机制

image.png

  1. 因为攻击者也有可能是注册用户，所以这里的token往往和具体用户绑定
  2. token需要一个过期时间

CSRF--iframe形式的攻击

demo

image.png

防御方式

X-Frame-Options：DENY/SAMEORIGIN

CSRF anti-pattern

GET !==GET+POST image.png 如果读到update进行更新操作，如果什么都没有读到就返回GET操作，如果被CSRF攻击，那么用户隐私可能泄露，甚至信息被篡改，可谓是一石二鸟

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

image.png 我页面的Cookie只能为我所用，其他页面向我发出请求都不能带上我页面的Cookie，这种方式从根源防御了CSRF攻击

SameSite Cookie限制的是：

  1. Cookie domain
  2. 页面域名

针对Injection的防御

  • 找到项目中查询SQL的地方
  • 使用prepared statement

除SQL外的防御

image.png

针对DoS的防御

image.png

针对DDoS的防御

几种防御思路：

  1. 过滤，对负载均衡或者API网关这一层进行流量识别，然后把识别出是恶意攻击的进行过滤
  2. 抗量，有前置CDN、快速自动扩容和非核心服务降级三种方式

尾声

安全无小事，历史上的left-pad事件、eslint-scope事件、event-stream事件等都是血与泪的教训，希望我们一直保持学习状态，在往后开发过程中将此类事件发生的可能性降至最低

avatar
文章
阅读
粉丝