前端 安全

目录

一、跨站脚本攻击（XSS）

1. 反射型 XSS

2. 存储型 XSS

3. DOM 型 XSS

XSS 通用防御

二、跨站请求伪造（CSRF）

三、点击劫持（Clickjacking）

四、开放重定向攻击（Open Redirect）

五、HTTP 头注入（Header Injection）

六、 WebSocket 安全漏洞

七、 客户端存储泄露

八、 第三方 SDK 风险

九、 浏览器扩展漏洞

十、 JSON 劫持（JSON Hijacking）

十一、 服务端请求伪造（SSRF）的前端因素

十二、 内容注入（Content Injection）

十三、 依赖混淆攻击（Dependency Confusion）

十四、 自动化工具滥用

总结

---

一、跨站脚本攻击（XSS）

XSS 攻击的核心是让恶意脚本在用户浏览器中执行。根据触发方式不同，分为以下三类：

---

1. 反射型 XSS

• 原理：攻击者构造恶意 URL，用户点击后，服务端将恶意参数直接返回并执行。

• 案例：

  http://example.com/search?keyword=<script>alert('XSS')</script>

  服务端未过滤参数，直接返回页面中包含 <script>alert('XSS')</script>，触发弹窗。

• 特点：

  • 恶意脚本在 URL 中，需用户主动点击。

  • 不存储到数据库，仅单次生效。

• 防御手段：

  • 输入转义：对用户输入的 URL 参数进行 HTML 转义（如 < → <）。

  • 输出编码：服务端返回数据时，对动态内容进行编码。

  • 启用 CSP：通过 Content-Security-Policy 头限制脚本来源，如：

    Content-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval';

---

2. 存储型 XSS

• 原理：恶意脚本被存储到服务端（如数据库），其他用户访问时触发。

• 案例：
  攻击者在评论区提交 <script>stealCookie()</script>，该内容被保存到数据库。其他用户加载评论时自动执行脚本。

• 特点：

  • 危害更大，所有访问页面的用户都会受影响。

  • 常见于用户生成内容（UGC）场景（如论坛、聊天室）。

• 防御手段：

  • 服务端过滤：对用户提交的内容进行严格过滤（如移除 <script> 标签）。

  • 前端转义：渲染时对动态内容使用 textContent 或 innerText，避免 innerHTML。

  • CSP 策略：禁用内联脚本（'unsafe-inline'），仅允许可信域名。

---

3. DOM 型 XSS

• 原理：恶意脚本通过修改 DOM 触发，不经过服务端。

• 案例：

  const hash = window.location.hash.substr(1);
  document.getElementById("content").innerHTML = hash;

  攻击者构造 URL：http://example.com#<img src=x onerror=alert('XSS')>，导致脚本执行。

• 特点：

  • 完全在客户端触发，服务端无法防御。

  • 常见于基于 location.hash、document.write 等操作。

• 防御手段：

  • 避免直接操作 DOM：使用 textContent 替代 innerHTML。

  • 安全 API：使用 encodeURIComponent 处理 URL 参数。

  • DOM 净化库：使用 DOMPurify 对动态内容过滤。

---

XSS 通用防御

1. 内容安全策略（CSP）：
   限制脚本仅从可信源加载，禁止内联脚本。

2. HttpOnly Cookie：
   设置敏感 Cookie 为 HttpOnly，防止被 JavaScript 窃取。

3. 输入输出检查：
   对所有用户输入和动态输出进行转义（如使用 OWASP ESAPI）。

二、跨站请求伪造（CSRF）

• 原理：攻击者诱导用户在已登录的状态下发送伪造请求（如转账、改密）。

• 案例：
  用户登录银行网站后，访问恶意页面，页面内隐藏一个自动提交的表单：

  <form action="http://bank.com/transfer" method="POST"><input type="hidden" name="amount" value="10000" /><input type="hidden" name="to" value="attacker" />
  </form>
  <script>document.forms[0].submit();</script>

• 防御手段：

  • CSRF Token：
    服务端生成随机 Token 嵌入表单或请求头，验证请求合法性。

    <input type="hidden" name="csrf_token" value="随机字符串">

  • SameSite Cookie：
    设置 Cookie 的 SameSite 属性为 Strict 或 Lax，限制跨域携带 Cookie。

    Set-Cookie: session=abc123; SameSite=Lax; Secure

  • 验证请求来源：
    检查 Origin 或 Referer 头是否来自合法域名。

三、点击劫持（Clickjacking）

• 原理：攻击者通过透明 iframe 覆盖页面，诱导用户点击隐藏按钮（如授权按钮）。

• 案例：
  恶意页面将目标网站（如社交平台）以透明 iframe 嵌入，覆盖一个“点赞”按钮在用户可见的虚假按钮上。

• 防御手段：

  • HTTP 头禁止嵌入：
    设置 X-Frame-Options 头为 DENY 或 SAMEORIGIN。

    X-Frame-Options: DENY

  • CSP 的 frame-ancestors 指令：
    限制页面只能被特定域名嵌入。

    Content-Security-Policy: frame-ancestors 'self';

  • 前端 JavaScript 防御：
    通过脚本检测是否被嵌入到 iframe：

    if (top !== window) {top.location = window.location;
    }

---

四、开放重定向攻击（Open Redirect）

• 原理：攻击者利用网站未验证的重定向参数，将用户引导至恶意网站。

• 案例：

  http://example.com/redirect?url=http://evil.com

  若服务端未校验 url 参数，用户会被重定向到钓鱼网站。

• 防御：

  • 限制重定向域名白名单。

  • 避免直接使用用户输入的 URL 参数重定向。

---

五、HTTP 头注入（Header Injection）

• 原理：攻击者通过输入控制 HTTP 响应头，注入恶意内容（如 Location 或 Set-Cookie）。

• 案例：

  攻击者可以构造一个恶意的URL，注入额外的HTTP头信息。例如：

https://example.com/set-header?header=Location&value=https://malicious-site.com%0d%0aSet-Cookie:%20sessionid=12345

在这个例子中，%0d%0a 是URL编码的换行符（\r\n），攻击者利用它注入了一个额外的HTTP头 Set-Cookie: sessionid=12345。服务器可能会生成如下HTTP响应：

HTTP/1.1 302 Found
Location: https://malicious-site.com
Set-Cookie: sessionid=12345

• 防御：

  • 对用户输入中的换行符（\r\n）进行过滤或编码。

  • 避免用户输入直接拼接到 HTTP 头。

---

六、 WebSocket 安全漏洞

• 风险：WebSocket 连接未加密或未验证来源，导致数据泄露或中间人攻击。

• 案例：

  未验证的 WebSocket 连接，攻击者可以伪造一个 WebSocket 客户端，直接连接到服务器的 WebSocket 端点：

const maliciousSocket = new WebSocket('ws://example.com/chat');
maliciousSocket.onopen = () => {maliciousSocket.send(JSON.stringify({ type: 'message', content: '恶意消息' }));
};

• 防御：

  • 强制使用 wss://（WebSocket over TLS）。

  • 验证 WebSocket 连接的 Origin 头。

---

七、 客户端存储泄露

• 风险：敏感数据（如 API 密钥、用户信息）明文存储在 localStorage 或 sessionStorage 中，被 XSS 窃取。

• 防御：

  • 避免在前端存储敏感数据，必要时使用加密（如 AES）。

  • 设置合理的存储过期时间。

---

八、 第三方 SDK 风险

• 案例：广告 SDK、社交登录组件可能收集用户数据或引入漏洞。

• 防御：

  • 最小化第三方 SDK 的使用。

  • 使用沙盒隔离（如 iframe）加载不可信内容。

---

九、 浏览器扩展漏洞

• 风险：恶意浏览器扩展可篡改页面内容或窃取数据。

• 防御：

  • 提示用户仅安装官方商店的扩展。

  • 敏感操作（如支付）使用独立窗口或验证二次确认。

---

十、 JSON 劫持（JSON Hijacking）

• 原理：攻击者窃取 JSON 数据（利用早期浏览器漏洞，如覆盖数组构造函数）。

• 防御：

  • 响应 JSON 时添加前缀：)]}',\n，强制解析前处理。

  • 使用 POST 替代 GET 请求敏感 JSON 数据。

---

十一、 服务端请求伪造（SSRF）的前端因素

• 风险：前端允许用户输入 URL 发起服务端请求（如图片裁剪、PDF 生成），攻击者利用此访问内网资源。

• 案例：
  用户输入 http://localhost/admin，服务端请求该地址导致内网信息泄露。

• 防御：

  • 禁止用户输入协议（如 file://、ftp://）。

  • 校验请求目标 IP 和域名是否合法。

---

十二、 内容注入（Content Injection）

• 原理：攻击者篡改页面内容（如插入虚假登录表单）。

• 防御：

  • 使用 Subresource Integrity (SRI) 确保静态资源完整性。

  • 对动态内容签名（如数字签名验证 HTML 片段）。

---

十三、 依赖混淆攻击（Dependency Confusion）

• 原理：攻击者上传与内部私有包同名的恶意包到公共仓库（如 npm），诱导安装。

• 防御：

  • 使用私有仓库（如 Nexus）并优先从私有源拉取依赖。

  • 在 .npmrc 中配置作用域包的来源：

    @mycompany:registry=https://private-registry.example.com

---

十四、 自动化工具滥用

• 风险：爬虫或脚本滥用前端 API（如短信发送接口）。

• 防御：

  • 接口限流（如 1 分钟/次）。

  • 添加验证码（如人机验证）。

总结

前端安全需覆盖 代码层（XSS 转义）、协议层（HTTPS）、架构层（CORS/SRI）和 运维层（依赖扫描），结合安全头、工具和流程规范，形成纵深防御体系。可参考 OWASP Web Security Testing Guide 进行全面防护。