前端安全相关

发表于 分类于 本文字数： 1k 阅读时长 ≈ 4 分钟

XSS

跨站脚本攻击（XSS，Cross - Site Scripting）攻击者通过在目标网站中注入恶意脚本，来获取用户的敏感信息、执行恶意操作等。这些恶意脚本通常是 JavaScript

整体过程

攻击者提交恶意代码 -> 浏览器执行恶意代码

攻击方式

反射型XSS

示例：一个简单的搜索功能，用户在搜索框输入内容后，服务器将用户输入的内容直接在页面上显示。攻击者构造一个类似 http://example.com/search?q=<script>alert('XSS')</script> 的 URL，当用户点击这个链接，就会弹出一个警告框显示 “XSS”。

存储型XSS

原理：攻击者将恶意脚本存储在目标服务器上，如存储在数据库、文件系统等。当其他用户访问包含该恶意脚本的页面时，浏览器就会执行这个脚本。这种类型的 XSS 通常出现在用户可以提交内容并且这些内容会被长期存储和展示的场景中，比如论坛、博客的评论区等。
示例：在一个论坛系统中，攻击者在评论区提交一个包含恶意脚本 <script>stealCookie()</script>（假设存在一个名为 stealCookie 的恶意函数）的评论。当其他用户查看这个评论时，他们的浏览器会执行这个脚本，导致他们的 Cookie 信息可能被窃取。

DOM型XSS

原理：这种类型的 XSS 是由于 HTML 页面中，JavaScript 通过 DOM 操作动态地修改页面内容而导致的。攻击者利用 JavaScript 代码中的漏洞，修改 DOM 来注入恶意脚本。与前面两种不同的是，它不依赖于服务器端对数据的反射或者存储，而是完全在客户端浏览器环境中发生。
示例：有一个网页，其中有一段 JavaScript 代码如下：

1
document.getElementById('userInput').innerHTML = location.hash.substr(1);

攻击者可以构造一个 URL，如 http://example.com/page.html#<script>alert('XSS')</script>，当用户访问这个 URL 时，浏览器会执行这个恶意脚本，弹出警告框。

预防漏洞的思路

  • 前端提交时过滤（请求可以绕过前端）
  • 后端过滤（不能预防dom型XSS）
  • 前端渲染时转义（完美）

其他安全措施

  • CSP内容安全策略
  • HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
  • 验证码：防止脚本冒充用户提交危险操作。

CSRF

CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

一个典型的CSRF攻击有着如下的流程：

  • 受害者登录a.com，并保留了登录凭证（Cookie）。
  • 攻击者引诱受害者访问了b.com。
  • b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。
  • a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
  • a.com以受害者的名义执行了act=xx。
  • 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。

预防漏洞的思路

阻止不明外域的访问

  • 同源检测
  • Samesite Cookie

提交时要求附加本域才能获取的信息

  • CSRF Token
  • 双重Cookie验证
  • Samesite Cookie = Strict（同源请求才会带上cookie）
  • Samesite Cookie = Lax（这意味着 cookie 不会在跨站请求中被发送，如：加载图像或框架（frame）的请求。但 cookie 在用户从外部站点导航到源站时，cookie 也会被发送（例如，访问一个链接）。这是 SameSite 属性未被设置时的默认行为。）
  • Samesite Cookie = None（都会带）