sloptic/sloptic-main

# Sloptic Sloptic 会对任何已部署的 Web 应用进行评分，无论其使用何种技术栈或用于何种目的，并给出一个你可以用来在不同应用间进行比较的单一分数。只需指向一个 URL，它就会返回一个 **slop score**（越低越好，`0` 表示未发现任何问题），并显示该应用在其他应用群体中的排名。它不需要读取源代码，也不需要规格说明，因此在黑客马拉松中，无论各个参赛作品是用什么构建的，都将采用同一标准进行评分。 ``` uv run python -m sloptic.cli --target https://your-app.example.com ``` ## 为什么 梅里亚姆-韦伯斯特将 *slop*（劣质内容）定为 2025 年度的词汇，它指的是生成式 AI 如今批量产出的敷衍内容，以及那些塞满每个信息流的垃圾图片和填充文本。软件在更深一层也存在着同样的现象。AI 辅助构建让发布 Web 应用变得几乎零成本，黑客马拉松的展示区里充斥着各种看起来已经完成、但从未经过加固的参赛作品。对 AI 生成代码的研究证实了这种担忧：研究发现其中大约一半存在漏洞。然而，当我们自己对 1,537 份真实的参赛作品进行评分时，发现它们的缺陷往往不是什么戏剧性的漏洞利用。更常见的，是那些被遗漏的枯燥且普遍的基础问题：没有安全 Header，没有 rate limiting，糟糕的 accessibility（无障碍访问），或者是将 dev build 发布到了生产环境。事实证明，应用 slop 是一种慢性病，而非急性病。 这也是该项目名字的由来。 ## 定位 大多数探测 Web 应用的工具都是 fuzzer 或 scanner。它们在单个应用中寻找 bug 并交给你一份列表。Sloptic 的做法与众不同：它将一个任意应用转化为一个 **可比较的质量数值**，这样一来，许多毫不相干的应用就可以在同一个衡量标准下进行排名，而完全不需要了解它们各自的功能。 这就是它被开发出来的目的：对黑客马拉松参赛作品进行客观的质量评分。Sloptic 最初是 HackLet League 的韧性评分工具，现在已成为一个独立项目，服务于该联盟以及任何希望在所有参赛作品中获得客观、一致的质量衡量标准的黑客马拉松组织者。人类评委无法在脑海中同时记住一百种技术栈。Sloptic 以相同的方式对它们进行评分，并将每一个应用置于同一条曲线上。 Sloptic 评判的是 slop 带来的可观察后果，即无论应用用于什么用途都是错误的那些故障，而不是产生这些故障的代码。 ## 评判内容 Sloptic 只针对 **与意图无关的** 故障进行触发：即无论应用旨在实现什么功能，都属于缺陷的问题。例如泄露的 SQL 错误、没有 rate limiting 的登录页面、满是几乎不可见文字的页面、因畸形输入导致的崩溃、或者是发布到生产环境的 dev build。这些问题都不依赖于了解应用的目的。这种边界是刻意设定的。人类带着意图，而 Sloptic 承担了机器可以客观评判的那部分。它永远不会告诉你某个功能好不好，它只会告诉你这个应用是否足够健壮。 其目录包含跨越三个维度的 **91 个 probe**： | 维度 | probe 数量 | 示例 | |------|:------:|----------| | **security** | 57 | SQLi、XSS/SSTI、path traversal、SSRF、暴露的 `.git`/备份/敏感信息、缺少 rate-limiting、header/CORS/重定向防御、托管后端（如 Supabase/Firebase）的 RLS | | **qa** | 22 | accessibility（基于 axe-core，按严重程度分级）、失效链接、soft-404s、未处理的 5xx 错误、发布 dev-build、content-type 准确性 | | **performance** | 12 | TTFB、页面负载大小、请求计数、Core Web Vitals（网络限速、N 次中取最优）、计算得出的加载时间 | 每个维度都会报告其自身经过衰减处理的 subtotal，这三项加起来精确等同于 slop score。 ## 分数与跨应用比较 - **仅扣分且上不封顶。** 没有加分项，也没有 0 到 100 的上限。一个没有攻击面的应用和一个对攻击面进行了防御的应用都会得 `0`。“未发现问题”和“发现并已处理”被视为相同的结果。 - **风险定价。** 每次惩罚的分数等于发生频率乘以严重程度（即预期危害），这是一张经过精心设计的表格，而不是原始的严重程度。 - **Damped（衰减）处理，因此同一根本原因只计算一次。** 一个 probe 的各种检测变体会被合并为单个发现，并且在多个 endpoint 上重复出现的同类问题会产生递减的边际惩罚。十个缺少某个 header 的 endpoint 并不等于十个独立发现。 - **具备可比性。** 通过一个固定的参考分布状态，可以将原始分数转化为百分位数：不仅仅是显示“slop 分数为 42”，而是表示“比 70% 的群体更干净”。正是这种对比使得排名成为可能，这也是 Sloptic 有别于普通 scanner 的地方。 ## Coverage 透明度 只有当你知道测试了什么内容时，低分才有意义。每次评分都会附带一份 coverage 报告（包含适用的 probe、已运行的 probe、观察到的攻击面），这样就可以区分出表示“干净”的 `0` 分和表示“无法触达攻击面”的 `0` 分。Sloptic 能够很好地对未经身份验证的、可观察的攻击面进行评分。它并不声称自己能对深层的需要身份验证或依赖于意图的行为进行测试，并且它对此直言不讳，而不是暗示自己具备全面性。 ## 安装 ``` uv sync # core uv sync --group browser # adds Playwright, for the accessibility, CWV, and DOM-XSS probes uv run playwright install chromium ``` ## 用法 对在线 URL 进行评分（不会部署任何内容，也不会破坏任何内容，并且仅限测试你拥有或被授权测试的目标）： ``` uv run python -m sloptic.cli --target https://your-app.example.com ``` 对参赛作品进行评分（包含 `Dockerfile` 的 zip 压缩包），该作品会在沙箱中构建并运行，随后进行评分： ``` uv run python -m sloptic.cli --submission team.zip ``` 如果提交的作品无法解压、没有 `Dockerfile`、无法构建，或者始终不响应 `$PORT`，系统将生成一条 `DNF` 记录并以非零状态退出。这绝不会导致评分程序崩溃。 针对内置的参考应用运行校准套件： ``` uv run pytest -q ``` ## 部署方式 该 pipeline 仅依赖于 `Deployer`，因此同一个目录可以在以下三种后端中的任何一种上运行： - **`SubprocessDeployer`**（用于开发和 CI）在本地启动受信任的参考应用。它从不用于不受信任的代码。 - **`DockerDeployer`**（用于生产环境）在沙箱中构建并运行不受信任提交者的 `Dockerfile`：配备临时的、固定的 CPU、RAM 和 PID 配额，应用 `--cap-drop=ALL`、`--security-opt=no-new-privileges`，并为对抗性代码提供位于阻止出站流量的内部网络上的可选只读 rootfs。 - **`RemoteDeployer`**（用于内部测试/dogfooding）指向一个已经在运行的 URL，且不进行任何部署。 在“应用响应 `$PORT`”之后的所有流程都是完全相同且与技术栈无关的。 ## 正确性如何检验 我们采用了两种工具，因为它们解答的是不同的问题： 1. **参考应用**（`references/`：`vulnerable`、`hardened`、`minimal`、`jsonapi`、`qa-janky`、`spa`）是一组具有已知标准答案的固定校准集。`vulnerable` 应用必然会产生 slop，而 `hardened` 应用必然得分为 `0`。这就是正确性的锚点。 2. **recall 基准测试** 包含带有 CWE 标签的场景，用于确认每个 probe 在其对应的 bug 确实存在时能够被触发。真实应用语料库能告诉你缺陷发生的频率，但只有具备真实基准的数据才能告诉你检测器是否有效。 `uv run pytest -q` 可运行校准套件（共 848 项测试）。 ## 关于范围的坦诚说明 Sloptic 旨在对已部署的 Web 应用进行大规模评分：包括黑客马拉松参赛作品、CI 门禁检查以及你自己的项目。它在处理未经身份验证的可观察攻击面，以及具有同源后端的客户端渲染 SPA 时表现最为出色。但在缺陷隐藏在它无法以黑盒形式建立的身份验证之后的情况下，或者在评判该发现需要结合产品意图的情况下，它的表现就会减弱。这些限制都会被如实报告出来，而不是被隐藏。 ## License Apache-2.0。

标签：Web应用测试, 可访问性, 安全合规, 性能监控, 特征检测, 网络代理, 自动化评分, 请求拦截, 质量评估, 逆向工具, 黑盒测试