WebCrack：面向真实Web后台的可控爆破验证框架

简介：WebCrack是一款面向网络安全从业者、渗透测试初学者及系统管理员的开源Web后台弱口令批量爆破与检测工具，专用于网站安全审计场景，帮助识别admin、root等常见账户搭配123456、password等高危组合引发的安全隐患。资源包为ZIP格式，共18个文件，含12个Python核心脚本（如webcrack.py主程序、crack_task.py任务调度、dict.py字典生成模块）、3个文本配置文件（password_list.txt密码库、url.txt目标列表、requirements.txt依赖说明）、1个README.md使用文档及1张界面示意图PNG，整体仅114KB，轻量易部署。已有410人学习下载，适合快速上手实战——读者可直接运行完整爆破流程，复用预置字典与日志模块（log.py），结合conf/与generator/目录下的配置管理与字典生成能力，构建可定制的弱口令检测方案。

1. WebCrack 不是“一键秒破”的黑匣子，而是你手里那把可调扭矩的螺丝刀：专治后台登录页弱口令批量验证场景

某高校实验室在做渗透测试教学时，常遇到一个尴尬问题：学生手写 Python 脚本跑 admin.php 的弱口令，5 分钟后卡在验证码或登录失败重定向上，根本跑不完 2000 行字典；而商用工具又动辄要授权、封 IP、不透明。这时候 WebCrack 就不是“黑客玩具”，而是一套面向真实 Web 后台登录接口的可控爆破验证框架——它不绕过验证码，也不伪造 UA 欺骗 WAF，而是老老实实模拟表单提交、解析响应状态码与 HTML 特征、支持自定义 Cookie 和 Referer、能按 HTTP 状态码（如 302 跳转）、响应体关键词（如 “欢迎回来”、“登录成功”）、响应头字段（如 Set-Cookie 中含 sessionid）三重维度判定“爆破成功”。它适合安全工程师做红队预检、运维自查账号强度、CTF 比赛中快速验证靶机后台，也适合刚学完 requests + BeautifulSoup 的新手，把“爆破逻辑”从黑盒脚本里拎出来，一行行看懂怎么和服务器“对话”。这不是万能钥匙，但它是你第一次亲手拧开 Web 后台门锁时，最稳的那一把螺丝刀。

2. WebCrack 的核心设计不是堆功能，而是把“登录交互”拆成可配置的原子动作：请求构造 → 响应解析 → 成功判定 → 限速控制

WebCrack 的底层逻辑非常干净：它不内置任何密码字典，不硬编码 CMS 类型（如 WordPress、Discuz），也不自动识别登录表单字段名。它把整个流程抽象为四个可配置环节，全部通过 YAML 配置文件驱动。这种设计让工具脱离“猜字段名”的玄学阶段，进入“我明确告诉它怎么发、怎么看、怎么判”的工程化阶段。下面我们就用一个真实复现过的案例——某国产 OA 系统后台（/login.jsp）——来走一遍完整配置链路。

2.1 登录请求模板：用 YAML 描述 POST 请求的每个细节，包括动态参数提取

WebCrack 的config.yaml中request字段不是简单写 URL 和 data，而是支持变量注入与前置提取。比如该 OA 系统登录前需先 GET/login.jsp获取隐藏字段__VIEWSTATE和__EVENTVALIDATION，再 POST 提交。配置如下：

request: method: POST url: "https://target.com/login.jsp" headers: User-Agent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" Referer: "https://target.com/login.jsp" cookies: {} data: __VIEWSTATE: "{{viewstate}}" __EVENTVALIDATION: "{{eventvalidation}}" txtUserName: "{{username}}" txtPassword: "{{password}}" btnLogin: "登录" pre_request: - method: GET url: "https://target.com/login.jsp" extract: - name: viewstate regex: 'name="__VIEWSTATE" value="([^"]+)"' - name: eventvalidation regex: 'name="__EVENTVALIDATION" value="([^"]+)"'

逻辑说明：pre_request是 WebCrack 的关键设计。它允许你在主请求前执行一次或多次 HTTP 请求，并用正则从响应体中提取值，注入到主请求的data字段中。这里{{viewstate}}不是 Jinja 模板语法，而是 WebCrack 内部解析器识别的占位符，运行时自动替换。regex必须写成单行字符串，括号捕获组即为提取内容，无需re.search().group(1)手动调用。

2.2 成功判定规则：三类响应特征并行校验，拒绝“只看状态码”的粗暴逻辑

很多初学者误以为status_code == 200就是登录成功，结果爆破出一堆“账号存在但密码错误”的页面。WebCrack 支持status_code、body_contains、header_contains三者任意组合，且支持布尔逻辑（and/or）。针对该 OA 系统，我们观察到：登录成功时返回 302 跳转到/main.jsp，且响应头Set-Cookie包含JSESSIONID=，同时响应体不含“用户名或密码错误”字样。配置如下：

success_rule: status_code: 302 body_contains: - "用户名或密码错误" - "验证码错误" body_contains_not: true # 注意：这是取反逻辑，即“不包含以上任一字符串” header_contains: Set-Cookie: "JSESSIONID="

参数说明：body_contains_not: true是 WebCrack 的独有设计，表示body_contains列表中的所有字符串都不能出现在响应体中。这比写body_not_contains: ["xxx", "yyy"]更符合直觉。header_contains支持键值对精确匹配，也可只写键名（如Location:）做存在性判断。所有判定项默认为AND关系，即全部满足才算成功。

2.3 限速与重试策略：防封 IP 的本质不是“慢”，而是“像人”

WebCrack 默认无延迟，但真实环境中直接并发 50 线程扫 1000 个密码，10 秒内必被 WAF 拉黑。它的rate_limit和retry配置不是摆设：

rate_limit: delay_per_request: 1.2 # 单次请求后固定休眠 1.2 秒 max_concurrent: 3 # 最大并发数，避免连接池耗尽 retry: max_attempts: 2 backoff_factor: 1.5 # 第一次重试延 1.2*1.5=1.8s，第二次延 1.8*1.5=2.7s

为什么这样设：delay_per_request比requests.adapters.HTTPAdapter(pool_connections=10)更底层——它是在每次session.request()调用后强制 sleep，确保时间戳间隔真实可控。max_concurrent: 3是血泪经验：多数中小型企业 Web 服务器的默认 Keep-Alive 连接数为 5~10，设太高反而触发服务端 RST。backoff_factor采用指数退避，比固定重试更抗网络抖动。这些参数不是“越小越安全”，而是根据目标服务器的响应时间分布（可用curl -w "@format.txt"测）动态调整的。

3. 字典与账号列表不是随便扔进去就行：格式规范、去重逻辑、分片加载机制决定爆破效率上限

WebCrack 支持三种输入模式：单账号多密码（-u admin -p pass.txt）、多账号单密码（-U users.txt -p 123456）、多账号多密码笛卡尔积（-U users.txt -P passes.txt）。但实际使用中，90% 的翻车源于字典文件本身不合规。我们以某次红队支撑任务为例，原始字典top1000.txt是从公开 GitHub 项目下载的，表面看是纯文本，实则暗藏坑点。

3.1 字典文件必须满足 UTF-8 BOM 清零 + 行末无空格 + 空行自动跳过

WebCrack 使用 Pythonopen(file, 'r', encoding='utf-8')读取，若文件含 BOM（Byte Order Mark），首行会读成\ufeffadmin，导致账号不存在；若某行末尾有不可见空格（如admin），密码校验时会传入admin而非admin，必然失败。正确处理方式是用iconv或 VS Code 编码转换：

# Linux/macOS 下清除 BOM 并标准化换行 iconv -f utf-8 -t utf-8-bom top1000.txt | sed 's/[[:space:]]*$//' | grep -v '^$' > clean_pass.txt # Windows 下用 PowerShell（管理员权限） Get-Content top1000.txt | ForEach-Object { $_.Trim() } | Where-Object { $_ } | Set-Content clean_pass.txt -Encoding UTF8

逻辑说明：sed 's/[[:space:]]*$//'删除每行末尾所有空白字符（空格、制表符、全角空格）；grep -v '^$'过滤空行。这两步必须在iconv后执行，因为 BOM 会影响正则匹配。WebCrack 本身不自动 trim 行内容，这是设计选择——避免误删密码中本就存在的末尾空格（如某系统强制密码以空格结尾）。

3.2 多账号文件-U的格式陷阱：冒号分隔 vs 换行分隔，WebCrack 只认换行

很多用户把users.txt写成admin:password\nroot:123456，期望 WebCrack 自动解析为账号密码对。但 WebCrack 的-U参数仅接受纯用户名列表，每行一个，格式必须是：

admin root testuser

若需账号密码对，必须用-U users.txt -P passes.txt并启用笛卡尔积，或改用-c cred_pairs.txt（需 CSV 格式，第一列为 username，第二列为 password）。这是为避免歧义：当某行含:时，是账号名含冒号？还是分隔符？WebCrack 选择不做猜测，强制格式统一。

3.3 大字典分片加载：内存友好型设计，避免 OOM 杀死进程

当passes.txt达到 50MB（约 500 万行），直接加载进内存会导致 Python 进程占用 1.2GB RAM，某些低配测试机直接被系统 OOM Killer 终止。WebCrack 的解决方案是流式分片（streaming chunk）：

# config.yaml 中启用 dictionary: chunk_size: 50000 # 每次只加载 5 万行到内存 buffer_mode: true # 启用缓冲区，避免频繁磁盘 IO

参数说明：chunk_size不是并发线程数，而是内存中缓存的密码行数。WebCrack 会先读取前 5 万行，爆破完再读下 5 万行，如此循环。buffer_mode: true会额外申请 2MB 缓冲区，将磁盘读取与 CPU 计算流水线化。实测在 4C8G 机器上，chunk_size=100000时内存稳定在 380MB，而chunk_size=500000时峰值达 920MB。这不是性能妥协，而是对资源边界的诚实交代。

4. 避坑：五个真实踩过的坑，现象、原因、解决全写透，省得你重蹈覆辙

WebCrack 的文档简洁，但真实环境远比示例复杂。以下是我在三个不同客户现场部署时，反复遇到并记录下来的典型问题。每一条都对应一次真实翻车，附带抓包证据和修复验证。

4.1 现象：爆破始终返回 “No valid credentials found”，但手动 curl 测试同一账号密码却能登录

原因：目标系统启用了SameSite=Lax的 Cookie 策略，WebCrack 默认未携带Referer，导致服务端拒绝设置 Session Cookie
解决：在config.yaml的request.headers中显式添加Referer，且值必须与url的域名一致（不能写https://evil.com）：

headers: Referer: "https://target.com/login.jsp" # 必须与目标 URL 同源 User-Agent: "Mozilla/5.0..."

验证方法：用curl -v -H "Referer: https://target.com/login.jsp" -d "..." https://target.com/login.jsp对比有无 Referer 时的Set-Cookie响应头差异。

4.2 现象：爆破中途大量出现 “Connection reset by peer” 错误，日志显示 socket.error 104

原因：目标 Web 服务器设置了MaxKeepAliveRequests 100，WebCrack 默认复用连接，第 101 次请求时连接被服务端主动关闭
解决：在config.yaml中禁用连接复用，强制每次请求新建连接：

request: # ... 其他字段 disable_keepalive: true # 新增此行

原理补充：HTTP/1.1 默认开启 Keep-Alive，disable_keepalive: true会让 WebCrack 在请求头中添加Connection: close，服务端处理完本次请求后立即断开 TCP 连接，规避服务端连接数限制。代价是略微增加 TCP 握手开销，但比连接重置可靠得多。

4.3 现象：使用-U users.txt -P passes.txt时，爆破速度极慢，CPU 占用仅 15%，IO Wait 高达 70%

原因：passes.txt文件放在 NFS 挂载的远程存储上，WebCrack 的流式分片读取触发了大量小文件 IO
解决：将字典文件拷贝至本地 SSD 盘，并在config.yaml中指定绝对路径：

dictionary: password_file: "/mnt/ssd/clean_pass.txt" # 绝对路径，避开网络文件系统

数据佐证：同一台机器，NFS 上读取 100 万行耗时 42 秒（IO Wait 68%），本地 SSD 仅 1.8 秒（IO Wait <5%）。WebCrack 的分片机制依赖顺序读取，随机 IO 性能差的存储会成为瓶颈。

4.4 现象：成功爆破后，导出的result.csv中密码字段为空，只有账号和 URL

原因：success_rule中配置了body_contains_not: true，但 WebCrack 解析 CSV 时将true误认为布尔值而非字符串，导致配置解析异常，密码未写入结果
解决：在 YAML 中对布尔值加引号，强制作为字符串处理：

body_contains_not: "true" # 加英文双引号 # 或更推荐写法： body_contains_not: yes # YAML 标准关键字，WebCrack 已适配

注意：YAML 规范中true/false/yes/no都是布尔类型，但 WebCrack 的配置解析器对true有特殊处理逻辑。加引号是最稳妥的绕过方式。

4.5 现象：在 CentOS 7 上运行webcrack.py报错ModuleNotFoundError: No module named 'urllib3.util.retry'

原因：系统自带的python36包中urllib3版本过低（<1.26），而 WebCrack 依赖urllib3.util.retry.Retry的新接口
解决：升级 urllib3 至 1.26.15 或更高版本：

pip3 install --upgrade urllib3==1.26.15 # 若提示权限不足，加 --user 参数 pip3 install --user --upgrade urllib3==1.26.15

兼容性提示：WebCrack 官方测试环境为 Python 3.8+，CentOS 7 默认 python36 属于“尽力支持”范围。生产环境强烈建议用pyenv管理 Python 版本，避免系统包污染。

5. 进阶技巧：用 WebCrack 的 Hook 机制实现动态 Token 注入与二次验证绕过

WebCrack 的hook功能是它区别于其他爆破工具的核心竞争力——它允许你在请求发出前、响应接收后插入自定义 Python 函数，实现完全动态的认证流程。比如某金融系统后台，登录成功后需用返回的token去/api/v1/verify接口做二次校验，只有两次都通过才算真正登录成功。原生配置无法覆盖这种链式调用，但 Hook 可以。

5.1 编写 Hook 函数：pre_request_hook.py实现 token 提取与注入

在 WebCrack 同级目录创建hooks/文件夹，放入pre_request_hook.py：

# hooks/pre_request_hook.py import re import json def inject_token(request_data, context): """ request_data: dict, 当前请求的 data 字典（如 {'username': 'a', 'password': 'b'}） context: dict, 全局上下文，含上一次响应的 response.text、response.headers 等 返回: 修改后的 request_data """ if 'token' in context and context['token']: # 将 token 注入到下一次请求的 data 中 request_data['auth_token'] = context['token'] return request_data def extract_token(response, context): """ response: requests.Response 对象 context: dict, 供后续请求使用的上下文 """ if response.status_code == 200: try: # 从 JSON 响应中提取 token data = response.json() if 'data' in data and 'token' in data['data']: context['token'] = data['data']['token'] except (json.JSONDecodeError, KeyError): pass return context

逻辑说明：inject_token在每次请求前被调用，检查context中是否有token，有则注入到request_data；extract_token在每次响应后被调用，尝试从 JSON 中提取token并存入context。两个函数通过context共享状态，形成“请求→响应→提取→下次请求注入”的闭环。

5.2 在 config.yaml 中启用 Hook：指定函数路径与执行时机

hook: pre_request: "hooks.pre_request_hook.inject_token" post_response: "hooks.pre_request_hook.extract_token"

路径规则：hooks.pre_request_hook.inject_token表示hooks/目录下的pre_request_hook.py文件中的inject_token函数。WebCrack 使用 Python 的importlib动态导入，因此文件名、函数名必须严格匹配。pre_request和post_response是唯一支持的两个钩子点，不支持pre_response或post_request。

5.3 验证链式流程：用 curl 模拟对比，确认 Hook 生效

假设原始登录请求返回：

{"code":200,"msg":"ok","data":{"token":"abc123xyz"}}

二次验证请求需 POST：

{"auth_token":"abc123xyz"}

我们用 curl 手动验证链路：

# Step1: 登录获取 token curl -X POST https://target.com/api/v1/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"123456"}' \ -s | jq '.data.token' # 输出 "abc123xyz" # Step2: 用 token 验证 curl -X POST https://target.com/api/v1/verify \ -H "Content-Type: application/json" \ -d '{"auth_token":"abc123xyz"}' \ -s | jq '.code' # 应输出 200

Hook 验证要点：启动 WebCrack 时加-v参数（verbose），日志中会出现HOOK: pre_request called和HOOK: post_response called，且context中的token值会被打印。若未看到日志，检查hooks/是否在 Python path 中（可临时加sys.path.append('./hooks')到 WebCrack 主程序）。

从那以后我每次遇到需要多步交互的后台系统，都不再手写脚本，而是先花 10 分钟写好pre_request_hook.py和post_response_hook.py，再用 WebCrack 的 YAML 配置把流程串起来。它逼着我把“登录逻辑”拆解成可验证的原子步骤，而不是靠运气猜。这种确定性，比任何“全自动”工具都让我安心。希望帮到你。

本文还有配套的精品资源，点击获取