一个人维护项目，上线前怎么做安全检查？用 Strix 跑一轮 AI 渗透测试

一个人维护项目，最难受的不是写代码。

是上线前那种心里发毛的感觉：

• 登录鉴权真的没问题吗？
• 用户 A 会不会看到用户 B 的订单？
• 支付金额能不能被前端改掉？
• 后台接口有没有忘记做权限判断？
• 上传文件会不会被打出 RCE？

如果你没有安全团队，也没预算天天请人做渗透测试，那可以看看 Strix。

它不是那种扫完甩你一屏“疑似漏洞”的工具。

它更像一个会动手的安全测试员：把你的应用跑起来，自己请求接口，自己改包，自己写 PoC，能打通才告诉你问题在哪。

项目地址：

https://github.com/usestrix/strix

Strix 到底是什么？

Strix 是一个开源 AI 渗透测试工具。

它的目标很直接：

帮你发现 Web 应用里的真实漏洞，并给出可复现步骤和修复方案。

它会把应用放到 Docker 沙箱里跑，然后配合浏览器、HTTP 拦截代理、Python 沙箱和多个 AI Agent 去做攻击测试。

听起来有点狠，对吧？

但这恰好是它和传统安全扫描器最大的区别。

传统工具常见流程是：

扫描代码或接口 → 匹配规则 → 给你一堆告警 → 你自己判断真假

Strix 更像这样：

运行应用 → 模拟攻击 → 写 PoC → 验证漏洞 → 给复现步骤 → 给修复建议

一个是“我怀疑这里有洞”。

一个是“我已经打通了，步骤在这，证据在这”。

差别很大。

它能测哪些安全问题？

Strix 盯的不是某一个小点，而是 Web 应用里最常见、最容易出事的那一批问题。

比如：

• XSS：评论区、富文本、搜索框有没有脚本注入风险
• SSRF：图片抓取、URL 预览、Webhook 能不能打内网
• SQL 注入：接口参数有没有被拼进 SQL
• 反序列化 RCE：不安全反序列化导致远程命令执行
• JWT 问题：签名校验、过期时间、算法混淆、权限字段篡改
• 越权访问：普通用户能不能访问管理员接口
• IDOR：改个订单 ID、用户 ID，就能看到别人的数据
• 支付篡改：前端传价格，后端不校验，直接血崩
• 竞态条件：优惠券、提现、库存扣减能不能并发刷穿
• OWASP Top 10 常见问题

这里面很多问题，普通静态扫描很难测出来。

尤其是业务逻辑漏洞。

比如支付金额篡改，工具光看代码很难判断“这个字段是不是关键价格”。但 Strix 会像测试员一样走流程，提交订单，拦截请求，改金额，再看后端有没有接收。

这种测试才有杀伤力。

Strix 的工作方式：不是看代码，是直接动手打

你可以把 Strix 理解成一支迷你安全小队。

它里面有几个关键组件。

1. Docker 沙箱：把应用关进安全测试环境

Strix 会在隔离环境里运行你的应用。

这样做有两个好处：

• 不影响你本机环境
• 攻击测试不会误伤真实服务

别拿生产库直接测。

真的，别。

你不想在凌晨两点看到测试工具把线上用户数据搞乱。

2. HTTP 拦截代理：像黑客一样改请求

它集成了类似 Caido 这类 HTTP 拦截代理的能力。

也就是：

• 抓接口请求
• 改参数
• 重放请求
• 对比响应
• 观察是否绕过权限或校验

举个很真实的例子。

你的前端提交订单时发了这个请求：

POST /api/orders
Content-Type: application/json
Authorization: Bearer xxx

{
  "productId": "pro_001",
  "quantity": 1,
  "price": 199
}

Strix 可能会尝试改成：

{
  "productId": "pro_001",
  "quantity": 1,
  "price": 1
}

如果后端真按 1 块钱创建订单，它就能抓住这个支付漏洞。

这类问题上线后被人发现，真不是“修个 bug”那么简单。

是事故。

3. 浏览器自动化：跑真实页面流程

很多漏洞不在单个接口里。

它们藏在流程里。

比如：

注册 → 登录 → 创建团队 → 邀请成员 → 修改成员角色 → 删除团队

权限问题往往出现在这种地方。

Strix 能通过浏览器自动化去走页面，把业务流程跑起来，再在关键节点尝试攻击。

这比只扫接口文档靠谱多了。

4. Python 沙箱：自动写 PoC

发现疑似漏洞后，它不会只丢一句“可能存在风险”。

它会尝试写 PoC。

比如 SSRF 的 PoC 可能长这样：

import requests

url = "http://localhost:3000/api/fetch-url"
payload = {
    "url": "http://169.254.169.254/latest/meta-data/"
}

r = requests.post(url, json=payload)
print(r.status_code)
print(r.text[:500])

你能直接拿来复现。

这点很关键。

安全工具最大的坑，就是报了一堆看起来很吓人的问题，开发者花一下午验证，结果全是误报。

能复现，才值得修。

适合谁用？

Strix 特别适合这几类人。

独立开发者

你一个人写前端、后端、部署、客服，还要管安全。

上线前跑一轮 Strix，至少能把明显的大坑抓出来。

尤其适合 SaaS、小工具、插件后台、付费会员系统。

小团队

没有专门安全岗位，但业务已经有用户、有付款、有后台权限。

别等出事再补。

安全这东西，线上补锅特别贵。

开源项目维护者

开源项目被 fork、被部署、被二开，使用场景很复杂。

把 Strix 加进安全检查流程，可以降低“别人一部署就被打穿”的风险。

AI 应用开发者

现在很多 AI 应用都有这些入口：

• 文件上传
• URL 抓取
• 插件调用
• Webhook
• 用户 Prompt
• 多租户数据隔离

这些地方都很容易出安全问题。

特别是多租户数据隔离。

用户 A 看到用户 B 的对话记录，这种事故能直接把信任打没。

快速上手：跑一次 Strix

下面给你一个通用流程。

不同项目细节可能不一样，具体命令以 GitHub 仓库文档为准。

项目地址：

https://github.com/usestrix/strix

准备环境

你需要准备这些东西：

• Docker
• Git
• 一个可用的 LLM API Key
• 你的应用源码
• 一份测试环境配置

建议单独准备测试数据库。

比如：

my_app_test

不要连生产库。

不要连生产对象存储。

不要连真实支付通道。

支付相关可以用 Stripe Test Mode、支付宝沙箱、微信支付沙箱。

克隆项目

git clone https://github.com/usestrix/strix.git
cd strix

配置模型 Key

一般这类工具会通过环境变量读取模型 Key。

示例：

export OPENAI_API_KEY="你的_key"

如果你用的是其他模型服务，查看 Strix 文档里的配置方式。

别把 Key 写进 Git。

可以放在 .env.local 或 CI/CD 的 Secret 里。

指定要测试的应用

假设你的应用在本地跑：

http://localhost:3000

你需要告诉 Strix 目标地址、启动命令、测试账号等信息。

例如：

target:
  url: "http://localhost:3000"
  start_command: "npm run dev"

accounts:
  user:
    email: "user@test.com"
    password: "password123"
  admin:
    email: "admin@test.com"
    password: "password123"

真实字段以项目文档为准。

核心思路是：

• 让 Strix 知道应用怎么启动
• 给它测试账号
• 告诉它哪些页面或接口值得重点测

建议这样写测试目标，效果更好

AI 工具不是玄学许愿池。

你给的信息越清楚，它越容易找到真问题。

可以准备一份测试说明，比如：

# 测试重点

这是一个订阅制 SaaS 应用。

核心功能：
- 用户注册登录
- 创建项目
- 邀请团队成员
- 修改成员角色
- 创建订单
- 开通会员
- 上传 PDF 文件
- 通过 URL 导入网页内容

重点检查：
- 普通用户是否能访问管理员接口
- 用户是否能读取其他团队的数据
- 是否能篡改订单价格
- 上传文件是否存在危险解析
- URL 导入功能是否存在 SSRF
- JWT 是否能被篡改

测试账号：
- 普通用户 A：a@test.com / password123
- 普通用户 B：b@test.com / password123
- 管理员：admin@test.com / password123

这种说明很有用。

因为业务逻辑漏洞需要上下文。

你不说“团队成员角色很重要”，工具未必知道要重点打这个点。

看报告时，重点盯这几块

Strix 生成报告后，别只看漏洞数量。

你要看的是这些内容。

漏洞是否可复现

高质量报告应该包含：

• 触发入口
• 请求参数
• 攻击步骤
• 实际响应
• 影响范围
• PoC 代码

如果它给了完整复现步骤，你就可以交给开发修。

哪怕开发就是你自己。🙂

CVSS 评分

CVSS 可以帮你判断优先级。

大致可以这么看：

| 评分 | 风险 | 处理建议 | |---|---|---| | 9.0 - 10.0 | 严重 | 立刻修，别上线 | | 7.0 - 8.9 | 高危 | 当前迭代必须修 | | 4.0 - 6.9 | 中危 | 排期修复，别拖太久 | | 0.1 - 3.9 | 低危 | 结合业务判断 |

别被低危麻痹。

有些低危组合起来，也能变成大事故。

修复建议是否具体

好的修复建议不是：

加强安全校验。

这话跟“多喝热水”差不多。

有用的建议应该像这样：

在 /api/orders/create 接口中，后端不要信任客户端传入的 price 字段。
应根据 productId 从数据库查询真实价格，并在服务端计算订单金额。

看到这种建议，就能马上改代码。

让 Strix 进 CI/CD：每次提交都拦一遍

如果你的项目已经用 GitHub Actions，可以把 Strix 放到流水线里。

典型流程是：

提交代码 → 启动测试环境 → 跑 Strix → 生成报告 → 高危漏洞阻止合并

这很适合多人协作。

比如有人改了权限逻辑，不小心把管理员接口暴露了。

CI 里直接拦住。

你不用等上线后被用户截图问候。

一个简化版思路：

name: Security Test

on:
  pull_request:
    branches: [main]

jobs:
  strix:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Docker
        uses: docker/setup-buildx-action@v3

      - name: Run app
        run: |
          docker compose up -d

      - name: Run Strix
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          # 这里按 Strix 官方文档填写实际运行命令
          echo "Run Strix security test"

命令别照抄就完事。

去看官方 README，把实际启动参数补进去。

一个实战场景：上线前检查会员系统

假设你做了一个小型 AI 写作工具。

功能包括：

• 免费用户每天 10 次生成
• 会员每天 500 次生成
• 用户可以购买套餐
• 支持团队协作
• 支持上传文档生成内容

上线前你可以让 Strix 重点打这些点。

检查 1：免费用户能不能绕过次数限制

测试目标：

免费用户调用生成接口超过 10 次，观察后端是否继续返回结果。

常见漏洞：

• 只在前端限制次数
• 后端计数可被重放绕过
• 并发请求导致扣减失败

检查 2：能不能篡改会员套餐价格

测试目标：

创建订单时修改 price、planId、duration 字段。

正确做法：

• 后端根据 planId 查询价格
• 支付回调重新校验金额
• 开通会员前验证支付状态

检查 3：团队数据是否隔离

测试目标：

用户 A 修改 projectId，尝试读取用户 B 的项目内容。

高发问题：

GET /api/projects/123

只判断用户已登录，却没判断这个项目是不是属于当前用户。

这就是典型 IDOR。

检查 4：文档上传是否安全

测试目标：

上传伪装文件、超大文件、特殊文件名、恶意内容。

建议处理：

• 限制文件类型
• 限制文件大小
• 文件名重新生成
• 文件内容异步解析
• 不要直接执行上传内容
• 对解析服务做隔离

避坑清单：别把安全测试跑成生产事故

用这类工具之前，先把下面这些坑避开。

别测生产环境

不要拿真实用户、真实订单、真实支付去测。

你以为是在验证安全。

结果可能是在制造事故。

别用管理员真实账号

准备专门的测试账号。

权限要覆盖业务场景，但不要接入真实后台数据。

别让测试环境连内网敏感服务

SSRF 测试可能会请求内网地址。

测试环境里不要暴露：

• 云厂商元数据服务
• 内部管理后台
• Redis
• Elasticsearch
• Jenkins
• Kubernetes API

别忽略成本

Strix 需要调用 LLM。

复杂项目跑一轮可能会消耗不少 token。

建议：

• 先测核心业务
• 限制测试范围
• 在 CI 里只对关键 PR 跑完整测试
• 日常提交跑轻量测试

别把报告原封不动公开

安全报告里可能包含：

• 真实接口
• Token
• 测试账号
• 漏洞细节
• PoC

公开前记得脱敏。

别把它当万能安全团队

Strix 很强，但不能替代完整安全体系。

你依然需要：

• 代码审查
• 依赖漏洞检查
• 密钥泄露扫描
• 日志审计
• 权限设计
• 备份和回滚方案

工具是安全网，不是护身符。

最推荐的使用节奏

如果你是个人开发者，可以按这个节奏来。

开发阶段

每做完一个敏感功能，就跑一次小范围测试。

敏感功能包括：

• 登录注册
• 权限系统
• 支付订单
• 文件上传
• URL 抓取
• 管理后台
• 团队协作

上线前

跑一轮完整测试。

重点看：

• 高危漏洞
• 可复现漏洞
• 业务逻辑漏洞
• 支付相关漏洞
• 数据越权问题

高危没修完，别硬上。

真别赌。

上线后

把 Strix 接进 CI/CD。

每次合并到主分支前，至少跑核心安全用例。

你会少很多半夜救火的机会。

这可太值了。

Strix 值得关注的点

几个亮点可以记住：

• 开源，Apache 2.0 协议
• 能在 Docker 沙箱里跑应用
• 能结合 HTTP 代理做真实攻击测试
• 能用浏览器自动化走业务流程
• 能写 PoC 验证漏洞
• 能生成复现步骤和 CVSS 评分
• 支持多个 Agent 分工协作
• 可以尝试自动生成补丁并开 PR
• 适合接入 CI/CD 做安全门禁

对没有安全团队的小项目来说，它像是在上线前多了一个“会动手找茬的人”。

而且这个人不嫌烦。

你可以今天就做的三件事

别收藏吃灰。

今天就能开干：

• 去 GitHub 看 Strix README：https://github.com/usestrix/strix
• 给你的项目准备测试账号和测试数据库
• 写一份“安全测试重点说明”，把支付、权限、上传、URL 抓取列进去

等这些准备好，再跑第一轮测试。

你可能会被结果吓一跳。

但放心，被工具吓到，比被真实攻击者教育要便宜太多。