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

TA_WORDL
126 阅读5分钟

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

攻击

XSS

在页面中，攻击者通过注入恶意脚本，用户在浏览页面的时候，这些恶意脚本就会被执行，进而完成攻击

image.png 出现问题的主要原因：

  • 盲目相信用户的提交内容
  • 直接将用户传入字符串转化为DOM

比如：document.write和element.innerHTML等

特点：

  • 通常难以从UI上感知（暗地执行脚本）
  • 窃取用户信息（cookie/token)
  • 绘制UI（例如弹窗），诱骗用户点击或填写表单

服务端未作过滤：

image.png

注入恶意脚本：

image.png

Stored XSS

  • 恶意脚本被存在数据库中
  • 访问页面 -> 读取数据 === 被攻击
  • 危害最大，对全部用户可见

image.png

Reflected XSS

  • 不涉及数据库
  • 从URL上攻击

image.png

DOM-based XSS

  • 不需要服务器的参与
  • 恶意攻击的发起 + 执行，全在浏览器完成

image.png

Mutation-based XSS

  • 利用浏览器渲染DOM的特性（独特优化）
  • 不同浏览器，会有区别（按浏览器进行攻击）

image.png

CSRF

  • 在用户不知情的前提下
  • 利用用户权限(cookie)
  • 构造指定HTTP请求，窃取或修改用户敏感信息

image.png

常见的场景：在邮箱中点击恶意链接

image.png

Injection 注入

SQL Injection

image.png

举例：

image.png

image.png

使用字符串拼接很容易造成sql的注入

Dos

通过某种方式（构造特定请求），导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩效益

基于正则表达式的Dos

image.png

image.png

DDos

短时间内，来自大量僵尸设备的请求流量，服务器不能及时完成全部请求，导致请求堆积，进而雪崩，无法响应新请求，主要是消耗带宽

  • 耗时的同步操作
  • 数据库写入
  • SQL join
  • 文件备份
  • 循环执行逻辑

image.png

中间人攻击

image.png

防御

XSS

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

前端：

  • 主流框架默认防御XSS
  • google-clourse-library

服务端（Node）：

  • DOMPurify

如果需求就是转化为DOM，那么需要注意几个点：

  • 使用DOMParser进行解析，返回一个新建的DOMParser 对象实例通过这个对象的 parseFromString() 方法将字符串解析为 DOM 对象

  • 对svg文件进行扫描，因为svg可插入script标签

  • 不要做用户自定义跳转行为，如果要做就必须要做好过滤，因为跳转可传递代码

    image.png

  • 自定义样式，对可设置URL的样式进行防范 image.png

CSRF

CSP

  • 哪些源（域名）被认为是安全的
  • 来自安全源的脚本可以执行，否则直接抛错
  • 对eval + inline script说不

image.png

image.png

token

image.png

image.png

iframe攻击

攻击者可以使用 iframe 绕过 Origin/Referer 的限制

image.png

image.png 用户点击button，由于button设置了CSS不能点击，从而点击iframe，万一触发iframe有请求，由于是同源请求并不会被拒绝，又完成了一次攻击

如果我们可以对服务器进行编码，就可以给每个页面设置响应头部：

X-Frame-Options: DENY/SAMEORIGIN

  • DENY：当前页面不能被作为iframe进行加载
  • SAMEORIGIN：必须是同源页面才可以访问该iframe

SameSite Cookie(避免用户信息被携带)

既然CSRF要利用用户权限，用户权限又在Cookie中，如果请求不带上Cookie，不就没有CSRF了吗？

我的页面的Cookie只能为我所用，其他页面的请求都不能带上我的Cookie，从根源上解决了CSRF。

image.png

当向域名A发送请求的时候，所有的第一方Cookie都可以被成功带上，所有的第三方Cookie都不会带给域名A对应的服务器

虽然解决了问题，但是如果网站确实依赖 Cookie 的第三方服务怎么办？

  • 比如内嵌一个 X 站播放器，识别不了用户登录态，发不了弹幕

  • 应对方式：Set-Cookie: SameSite=None; Secure;

    • SameSite=None 代表Cookie将在所有上下文中发送，允许跨站发送，不对SameSite进行控制
    • Secure 确保 Cookie 是安全的

SameSite和CORS的区别

SameSiteCORS
Cookie 发送资源读写（HTTP请求）
domain vs 页面域名资源域名 vs 页面域名
“出这屋我可就不忍了”，只在当前页面有效“白名单”

Injection

防御sql注入

  • 找到项目中查询 SQL 的地方
  • 使用 prepared statement（数据库本身也推荐这种写法）
PREPARE q FROM 'SELECT user FROM users WHERE gender = ?';
SET @gender = 'female';
EXECUTE q USING @gender;
DEALLOCATE PREPARE q;

Reges Dos

  • 完善代码的回溯工作，避免写出贪婪匹配的方式，特别在接口处理相关操作中
  • 使用代码扫描工具去扫描整个代码仓库的正则表达式，进行规整与改进
  • 禁止使用用户提供的正则表达式

DDos

  • 流量治理

    • 负载均衡（过滤）
    • API网关（过滤）
    • CDN（抗量）

  • 快速自动扩容（抗量）

  • 非核心服务降级，流出更多资源用于处理（抗量）

传输层——防御中间人

HTTPS: HTTP over TLS，是一种在加密信道进行 HTTP 内容传输的协议。 TLS 的早期版本叫做 SSL

HTTP3（QUIC）内置了TLS 1.3

image.png

HTTPS完整性

所有传输的信息除了加密外，还会传输信息一个哈希值，接收方再调用哈希函数判断信息是否被篡改

image.png

HTTP Strict-Transport-Security(HSTS)

如何将HTTP主动升级到HTTPS呢？

  • 首先，浏览器侧向服务器发送一个https的请求

  • 服务器收到请求后，会返回一个Strict-Transport-Security头部，后面的max-age表明在该时间内，如果浏览器再次发送http请求，会自动升级为https请求，确保了之后不会因为用户手动输入http造成潜在的中间人攻击

  • 缺点：一定要先有一次https请求

image.png

Feature Policy/Permission Policy

规定一个源（页面）下，可以使用哪些功能

  • camera
  • microphone
  • autoplay

如果是标签，可以通过allow属性规定可以使用哪些功能 

    <iframe allow="xxx" />
avatar
文章
阅读
粉丝