首页

# XSS（跨站脚本攻击）

XSS 就是攻击者想尽一切办法将可以执行的恶意代码注入到网页中。

# XSS 的分类

📌 1. 存储型

场景

这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。

攻击步骤

  1. 攻击者将恶意代码提交到目标网站的数据库中。

  2. 用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。

  3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。

  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

📌 2. 反射型

与存储型的区别在于，存储型的恶意代码存储在数据库中，反射型的恶意代码存在 URL 上。

场景

这种攻击常见于通过 URL 传递参数的功能，如网站搜索、跳转等。

攻击步骤

  1. 攻击者构造出特殊的 URL，其中包含恶意代码。

  2. 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。

  3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。

  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

📌 3. DOM 型

DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

场景

这种攻击常见于通过 URL 传递参数的功能，如网站搜索、跳转等。

攻击步骤

  1. 攻击者构造出特殊的 URL，其中包含恶意代码。

  2. 用户打开带有恶意代码的 URL。

  3. 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。

  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

# XSS 的预防方案

防止攻击者提交恶意代码，防止浏览器执行恶意代码。

  • 对数据进行严格的输出编码，如 html 编码、js 编码、css 编码、url 编码等等。

  • 避免拼接 html，使用 vue / react 技术栈时避免使用 v-html / dangerouslySetInnerHTML。

  • 一些常见的数字、url、电话号码、邮箱地址等等要做校验判断。

  • 使用验证码，防止脚本冒充用户提交危险操作。

  • 开启浏览器的 XSS 防御：HttpOnly Cookie，禁止 js 读取某些敏感 cookie，攻击者完成 XSS 注入后也无法窃取此 cookie。

  • 增加攻击难度，配置 CSP（Content Security Policy (opens new window)），本质是建立白名单，由浏览器进行拦截。比如：Content-Security-Policy: default-src 'self' 限制所有的外部资源都只能从当前域名加载。

详细介绍可以参考：如何防止 XSS 攻击？ (opens new window)

# CSRF（跨站请求伪造）

攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站中已经获取的登录凭证，绕过后台的用户验证，达到冒充用户对被攻击网站执行特定操作的目的。

# CSRF 的攻击流程

攻击流程

  1. 受害者登录 a.com，并保留了登录凭证（cookie）。

  2. 攻击者引诱受害者访问 b.com。

  3. b.com 向 a.com 发送了一个请求：a.com/act=xxx，浏览器会默认携带 a.com 的 cookie。

  4. a.com 接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。

  5. a.com 以受害者的名义执行了 act=xxx。

  6. 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让 a.com 执行了自己定义的操作。

攻击类型

  1. GET 型：比如在页面的某个 img 中发起一个 get 请求。

  2. POST 型：通过自动提交表单到恶意网站。

  3. 链接型：需要诱导用户点击链接。

# CSRF 的预防方案

CSRF 通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对 CSRF 的防护能力来提升安全性。

1. 同源检测

通过 Header 中的 Origin Header、Refer Header 确定来源域名，但不同浏览器可能会有不一样的实现，不能完全保证。

2. CSRF Token 校验

我们可以要求所有的用户请求都携带一个 CSRF 攻击者无法获取到的 Token（通常保存在 Session 中）。服务器通过校验请求是否携带正确的 Token，来把正常的请求和攻击的请求区分开，也可以防范 CSRF 的攻击。

3. 双重 cookie 验证

流程

（1）在用户访问网站页面时，向请求域名注入一个 cookie，内容为随机字符串（比如 csrfcookie=v8g9e4dffaas）。

（2）在前端向后端发起请求时，取出 cookie，并添加到 url 的参数中（比如 https://www.a.com/comment?csrfcookie=v8g9e4dffaas）。

（3）后端接口验证 cookie 中的字段与 url 参数中的字段是否一致，不一致则拒绝。

优点

  • 无需使用 session，适用面更广，易于实施。

  • cookie 储存在客户端中，不会给服务器带来压力。

  • 相对于 Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个一个接口和页面添加。

缺点

  • cookie 中增加了额外的字段。

  • 如果有其他漏洞（比如 XSS），攻击者可以注入 cookie，那么该防御方式失效。

  • 难以做到子域名的隔离。

  • 为了确保 cookie 传输安全，采用这种防御方式时最好确保整站用 HTTPS，如果还没切 HTTPS，这种方式也会有风险。

4. SameSite Cookie

  • Google 起草了一份草案来改进 HTTP 协议，那就是为 Set-Cookie 响应头新增了 SameSite 属性，它用来标明这个 cookie 是个 “同站 cookie”。同站 cookie 只能作为第一方 cookie，不能作为第三方 cookie。

  • SameSite 有两个属性值，Strict 表示任何情况下都不可以作为第三方 cookie，Lax 表示可以作为第三方 cookie，但必须是 Get 请求。

详细介绍可以参考：如何防止 CSRF 攻击？ (opens new window)

Cookie 和 Token 实际上在⽹络传输中扮演不同的⻆⾊，并且它们在安全性⽅⾯的特点也有所不同，这些差异导致了 Cookie 相对于 Token 更容易被劫持。

  • ⾃动发送：浏览器会⾃动将与域关联的所有 Cookie 发送到服务器，不管是哪个⽹站发起的请求。这就意味着，如果⽤户访问了⼀个恶意⽹站，该⽹站可以利⽤⽤户的浏览器发送带有⽤户凭证的请求。

  • 跨站脚本攻击（XSS）：由于 Cookie 通常⽤于存储会话标识符，它们成为了跨站脚本攻击的⽬标。如果⽹站存在 XSS 漏洞，攻击者可以注⼊脚本，窃取⽤户的 Cookie，并⽤它们来模拟⽤户。

  • 跨站请求伪造（CSRF）：由于浏览器⾃动发送 Cookie，攻击者可以通过构造外部请求来利⽤⽤户的登录状态，这是 CSRF 攻击的基础。

# Token

  • 不⾃动发送：Token（例如 JWT —— JSON Web Tokens）通常存储在客户端，并且只在需要时由客户端显式地发送到服务器。这意味着，除⾮客户端被明确告知何时发送 Token，否则它们不会⾃动发送。

  • 防范 XSS 和 CSRF：由于 Token 不是⾃动发送的，攻击者难以通过 XSS 窃取和利⽤ Token（除⾮能完全控制前端 JavaScript）。同样，Token 不会⾃动随请求发送，因此在 CSRF 攻击中也较为安全。

# 防范措施

  • 设置 Cookie 属性：为了提⾼安全性，可以将 Cookie 设置为 HttpOnly（防⽌ JavaScript 访问）和 Secure（仅通过 HTTPS 发送）。

  • 使⽤ Token：Token 可以提供跨域和移动应⽤的身份验证，并且更容易控制和撤销。

  • 防范 XSS 和 CSRF：⽆论是使⽤ Cookie 还是 Token，都需要在应⽤层⾯防范 XSS 和 CSRF 攻击。

总的来说，由于 Cookie 的⾃动发送特性和易受 XSS 和 CSRF 攻击的特点，相对于 Token，它们更容易被劫持和滥⽤。⽽ Token 提供了更多的控制能⼒和灵活性，使得在多种应⽤场景下提供了更⾼的安全性。

# 什么是中间⼈攻击，如何解决

中间⼈攻击是⼀种⽹络安全威胁，攻击者在通信双⽅之间秘密地拦截和篡改信息。在这种攻击中，攻击者可以拦截、发送和接收数据，并在不被通信双⽅察觉的情况下改变通信内容。

# 攻击方法

  • 拦截通信：攻击者截获双⽅之间的数据传输。

  • 会话劫持：攻击者插⼊⾃⼰的设备到现有的通信会话中。

  • SSL 剥离：攻击者强制客户端使⽤⾮加密连接，从⽽获取敏感数据。

  • DNS 欺骗：通过篡改 DNS 响应，将⽤户重定向到恶意⽹站。

  • Wi-Fi 侦听：在未加密的 Wi-Fi ⽹络中拦截数据。

# 实际案例

  • 攻击者在公共 Wi-Fi 上拦截⽤户的⽹络活动。

  • 通过伪造证书实现对 HTTPS 连接的拦截。

# 解决⽅案

1. 加密

  • 使⽤ HTTPS：始终使⽤ HTTPS 协议来加密⽹站和⽤户之间的通信。

  • 强化 TLS 配置：使⽤强加密套件和最新版本的 TLS。

2. 认证

  • 数字证书：使⽤由可信 CA 颁发的数字证书来验证⽹站的身份。

  • 双因素认证：在敏感操作中使⽤双因素认证增加安全性。

3. ⽹络安全

  • 安全 Wi-Fi 连接：避免在公共 Wi-Fi 上进⾏敏感操作，使⽤ VPN。

  • 防⽕墙和⼊侵检测系统：部署防⽕墙和⼊侵检测系统来监控可疑活动。

4. 安全意识

  • 培训与教育：教育⽤户识别钓⻥⽹站和可疑邮件。

  • 检查 URL 和证书：在输⼊敏感信息之前检查⽹站的 URL 和证书。

5. ⽹络监控

  • 实时监控：实时监控⽹络流量，检测和阻⽌可疑的活动。

6. 更新和修补

  • 定期更新：定期更新软件和操作系统，修补已知的安全漏洞。

通过这些措施，可以显著降低中间⼈攻击的⻛险。然⽽，保持警觉并定期审查安全措施对于保护⽹络免受此类攻击⾄关重要。

# 什么是运营商 DNS 劫持，如何解决

运营商 DNS 劫持是指互联⽹服务提供商（ISP）或其他⽹络提供商在 DNS 解析过程中篡改 DNS 响应的⾏为。在这种劫持中，⽤户在尝试访问某个⽹站时，可能被重定向到另⼀个不同的地址。

# 劫持⽅式

  • 错误⻚⾯替换：⽤户输⼊的不存在的⽹址时，运营商将错误⻚⾯替换为含有⼴告的⾃家搜索⻚⾯。

  • 重定向流量：⽤户尝试访问某些⽹站时，被重定向到其他⽹站，如⼴告或运营商推⼴的服务。

  • 注⼊⼴告：在⽤户访问的⽹⻚中注⼊⼴告。

# 解决⽅案

1. 使⽤第三⽅ DNS 服务

  • 公共 DNS：使⽤像 Google Public DNS（8.8.8.8 和 8.8.4.4）或 Cloudflare（1.1.1.1）这样的公共 DNS 服务。

  • DNS 加密：使⽤⽀持加密的 DNS 服务，如 DNS-over-HTTPS（DoH）或 DNSover-TLS（DoT），以防⽌运营商劫持。

2. VPN

  • 虚拟私⼈⽹络：使⽤ VPN 服务可以加密所有的⽹络流量，包括 DNS 请求，从⽽绕过 ISP 的 DNS 设置。

  • VPN DNS：确保 VPN 服务提供⾃⼰的 DNS 服务器，以避免 DNS 泄露。

3. HTTPS

  • 强制 HTTPS：使⽤ HTTPS ⽽不是 HTTP 可以确保即使 DNS 请求被劫持，数据传输也仍然是加密的。

  • HSTS：使⽤ HTTP Strict Transport Security（HSTS）确保浏览器总是通过 HTTPS 连接到服务器。

4. 监控和验证

  • 检查 DNS 设置：定期检查和验证⽹络的 DNS 设置，确保它们没有被篡改。

  • ⽹络监控⼯具：使⽤⽹络监控⼯具来检测⾮正常的重定向或流量异常。

通过实施这些解决⽅案，⽤户可以有效避免运营商 DNS 劫持的影响，保护⾃⼰的⽹络活动不受⼲扰，并确保隐私和数据的安全。

# React XSS 如何防范与解决

1. 利⽤ React 的内置防护

⾃动转义：React 默认会转义所有要渲染到 DOM 的字符串。这意味着，如果你不使⽤ dangerouslySetInnerHTML ，并且不使⽤从⽤户输⼊或其他不安全源动态⽣成的字符串来作为 JSX 属性，你的应⽤应该是安全的。

2. 避免使⽤ dangerouslySetInnerHTML

除⾮绝对必要，否则尽量避免使⽤ dangerouslySetInnerHTML 。如果必须使⽤，请确保内容是安全的，可以通过第三⽅库如 DOMPurify (opens new window) 来清洁 HTML 内容。

3. 验证和清洁⽤户输⼊

  • 输⼊验证：对所有⽤户输⼊进⾏严格的验证。例如，如果你的应⽤允许⽤户输⼊ URL，确保这些 URL 符合预期的格式。

  • 使⽤第三⽅库：对于不可避免需要处理⽤户输⼊的 HTML，可以使⽤像 DOMPurify (opens new window) 这样的库来清洁 HTML 内容，移除所有潜在的危险脚本。

4. 使⽤ Content Security Policy (CSP)

实施 CSP 可以作为⼀道额外的防线来防⽌ XSS 攻击。CSP 通过⽩名单机制来限制⽹⻚可以加载和执⾏的资源。

5. ⼩⼼处理 URL 和链接

当创建链接或处理 URL 时，确保它们不会被注⼊恶意代码。例如，使⽤ encodeURIComponent 函数来处理 URL 参数。

6. 更新依赖

定期更新你的所有依赖，包括 React 和其他 npm 包。安全漏洞时常被发现，⽽依赖的维护者通常会发布修复版本来解决这些问题。

7. 使⽤安全的第三⽅库

当引⼊第三⽅组件或库时，确保它们是可信赖的，并且没有已知的安全漏洞。

8. 教育和代码审查

对开发团队进⾏安全教育，并实施代码审查流程，确保所有代码符合安全标准。

# Vue XSS 如何防范与解决

1. 利⽤ Vue 的内置防护

⾃动转义：Vue 会⾃动转义所有的数据绑定内容，防⽌ HTML 注⼊。只有在明确使⽤ v-html 指令时才会渲染原始 HTML。

2. 避免使⽤ v-html

谨慎使⽤ v-html ：v-html 会跳过 HTML 内容的转义，容易引发 XSS 攻击。尽量避免使⽤ v-html ，特别是对于⽤户提供的内容。

3. 验证和清洁⽤户输⼊

  • 输⼊验证：对⽤户输⼊进⾏验证，确保输⼊内容符合预期格式，特别是对于 URL、电⼦邮件地址等。

  • 内容清洁：对于必须插⼊的 HTML 内容，使⽤诸如 DOMPurify (opens new window) 等库来清洁内容，移除可能的脚本代码。

4. 使⽤ Content Security Policy (CSP)

实施 CSP，使⽤内容安全策略作为额外的防御层。CSP 可以帮助减少 XSS 攻击的⻛险，通过限制⽹⻚可以加载和执⾏的资源。

5. ⼩⼼处理 URL 和链接

在处理和拼接 URL 时，使⽤适当的函数（如 encodeURIComponent ）来避免注⼊攻击。

6. 更新依赖 定期更新 Vue 及其依赖项。确保使⽤的库和框架是最新的，以利⽤最近的安全修复和更新。

7. 使⽤安全的第三⽅库

审查第三⽅库，谨慎选择和使⽤第三⽅库，确保它们没有安全漏洞，并且得到了适当的维护。

8. 教育和代码审查

  • 团队培训：对团队进⾏ XSS 和其他安全问题的培训。

  • 代码审查：实施代码审查流程，确保所有新代码都符合安全标准。

上次更新时间: 2024年01月05日 15:06:06

← Node.js 入门 →