Web开发的安全之旅 | 青训营笔记

Xh1Xxhg
192 阅读5分钟

Web开发的安全之旅 | 青训营笔记

这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天，学习了掘金视频课《前端入门——理论篇》第六节课程 “Web 开发安全 - 攻击篇” ，第七节课程 “Web 开发安全 - 防御篇” ，以下为本次的学习笔记：

Web 开发安全 - 攻击篇

Cross-Site Scripting(XSS)

  • 跨站脚本攻击：在Web页面中，攻击者恶意注入script代码，在用户访问该页面时，这些恶意脚本就会被执行，达到攻击用户的目的，可能会造成用户隐私泄露或者用户被当成“挖矿”的机器。

  • XSS主要利用

    • 开发者盲目信任用户提交的内容；
    • 前端工程师直接把用户提交的字符串转换成DOM

  • XSS特点

    • 难以从UI上感知（暗地执行脚本）
    • 窃取用户信息，如cookie、token
    • 执行JS，绘制UI（如弹窗）
    • 诱骗用户去点击和访问

  • XSS类型

存储型：把恶意脚本存在数据库里面，当用户访问页面时，就会去读取database中的数据，从而攻击用户；这是危害最大、对所有用户可见的恶意攻击

Snipaste_2023-02-06_12-37-25.png

反射型：reflected，不涉及数据库，完全从URL攻击 如：host/path/?param=<script>alert('123')</script>，在服务端注入脚本

Snipaste_2023-02-06_12-37-52.png 基于DOM的：无需服务器参与，“注入+攻击”由浏览器完成

Snipaste_2023-02-06_12-38-22.png

两者区别：

Snipaste_2023-02-06_12-39-36.png 基于Mutation的：利用浏览器渲染DOM的特性，不同浏览器有所差异，非常巧妙、最难防御的攻击

Snipaste_2023-02-06_12-42-23.png

Cross-site request forgery(CSRF)

  • 跨站点请求伪造：攻击者通过设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或者设定信息等的状态更新

  • CSRF特点

    • 用户不知情
    • 利用用户权限（cookie、token等）构造http请求
    • 窃取或修改用户信息

  • 最常见的就是GET请求

Snipaste_2023-02-06_14-02-09.png

Injection

  • 最常见的是SQL注入攻击：在进行http请求时，恶意注入一段sql参数，服务器端将参数构造成SQL语句并运行SQL代码，代码被执行后就实现了SQL的恶意注入，可以用来获取、修改、删除数据

Snipaste_2023-02-06_14-04-14.png

  • 另外的注入攻击还有：CLI、OS command，以及原理相似的Server-Side Request Fprgery（SSRF，服务器端请求伪造）
  • 删除
  • 读取、修改，通过把自己的网站代理转换成另一个第三方网站，把流量牵引过去，如果第三方承受不住就会导致服务器over，竞争对手GAMEOVER
  • SSRF：访问callback，暴露内网信息

Snipaste_2023-02-06_14-06-49.png

Denial of Service(DoS)

  • 服务拒绝，攻击者通过构造特殊请求，大量消耗服务器资源，使得更多请求无法响应，造成请求积压，引发雪崩效应

  • 回顾一下：正则表达式的贪婪模式

    • 满足“一个”或者“多个”：使用“?”满足一个即可，不用“?”有多少来多少

  • 类型

    • ReDoS：基于正则表达式的DoS，不断回溯
    • Distributed DoS(DDoS)：最常见的，在短时间内使用大量僵尸设备请求流量，使得服务器不能及时完成所以请求，造成请求堆积引发“雪崩”，无法响应新请求

  • 特点

    • 不会限制在域名的访问，更多的是直接访问IP
    • 目的：耗尽带宽，eg：三次握手
    • 耗时的同步操作、数据库写入、文件备份、循环执行逻辑
  1. 中间人攻击
  • 基于传输层的攻击方式，在浏览器和服务器之间插一个中间人来窃取、修改信息，进行网络请求
  • 中间人攻击利用：明文传输、信息篡改不可知、对方身份未验证

Web 开发安全 - 防御篇

跨站脚本攻击XSS防御

  • 原则：永远不要信任用户提交内容，不能直接转换成DOM而是转换成字符串

  • 前端主流框架都是默认防御XSS攻击的，也有工具：google-closure-library

  • 服务端（Node）使用DOMPurify

  • 如果非要动态生成DOM

    • new一个DOM的时候一定要对string进行转义
    • 扫描svg图片
    • 尽量不允许用户自定义跳转行为

  • 内容安全策略CSP（Content Security Policy）

    • 基于同源策略：协议、域名、端口都相同

      CSP

    • 由开发者定义哪些源是安全的，安全源脚本可以执行，非安全源的抛出错误

    • 服务器响应头部

      Content-Security-Policy: script-src 'self' https://domain.com

    • 浏览器的meta

CSRF的防御

  • 原则：限制请求来源 => 限制伪造请求

  • Origin + Referrer 形式

  • 校验token，token应该设置有效期

  • iframe攻击：http响应头 ，X-Frame-Options: DENY（不能加载iframe）/ SAMEORIGIN（必须同源）

  • anti-pattern：不能将GET、POST写成同一个

  • SameSite Cookie：“我页面的Cookie只能为我所用”，从根源解决

    • 限制条件：Cookie domain属性和当前页面域名是否匹配

    • 第一方Cookie ✔；第三方Cookie ✘

    • 依赖第三方Cookie服务怎么办

      Set -Cookie: SameS ite=None; Secure;

  • 从node层面讲：生成中间件，专门防御CSRF

Injection

  • 找到项目中查询SQL的地方，使用prepared statement
  • 最小权限原则
  • 建立白名单
  • 对URL类型参数进行协议、域名、ip的限制

DoS

  • 基于正则：避免贪婪匹配；使用代码扫描工具，进行正则性能测试；拒绝用户使用的正则
  • 防御关键：流量治理、快速扩容、非核心服务降级
  1. 传输层
  • 防御中间人：使用https
  • https特点：可靠（TLS加密层）、完整（MAC验证）、不可抵赖性（数字签名）
  • HSTS 将http主动升级成https，需要先有一次https请求

SRI

avatar
文章
阅读
粉丝