SPA安全扫描实战：基于Playwright的自动化漏洞发现与攻防

1. 项目概述：为什么SPA扫描是攻防的“新战场”

如果你最近几年参与过针对Web应用的渗透测试或安全评估，一定会发现一个明显的趋势：目标应用变得越来越“安静”了。传统的页面跳转、表单提交后整页刷新的场景越来越少，取而代之的是流畅的、无刷新的交互体验。这正是单页应用（Single Page Application， SPA）带来的变革。作为一名长期在一线进行安全测试的从业者，我深刻体会到，SPA的普及彻底改变了Web安全攻防的格局。过去，我们依赖的扫描器，无论是开源的Burp Suite、ZAP，还是商业的AWVS、AppScan，其核心工作模式都是基于“请求-响应”的静态页面模型。它们擅长爬取链接、分析表单、触发已知漏洞，但面对一个由JavaScript动态构建、路由在客户端管理、数据通过API异步加载的SPA时，常常会“失明”——爬虫只能看到一个几乎为空的初始HTML骨架，大量的功能、接口和潜在的攻击面都隐藏在JS代码和后端的API中。

这个项目标题“SPA扫描攻防”精准地指向了当前Web安全领域最棘手也最富挑战性的问题之一。它不仅仅是关于使用某个工具，而是要求我们建立一套全新的认知和方法论。从“JavaScript渲染”到“高级路由”，这勾勒出了SPA安全测试的两个核心维度：一是内容发现，即如何让扫描器“看到”JS执行后生成的完整DOM和动态事件；二是状态与路径发现，即如何理解并遍历SPA复杂的客户端路由逻辑，从而覆盖整个应用的功能面。而“全景式解析与自动化实战”则点明了目标：我们需要的是一个系统性的、可落地的解决方案，而不仅仅是零散的点子。

简单来说，这个项目探讨的是：如何让自动化安全测试工具重新“认识”和“理解”一个现代化的SPA，并在此基础上进行有效的漏洞挖掘。这适合所有从事Web安全、渗透测试、红蓝对抗以及前端开发（希望了解自身应用安全盲点）的同行。无论你是想提升自己手工测试SPA的效率，还是希望构建或优化自动化的扫描流程，这里面的思路和实战经验都能给你带来直接的帮助。

2. SPA安全测试的核心挑战与思路拆解

在深入技术细节之前，我们必须先搞清楚，为什么传统的扫描方法在SPA面前会失效，以及我们构建新思路的出发点在哪里。

2.1 传统扫描器的“失明”症结

传统的Web扫描器工作流程可以简化为：爬虫阶段和攻击阶段。爬虫通过解析初始HTML中的<a href>、<form action>等标签来发现链接和端点，然后递归访问，构建应用地图。攻击阶段则基于这个地图，对每个参数点进行漏洞检测。

SPA彻底打破了这套逻辑：

1. 初始HTML内容极少：SPA的入口HTML通常只有一个<div id=”app”>和几行引导JS代码。所有页面内容（包括菜单、列表、表单）都是由JavaScript在浏览器中动态创建并插入DOM的。传统爬虫看不到这些，因此其构建的应用地图几乎是空的。
2. 导航不依赖传统链接：SPA使用客户端路由（如React Router、Vue Router）。点击一个“按钮”切换页面，可能只是改变了URL的hash（#/user）或通过History API推送了一个新路径（/dashboard），并没有向服务器发起新的页面请求。爬虫无法通过分析HTML来发现这些“虚拟”的页面。
3. 数据交互高度API化：所有数据操作都通过Fetch或XHR调用后端的RESTful或GraphQL API完成。这些API端点通常不会直接出现在初始HTML中，而是封装在JS函数里，在特定用户交互（如点击、滚动）后触发。爬虫难以自动模拟这些复杂的交互序列来触发API调用。
4. 应用状态（State）管理复杂：SPA的很多功能受限于应用状态。例如，“编辑资料”按钮可能只在用户登录后才渲染；“提交订单”接口需要携带一个从之前流程中获取的购物车ID。扫描器需要能够模拟并维持一个完整的用户会话状态，才能触及深层功能。

2.2 构建SPA感知型扫描的总体思路

面对这些挑战，我们的应对思路需要从“静态分析”转向“动态执行”和“状态模拟”。核心思路可以概括为“一个大脑，两只手”：

• “大脑” - 浏览器自动化驱动：这是基石。我们必须使用一个能真正执行JavaScript、渲染完整DOM、并允许我们编程式操控的“真实浏览器”。Selenium、Playwright和Puppeteer是三大主流选择。它们允许我们的扫描脚本像真实用户一样操作浏览器：点击、输入、滚动、等待元素出现。
• “左手” - 动态内容爬取（渲染引擎）：利用浏览器自动化工具，加载SPA初始页面，然后驱动其执行JS，等待页面稳定（即网络空闲、DOM不再剧烈变化）。之后，再从这个“完整渲染”后的DOM树中提取链接、表单、API端点等信息。这解决了“看不见”的问题。
• “右手” - 高级路由与状态遍历：这更具挑战性。我们需要让扫描器理解SPA的路由机制。思路包括：
  • 静态分析JS代码：提取打包后的JS文件，寻找路由配置（如react-router的<Route>组件或路由数组），提前发现所有可能的路径。
  • 动态探测：在浏览器环境中，通过读取全局对象（如window.__NUXT__、window.$router）或注入探测脚本，来获取路由表。
  • 交互式探索：模拟用户点击所有可能的导航元素（按钮、菜单），并监听URL的变化和网络请求，从而发现新的路由和关联的API。

最终，我们将这两只手获取的信息（渲染后的DOM元素、发现的路由路径、触发的API请求）整合成一个完整的“SPA应用地图”，提供给后续的漏洞扫描引擎（如Burp Suite的主动扫描）进行测试。

注意：完全自动化的、无监督的SPA深度扫描目前仍然是一个开放性问题，尤其是在需要处理复杂登录状态、多步骤流程的应用中。我们的目标通常是实现“半自动化”，即通过工具大幅提升发现能力，再结合人工的上下文判断进行引导和深化。

3. 核心技术栈选型与工具链搭建

工欲善其事，必先利其器。选择合适的工具链是成功的第一步。这里我结合实战经验，对几个核心工具进行对比和选型分析。

3.1 浏览器自动化框架：Playwright vs Puppeteer vs Selenium

这是整个技术栈的核心。我们需要的框架必须稳定、快速，并且能很好地处理SPA的异步渲染。

• Selenium: 老牌王者，支持语言多（Java, Python, C#等），浏览器支持最全。但其架构相对陈旧，执行速度较慢，且API有时不够直观。对于需要高频、快速交互的SPA扫描来说，可能不是最优选。
• Puppeteer: 由Chrome团队开发，直接通过DevTools Protocol控制Chrome/Chromium，因此性能极高，API现代且强大。但它主要绑定Chromium系浏览器。在扫描场景中，这通常不是问题，因为我们的目标是功能发现，而非跨浏览器兼容性测试。
• Playwright: 由原Puppeteer团队核心成员开发，可以看作是Puppeteer的“升级版”。它支持Chromium、Firefox和WebKit（Safari）三大引擎，API设计更人性化，自动等待机制（auto-wait）非常强大，能智能等待元素可操作、网络请求完成，这对处理SPA的异步加载至关重要。其网络拦截（route）和请求修改能力也极其适合安全测试。

我的选择与理由：Playwright。在SPA扫描这个特定场景下，它的优势非常明显：

1. 强大的自动等待：无需在代码里写满sleep或复杂的条件等待，page.click(‘button’)会一直等到按钮真正可点击。这大大简化了处理动态内容的代码。
2. 卓越的网络控制：可以轻松监听、修改、拦截所有请求和响应，这对于捕获API端点、修改请求参数进行模糊测试至关重要。
3. 多浏览器支持：虽然Chromium是主力，但偶尔用Firefox或WebKit引擎测试，可能发现一些引擎特定的JS执行差异或安全问题。
4. 活跃的社区和良好的文档：遇到问题更容易找到解决方案。

基础环境搭建（以Python为例）：

# 安装Playwright pip install playwright # 安装浏览器驱动（Chromium, Firefox, WebKit） playwright install

安装完成后，一个最简单的渲染爬虫脚本如下：

from playwright.sync_api import sync_playwright def crawl_spa(url): with sync_playwright() as p: # 启动浏览器，推荐使用无头模式（headless=True）以提高速度 browser = p.chromium.launch(headless=True) context = browser.new_context() page = context.new_page() # 监听所有网络请求，用于捕获API api_endpoints = [] def on_request(request): if ‘api’ in request.url or ‘json’ in request.url: api_endpoints.append(request.url) page.on(‘request’, on_request) # 导航到目标URL page.goto(url) # 等待页面达到“网络空闲”状态，对于SPA很重要 page.wait_for_load_state(‘networkidle’) # 此时，页面已由JS渲染完成，可以获取完整HTML full_html = page.content() # 也可以获取所有链接 all_links = page.eval_on_selector_all(‘a’, ‘elements => elements.map(e => e.href)’) print(f”捕获到API端点: {api_endpoints}“) print(f”发现链接数量: {len(all_links)}“) browser.close() crawl_spa(‘https://example-spa-app.com’)

3.2 辅助分析工具：AST解析与JS监控

单纯依靠浏览器驱动进行黑盒探索有时效率不足，我们需要结合白盒或灰盒分析。

• 静态JS分析（AST）：对于可以获取到源码或未混淆的打包JS文件的情况，使用像esprima、acorn这样的JavaScript解析器生成抽象语法树（AST），然后编写规则来提取敏感信息。例如，寻找fetch或axios调用的URL模式，搜索路由配置对象。

  # 简化的AST分析思路（需安装esprima） import esprima import json js_code = “”“ const routes = [ { path: ‘/home’, component: Home }, { path: ‘/user/:id’, component: User } ]; fetch(‘/api/user/data’).then(...); ”“” tree = esprima.parseScript(js_code, {‘range’: True}) # 遍历AST，寻找特定类型的节点（如VariableDeclarator, CallExpression） # 提取出`routes`数组和`fetch`的URL参数。

  这种方法能提前发现大量端点，但严重依赖代码可读性，对于经过混淆、压缩的代码效果会大打折扣。

• 浏览器内JS监控：通过Playwright的page.add_init_script方法，在页面加载前注入我们的监控脚本。这个脚本可以重写关键的浏览器API，如fetch、XMLHttpRequest、history.pushState等，记录下所有的调用参数和堆栈信息。

  // 注入的监控脚本示例 (function() { var originalFetch = window.fetch; window.fetch = function(...args) { console.log(‘[Monitored Fetch]’, args[0]); // 记录URL // 可以将信息发送到某个收集端点，或存储在window对象供Playwright读取 window.__capturedRequests = window.__capturedRequests || []; window.__capturedRequests.push({type: ‘fetch’, url: args[0]}); return originalFetch.apply(this, args); }; // 类似地可以监控XHR和路由变化 })();

  然后在Playwright中通过page.evaluate来读取window.__capturedRequests。这种方式能捕获到运行时实际发生的请求，非常精准。

3.3 与现有安全工具集成：Burp Suite & ZAP

我们构建的SPA爬虫不应是一个孤岛，最终目的是为了给专业的漏洞扫描器提供“弹药”。因此，与Burp Suite或OWASP ZAP的集成是关键。

• 作为上游爬虫：我们的Playwright脚本可以配置为使用Burp Suite作为代理。这样，所有由浏览器发起的请求（包括渲染页面时加载的JS、CSS，以及后续触发的API请求）都会流经Burp。我们只需让Playwright尽可能多地触发页面功能，Burp的Target站点地图就会自动丰富起来。

  browser = p.chromium.launch(headless=True, proxy={ “server”: “http://127.0.0.1:8080” # Burp默认监听端口 })

  之后，可以在Burp中对这些请求进行主动/被动扫描。

• 导出结果：另一种方式是将我们爬取到的所有URL、表单、API端点整理成标准的格式（如简单的文本列表、XML），然后导入到ZAP的“传统爬虫”结果中，或者使用ZAP的API（zap-api-script.py）动态添加扫描目标。

工具链总结：一个高效的SPA扫描工具链通常以Playwright作为核心驱动引擎，负责渲染和交互；辅以自定义的JS监控脚本进行深度请求捕获；最终将所有流量代理到Burp Suite进行专业的漏洞检测，或自行处理结果后导入其他扫描器。AST静态分析可以作为前期信息收集的补充手段。

4. 动态内容爬取与渲染引擎的实现细节

有了工具，接下来就是实现“左手”——动态内容爬取。目标很简单：让浏览器加载SPA，等它“忙完”，然后抓取它生成的一切。但魔鬼在细节中。

4.1 智能等待策略：如何判断“渲染完成”？

这是第一个坑。简单地使用page.goto(url, wait_until=‘networkidle’)并不总是可靠。networkidle意味着500毫秒内没有超过2个网络连接。但对于一些使用长轮询、WebSocket或缓慢加载大型资源的SPA，可能永远达不到这个状态。或者，一些基于用户交互（如滚动）的懒加载内容，在初始加载后不会触发网络请求。

我的实战策略是组合等待条件：

1. 基础网络等待：page.wait_for_load_state(‘networkidle’)仍然是第一道防线。
2. 关键元素等待：如果我知道SPA加载后某个特定元素（如一个包含用户名的<div>或一个主内容区域的容器）一定会出现，我会使用page.wait_for_selector(‘.user-info’, timeout=10000)。这比单纯等网络更精准。
3. 自定义等待函数：有时需要更复杂的逻辑。例如，等待某个特定的JavaScript变量被设置，或者等待Vue/React的某个组件状态。

   def wait_for_app_ready(page): # 方案A：等待某个JS变量 page.wait_for_function(“””() => window.app && window.app.mounted === true”””, timeout=15000) # 方案B：等待DOM树在连续几次检查中不再变化（简单实现） # ... 这里需要实现一个检查DOM稳定性的循环 ...

4. 超时与重试：为整个渲染过程设置一个总超时（如30秒）。如果超时，记录日志，并尝试刷新重试，或者转入更保守的扫描模式。

4.2 深度内容提取：不仅仅是HTML

当页面“稳定”后，我们提取的内容不应只是page.content()得到的HTML字符串。

• 提取所有交互元素：

  # 获取所有可能的点击目标：按钮、链接、带有点击事件的div/span clickables = page.query_selector_all(‘button, a, [onclick], [role=”button”]’) for elem in clickables: # 获取元素文本、ID、类名，用于后续智能点击 info = { ‘tag’: elem.get_property(‘tagName’), ‘text’: elem.inner_text(), ‘id’: elem.get_attribute(‘id’), ‘classes’: elem.get_attribute(‘class’) }

• 提取所有表单与输入点：这是漏洞测试的重点。

  forms = page.query_selector_all(‘form’) inputs = page.query_selector_all(‘input, textarea, select’) # 需要记录input的name, type, value, placeholder等属性

• 提取所有URL模式：从<a>标签的href，从JS事件处理函数内联的字符串，甚至从CSS背景图中提取。
• 捕获内联的JS事件：有些事件处理器是直接写在HTML属性里的，如onclick=”submitForm()”。这些函数名和可能的参数也值得记录。

4.3 处理JavaScript框架的特定行为

不同的前端框架在渲染和更新DOM时有不同的特点。了解这些有助于我们优化爬取策略。

• React (Virtual DOM)：React的更新是异步批处理的。有时元素在DOM中已经存在，但可能因为状态更新而即将改变。使用Playwright的auto-wait通常能处理好。对于复杂情况，可以尝试等待React的某个根组件完成更新（通过监听自定义事件或检查__REACT_DEVTOOLS_GLOBAL_HOOK__，但这在无头模式下可能受限）。
• Vue.js：Vue的响应式系统也有类似特点。可以尝试等待Vue实例的nextTick。
• Angular：Angular应用通常有一个根组件。等待其特定元素出现是个好办法。

一个通用的技巧是，在页面加载后，主动触发一次轻微的滚动，以激活那些基于滚动事件的懒加载组件。

page.mouse.wheel(0, 100) # 向下滚动100像素 page.wait_for_timeout(500) # 给懒加载一点时间

实操心得：不要追求“一次性完美渲染”。在实际扫描中，我通常采用“分层渲染”策略。先进行一轮基础渲染和提取，然后针对提取到的关键交互元素（如主导航按钮），进行有目的的点击，触发新的渲染，再提取新内容。这种“探索-渲染-记录”的循环，比试图在初始状态就加载所有内容更高效、更稳定。

5. 高级路由发现与状态遍历的自动化策略

这是SPA扫描中最具挑战性的部分，也是区分普通爬虫和智能扫描器的关键。我们的目标是自动发现所有可通过客户端路由访问的“页面”或“视图”，并理解访问它们所需的状态（如是否登录、是否需要特定参数）。

5.1 路由发现：静态分析与动态探测结合

1. 静态分析（如果可能）： 如前所述，如果能够获取到应用的路由配置文件（通常是独立的router.js或routes.js），或者从打包的JS中解析出路由定义，那将获得最全的路由列表。寻找类似createRouter、<Routes>、route数组等模式。

2. 动态探测（更通用）： 在浏览器环境中执行探测脚本。

• 读取全局路由对象：许多框架会将路由实例挂载在window对象上。

  // 注入的探测脚本 let routes = []; if (window.$router && window.$router.options && window.$router.options.routes) { // Vue Router 2/3 routes = window.$router.options.routes; } else if (window.router && window.router.routes) { // 可能是其他自定义路由库 routes = window.router.routes; } // 将routes序列化后传回 return JSON.stringify(routes);

• 暴力枚举常见路径：根据应用类型（管理后台、用户中心、电商），准备一个常见路径字典（如/admin,/profile,/settings,/cart,/api/docs等），尝试导航过去，观察页面内容或URL是否有效变化。这属于“猜测”，但往往有意外收获。

3. 交互式探索（核心方法）： 这是最有效的方法。我们让爬虫模拟用户点击所有看起来像导航的元素。

• 识别导航元素：除了普通的<a>标签，要特别注意那些有特定class（如nav-item,menu-link）或role（如role=”navigation”）的<div>或<span>。
• 点击与观察：点击元素后，我们需要判断这次点击是否导致了有效的路由切换。
  • URL变化：监听page.on(‘framenavigated’)事件或定期检查page.url。
  • 页面内容显著变化：比较点击前后的页面标题（<title>）、主要区域（<main>）的HTML内容哈希值。
  • 网络请求：路由切换常伴随新的API请求来获取该路由对应的数据。
• 构建路由图：将发现的路由路径（如/dashboard,/user/123）以及到达该路径所需的交互序列（如“点击首页 -> 点击‘我的账户’按钮”）记录下来，形成一个有向图。这有助于后续的系统性遍历。

5.2 状态管理与会话维持

没有正确的状态，很多路由和功能是无法访问的。自动化状态管理是SPA扫描的“圣杯”。

• 登录状态自动化：

  • 表单自动填充与提交：如果登录表单是可见的，用Playwright自动填充用户名密码并提交。这需要你预先准备好测试账号。
  • Cookie/Session注入：更常用的方法是，先用浏览器手动登录一次，然后使用Playwright的browser_contexts的storage_state功能导出Cookie和LocalStorage。

    # 手动登录后，保存状态 context.storage_state(path=”auth_state.json”) # 在新的扫描会话中加载状态 context = browser.new_context(storage_state=”auth_state.json”) page = context.new_page() page.goto(target_url) # 此时应处于已登录状态

  • Token处理：对于使用JWT等Token认证的API，可能需要从LocalStorage中读取Token，并在后续的Playwright请求中手动添加到Header，或者通过page.route统一修改请求。

• 应用内状态模拟： 有些操作需要前置状态。例如，要测试“删除商品”功能，必须先有商品在购物车里。这需要编写状态流脚本。

  1. 定义一个目标（如“到达订单详情页”）。
  2. 反向推导所需状态（订单详情页需要订单ID -> 订单ID来自创建订单 -> 创建订单需要购物车有商品 -> 购物车商品来自添加商品）。
  3. 正向编写自动化脚本，按顺序执行“添加商品 -> 创建订单 -> 导航到订单详情”这一系列操作。 这本质上是在编写自动化业务流程测试脚本，复杂度很高，通常只针对核心高危功能进行。

5.3 参数化路由与动态内容的处理

SPA路由常常包含参数，如/user/:id，/product/:slug。我们的扫描器需要能处理这些。

• 参数发现：从静态分析或动态探测中获得的路由路径可能包含参数占位符（如:id）。我们需要生成具体的值去测试。
• 参数值生成策略：
  • 数字ID：尝试小数字（1,2,3），或从其他API响应中提取（例如，从/api/users列表响应中提取用户ID）。
  • 字符串Slug：尝试常见值（如test,admin,index），或从页面其他部分抓取（如文章列表中的文章slug）。
  • 枚举测试：如果发现类似/api/user/1,/api/user/2的模式，可以编写一个简单的循环进行枚举请求，观察响应差异（如状态码200 vs 403/404）。
• 自动化测试：对于发现的每个参数化路由，将其作为测试用例，用不同的参数值去访问，并记录响应。这有助于发现不安全的直接对象引用（IDOR）这类典型漏洞。

注意事项：自动化的状态遍历和参数化测试必须非常小心，避免对生产数据造成破坏。务必在测试环境或获得明确授权的情况下进行。对于“写操作”（POST, DELETE, PUT），建议先使用拦截功能（page.route）将请求方法改为只读的GET，或者直接阻止请求发出，仅记录其格式和参数，供后续手动验证。

6. 实战：构建一个简易的SPA自动化扫描原型

理论说了这么多，我们动手搭建一个简单的、但能体现核心思路的扫描原型。这个原型将使用Playwright进行渲染和基础交互，并尝试发现路由和API。

目标：给定一个SPA的入口URL，自动发现其部分客户端路由和触发的API端点。

步骤：

1. 初始化与状态加载：

   import asyncio from playwright.async_api import async_playwright import json async def scan_spa(target_url, auth_state_path=None): async with async_playwright() as p: browser = await p.chromium.launch(headless=True) # 如果有保存的登录状态，加载它 context = await browser.new_context(storage_state=auth_state_path) if auth_state_path else await browser.new_context() page = await context.new_page() # 用于收集结果的容器 discovered_routes = set() discovered_apis = set() click_elements = []

2. 设置请求监听与路由变化监听：

   # 监听API请求 async def handle_request(request): url = request.url # 简单的过滤规则，可根据需要扩展 if any(keyword in url for keyword in [‘/api/’, ‘/graphql’, ‘.json’]): discovered_apis.add(url) print(f”[API Found] {request.method} {url}“) page.on(‘request’, handle_request) # 监听路由变化（通过hashchange或popstate） await page.expose_function(‘onRouteChange’, lambda url: discovered_routes.add(url) or print(f”[Route Changed] {url}“)) await page.add_init_script(“”” const originalPushState = history.pushState; const originalReplaceState = history.replaceState; history.pushState = function(state, title, url) { window.onRouteChange(url); return originalPushState.apply(this, arguments); }; history.replaceState = function(state, title, url) { window.onRouteChange(url); return originalReplaceState.apply(this, arguments); }; window.addEventListener(‘hashchange’, () => window.onRouteChange(window.location.href)); ”“”)

3. 初始页面加载与内容提取：

   print(f”正在访问: {target_url}“) await page.goto(target_url, wait_until=‘networkidle’) await page.wait_for_timeout(2000) # 额外等待2秒确保JS执行完毕 # 提取初始可点击元素 initial_clickables = await page.query_selector_all(‘button, a, [role=”button”], [onclick]’) for elem in initial_clickables: # 简单的去重和过滤 text = await elem.inner_text() or ” tag = await elem.get_property(‘tagName’) if len(text.strip()) < 50: # 过滤过长文本（可能是整个文章内容） click_elements.append(elem) print(f”初始发现 {len(click_elements)} 个可点击元素。”)

4. 第一轮交互探索：

   # 对前N个元素进行试探性点击（避免无限循环） max_clicks = 20 for i, elem in enumerate(click_elements[:max_clicks]): try: print(f”尝试点击元素 {i+1}/{min(len(click_elements), max_clicks)}“) current_url_before = page.url await elem.click() # 等待可能发生的导航或网络活动 await page.wait_for_timeout(1000) await page.wait_for_load_state(‘networkidle’) current_url_after = page.url # 如果URL变化，则记录为新路由 if current_url_before != current_url_after: discovered_routes.add(current_url_after) # 点击后，可能出现了新的元素，可以重新抓取（这里简化处理） except Exception as e: # 元素可能已消失或不可点击 print(f”点击元素 {i} 时出错: {e}“) continue

5. 结果汇总与输出：

   print(“\n=== 扫描结果摘要 ===”) print(f”发现的路由 (URL):“) for route in sorted(discovered_routes): print(f” - {route}“) print(f”\n发现的API端点:“) for api in sorted(discovered_apis): print(f” - {api}“) # 可以将结果保存为文件 result = { “target”: target_url, “routes”: list(discovered_routes), “apis”: list(discovered_apis) } with open(‘spa_scan_result.json’, ‘w’) as f: json.dump(result, f, indent=2) await browser.close() # 运行扫描 asyncio.run(scan_spa(‘https://demo.spa.app’))

这个原型非常基础，但它演示了核心流程：加载 -> 监听 -> 交互 -> 收集。在实际项目中，你需要在此基础上增加更多功能：更智能的元素过滤、更稳定的等待逻辑、处理iframe、处理登录弹窗、管理复杂的会话状态、以及将发现的结果导出给Burp Suite等。

7. 常见问题、排查技巧与进阶优化

在实际操作中，你会遇到各种各样的问题。下面是我总结的一些典型问题及其解决思路。

7.1 常见问题速查表

7.2 进阶优化技巧

1. 并行化扫描：一个复杂的SPA可能有成百上千个交互点。串行点击效率极低。可以使用Playwright的多个browser_context甚至多个browser实例进行并行探索。但要注意会话状态的管理和避免操作冲突（如同时修改同一数据）。
2. 智能探索策略：不要盲目点击所有按钮。优先点击具有导航语义的元素（如带href=”#/...”的链接、侧边栏菜单项）。使用机器学习或简单规则对元素进行分类（“导航类”、“表单提交类”、“装饰类”），优先探索高价值目标。
3. 与漏洞扫描器深度集成：不要只把URL列表丢给Burp。可以开发一个Bridge，将Playwright中捕获到的完整请求（包括Header、Cookie、POST数据）直接发送到Burp的Intruder或Repeater，甚至自动生成扫描任务。Playwright的page.route可以拦截请求并获取其所有详细信息。
4. 处理GraphQL：现代SPA后端可能是GraphQL。单个端点（如/graphql）承载了所有操作。你需要监听请求，提取其中的operationName和query变量，将其转化为不同的测试用例。这需要专门的GraphQL解析和变异（Mutation）测试逻辑。
5. 反爬虫绕过：一些应用会检测自动化工具（如检查navigator.webdriver属性）。Playwright提供了一些绕过方法：

   browser = await p.chromium.launch(headless=True, args=[ ‘–disable-blink-features=AutomationControlled’ ]) # 此外，可以在每个页面加载前注入脚本删除或覆盖`webdriver`属性 await page.add_init_script(“”” Object.defineProperty(navigator, ‘webdriver’, { get: () => undefined }); ”“”)

7.3 安全与伦理边界

最后必须强调，自动化扫描是一把双刃剑，尤其当它具备高度模拟用户行为的能力时。

• 明确授权：永远只在你有权测试的目标上运行自动化扫描。未经授权的扫描是违法的。
• 避免破坏性操作：在扫描逻辑中，默认将所有的POST、PUT、DELETE、PATCH请求拦截并改为GET，或者仅记录而不实际发送。对于删除、扣款等关键操作，必须进行人工确认。
• 控制扫描强度：设置合理的请求速率（requests per second）限制，避免对目标服务器造成拒绝服务（DoS）攻击。
• 数据隐私：扫描过程中可能会接触到测试数据。确保这些数据被妥善处理，不在日志或报告中泄露真实用户的敏感信息。

SPA扫描攻防是一个持续演进的过程。前端框架在更新，防御技术在加强，我们的工具和方法也需要不断迭代。这个项目提供的是一套基础框架和核心思路，真正的战斗力来源于在具体目标上的持续实践、调试和优化。记住，没有银弹，但有了正确的工具链和方法论，你就能在SPA的安全迷宫中，拥有了一幅可靠的地图和一支强光手电。