简介：WebCrack是一款面向网站安全审计与渗透测试场景的开源免费工具，主要用于对Web后台常见弱口令及万能密码进行批量检测，帮助管理员提前发现登录入口的脆弱点，适合安全工程师、运维人员及合规测试学习者使用。压缩包共18个文件，大小仅114KB，其中12个Python脚本承担核心爆破、解析与任务调度逻辑，3个txt文档提供默认字典与URL配置，另有README说明及示意图片，结构清晰，便于二次开发。已有406人浏览学习。通过阅读源码和配置文件，可以掌握弱口令字典构造、并发请求参数调整以及结果日志解析等思路；借助项目自带的密码字典与输入输出模块，可直接替换目标地址展开受控环境下的合规测试，也可作为学习Python安全脚本编写的完整范例，兼顾实用性与教学价值。
1. WebCrack 到底是什么：开源的 web 后端弱口令批量检测工具
先说结论：WebCrack 不是扫描器，是一个跑在 Python 环境里的 web 后端登录爆破器。它把“目标地址 + 用户名列表 + 密码字典”三者组合起来，自动发 HTTP 请求，通过返回内容判断是否登录成功，并且额外集成了一批万能密码 payload 用于测试后台登录接口的注入式绕过。开源免费，命令行驱动，适合批量验证内网或授权项目的后台弱口令风险。
它解决的核心问题很具体：当你有几十个后台地址要检查时，手工一个一个试密码是不现实的，而 WebCrack 这类工具能把“弱口令检测”这件事做成半自动流水线。适用人群是安全测试、运维、开发自测，前提是目标授权明确。它并不能发现未知漏洞，也不是爬虫，必须由你先给定后台登录 URL 和用于判断登录成功的特征。把这件事想清楚，后面用起来才不会翻车。
2. 快速上手：先跑通最小命令，再谈批量爆破
2.1 环境准备：Python 版本与依赖安装
WebCrack 常见实现基于 Python 3，依赖 requests、beautifulsoup4 这类 HTTP 解析库。安装依赖之前先确认 Python 版本，避免在 2.7 环境里折腾半天发现语法不兼容。
python3 --version pip3 install requests beautifulsoup4逻辑说明：第一条命令确认解释器版本，第二条把 HTTP 客户端和 HTML 解析库装上。requests 负责发送登录请求，beautifulsoup4 用于从响应里提取提示信息。如果你用的发行版自带 python3-requests 系统包，也可以用 apt 或 yum 安装，但我一般建议用 pip 装到虚拟环境里，省得污染系统环境。
参数说明：这里没有指定版本号，因为工具本身对依赖版本不敏感。若你本机已有旧版 requests，出现响应乱码时再升级不迟，不必提前锁版本。
2.2 启动命令：从单目标测试到批量模式
WebCrack 命令行参数在大多数开源实现里遵循同一套风格：目标文件、线程数、超时、延时、字典路径。先跑单目标，确认逻辑通，再上批量。
python3 webcrack.py -u "http://192.168.1.10/admin/login.php" -U users.txt -P pass.txt -t 1 --timeout 8 --delay 1逻辑说明：-u指定单个登录 URL，-U指定用户名字典，-P指定密码字典，-t 1表示单线程，--delay 1表示每次请求间隔 1 秒。第一次跑单线程是为了看输出格式，确认工具能正确识别“登录失败”的页面特征，避免批量时全是误报。
参数说明：--timeout 8是单次请求超时，单位为秒。内网目标可以压到 5，公网目标建议给到 10 以上，避免网络抖动导致大量假超时。--delay是请求间隔，批量时建议不低于 0.5 秒，这个值是对目标服务器最基本的礼貌。
2.3 确认批量目标文件格式
批量模式用-f指定目标文件，每一行一个后台登录地址。注意：URL 必须带协议头，且最好是完整的登录接口地址，不是站点根目录。
python3 webcrack.py -f targets.txt -U users.txt -P pass.txt -t 5 --timeout 8 --delay 0.5 --save result.txt逻辑说明：-f targets.txt批量模式下从文件读取目标，--save result.txt把成功条目写入结果文件。targets.txt 格式参考：
http://192.168.1.10/admin/login.php http://192.168.1.11/wp-login.php http://test.example.com:8080/user/login参数说明：-t 5表示 5 个并发线程。线程数不是越大越好，超过 10 之后目标服务器的连接数限制会触发大量连接失败。公网目标建议 3 到 5，内网目标可以到 8 到 10，视目标吞吐量调整。
跑通最小命令之后，你已经掌握了这个工具 80% 的日常用法。剩下的是理解它的判断逻辑，以及知道为什么有些目标爆破结果不可信。
3. 爆破原理与万能密码：工具为什么能判断登录成功
3.1 登录请求的构造逻辑
后端登录爆破工具要解决的核心问题有三个：表单参数名是什么、密码字段叫什么、登录成功和失败在响应里怎么区分。WebCrack 的做法是先让用户提供示例请求，或者自动从 URL 对应的 HTML 表单里解析 input 字段。
import requests from bs4 import BeautifulSoup # 自动解析登录表单的字段名 def parse_form(url): resp = requests.get(url, timeout=8) soup = BeautifulSoup(resp.text, "html.parser") form = soup.find("form") inputs = {} for inp in form.find_all("input"): name = inp.get("name") if name: inputs[name] = inp.get("value", "") # 常见登录表单会有 username / password 字段 return inputs # 构造登录请求 def try_login(url, username, password): data = { "username": username, "password": password, } resp = requests.post(url, data=data, timeout=8, allow_redirects=False) return resp逻辑说明：第一段从登录页 HTML 里解析出所有 input 字段名，第二段用解析结果构造 POST 请求。allow_redirects=False很关键——很多后端登录成功后会 302 跳转到首页，如果自动跟随跳转，判断逻辑会被干扰。
参数说明：parse_form只适用于表单直出的传统后端。如果目标用 JavaScript 动态渲染登录框，解析结果为空，这种目标就需要把参数名手动写进配置文件。不要指望一条命令通吃所有前后端分离的项目。
3.2 登录成功的判定特征：关键字、状态码、跳转
工具判断“这一组用户名密码是否有效”，靠的不是猜测，而是三种响应特征的组合。第一种是响应体中的关键字，比如“欢迎”“dashboard”“logout”；第二种是 HTTP 状态码，比如登录失败返回 200 但带错误提示，登录成功返回 302；第三种是响应长度，成功页和失败页的 HTML 体量通常差很多。
正确密码响应: 302 -> /admin/index.php (响应体 512 字节) 错误密码响应: 200 -> 用户名或密码错误 (响应体 206 字节) 万能密码响应: 302 -> /admin/index.php (响应体 512 字节)这是 WebCrack 这类工具判断的核心：拿“正确登录”的响应特征作为基准，批量测试时用同样的特征去比对。所以使用前最好先手工登录一次目标后台，保存成功响应特征，然后在工具配置里指定关键字为“logout”或“欢迎”，比默认判断精准得多。
3.3 万能密码为什么能绕过认证：本质是 SQL 注入
万能密码不是“一个密码通杀所有后台”，而是一组利用后端 SQL 拼接漏洞的 payload。常见形式是' or '1'='1和admin'--，前者让 WHERE 条件恒真，后者把后续密码校验注释掉。WebCrack 内置的万能密码模块本质是把这些 payload 作为密码字典的一部分发送。
# 内置万能密码表（常见实现中的子集） universal_payloads = [ "' or '1'='1' --", "' or '1'='1' #", "admin' --", "' or 1=1 --", "1' or '1'='1", ]逻辑说明：上面这段 payload 列表是工具里最常见的几种。关键在于后端代码里 SQL 语句是字符串拼接而不是参数化查询，用户名和密码直接进入 SQL 条件，闭合引号后注释掉剩余条件。WebCrack 批量发送时把每个 payload 当作密码，用户名用admin或目标已知用户名。
参数说明：万能密码测试不需要完整字典，只需要少量 payload 加高频用户名。很多内网后台用的是select * from user where name='$name' and pwd='$pwd'这种代码，一条' or 1=1 --就能直接登进去。如果目标用 PDO 参数化查询，万能密码模块会全部失败，这本就是预期结果。
3.4 漏洞原理的边界：不要把万能密码想得太神
万能密码有效的前提是后端存在 SQL 注入，并且登录逻辑没有做二次校验。现在稍微规范点的框架默认参数化查询，这个模块大概率一无所获。但老旧 PHP 项目、asp 项目、内部管理系统里，这种问题仍然存在。WebCrack 把万能密码做成内置模块，价值在于批量检测时不需要额外准备 payload 文件，省去手工拼接的时间。
实际使用中，万能密码成功率远低于弱口令成功率。弱口令靠的是用户安全意识差，万能密码靠的是代码写得糙。两个方向都测，覆盖的是不同的风险面。
4. 批量爆破的实操细节：字典、线程与结果判定
4.1 用户名字典和密码字典怎么准备
弱口令爆破的成败有七成取决于字典质量。好的字典不是网上随便下载的千万级大字典，而是符合目标业务场景的小字典。比如目标后台是 OA 系统，用户名优先试 admin、administrator、sysadmin，密码优先试 Admin@123、a123456、1qaz@WSX。
# 用户名列表 admin administrator sysadmin root test demo manager # 密码列表 admin 123456 admin123 Admin@123 password 12345678 admin@123逻辑说明：上面两组内容是我常用的起步字典。用户名 7 个、密码 7 个，组合 49 次请求，单线程半分钟跑完，先快速摸底。如果 49 次请求全失败，再上大字典，而不是一开始就拿 2000 万条密码的大字典做全量测试，那等于让工具在做无用功。
参数说明：字典文件编码建议 UTF-8 无 BOM，每行一个条目，末尾换行。Windows 记事本保存的 UTF-8 BOM 会让第一个用户名变成\ufeffadmin，导致登录请求带了不可见字符，结果全部失败。这个问题我遇到不下五次，排查时肉眼根本看不出来。
4.2 并发数、超时和延时：三个参数的调优逻辑
批量爆破不是把线程调到最大就能跑得更快。目标服务器有连接数限制、有带宽限制、有 WAF 限速，线程过高会换来大量超时和连接重置，实际有效请求反而更少。
目标类型 推荐线程数 推荐延时 推荐超时 内网后台 8-10 0.2-0.5s 5-8s 公网后台(无WAF) 5-8 0.5-1s 8-10s 公网后台(有WAF) 2-3 1-2s 10s+逻辑说明：上面这张参数表是我常用的配置组合。内网目标吞吐量高，可以放开一点；公网目标过了 WAF，快速连续请求会触发封禁，必须主动降速。判别目标有没有 WAF 很简单：连续发 20 个请求后看是否出现验证码或 403。
参数说明：--delay在工具里通常只控制单个线程内请求间隔，多线程下全局请求频率会乘以线程数。比如-t 3 --delay 1，每秒大约 3 个请求，而不是 1 个。
4.3 输出结果与误报筛除
爆破结束后，工具会把判定成功的条目写进结果文件，但“成功”不一定真的成功。响应体里包含“welcome”但只是页面公共部分的情况很常见，这时需要二次验证。
# 用结果文件里的账号密码，手工登录一次，确认是否真的能进后台 cat result.txt # 期望输出格式 http://192.168.1.10/admin/login.php [admin/Admin@123] http://192.168.1.11/wp-login.php [admin/password]逻辑说明：结果文件每一行是目标 URL 加账号密码，这个文件是后续复核的清单。拿到结果后挑两个条目手工登录验证，如果手工登录失败，说明工具判定特征配置有误，需要回去调关键字参数。
参数说明：部分实现支持--verify二次确认模式，对成功条目再发一次请求并验证状态码。有就开，没有就手工抽验，不要直接信任全部结果。
4.4 验证码和动态 token 处理
带验证码的后台登录页面是 WebCrack 这类工具的克星。常见做法是检测到验证码图片后跳过该目标，而不是试图去识别验证码。跳过是理性的：为了一个弱口令检测去训练一套 OCR 模型，投入产出比太低。
处理思路分三种：第一种是验证码只在连续失败后出现，此时降低线程、加长延时，可以避开触发机制；第二种是每个登录页都有验证码，工具基本无能为力，只能标记跳过；第三种是验证码但后端校验不严，比如验证码不刷新、验证码不绑定会话，这种情况下空验证码或固定验证码也可能通过，可以手工改请求把验证码字段写成固定值。
5. 避坑指南：批量爆破翻车现场与排查清单
5.1 目标数量太多导致线程假死：现象、原因、解决
现象：批量任务跑到三分之一时，输出日志停住不动，进程还在但没有任何新请求发出。
原因：--timeout设置过短，加上目标服务器慢速响应，线程池里的线程全部卡在等待响应状态，新任务排不上队。
解决：把超时从 8 秒放宽到 15 秒，线程数降低一半。如果日志里大量出现ReadTimeout和ConnectionResetError，说明不是工具问题，是目标服务器已经扛不住，直接停掉换更小的字典。
5.2 全部目标返回“登录成功”：误报的典型场景
现象：跑完一批目标，结果文件里几十条记录全是“成功”，手工验证却一条都进不去。
原因：登录失败页面和成功页面的响应体里含有相同的关键字，工具默认用“用户名或密码错误”做失败特征，但目标把错误提示写在了 JavaScript 变量里，HTML 响应里没有这个字符串。
解决：先手工抓一个失败响应，看实际失败特征是什么。比如失败时状态码是 200 且页面标题为“登录”，成功时状态码是 302，那就把判定条件改成“状态码为 302”而不是依赖页面内容。如果工具支持自定义成功关键字，把成功页里特有的字符串填进去，效果最稳。
5.3 提示“No form found”：登录页不是标准表单
现象：目标 URL 确认无误，但工具报错找不到登录表单。
原因：前端框架渲染的页面，HTML 里没有传统<form>标签，input 全是 JavaScript 动态生成的。工具自动解析表单失败。
解决：手工抓包看登录请求，把 POST 参数名和提交地址写进工具的配置模板。比如 Vue 项目常见提交格式是{"username":"xxx","password":"xxx"}的 JSON 格式，此时工具默认的application/x-www-form-urlencoded请求头不可用，要改成application/json。
5.4 万能密码模块全军覆没：不一定是工具问题
现象：内置万能密码跑完，所有目标都是失败，一条成功都没有。
原因：目标用了参数化查询，或者登录接口是 API 网关转发，后端逻辑里根本不存在 SQL 拼接。这不是工具坏了，是这类脆弱点在当前目标上不存在。
解决：先用弱口令字典跑一遍，确认弱口令有结果，万能密码没结果的组合是合理的。如果弱口令也没有结果，先回头检查字典和目标文件，大概率是第一步就没走对。
5.5 合规边界：明确授权再跑，别碰不该碰的系统
这个必须要说清楚：弱口令爆破工具天然带有攻击属性，使用边界是所测目标已获得书面授权。未经授权对公网目标发起爆破属于违法行为，这一点没有任何争议。内网测试也要先确认目标系统是测试环境还是生产环境，生产环境爆破导致账号锁定、后台卡顿，账都会算在测试者头上。
做安全检测的正确姿势是先拿授权单，再限定目标范围，最后固定时间段执行。工具是放大器，解决了批量效率问题，但不会替你判断目标是否合法。
6. 让批量爆破结果更可信：二次验证与报告整理
6.1 结果二次验证脚本：过滤误报的实用办法
爆破结束只是开始，真正的产出是“可信的结果清单”。我习惯把 WebCrack 的输出结果再过一道验证脚本：
import requests with open("result.txt", "r") as f: lines = f.readlines() verified = [] for line in lines: url, cred = line.strip().split(" [") username, password = cred.strip("]").split("/") # 对成功条目逐一验证 data = {"username": username, "password": password} resp = requests.post(url, data=data, allow_redirects=False, timeout=10) if resp.status_code == 302 or "/index" in resp.headers.get("Location", ""): verified.append((url, username, password)) print(f"[OK] {url} {username}/{password}") else: print(f"[FAIL] {url} 判定失败，疑似误报")逻辑说明：脚本重新对所有标记成功的条目发送真实登录请求，用状态码 302 或跳转地址里的关键字做二次确认。这一步能过滤掉大部分工具误报。说明：脚本里的status_code == 302是我常测 PHP 项目时的行为，不同后端可能返回 200 加首页内容，按实际调整。
参数说明：allow_redirects=False在这里格外重要，跟随跳转后状态码会变成 200，丢失判断依据。如果你要验证的目标登录成功不跳转，就把条件改成“响应体里面包含指定特征”。
6.2 按网段批量测试的常用姿势
目标不是单台服务器而是一个网段时，需要先做资产梳理再喂给 WebCrack。常见做法是用 nmap 扫描网段内开放的 80/443/8080 端口，然后把存活的 web 服务 URL 整理成 target 文件。
# 扫描网段内 web 服务 nmap -p 80,443,8080,8443 -oG - 192.168.1.0/24 | grep "open" | awk '{print $2}' > live_hosts.txt # 给存活主机拼上后台路径 while read ip; do echo "http://${ip}/admin/login.php" echo "http://${ip}:8080/login" done < live_hosts.txt > targets.txt逻辑说明：第一段扫描网段里开放 web 端口的存活主机，第二段给每个 IP 拼上常见后台路径。目标文件生成后交给 WebCrack 批量跑，比手工维护列表省事得多。
参数说明：后台路径建议用登录入口聚合的思路，包括/admin/login.php、/wp-login.php、/user/login等常见位置。不同框架的默认后台路径不一样，这一步没有统一的答案，只能按经验枚举。
6.3 字典迭代与增量测试：把爆破越做越准
跑完一轮以后别急着删字典，每次爆破的结果都是在给字典做反馈。某个目标系统用admin/Admin@123登进去了，说明该公司管理员偏好大小写加数字的组合，后续在同类目标上优先试这种模式。
我的习惯是维护一个“高频账号密码”小字典，放进每次测试都会优先跑的那一组，再配合一个大字典做兜底。先用小字典快速摸底，没收获再上大字典，整个流程在时间上的开销是可控的。
爆破这一类工具用久了会形成一个直觉：同一个后台系统，如果小字典一轮跑下来完全无结果，通常不是密码有多强，而是登录接口做了额外的防护，比如 IP 限速、账号锁定、加密传输。这时候换大字典没有意义，应该回头分析请求构造和防护机制。
如果你准备在自己的测试环境里长期使用 WebCrack，还有一件值得做的事：把每次跑完的结果按日期归档，连同当时使用的字典版本一起保存。时间久了你会积累出一套针对不同框架的测试方案，这才是批量爆破真正值钱的部分。希望这些经验能帮到你。
本文还有配套的精品资源，点击获取
