从登录爆破到JS逆向：零基础Web安全的第一个完整实战路径

有人问我，零基础想学网络安全，该从哪一步开始？我经常给出的答案不太一样：先找一台你自己能控制的登录框，做一次只限在本地靶场里的登录爆破练习。听到“爆破”两个字，很多新人第一反应是找工具、跑字典，但真正做过之后才会发现，爆破登录只是表面，里面真正练的是网络协议、JS逆向和加密算法。这些年我带过不少人入门，凡是能把这个场景吃透的人，后续无论是走渗透测试还是逆向分析，上手速度都比一上来啃汇编的人快得多。这篇文章就顺着这条线，把登录爆破背后的知识结构、实操流程和容易踩的坑一次讲清楚。

先说明一件事：本文所有示例都假设你在自己搭的靶机、CTF平台或者明确获得授权的目标上操作。不要对任何你没有权限的系统做测试，哪怕只是试一个密码，同样可能违法。技术本身是中性的，但使用对象决定了学习行为和犯罪行为的区别，这个边界我全文都会反复强调。

1. 为什么我劝你先找登录框练手，而不是一上来啃汇编

1.1 登录框是 Web 世界与逆向知识的十字路口

很多新人提到逆向，第一反应是汇编、调试器、反汇编窗口、内存断点，然后就被劝退了。我理解这种焦虑，但真正进入安全行业之后你会发现，逆向并不是只有“二进制逆向”这一条路。Web前端JS逆向、安卓应用逆向、固件逆向都叫逆向，它们的共同点是：你拿到的是一个已经运行起来的东西，要通过观察输入输出、阅读中间代码、分析算法逻辑，把这个东西背后的规则还原出来。而登录框，恰好是所有这些能力最适合起步的训练场地。

登录框看起来简单，但一次登录请求背后至少牵扯到HTML表单、HTTP协议、Cookie与Session、数据库存储、前端脚本、加密算法、服务端校验逻辑。你想把账号密码发到服务端，中间任何一个环节设计得稍微复杂一点，都会让你原来的请求“对不上”。对不上，就是逆向的开始。

我第一次带新人练习时，会让他们先把下面这几样东西说清楚：用户名和密码是怎么收集的、浏览器把数据包装成了什么请求、服务端返回来的是什么内容、哪些字段看起来加密了。这些问题听着基础，实际上覆盖了一个Web安全工程师日常工作中最常打交道的协议、前端代码和业务逻辑。能把这一个小登录框讲明白，你再去学更底层的逆向，思路会顺很多。

1.2 爆破失败不是运气问题，而是业务逻辑没读透

很多人对爆破的想象是：准备一个巨大的密码字典，写一个循环，把密码一个一个试过去，剩下交给运气。真这么做，大概率跑一个晚上也跑不出结果。我第一次做类似练习时也一样，字典拿了好几万行，跑得电脑风扇直转，结果一个也没成功。

后来把流量抓下来看才发现，问题不在密码本身。浏览器里填写的密码是 123456，发出去的请求体里对应的字段却是 e10adc3949ba59abbe56e057f20f883e。前端在提交前已经对密码做了一次MD5运算。如果我直接用明文密码去跑，服务器一看格式就判断校验失败，自然会给我返回错误。这时候真正需要逆向的，不是密码字典，而是这一段加密逻辑。

类似的坑还很多：有些系统会在登录请求里加入一个 timestamp 和 sign，服务端先校验签名，不合法就直接丢弃请求；有些系统会把用户名和密码拼在一起做一次加盐哈希；更复杂的还会前端加密后再用HTTPS传输。表面上看登录框是一个入口，实际上它是验证逻辑的前线。你每一次爆破失败，背后几乎都有一个“参数没搞对”或“算法没还原”的问题，而不是运气差。

所以我会说，爆破登录这个场景，学到最后你得到的不只是某一个密码，而是读别人代码逻辑的能力。这种能力放在哪都值钱。

1.3 先立好边界：只有授权环境才谈得上“爆破”

写文章还是得先把丑话说前面。登录爆破这个词在正规安全测试里，属于“验证机制测试”的一部分。正规流程是什么？你先拿到项目授权，授权范围写得明明白白，允许测试哪个域名、哪个应用、多长时间、能不能做爆破，这些都得提前确认。很多众测项目对登录爆破有严格限制，甚至默认不允许，因为大量尝试会干扰正常用户、触发风控，也可能打爆账号导致线上故障。

对于零基础学习者，我的建议非常简单：本地用 Docker 装一个专门的靶场，或者自己写一个带加密逻辑的测试页面。你甚至不需要有一台多好的电脑，只要能跑浏览器和几个基础工具就够了。靶场环境里你可以随便折腾，怎么爆破都不会影响别人，这才是最安全、最合适的学习路线。

还有一点：不要在公网上的真实网站去“验证自己学到的技术”。哪怕只是拿弱口令字典测一个陌生网站，在多数国家和地区都是违法行为，不是“手滑”或者“只试一次”就能解释的。技术学习要有主动的红线意识，这条线守不住，本事越大越危险。

2. 把登录请求拆开看：一次交互里藏着多少待学点

2.1 从“点击登录”到“返回结果”这段时间发生了什么

想要理解爆破，先得知道正常登录是怎么走完的。我习惯把一次登录交互拆成下面几步。

第一，用户填写账号密码并点击登录按钮，浏览器会从页面HTML中读取表单结构，把用户输入的值放到请求参数里。此时如果页面上有JS脚本，脚本可能会在提交前对参数做额外加工，比如把密码变成哈希、加入时间戳、计算签名。

第二，浏览器把这些参数拼进一个HTTP请求中。以最常见的表单登录为例，它通常是一个POST请求，请求头里带有浏览器标识、Cookie、Content-Type等信息，请求体里是一些形如 username=admin&password=xxx 的键值对。这一步是逆向最关键的一环，因为你看到的请求体未必是你在表单里填的内容。

第三，服务端收到请求后，不会立刻去查数据库。它要先做一些通用校验：看参数格式对不对、验证码对不对、时间戳是否过期、签名是否合法、账号有没有被锁定、IP有没有被限制。这些校验有先后顺序，一般会把最耗资源的数据库查询放在后面，把便宜的签名校验放在前面。

第四，服务端去数据库里查这个用户是否存在，再把数据库里的密码哈希和客户端提交上来的值做比对。注意这里存的是密码摘要，不是明文密码。如果匹配，服务端会生成一个会话标识，通过响应头或Cookie返回给浏览器，然后浏览器带着这个凭证进入登录后的页面。

这几个步骤听起来简单，但每一层都可以加防护。而我们做安全测试，就是要在每一层观察“我的输入去了哪里，服务端怎么判断的，哪一步会改变结果的走向”。爆破的本质不是狂发请求，而是针对某个校验点构造可控的输入。

2.2 一张验证点地图：你的每次失败都可能卡在这里

为了让自己不迷路，我建议新手把登录中常见的校验点画成一张思维地图。下面这个表格差不多覆盖了主流的拦截面，可以对照它检查自己的请求到底卡在哪一步。

举个例子，很多人用工具跑登录爆破时，设置的是一个通用模板，比如 username=admin&password=§payload§。但实际页面上发的可能是 uname=admin&pwd=md5(§payload§)&ts=169xxxx。你拿通用模板去跑，服务器当然不会把你当成正常的“密码错误”，它可能在参数校验阶段就把你丢弃了。看到返回结果一模一样，很多人以为是IP被限制了，其实只是你的请求压根没走到密码比对那一步。

每一次失败，不要先急着怀疑目标系统搞了什么高级防护，先回头把请求体逐字段和浏览器真实发出的请求做对比。这个习惯比任何工具都重要。

2.3 反爆破机制并不神秘，它们只是逼着你补课

现在很多登录系统都有反爆破设计，常见的包括：验证码、滑块、短信二次验证、连续错误锁定、IP限速、动态签名。

这些机制在安全工程师眼里不是“烦人的阻拦”，而是“由浅入深的学习路线”。前端加密要求你会读JS，动态签名要求你会还原算法并把它写进请求里，限速要求你控制频率而不是像没头苍蝇一样狂发。想绕过滑块或验证码，在真实系统里涉及计算机视觉、行为轨迹模拟、打码平台等额外问题，这已经远超“登录爆破”的范畴了。零基础阶段不需要研究这些，你只要知道它们存在的目的是什么，然后老老实实找没有这些机制、或者安全级别调低的靶场来练习即可。

我自己见过最可惜的情况是，有人花大量精力研究绕过图形验证码，却连最基本的POST请求都讲不清楚。这相当于还没学会走路就想去跑马拉松。正确的顺序应该是：先理解一个最朴素的登录验证流程，再逐个把验证码、签名、时间戳这些因素加回去，每加一个，你对系统的理解就深一层。等你把本地靶场里的完整链路吃明白了，再回头看各种真实系统的登录逻辑，你会觉得它们好像也没有那么玄。

3. 搭好一个属于你自己的实验室：本地靶场与 Burp 拦截

3.1 为什么用 Docker 学习环境而不是拿线上网站练手

登录爆破实验的第一步，不是下载“爆破神器”，而是搭一个隔离、可控、可随时重置的实验环境。我强烈推荐用 Docker 来做这件事，而不是在本地装一个完整的Web服务或者拿线上网站实验。

Docker 的好处很直接：靶场镜像是一个独立的容器，里面有自己的一套操作系统和运行环境，即使被你的操作搞得乱七八糟，一条命令就能删掉重建。容器默认只暴露你指定的端口，不会像某些集成环境那样把 MySQL、Apache 整个散落在你电脑里。而且靶场软件本身是故意做成有漏洞的，装在你日常用的系统里始终有风险，放在容器里更让人放心。

如果你还没安装 Docker，去官网下载对应系统的安装包即可。Windows 注意开启虚拟化支持；macOS 和 Linux 相对顺利，网上官方文档都有详细说明。我建议新手不要去折腾“手动安装 PHP+MySQL+靶场”的过程，那是另一种零基础劝退路线。把精力留给后面的逆向分析，环境能跑起来就行。

3.2 快速跑起一个 DVWA 靶场

DVWA 是 Web 安全圈很常用的演练靶场，全称是 Damn Vulnerable Web Application，中文可以理解为“故意留了一堆漏洞的Web应用”。它自带登录页面、多种漏洞案例和不同的安全等级，特别适合做登录类实验。

在终端里执行下面这几条命令，你的靶场就起来了：

bash复制docker run -d -p 8080:80 --name dvwa vulnerables/web-dvwa

跑起来之后，浏览器访问 http://127.0.0.1:8080/，默认登录账号是 admin，密码是 password。第一次进入会看到一个初始化页面，提示你点击按钮创建或重置数据库，按流程走一遍就好。DVWA 默认的安全级别是 low，这个级别下没有太多乱七八糟的防护，方便你先观察最原始的登录验证逻辑。

如果你想多一点挑战，可以自己再部署一个简单的登录测试页，比如前端调用一段JS，把用户名、时间戳和固定盐拼在一起生成一个 sign 字段再提交。这个“自制靶场”的过程也是很好的练习，因为你在写这段加密逻辑时，会知道服务端通常用什么思路来校验，下一次看到类似系统时就能很快猜出方向。

3.3 Burp 社区版在你学习里扮演的角色

Burp Suite 是安全测试里绕不开的抓包工具。它在登录爆破学习中主要干三件事：拦截浏览器发出的请求、允许你手动修改后发送、在多次请求之间观察差异。社区版完全够用，不需要一开始就去折腾专业版和那些复杂插件。

你需要在浏览器里把流量指向 Burp 的监听端口，具体就是设置一个本地的HTTP监听端口，并确保安装 Burp 的证书。这一步在官方文档和大量入门视频里都有，照着做就行。注意这里的学习重点是“拦截、查看、重放”三个动作，而不是把Burp当成黑盒按钮。

当你打开 Burp 的拦截功能，再去浏览器点击一次登录，你会发现本来应该发往服务器的请求停在了工具里。你可以看到完整的请求行、请求头、请求体。这一步极其重要，因为它是你第一次离开浏览器界面，直接看到登录背后的数据长什么样。我经常让学员在这里做一个练习：把请求体里某个参数值改掉再放行，看服务器返回有什么变化。通过改一个值来观察响应变化，是后续逆向分析里最基本的实验方法。

3.4 学习初始约定：控制频率、记录差异

登录爆破实验容易让人兴奋，工具一点就开始批量发送，但这样反而不利于学习。我在做实验时给自己定了三条规矩，后来也成了我带人的基本要求。

第一，实验用的字典不要贪大。从几条手工整理的弱口令开始就够用了，比如 123456、admin、password 这种最典型的常见值。跑通一次完整流程，比机械地跑一百万行更有价值。第二，每条请求之间要有意识地控制时间间隔。学习阶段不是为了“打爆”一个账号，而是在观察不同输入对应的不同响应。你在工具里手动重放时自然会慢下来，这个慢反而能帮你注意到每个返回结果的变化。第三，每次实验只改变一个条件。测试密码就只改密码，测试用户名就只改用户名，参数名和Cookie保持原样。这样定位问题时，你能确定是哪一步变化导致了结果变化。

这些约定看似保守，但它训练的是以后做正式授权渗透测试时的职业习惯。真实系统上无节制地跑爆破，可能把线上账号锁死、把日志塞满、触发风控甚至造成事故。能在实验室里养成克制和节律感，比会按几个工具按钮重要得多。

4. 你的第一次逆向跃迁：发现实际提交的不是明文

4.1 按下 F12 后，看见了请求里多出的字段

现在假设你已经在本地搭好了一个带前端加密的登录页。你在页面上输入用户名 admin、密码 123456，点击登录。经验不足的人会直接去Burp里尝试爆破，但我希望你做的第一件事是：打开浏览器开发者工具，切到Network面板，勾选Preserve log，再点一次登录，找到名为 login.php 或类似接口的请求。

在请求负载里，你会看到用户名参数是 admin，看起来很正常。但密码参数可能已经变成一长串字符，比如 25f9e794323b453885f5181f1b624d0b。这时候你心里应该咯噔一下：这不是我输入的明文密码。这串字符的长度通常是32位，内容由数字和字母a-f组成，看到这个特征，第一反应应该是有哈希运算介入了。

这种“眼见不一定为实”的体验，就是逆向思维的起点：你不能相信页面里写了什么，要去相信实际传输了什么，再倒推这个结果是怎么算出来的。

可能有人会问，为什么网站要在前端先把密码处理一遍，不能直接发明文吗。设计者的考虑是尽量不让明文密码出现在传输链路中。虽然HTTPS本身已经能加密传输，但在很多内部系统或早期业务里，前端哈希仍然是一种常见的防护习惯。只不过如果只是简单MD5，没有加入随机盐，它的强度并不高，更多像是为了不让运维和日志直接看到明文而做的混淆。

如果你发出去的密码字段是一串MD5值，那你爆破的对象就变了。传统爆破是“拿字典里的每一行直接当密码提交”，现在则需要把字典里的每一行先做同样的MD5运算，再把运算后的值放到请求体里。这个变换过程，本质上就是一次简单的逆向还原。

4.2 JS加密让“爆破对象”改变，你需要先找到算法

看到加密值之后，下一步是找到这个值到底是在哪里生成的。绝大多数情况下，它是在浏览器页面里的JavaScript中完成的。

按下F12进入开发者工具，切到Sources或调试器面板，然后全局搜索一些关键词：password、pwd、encrypt、md5、sign、crypto。这些词通常是算法函数命名的习惯。搜索之后，你可能会看到类似下面这样一段代码：

javascript复制function encryptPassword(plain) {
    return CryptoJS.MD5(plain).toString();
}

页面在表单提交时调用了 encryptPassword 函数，把用户输入的密码先转成了MD5值，再放进请求体。这时你可能会想，要不要去找什么“反混淆工具”来解这段代码？其实不用的，这段逻辑已经足够清楚了：它对输入的明文做了一次MD5计算。

有些页面为了增加一点复杂度，会把脚本压缩成一行，变量名也改成 a、b、c。但只要你搜索到 md5、sha256、encrypt 这类特征字符串，再跟一下函数的调用关系，通常还是能还原出它的流程。真正的Web安全逆向，很多时候不是你想象的“看汇编”，而是用浏览器开发者工具一点点找函数、打断点、看调用栈、观察入参和返回值。

4.3 把前端的加密逻辑还原成自己的代码

找到算法之后，最有效的一件事就是把它搬到本地，用Python或其他语言重新实现一遍，然后自己算一次，看看能不能得到一样的结果。

上面这个例子里，对应Python代码非常简单：

python复制import hashlib

def transform_password(plain: str) -> str:
    # 还原页面中的 CryptoJS.MD5(plain).toString()
    return hashlib.md5(plain.encode("utf-8")).hexdigest()

print(transform_password("123456"))
# 输出: e10adc3949ba59abbe56e057f20f883e

把输出结果和浏览器开发者工具里看到的密文比对，如果一致，说明你还原的算法是正确的。这个时候，你可以说已经完成了一个最小闭环的“逆向”过程：观察输入输出、定位处理函数、复现算法逻辑、验证一致性。也许你觉得这个例子太简单，但实际上很多真实系统的第一层加密，就是这个模式。复杂系统只是在外面套了更多壳，核心思路一样。

在带人入门时，我很喜欢让他们亲手做一次这种还原。因为很多新人会误以为逆向必须要会反汇编、必须能看懂大量底层指令，但现实是，Web前端逆向的第一步往往是从一段可读的JS开始，你需要的不是背语法，而是建立“看到密文就去找算法”的条件反射。

4.4 哈希和加密：新手最容易被绕晕的两个词

在看这个例子的过程中，你大概率会遇到两个词：哈希和加密。很多人把它们混在一起，但它们做的事情完全不同。

哈希是一种单向运算，常见的有MD5、SHA-1、SHA-256。你可以把任意长度的输入变成固定长度的输出，但是从输出反推输入极其困难，除非输入内容本身太简单，可以被穷举猜测出来。加密则是双向的，比如AES、RSA，加密之后可以通过密钥解密还原成原文。

在登录场景里，前端对密码做哈希，是一种比较朴素的做法。真正安全的系统，密码库中存储的也应该是经过加盐哈希的值，比如bcrypt或argon2。专业的密码存储不会存明文，也不会直接存无盐MD5，因为无盐哈希很容易被彩虹表反查。但很多旧系统或内部系统没有做到这一步，这也是安全测试中经常发现问题的地方。

新手第一步不需要深究密码学理论，但要能分清：服务器返回的密码字段如果是固定长度的十六进制串，先想哈希；如果密钥可以解密还原，再想AES/RSA这类加密。搞清楚这个方向，能少走很多弯路。

4.5 知道“逆向一个参数”的具体动作了吗

写到这，我总结一份检查清单，你可以直接拿来用：

1. 打开浏览器开发者工具Network面板，找到真实的登录请求。
2. 逐字段比较表单内容和实际请求体，找出所有凭空出现、格式异常的参数。
3. 在JS源码中搜索可疑参数名及 encrypt、md5、sign 等关键字。
4. 用断点调试或多加几个 console.log，观察算法函数执行前后的关键值。
5. 用Python等脚本复算一次，把结果和浏览器请求中的值做比对。

完成过一次，你就不会再对“爆破登录”这四个字产生错误的期待了。你会发现最重要的不是跑多少遍字典，而是你能否把一个请求完整、真实地再造出来。做不到这一点，再快的网络、再大的字典都没用。

5. 带签名参数的登录题是怎么被抽丝剥茧的

5.1 一种典型签名登录策略：timestamp + sign

现在我们把难度上调一级，假设你本地实验系统采用了更常见的签名方案。登录请求体里有四个参数：username、password、timestamp、sign。

其中 password 是用公钥或哈希处理过的密码，timestamp 是当前时间戳，而 sign 长得很像一串随机的十六进制字符。这个 sign 不是前端生成的随机串，而是服务端用来校验请求合法性的签名：它一般是由用户名、密码、时间戳甚至某个固定盐组合后，经过哈希运算得到的结果。服务端收到请求后，先检查 timestamp 和服务器当前时间差是否过大，再用同一套算法重新计算 sign，如果两边不一致，就拒绝请求。

正因为 sign 参与了完整校验，你直接去修改 password 再放行，服务端会返回“签名校验失败”，而不是“密码错误”。要解决这个问题，你必须先知道 sign 是怎么算出来的，然后把整个请求体当作一个整体来生成。到这里，爆破登录已经从“尝试密码”悄悄变成了“完成一次签名的逆向还原”。

这是我个人觉得整体学习曲线中最关键的一道坎。跨过去，你对动态请求的理解会上一个台阶；跨不过去，你会一直卡在“为什么我改了参数就报错”的困惑里。

5.2 四步定位前端签名函数

定位 sign 的生成函数，我通常按四个步骤来。

第一步：在Network面板中找到登录请求，记录一组完整的 username、password、timestamp 和 sign 值。第二步：进入Sources面板，在搜索框里输入 sign，JS源码中所有出现这个词的地方都会列出来。第三步：找到类似“生成签名”“sign =”“makeSign”这类赋值和函数调用，点击函数名可以跳转到定义处。第四步：在函数定义处打断点，重新点击登录，观察传入的参数和返回值。

你可能会看到这样一段逻辑：

javascript复制function generateSign(username, password, timestamp) {
    var salt = "SALT_FOR_DEMO";
    var text = username + password + timestamp + salt;
    return md5(text);
}

看到这种代码，先不要急着高兴，因为它太“规整”了，真实工程里源码很可能是压缩混淆过的。但没关系，你只需要关注它做了什么：把 username、password、timestamp 和一个固定字符串拼接在一起，再计算 md5。变量名可以乱，逻辑核心就这么多。

如果函数是压缩的，比如写成 function x(a,b,c){var d="SALT_FOR_DEMO";return md5(a+b+c+d)}，阅读方式也是一样的，只是需要你对关键字 md5、拼接符号和字符串常量更敏感。后续接触Webpack打包的JS，还能看到模块化的调用方式，但那是另一个进阶方向，本文先不展开。

5.3 控制变量法确定签名参与项

假设你看到的JS逻辑比较隐晦，不能确定 sign 到底算上了哪些参数。这时不要靠猜，用控制变量法做几次实验。

第一次实验：保持 username 和 password 不变，只修改 timestamp 后重新发起请求，观察页面生成的 sign 是否改变。如果变了，说明 timestamp 参与签名。第二次实验：保持其他参数不变，只修改 username 或 password，观察 sign 的变化。如果变了，说明这些参数也在签名里。第三次实验：如果把盐从源码里删掉，重新算出来的 sign 和服务端校验不一致，说明服务端预期里带了一个额外常量。

通过这几组对比，你可以确定参与签名的最小集合。这个过程和科学实验很像：每次只改变一个变量，记录结果，推导规则。千万不要一次性改多个参数，否则你无法判断是哪个变量导致了 sign 变化。

很多安全性更高的系统还会加入随机数或者一次性Token，这样即使是同一时间、同一用户名、同一密码，每次生成的 sign 也不一样。遇到这种情况，你需要在页面上下文中找到这个随机值是怎么产生和传递的，这不是一两句话能讲完的。但作为入门，你先掌握固定盐+时间戳的模型就够了。

5.4 用单次重放来验证算法是否正确

算法还原完成之后，别急着写循环跑字典。第一步是做一次“单点验证”：构造一个和浏览器原始请求一致的完整请求，发到本地靶场，看服务器返回什么。

如果请求体里的 username、password、timestamp、sign 和浏览器里看到的一模一样，服务器应该返回正常的业务响应，比如“密码错误”或“用户名不存在”。如果返回的是“签名校验失败”“非法请求”之类的提示，说明某个参数、签名或Cookie没有还原到位。

此时要回头检查三类信息：一是时间戳是否使用了和服务端一致的时区；二是签名函数里的字符串拼接顺序是否和JS完全一样，顺序调换会导致完全不同的哈希值；三是请求头里是否还需要携带特定的自定义Header，有些系统的签名校验依赖请求头但不会在文档里写明，只能靠流量对比发现。

本地实验场景下，我建议你直接用Python的requests库写一个最小脚本，用来验证算法是否正确：

python复制import hashlib
import requests
from time import time

url = "http://127.0.0.1:8080/login"
username = "admin"
password = "123456"
timestamp = str(int(time()))

# 假设从JS中还原出来的规则是:
# sign = md5(username + password + timestamp + "SALT_FOR_DEMO")
salt = "SALT_FOR_DEMO"
raw = username + password + timestamp + salt
sign = hashlib.md5(raw.encode("utf-8")).hexdigest()

payload = {
    "username": username,
    "password": password,
    "timestamp": timestamp,
    "sign": sign,
}

resp = requests.post(url, data=payload, timeout=5)
print(resp.status_code)
print(resp.text[:500])

注意，上面只是一个“单请求重放”骨架，没有循环、没有并发、没有字典爆破。我建议所有新手都从这种不带攻击性的脚本开始。当你把脚本跑通，服务器返回的错误信息终于从“签名错误”变成“密码错误”，你就真正掌握了签名的构造能力。接下来再往脚本里加循环去遍历候选密码，只是水到渠成的小事，但请务必确保目标是你自己的靶场。

这一节是整个登录爆破场景的精华。你在其中经历的“定位函数、还原规则、验证算法”过程，已经具备了对抗动态签名的基础能力。以后看到任何请求里带 sign、token、cipher 之类的字段，你不会再慌，因为你已经有了固定的思考路径。

6. 工具观的转变：Burp、字典与自己写脚本的关系

6.1 为什么我不建议第一周就背“神器清单”

每个安全论坛里都有人问：“爆破登录用什么工具最强？”下面回帖经常出现各种工具名和参数配置。我可以负责任地说，工具清单不是最重要的，尤其是第一周。

Burp Suite、Yakit、各种命令行工具，本质上都只是帮助你查看和发送HTTP请求的“容器”。你真正要往里面放的，是已经分析正确的参数和已经还原的算法。工具不会帮你读懂业务逻辑，也不会帮你判断一个请求为什么被拒绝。过早地沉迷工具会让你产生一种假掌握的感觉：按钮都会点，但换个场景就完全不知道怎么下手。

社区版Burp对入门者是很好的选择。它免费、跨平台、社区资料多，拦截功能和Repeater功能能让新手直观地看到请求的每一次变化。你可以在Burp里修改用户的密码参数，发送到服务器，观察返回结果；也可以打开历史记录，仔细对比几次请求中某个字段的差异。

6.2 爆破字典的本质是输入集管理

再来谈字典。很多人一听到爆破，就去找那种几个G的“全网密码本”。但我的建议是：学习阶段千万不要用别人的超大字典。原因有几个：第一，文件太大，工具处理慢，你根本观察不到每次请求的结果；第二，你完全不知道里面有哪些行，练习时很难建立输入和响应之间的对应感；第三，容易让自己形成“爆破就是靠海量尝试”的错误依赖。

爆破字典的本质，是你要提供给测试系统的“候选输入集合”。这个集合怎么来，取决于你对目标业务的理解。在本地靶场里，你可以手动整理几条典型的弱口令，比如把 admin、123456、password、Admin@123 放进去，体会接口对各种密码的响应差异。

到了真实授权项目，字典的构建会更讲究。你会结合目标系统的命名规则、初始密码策略、已知信息泄露等来生成候选集。这套分析能力比任何现成字典都值钱。但这一点也就点到为止，具体针对某个系统去生成字典，需要先有明确的授权和合法的目的，否则就越界了。

6.3 独立写一个重放请求的小框架

当你用Burp完成了手工验证，下一步就是把这个过程脚本化。写脚本不是不信任Burp，而是因为真实测试中你需要灵活地控制时间戳、签名、随机因子，有时还要实现复杂的条件判断，纯靠鼠标很难完成。

最小脚本的结构大概是这样的：先读入一个候选密码，根据目标算法对密码做变换，如果存在签名机制就为每位密码重新计算对应的签名和时间戳，然后发送请求，最后根据服务器响应的关键字判断是否成功。

我可以给你一个框架，但具体业务字段要靠你自己去补：

python复制import hashlib
import requests
from time import time

def make_sign(username, plain_password, timestamp):
    # 假设页面前端会先把密码做一次md5，然后把结果拼接进去签名
    pwd_md5 = hashlib.md5(plain_password.encode()).hexdigest()
    text = username + pwd_md5 + timestamp + "SALT_FOR_DEMO"
    return hashlib.md5(text.encode()).hexdigest(), pwd_md5

def try_login(username, plain_password):
    timestamp = str(int(time()))
    sign, pwd_md5 = make_sign(username, plain_password, timestamp)
    payload = {
        "username": username,
        "password": pwd_md5,
        "timestamp": timestamp,
        "sign": sign,
    }
    resp = requests.post("http://127.0.0.1:8080/login", data=payload, timeout=5)
    return resp.text

上面这段代码只演示了一个请求的构造，不会批量跑字典。循环遍历候选密码并控制频率的部分，我建议你先自己动手补一遍，因为只有自己写过“发一条、停一下、看结果”的流程，你才会真正理解限速和超时控制为什么重要。写脚本时，最好加一个可配置的延迟时间，并在连续多次失败后自动暂停，避免对目标造成不必要压力。

6.4 在真实安全项目里怎么看待爆破

等到你已经能独立完成这套流程，可以想一想怎么把它放到真实工作或漏洞挖掘中。正规渗透测试中，登录爆破是验证机制测试的一部分，但执行前要再三确认授权范围。现在不少众测平台的规则里，暴力破解攻击属于影响面较大的高危险操作，有些项目完全不允许，有些只允许在指定测试环境或测试账号上进行。

SRC漏洞平台也是如此。很多新手拿到一个目标就想去后台登录框“试一试”，实际上不仅违反平台规则，还很容易触发风控导致对方正常业务受损。我见过不少初学者因为这种操作被平台封号，连申诉机会都没有。所以我的经验是：登录爆破的能力要练，但什么时候能用、能用到什么程度，一定是跟着授权规则走。规则不允许，再熟练也要停手。

7. 零基础到入门的三个月节奏：别被“精通”两个字吓住

7.1 三个月的阶段性任务表

标题里的“从入门到精通”是博眼球的说法，我把它改成更靠谱的“三个月能入门”。如果每天能拿出1到2小时，三个月足够你跑通上面所有环节。我在带新人时常用下面这个节奏：

这张表里没有安排背大量面试题或刷证书，原因很简单：零基础阶段最重要的是亲手“做出来”一个又一个结果，而不是背诵概念。只有当你亲手搭过靶场、抓过包、还原过签名，再去看各种课程和面试题时，那些术语才会自动安放到你已经实践过的框架里，不会觉得抽象。

7.2 每个阶段如何判断自己过关

很多人自学时不知道该不该进入下一阶段。我的判断标准很简单，每个阶段结束前，问自己几个问题。

第一阶段，你能否不借助别人，直接从Network面板里说出某个登录请求的URL、方法、请求头和请求体各是什么。如果只能说个大概，先别往下走，否则后面你会越来越晕。第二阶段，你能否不打开教程，独立完成Burp的拦截、修改、放行和查看响应。第三阶段，你能否解释服务器返回的“用户名不存在”和“密码错误”在实际测试中有什么区别。第四阶段，你能否在没有提示的情况下，在开发者工具的搜索框里找到加密函数，并说出它处理的是哪个参数。第五阶段，你能否只根据浏览器的原始请求，写出一段能复现相同请求的代码。

这些标准不求高，但要求你真的能独立完成。如果哪个环节卡了超过三天，大概率是前面某一章的基础没打牢，回头重新看对应的部分，比硬着头皮往下走更有效。

7.3 后续可以继续延伸的方向

当你完成了上面的三个月节奏，后面的路会很宽。如果你想继续做Web安全，可以深入Web漏洞挖掘的更多方向，比如OWASP Top 10里的各种漏洞类型、权限校验、业务逻辑漏洞。那时候你会发现在登录场景里练出来的请求构造能力，几乎每个漏洞类型都用得上。

如果你想更偏向逆向，可以顺着JS逆向往下走，学习Webpack模块化、AST语法树、JS混淆还原、反调试等更高级的技术。Wbe前端加密只是整个逆向体系的入口，进入之后你会接触到更多有趣的工程化问题。

如果你对移动端感兴趣，安卓逆向是另一个合理方向。登录爆破在App里同样存在，只是多了一层“先抓取App流量、再反编译定位算法”的步骤。到那时你可能还需要接触APK解包、smali代码阅读和脱壳等技能。这些方向不是三条互不相干的路，它们共用许多底层思路：找参数、找算法、找密钥、还原请求。而你从登录爆破里学会的那套“观察差异、定位代码、复现逻辑”的方法，会一直在你手边。

这里再说点个人体会吧。我见过太多人一开始就囤了十几个G的教程、几百个工具，结果两个月过去仍然停在一个“什么都知道一点，但什么都不会做”的状态