1. 先从执行环境说起为什么JS是前端安全的第一道门前一阵子我在一个Web安全系列课里翻到第29天的内容主题是JS应用与前端逆向。说句实话做渗透测试的人如果只会用Burp抓包改包早晚会遇到瓶颈——现在稍微有点规模的应用前端逻辑早就不是十年前那种“按下按钮直接提交”的结构了。参数会加密、字段会动态生成、行为会经过JS动态渲染整个页面背后其实是一套运行在浏览器里的微型程序。你今天看到一个登录框它背后可能有七八个JS文件在做校验、拼参数、算签名、渲染结果这些逻辑全在前端也就意味着全都能被调试和观察。这节课的价值就是教你把浏览器当成一个“会亮出内部状态的观察窗”。学完之后你会对自己说原来以前只是在看页面表面现在能看到页面背后在跑什么逻辑了。这节内容适合谁如果你是刚接触前端安全的初学者这堂课算是一条捷径如果你是做爬虫、写自动化脚本的老手这部分对你同样有用因为你会知道对方在前端埋了哪些加密步骤也就能知道该在哪个环节下手绕过。整天的内容主要围绕六个关键词展开JS应用、DOM树、加密编码库、断点调试、逆向分析、元素属性操作。它们不是孤立的而是串成一条链——从页面结构出发沿着代码执行路径找到数据被加工的位置再决定是分析还是绕过。讲得通俗一点前端安全本质上是在回答三个问题页面是谁构造的、数据是经过什么处理才变成请求的、我怎么在浏览器里把这些处理过程“重放”或“修改”。这三个问题都离不开对JS的理解。我这篇就按那天课程的主线把这套思路完整拆开来讲每一个环节都尽可能带上能直接上手的操作方式和我踩过的坑。2. DOM树与元素属性操作页面结构里的突破口2.1 先建立DOM直觉页面在你眼里不该是“图片”而是一棵能改的树DOMDocument Object Model是浏览器把HTML解析之后形成的一棵节点树。很多做安全的朋友一开始会忽略它觉得“我要分析的是请求和响应管页面结构干嘛”。但实际测试里DOM的重要性远超你的想象。一个请求的参数名、一个加密开关、一段被隐藏的逻辑往往就藏在某个节点属性的变化里。最简单的例子很多后台系统有一个隐藏字段比如input typehidden namerole valueuser前端表单提交时直接把这个值传给后端。这种结构在网上管理系统里非常常见。安全测试时第一件该做的事就是打开开发者工具把页面上所有hidden输入框都扫一遍看看有没有不该暴露的字段。你在控制台一行代码就能做到document.querySelectorAll(input[typehidden]).forEach(el { console.log(el.name, el.value); });这个操作的原理是浏览器把HTML解析成DOM后每个标签都变成了一个可读写的对象。querySelectorAll负责从DOM树里筛出符合条件的节点forEach遍历它们然后把name和value属性取出来给你看。整个过程不需要刷新页面、不需要抓包直接在控制台就能完成。2.2 元素属性操作改属性、看逻辑、找入口DOM树的价值不只是“看”更在于“改”。浏览器赋予了JS对节点属性的完整读写能力包括getAttribute()、setAttribute()、removeAttribute()以及更直接的element.xxx yyy方式。这套能力在安全测试里就是一把螺丝刀。常见操作场景有这几种修改disabled属性让原本不可点击的按钮生效。比如某些页面的提交按钮被置灰理论上需要先勾选协议才能点击但你直接删掉disabled属性就能跳过这个前端限制。修改maxlength属性绕过长度的前端校验。有些场景后端不做校验只靠前端限制长度那你在控制台执行el.maxLength 9999就能提交远超限制的数据。修改href或src属性观察跳转逻辑。很多前端埋了跳转事件你的参数不同跳转目标就不同直接改属性可以快速判断逻辑分支。修改innerHTML动态插入测试代码。遇到DOM型XSS测试时你需要在某个节点里塞一段测试标记观察是否被执行。我再举一个实际测试中常碰到的场景。某个系统的前端禁用词检测是一个oninput事件在过滤用户输入。当你输入敏感词它直接替换成***。这个逻辑在前端那就直接在控制台把这个事件解绑const el document.querySelector(#input-area); el.oninput null;之后你再输入任何内容都不会被前端过滤了。如果后端也做了同样限制那这个操作至少帮你跳过了一层障碍方便你单独测试后端逻辑。2.3 从DOM操作中嗅探JS与后端的交互习惯还有一个容易被忽略的观察点通过元素属性操作往往能看出前后端之间传递数据的方式。比如有些页面会在某个节点的>document.querySelectorAll(*).forEach(el { [...el.attributes].forEach(attr { if (attr.name.startsWith(data-)) { console.log(el.tagName, attr.name, attr.value); } }); });实测下来这个操作经常能翻到一些“本不该出现在前端”的东西比如用户角色标识、接口路径前缀甚至内部ID。攻防双方的博弈往往就在这些细节里——前端认为隐藏就是安全但实际上对于能打开控制台的人来说看到的只是“透明”而已。DOM树这个环节练熟之后你会形成一种条件反射拿到一个页面先扫隐藏字段、再扫自定义属性、再看事件绑定这比你直接抓包高效得多。3. 加密编码库前端数据加工的标准套路3.1 前端为什么要做加密编码在很多初学者眼里加密是用来保护传输数据的。这个理解对一半但安全测试里要换个角度前端加密更准确说是一种“数据加工”目的是让服务端更轻松、让测试者更难受。它不一定是为了防黑客更多时候是为了防“顺手抓包的人”——直接看请求就能读懂参数的应用早就不多见了。现在常见的前端加密封装手段有几类编码类Base64、URL编码、Hex、摘要类MD5、SHA-1、SHA-256、对称加密AES、DES、非对称加密RSA、国密算法SM2、SM3、SM4。注意编码和加密本质上是两回事。编码是可逆的格式转换比如Base64解码就是反操作加密则需要密钥、算法配合才能还原。但在前端世界它们经常混在一起用因为对业务开发者来说差别并不大——反正把明文变成一堆看不懂的字符就算“处理过了”。3.2 常见编码加密的特征识别做逆向分析的第一步往往是“认”出对方用的是什么算法。从我的经验看识别特征比你想的简单不需要什么专业工具眼睛加控制台就能完成。类型典型特征常见输出示例Base64大小写字母数字结尾常带号YWRtaW4URL编码%号加两位十六进制%61%64%6D%69%6E十六进制纯0-9和A-F组成61646D696EMD5固定32位十六进制字符串21232f297a57a5a743894a0e4a801fc3SHA-256固定64位十六进制字符串240be518fabd2724ddb6f04eeb1da5967448d7e831c08c8fa822809f74c720a9AES需要密钥输出通常为随机字符串或Base64U2FsdGVkX1...RSA输出长度较长通常也是Base64分段字符串明显比明文长得多国密SM4输出看起来像乱码通常用Base64或Hex包裹固定16字节分组的二进制结果这些特征不是绝对准确比如Base64和AES输出看起来就很像但作为第一轮判断已经够用。实践里的流程是先看长度和字符集再搜索关键词如果能找到加密函数名就直接定位找不到就下断点跟函数调用。3.3 如何跟到加密函数所在位置这是整节课程里争议最多的地方很多新手卡在这一步。最笨也最有效的方法是“搜”。登录页面按下F12在Sources面板里调出全局搜索快捷键CtrlShiftF输入你掌握的字段名比如password、username、encrypt、sign、token。搜出来以后挨个点进去看你大概率能找到一段函数里面写着怎么把明文加工成密文。看到一个典型的前端加密逻辑长这样function encryptLoginData(username, password) { const timeStamp Date.now(); const raw ${username}|${password}|${timeStamp}; return { data: CryptoJS.AES.encrypt(raw, secretKey, { mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString(), time: timeStamp }; }这一眼就能看懂先拼字符串再用AES的CBC模式加密密钥来自一个全局变量secretKey。到这里逆向分析的目标就清晰了——要么找到secretKey要么在调用时把encryptLoginData的结果“截胡”下来。这里我想分享一个我常用来定位加密函数的方法在控制台重定义可疑函数。比如你怀疑某个函数是加密入口你可以在控制台里做一次“函数替换”const originalFunc window.encryptData; window.encryptData function(...args) { console.log(encryptData被调用参数是, args); const result originalFunc.apply(this, args); console.log(返回结果是, result); return result; };这种方式叫“Hook”不用改页面代码只用控制台在当前环境里把目标函数包一层。每次函数被调用时你都能看到入参和出参甚至还能在result上做二次修改再返回。实际测试中Hook比断点调试更容易上手因为它不需要精确知道调用位置只要函数挂在window或者某个全局对象上就能拦住。3.4 前端加密的本质局限一个必须明确的安全观点前端加密防不住真正想分析的人。因为密钥、算法、逻辑全都跑在你的浏览器里你拥有完全的执行环境可以任意查看、修改、截断。前端加密解决的是“数据传输可读性”问题不是“数据安全”问题。用前端加密来保护核心业务的做法本质上就是给自己设一道栅栏而不是一堵墙。这道栅栏的意义在于增加分析成本把“随手抓包看明文”的人挡在外面而认真做测试的人花个把小时总能绕过去。我在测试里学到的一个心态很重要对待前端加密不要一上来就想着还原算法、写解密脚本。很多时候你根本不需要解密。你只需要让请求能发出去即可。比如登录密码加密了你不知道密钥是什么但你可以直接在控制台调用页面上现成的加密函数用同样的方式生成一份密文塞进请求里。这就是“重复调用代替破解”的思路是快速突破口。4. 断点调试把执行过程“定格”下来4.1 断点调试为什么要单独练加密函数找到了人能到这一步往往还不够因为代码可能是压缩过的、混淆过的函数嵌套很深你想逻辑时间太长。这时候断点调试就成了核心工具。断点的本质是告诉浏览器“执行到这里的时候暂停给我看。”这对于安全测试的意义很大——你可以把动态过程拆成一个个静态片段逐帧观察变量的值怎么变、函数怎么进怎么出、参数从哪里来最后拼出完整的逻辑链。浏览器自带的开发者工具里其实有好几种断点不只是平时网上教程里那种“在行号上点一下”的普通断点断点类型触发时机适用场景行断点代码执行到指定行定位某个具体赋值或加密调用DOM断点节点被修改、属性被改变时观察是谁改了页面元素XHR断点发Ajax请求时拦截所有网络请求入口事件监听器断点点击、输入等事件发生时找到按钮点击后的处理逻辑异常断点抛出异常时遇到反调试报错或不合理行为时4.2 XHR断点监听请求才是最快路径我刚接触断点调试时习惯先找行号浪费很多时间。后面发现对安全测试来说最高效的断点是XHR断点。因为页面最终总要发请求请求的URL和参数会经过所有加密和处理相当于所有线索最终都会汇聚到请求上。打断点的位置不是某一行代码而是开发者工具里的事件监听器断点面板勾选上XHR事件。之后只要有网络请求发生代码就会停在发请求的地方。这时候往右侧调用栈面板一看从上到下就是完整函数调用链顺着这个链往上走就找到了所有参数加工的位置。这种方式特别适合处理“压缩过、混淆过的一行JS”场景。压缩代码让人没法一眼读懂但调试时浏览器会把执行位置标得很清楚你不需要人类去读全篇你只需要在关键位置断下然后顺着调用栈走。4.3 断点调试实操定位参数生成过程的完整步骤结合课程里演示的案例我把一个典型流程拆成五步这个流程我后来在多个目标上反复验证过稳定性很好第一步打开开发者工具切到“网络”面板在页面上做一个操作比如点一次登录按钮。观察发出的请求里有哪些参数是固定的、哪些是动态的。第二步确定目标参数。假设登录密码字段是encryptedPwd值是abc123...密文。第三步切到“源代码”面板按CtrlShiftF全局搜索encryptedPwd这个字段名。这一步就能把生成这个字段的代码位置找出来。第四步在搜索结果里找到赋值语句在那一行打上行断点。第五步重新触发登录操作。代码会在断点处暂停此时观察右侧“作用域”面板展开各个变量确认密文的来源。大多数时候你会看到类似这样的代码let encryptedPwd rsaEncrypt(plainPwd publicKeySuffix);然后你就可以在控制台里直接调用rsaEncrypt函数验证它是不是纯前端逻辑。如果是那就意味着你完全可以在不询问服务端的情况下自己构造合法密文。4.4 断点调试的三个反面教训断点调试有一些细节初学者很容易踩坑。第一XHR断点默认会把所有请求都拦下来。你做一个操作可能触发十几个页面统计类请求一个一个放行非常烦人。解决方法是只保留你关心的URL关键词。这块在DevTools里可以配置XHR断点的URL过滤规则支持子串匹配实测能大幅减少干扰。第二断点打到“匿名函数”里时变量列表经常是空的。这种情况多半是压缩代码把变量名变成了t、n、e这样的单个字母不是没传参只是打包工具把上下文藏起来了。这时候不要急着放弃在控制台手动输入t、n、e试试看好多次关键密文就藏在其中一个字母变量里。第三不要忘了“格式化”按钮。Sources面板左下角有一个{}图标点一下压缩成一行的大函数就会展开成可读的多行代码。这是逆向分析的第一步操作。不格式化就分析行号和括号配对都能让你崩溃。格式化之后虽然变量名还是短字母但至少控制流能看清楚了后续断点位置也更准确。5. 逆向分析思路从“看不懂”到“能改”的进阶路径5.1 压缩、混淆和加密的前端代码怎么看前端逆向的核心难点在于代码被处理过。处理层级大概分三种压缩、混淆、加密。压缩只是删掉了空格和换行变量名可能不变混淆则会把短变量名替换、字符串挪位、控制流打乱加密就更加粗暴直接用WebAssembly或者自定义解码器把核心逻辑藏起来。大多数商业站点的选择是“压缩轻度混淆”真正上高强度混淆的还是少数。对于压缩和轻度混淆我的经验是一句口诀先格式化再搜索关键词最后跟调用栈。格式化你只干了一次搜索关键词找入口调用栈反应出生命路径。这三板斧能覆盖绝大多数场景。5.2 Hook技术不改代码只改运行时前面提过一次Hook这里展开说。Hook这种手法的独特之处是不需要理解全部代码逻辑只需要关注你关心的那个函数。你像装了一个监控摄像头无论函数的参数来自哪里、返回结果给谁你都能记录得清清楚楚。实际测试中最常Hook的对象有三类window.btoa和window.atobBase64编码解码登录页高频操作。CryptoJS.AES.encryptAES加密入口经常和登录、支付相关。Date.now或Math.random时间戳或随机数生成签名参数常用。举一个实际例子。某站点登录请求里有sign参数看起来像一串MD5。搜索定位后发现代码调用了md5(rawString)。但你不知道rawString怎么拼的。这时候直接Hook掉全局md5方法const origMd5 window.md5; window.md5 function(s) { console.log(MD5入参, s); return origMd5(s); };刷新页面再登录控制台里就会打印出原始字符串拼接规则。整个过程不打断点、不翻代码一行都没改页面静态资源。这种操作方式非常适合做快速验证。5.3 逆向分析的两个结果走向逆向JS的目标一般有两种结局。一种是你把逻辑还原了知道参数怎么生成于是自己写脚本模拟整个过程这是自动化工具要用的路径。另一种是你没有去完全还原但通过在浏览器里动态调用页面函数“借用”它的能力生成合法参数。比如预约抢票系统、投票系统多数情况下都是靠第二种思路突破的。这两种思路在效率上差别很大。写脚本还原逻辑往往需要搞懂所有细节耗时按小时算动态调用页面函数只需要在当前浏览器环境里执行一行代码耗时按秒算。不过动态调用有一个限制页面必须开着页面闭包变量被垃圾回收后就失效了。我个人的建议是快速验证场景用动态调用长期自动化脚本再考虑完整还原。考试也好、实战也罢先动起来比先搞明白更重要。5.4 常见难度升级情况现在有些站点已经开始升级JS防护手段常见的有debugger检测代码里直接写死debuggerDevTools一打开就陷入无限断点。绕过办法是在Sources面板右键该断点“Never pause here”或者用CtrlF8开关断点。格式化检测检测代码是否被格式化如果格式化了逻辑就变了。需要禁用格式化功能直接把源码手动重新缩进后保存为本地文件用本地替换模式加载。时间差异检测代码执行时间太短或太长会触发反调试分支。需要在设置里关闭JavaScript源码映射或手动修改变量绕过。WebAssembly加密这种基本是为了防逆向分析成本极高实战中优先考虑找旧版接口或其他终端。这些内容听起来玄乎但你在日常小目标上碰到的概率很低。能用上断点调试和Hook你就能解决掉百分之八十的前端加密问题。6. 一条完整的串联实战从元素属性到发送请求6.1 完整演练目标用一个虚构场景把所有知识点串起来某后台管理系统有个“修改手机号”功能页面打开后要求输入旧手机、新手机、短信验证码点击提交会发送一个POST请求。抓包看到请求体如下{ userId: U10293, newPhone: dG9tMTIzNDU2, verifyCode: k3x7e2, sign: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 }你发现newPhone不是明文sign看起来是32位哈希。现在的任务是搞清楚这两个参数怎么生成并判断有没有可利用的点。6.2 实操步骤与观察第一步看页面源码。在控制台跑一下隐藏字段扫描document.querySelectorAll(input, button, form).forEach(el { console.log(el.tagName, el.type, el.name, el.value); });发现表单里有一个隐藏字段userId值就是U10293。同时注意到提交按钮绑定了onclicksubmitChange()说明逻辑在全局函数里。第二步搜索关键词。在Sources面板全局搜索newPhone和sign发现一段代码function submitChange() { let phone document.getElementById(newPhoneInput).value; let params { userId: getUserId(), newPhone: encodeBase64(phone), verifyCode: document.getElementById(verifyCode).value, sign: md5(userId phone verifyCode salt) }; sendRequest(params); }这就清楚了newPhone是Base64编码sign是MD5。密钥盐值是salt硬编码在JS里。你不需要逆向加密算法你只需要理解逻辑即可。第三步验证可控性。用一个新手机号替换Base64值同时用控制台重新计算MD5const userId U10293; const phone 13800138000; const code 123456; const sign md5(userId phone code salt); const params { userId, newPhone: btoa(phone), verifyCode: code, sign };这样你就拿到了一个合法参数组。如果你还能控制userId就可以尝试越权改其他用户的手机号。这里的风险点不是加密算法不够强而是前端逻辑把该藏的盐值和算法全部暴露了。6.3 链路上的安全反思这个练习充分体现了课程开头强调的链路观念DOM树让你看到了隐藏字段元素属性操作让你摸清了表单结构加密编码库帮你识别出Base64和MD5断点调试让你定位到字段拼接逻辑逆向分析帮你构造出合法请求。你从头到尾没有破解任何密码只是把前端自己提供的工具链用了一遍。这条链路对测试人员的启发是不要总想着从后端寻找突破口。前端代码本身就是一张地图上面标注了参数生成规则、密钥盐值、接口地址。做安全测试时打开浏览器按F12的那一刻你已经拿到了一半的答案。7. 实际操作中的几条经验总结最后分享几条我自己在学习和实战中反复验证过的经验不是什么大道理就是踩坑踩出来的心得。第一DevTools的Sources面板里那个“{}”格式化按钮养成习惯看到压缩代码先点它。我遇到很多人花半小时在一行密密麻麻的代码里找某个参数其实格式化后十秒钟就看清了。第二遇到加密参数先问自己一句“我不解开它能不能直接用”大部分时候答案是能。前端既然能加密就一定有生成密文的函数在浏览器里直接调用它比自己逆向解密快得多也稳得多。第三DOM断点不是摆设。遇到“页面元素突然被替换掉”“某个输入框被自动填满”这类诡异情况在对应节点上打一个DOM断点触发变化时它会把修改属性的代码精确定位出来。这个技巧在分析动态渲染页面时特别好用建议没事就在几个关键节点上试试。第四Hook的时机很关键。要在页面加载早期就注入否则你等页面已经跑完逻辑再重新覆盖窗口方法很多调用已经过去了。动手前先刷新页面、提前把Hook代码准备好放进Sources里的Snippets代码片段功能里一键运行不污染Console。第五做逆向分析一定要记录。我在分析过程中习惯用一个文本文件记录函数名、参数、调用栈和结果。因为分析过程会很长变量名又多纯靠大脑记过半个小时必然乱。整理成笔记后面写自动化脚本时可以直接照着变量名来。这门课学到最后一节时课程组织者给了一句话让我印象非常深“前端安全不是让你去破解代码而是让你学会阅读代码的执行轨迹。”用这个视角去看JS应用你会发现之前觉得难啃的加密、混淆、断点调试都变得顺理成章。工具永远是那些工具真正拉开差距的是你看待问题的方式。
