从JS文件泄露到数据解密一次RSA私钥暴露的完整利用链分析前端JS文件里藏着私钥这件事我遇到过不止一次。有一次做授权测试目标是个企业后台管理系统登录接口做了RSA加密前端代码把password加密后再提交。表面上看起来很正规加密传输嘛但当我习惯性地打开控制台翻Sources时在一个叫login.min.js的文件里看到了字符串BEGIN RSA PRIVATE KEY。当时我就知道这套所谓的加密防御从根上就已经失效了。拿到私钥之后后面的路子其实非常顺定位加密逻辑、还原加密入口、抓取密文、用私钥离线解密——整条利用链在几分钟内就能走通。这篇博文我就把这次RSA私钥暴露的完整利用链拆开来讲包括前端私钥泄露的常见形态、私钥暴露后的价值评估、实际解密操作的每一步细节以及我踩过的几个格式和填充模式的坑。适合做渗透测试、前端开发和安全运维的朋友参考哪怕你是刚入门的安全爱好者跟着操作一遍也能完全理解这套攻击路径的原理和防御思路。1. 从JS文件开始前端私钥泄露的常见形态与定位方法1.1 为什么前端文件会变成“私钥仓库”很多开发团队有一个根深蒂固的误解只要数据在传输前做了加密攻击者截获了也没办法。这个逻辑本身没错但前提是密钥不能跟密文一起暴露。问题在于RSA加密如果要让浏览器端完成加密所需的公钥必须下发到前端。按理说私钥应该留在服务端只做解密但有些项目为了省事直接把解密逻辑也搬到了前端或者把服务端私钥误打误撞打进了静态资源包最后被浏览器下载到了本地。我实际审计过的前端私钥泄露案例来源大概就这几种硬编码在业务JS文件里团队为了赶进度直接把私钥写进utils/encrypt.js注释还写着“这里先用着后面再改”。藏在SourceMap源码映射文件里生产环境的.js.map文件没关闭源码一层层展开后私钥和管理员接口地址一起暴露。混在静态配置JSON中有些SPA会把全局配置打成config.js或env.js里面既有API网关地址、AppId也可能带着一段私钥。构建产物残留开发环境调试用的加密工具类被打包进了生产包开发时的测试私钥忘了删除。这里有一个关键认知前端代码里出现的私钥本质上就不是私钥了而是公开密钥。因为任何一个访问者都能下载JS文件并提取出其中的内容私钥的机密性在前端环境里是不存在的。理解这一点后面才能说清楚为什么私钥暴露会造成那么大的破坏。1.2 快速定位可疑JS文件与关键代码片段的技巧面对一个目标站点我不可能把几十个JS文件从头到尾读一遍。实际做法是先抓特征再人工确认。第一步是打开开发者工具切到Sources面板把JS文件列表拉出来优先看几个可疑位置入口文件通常是app.js或main.js、登录相关的页面路由文件、名字里带encrypt、crypto、security、rsa字样的文件。第二步是直接搜关键词。在Sources面板的搜索框里输入这些高价值字符串BEGIN RSA PRIVATE KEYBEGIN PRIVATE KEY-----BEGINprivateKeysetPrivateKeydecryptJSEncryptcrypto-js搜索结果如果命中直接定位到对应文件结合上下文判断这段私钥是用在哪个接口。第三步可以借助自动化工具去爬取JS文件并做特征匹配。很多开源工具可以把目标域名下的JS资源全部拉下来然后用正则扫描敏感关键字。这类工具能跑出几十个JS文件里所有的可疑字符串省去人工点开每个文件的时间。我自己习惯在扫描结果里再人工过一遍因为自动化工具只负责“找出异常”最终还是得靠人判断哪些异常能串成一条利用链。我遇到过一个小细节有些私钥不是完整写在JS里的而是被拆成了几段字符串运行时会拼接起来再用。比如代码里写const keyPart1 -----BEGIN RSA PRIVATE KEY-----\n;后面再定义keyPart2、keyPart3最后privateKey keyPart1 keyPart2 ...。所以单纯搜BEGIN RSA PRIVATE KEY可能搜不到。遇到这种情况可以搜charCodeAt、join()、concat这类字符串处理函数找到可疑拼接代码后再看内容。实在不行直接在控制台里手动执行一次完整的拼接和加载流程让运行时把私钥打印到console里。提示如果是做授权渗透测试搜索和提取私钥的操作要在测试范围确认后进行。如果只是自己学习强烈建议在本地搭建靶场环境复现不要在未经授权的目标上做这些操作。2. RSA私钥暴露后的价值评估拿到私钥到底能做什么2.1 先说清楚RSA在Web场景里的两种典型用法RSA非对称加密有两个核心能力一个是公钥加密、私钥解密用于保证机密性另一个是私钥签名、公钥验签用于保证完整性和身份认证。在Web前端场景里最常见的还是第一种——登录密码加密传输。正常的流程应该是服务端生成密钥对公钥给前端前端用公钥加密密码服务端用私钥解密。这个设计的核心保护点是即使攻击者截获了传输中的密文没有私钥就还原不出明文。但如果私钥本身跑到了前端JS里这个保护点就完全失效了因为攻击者可以从JS中拿到私钥然后离线对任何密文做解密等同于拿到了明文通道。如果项目里还把私钥用在签名场景危害会更直接。比如前端用私钥给某个请求参数签名服务端用公钥验签以为这样能防止请求被篡改。私钥暴露后攻击者可以用这把私钥伪造任意参数的合法签名构造一个服务端校验完全通过的新请求。我们当时测试的那个系统私钥泄露意味着攻击者不仅能解开登录密码密文还能直接伪造请求签名绕过接口校验。2.2 拿到私钥后要分清“能做什么”和“不能做什么”刚拿到私钥的时候不要急着到处解密先做三件判断第一确认私钥对应的公钥是什么。用OpenSSL命令读取私钥的modulus再去服务端公开接口或JS代码里找公钥对比两者的modulus是否一致。这一步是为了确认私钥没有被替换或误放别解了半天发现解出来的是乱码因为根本不是同一对密钥。第二判断私钥适用的业务场景。在JS代码里搜索这把私钥被引用的位置。如果是在登录模块的decrypt函数里引用那么它解的就是用户名或密码密文如果是在某个支付回调参数里引用那价值就更大了。要顺着引用链去看它会影响哪些接口而不是笼统地说“私钥泄露了”。第三评估密文数据的可达路径。拿到了私钥你还得考虑怎么拿到密文。密文可能在网络请求里、本地存储里、Cookie里也可能在数据库的某个字段里。如果密文在请求里你只需要抓包拿到相应参数即可如果密文存在数据库里那说明攻击者已经拿到一定权限了私钥此时是扩大战果的助推器而不是入口。关联上下文后你才能判断这条利用链的深度。这里要特别提醒一个误区有人以为拿到私钥就能解密所有RSA密文。其实RSA只能解密“用这把私钥对应的公钥加密”的数据如果某个接口用的是另一对密钥的公钥加密那这把私钥就派不上用场。所以私钥的价值评估永远要围绕“它被用在哪里、影响哪些数据”来判断。2.3 验证私钥有效性的标准操作拿到一段私钥字符串先别急着写代码解密先用标准工具验证一下。我习惯先在Linux终端里把私钥内容写进一个private.pem文件然后执行openssl rsa -in private.pem -text -noout如果输出能看到模数、指数、素数等信息说明私钥格式是PEM标准且可解析。如果报错“bad decrypt”或者“unable to load Private Key”说明私钥被加密过或格式不对。接着把服务端公钥也存成public.pem执行openssl rsa -in private.pem -pubout对比输出的公钥模数和服务端下发到前端的公钥模数。模数一致才说明这对密钥是真的配对的。另外要注意私钥的编码格式。常见的有两种PKCS#1格式的私钥块以-----BEGIN RSA PRIVATE KEY-----开头PKCS#8格式以-----BEGIN PRIVATE KEY-----开头。OpenSSL工具和大多数编程库两种都支持自动识别但如果你用某些较旧的库处理可能只认识其中一种。遇到解析不了的情况可以先用OpenSSL转换一下格式openssl pkcs8 -topk8 -nocrypt -in private_pkcs1.pem -out private_pkcs8.pem转换后再验证一遍避免因为格式问题导致后面解密脚本跑不通。3. 完整利用链的实操复现从提取私钥到密文还原3.1 搭一个可复现的靶场场景为了方便说明我定义一套完整模拟场景某后台管理系统登录接口为login.do前端使用JSEncrypt库对密码做RSA加密提交参数为username和passwordCipher。开发人员在JS文件里误将私钥一起打包发布且私钥无密码保护。我们的目标是验证能否从JS提取私钥并还原登录密码明文。这套场景非常适合用本地靶场复现。前端页面有一个login.js包含以下核心代码逻辑var encrypt new JSEncrypt(); encrypt.setPublicKey(-----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...\n-----END PUBLIC KEY-----); var encrypted encrypt.encrypt(document.getElementById(password).value); document.getElementById(passwordCipher).value encrypted;而同一个JS文件的底部有一段看起来毫不起眼的配置代码// 临时方案后续移除 var rsaDecryptKey -----BEGIN RSA PRIVATE KEY-----\nMIICXQIBAAKBgQ...\n-----END RSA PRIVATE KEY-----;这段代码就是私钥的泄露源。实际测试中我们只需要从该文件中提取这段字符串并保存为private.pem。3.2 提取私钥并验证配对关系打开浏览器开发者工具复制JS文件中私钥部分的内容到本地文件。注意复制时要保留换行符和-----BEGIN RSA PRIVATE KEY-----与-----END RSA PRIVATE KEY-----完整标记。如果从Sources面板复制的是单行字符串要注意\n字符在源码里是转义符还是真实换行。如果源码是字符串拼接的写法直接把整个字符串表达式复制到控制台执行得到完整私钥后再保存。保存后执行验证命令openssl rsa -in private.pem -text -noout看到“Private-Key”信息后再导出公钥openssl rsa -in private.pem -pubout -out public_from_pem.pem然后对比前端JS里嵌入的公钥模数。方法是执行openssl pkey -pubin -in public_from_pem.pem -text -noout | grep modulus再对前端公钥执行同样命令模数一致就说明私钥确实对应前端加密用的公钥。这一步非常重要如果不一致说明私钥可能只是开发残留对当前接口没有实际威胁需要继续寻找与其配对的公钥。3.3 定位接口加密逻辑与密文入口密钥验证通过后下一步是在JS代码中找出加密逻辑的完整链路。搜索passwordCipher这个字段名能定位到表单提交函数。然后找到提交前调用加密库的位置一般是encrypt.encrypt(...)或setPublicKey(...)。通过这些调用位置我们能确认两件事哪个接口接收密文参数密文是Base64编码还是Hex编码。JSEncrypt的输出默认是Base64字符串形如X2pR...mZQ。但有些封装代码会再做一层处理比如把Base64转成URL编码、去掉头尾特殊字符甚至用URLSearchParams重新拼装。这些细节都会影响后续解密脚本。我在测试中习惯直接抓一次登录请求把passwordCipher参数的真实值保存下来。同时用开发调试模式把JS加密函数手动执行一遍比对输出格式。确定密文格式后再利用私钥解密。密文入口和格式确认后利用链的后半段就明朗了。3.4 编写解密脚本还原明文数据解密脚本我通常用Python的rsa库实现也可以直接用cryptography库。这里给出一个通用解密脚本处理Base64编码的密文字符串import base64 import rsa # 读取私钥文件 with open(private.pem, rb) as f: private_key rsa.PrivateKey.load_pkcs1(f.read()) def rsa_decrypt(cipher_b64: str) - str: # Base64解码 cipher_bytes base64.b64decode(cipher_b64) # RSA私钥解密 plaintext_bytes rsa.decrypt(cipher_bytes, private_key) # 默认使用UTF-8解码 return plaintext_bytes.decode(utf-8) if __name__ __main__: captured_cipher input(请输入抓包得到的密文: ) print(解密结果:, rsa_decrypt(captured_cipher))这里的核心逻辑就是三步Base64解码、RSA解密、字符集还原。实际跑一遍就会发现如果一切顺利输出的就是登录密码明文甚至因为系统内部还用了这同一把私钥去解密其他敏感数据我们后续还能解密更多接口的密文。但这里有一个高概率踩坑的点填充模式。上述代码默认使用PKCS#1 v1.5填充方式。JSEncrypt库的加密默认就是RSA_PKCS1_PADDING所以用上面的脚本能正常解出。如果你遇到的是OAEP填充模式rsa.decrypt会直接报错这时要用支持OAEP的库来处理from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import padding from cryptography.hazmat.backends import default_backend from cryptography.hazmat.primitives import serialization with open(private.pem, rb) as f: private_key serialization.load_pem_private_key(f.read(), passwordNone, backenddefault_backend()) cipher_bytes base64.b64decode(captured_cipher) plaintext_bytes private_key.decrypt( cipher_bytes, padding.OAEP( mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone ) ) print(plaintext_bytes.decode(utf-8))如果你的目标系统用的是OAEP还得确认哈希算法是SHA1还是SHA256用错了也会解不出来。3.5 渗透测试中的合规边界提醒虽然这条利用链复现起来很快但我必须强调测试边界。完整的私钥提取、密文解密操作只应在以下场景中进行获得了目标系统所有者明确的书面授权测试范围包含前端代码审计和认证机制验证在自建靶场或本地模拟环境中进行学习研究作为应急响应中对已知泄露事件的评估。测试过程中提取到的任何敏感数据不能外传、不能留存超过必要时间、不能用于任何未授权的后续访问。这一点是整个利用链分析中最容易被忽视的部分却是从业者必须守住的底线。注意未经授权对任何现实目标执行这套流程属于违法行为。本文所有操作均基于靶场环境或授权测试场景。4. 常见问题与排查技巧实录4.1 问题速查表我整理了一份实际操作中经常遇到的问题速查表按症状、原因、解决方案排好方便你解密脚本跑不动时逐一排查。症状可能原因解决方法OpenSSL无法加载私钥私钥带BOM头、文件编码不对或私钥被密码保护用hexdump检查文件头保存为UTF-8无BOM若加密则用-passin参数解密结果乱码密文不是Base64编码而是Hex尝试bytes.fromhex(cipher)后解密解密抛错“Decryption failed”密文与私钥不匹配或填充模式不对先验证modulus是否一致再尝试切换PKCS1/OAEP模式前端返回的密文带符号密文被URL编码或HTML实体转义先做urllib.parse.unquote或html.unescape还原私钥里有注释文字代码做了字符串截取或拼接把JS表达式完整执行后再提取过滤非PEM内容解密出的明文是十六进制串系统内部可能还对明文做了Hex编码将十六进制字符串转回ASCII即可这张表里面我特别想强调最后两条因为它们都因为细节问题浪费过我不少时间。拼接私钥的情况最坑因为从开发者工具里复制出来的文本看起来像完整的PEM但只要少了一个\nOpenSSL就报错而带Hex编码的情况则是解出了数据但就是不对最后翻源代码才发现原来加密前还多套了一层。4.2 踩过的几个关键格式坑第一个坑换行符丢失。PEM格式的私钥需要标准换行如果从开发者工具里复制出来时换行符被转成了空格或消失了私钥块就变成一个超长单行OpenSSL大概率解析失败。我习惯复制后先执行wc -l private.pem看看有几行标准PEM私钥应该是至少三行头标记、内容体、尾标记。如果只有一行就用编辑器重新排版配合fold -w 64把内容体折成64列一行。第二个坑本地私钥是DER二进制格式。有些导出工具会生成DER格式私钥文件开头不是-----BEGIN而是0x30 0x82的二进制字节。识别这个很简单用文本编辑器打开看到乱码就知道了。处理方式是用OpenSSL转换openssl rsa -inform DER -in private.der -outform PEM -out private.pem第三个坑解密数据里有填充占位符。严格按标准实现的话RSA解密出来的原始数据是编码后的结构不是直接可读的明文。但JSEncrypt这类库在加密时已经把填充处理好了解密出来往往就是完整明文。你要是用了底层库自己做就得处理填充前缀否则会看到明文前面一堆\x00或者随机字节。最稳妥的办法是直接使用成熟密码库的高层API别自己实现RSA原始运算。4.3 排查脚本的一个调试小技巧解密遇到问题的时候不要反复盲试先用OpenSSL做一次标准验证。拿你抓到的密文Base64字符串解码成二进制后执行# 先用base64解码成二进制文件 echo $BASE64_STRING | base64 -d cipher.bin # 用私钥尝试解密 openssl pkeyutl -decrypt -inkey private.pem -in cipher.bin -out plain.txt如果这一步成功说明问题不在私钥和密文而在你自己写的脚本某个环节如果这里也失败那就要检查密钥配对、填充模式、密文格式了。OpenSSL把“底层的可能性”压缩成一次简单验证能帮你快速缩小问题范围省去在Python和JS中间反复横跳的时间。5. 前端密钥安全与修复建议别让私钥再次“裸奔”5.1 前端密钥管理的第一性原则前端做RSA加密时私钥绝不能出现在浏览器端这是第一性原则。很多人会问那登录密码加密到底该怎么设计标准做法是前端保留公钥加密密码后提交服务端持有私钥负责解密和校验。整个过程中前端代码里不需要也不应该出现解密逻辑。如果业务上确实需要在前端解密某些数据说明设计本身出了问题需要把解密逻辑挪到服务端通过网络接口返回解密后的结果。还有一个场景要格外注意有些团队为了安全把私钥放在本地配置文件里然后程序运行时读取。这种做法在服务端是合理的但一旦文件被放到静态目录下通过HTTP直接访问就和写在JS里没区别了。我之前遇到一个案例私钥文件放在/static/config/目录下文件名是rsa_key.pem加上目录没有做访问控制任何人都可以下载。这类问题暴露出的不是加密强度不够而是资产管理和访问控制失效。5.2 加固方案与日常检测思路修复前端私钥泄露问题我建议从下面几个方向同时入手第一服务端集中管控加解密能力。前端只做密钥加载和加密动作解密统一收敛到后端接口。可以用网关层拦截解密或在服务端增加解密接口前端不接触任何私钥相关代码。第二构建产物做最小化检查。CI/CD流程中加入敏感内容扫描对构建后的JS目录做正则匹配发现BEGIN PRIVATE KEY、password 、secret 等特征直接停止发布并告警。这个检查要放在构建产物上而不是源码上因为问题往往出在打包过程。第三SourceMap生产环境关闭。很多系统出问题就是因为SourceMap没关导致源码和注释全部暴露。建议生产环境不发布SourceMap或使用独立鉴权域名挂载不允许匿名访问。第四定期做外部视角检测。以攻击者的方式扫描自己系统的JS文件用一个通用规则集去匹配私钥、Token、API密钥。跑完一版我建议不仅看检测结果也顺手看一眼命中文件的数量和位置如果在无关紧要的地方命中了敏感字面量说明团队在代码规范上还有改进空间。第五密钥定期轮换。如果过去曾经泄露过密钥可以先用工具批量解密历年密文来评估影响范围然后强制所有客户端重新用新公钥加密。服务端兼容新旧密钥解密一段时间后再彻底移除旧密钥避免一次性切换导致大量用户登录失败。5.3 检测到泄露后的应急响应路径一旦发现私钥泄露别只盯着“删掉代码重新发布”这一步。我建议按这个顺序处理立即确认泄露私钥对应的业务范围用OpenSSL比对公钥和接口圈定受影响的系统尝试从日志、历史流量中确认是否存在已发生的未授权解密行为重点看非工作时间的异常请求生成新的密钥对更新服务端配置和前端公钥在服务端增加解密失败率监控因为旧客户端用旧公钥加密的数据在密钥切换后可能产生一批解密失败日志需要用兼容期来平滑过渡最后复盘问题源头是构建配置把开发目录打进了生产包还是某个同学图方便把私钥写在了业务文件里找到根因后把对应代码评审项加到团队规范里。这一步做扎实比单纯“改一个文件”有意义得多因为同类问题往往会以不同的形式反复出现。6. 最后分享一点个人体会这条从JS文件泄露到数据解密的利用链技术上并不复杂难的是从业者有没有“从文件里翻出私钥”的意识和耐心。我见过不少系统在基础设施层面防御做得非常到位防火墙、WAF、主机加固一样不缺但最后被撕开口子的却是前端JS里一行不起眼的配置代码。所以每次做安全评审我都会提醒团队安全设计不仅要把服务端铜墙铁壁也要把前端静态资产当成攻击面来看任何下发到浏览器的东西默认都是可以被攻击者拿到并分析的。整个排查过程跑下来我的切身体会是私钥泄露很少是孤立事件它往往意味着开发流程中存在“临时方案转正”“开发配置带入生产”“测试设备直接映射公网”等更深层的问题。把发现私钥当作信号而非终点顺着代码去找它为什么出现在那里才能从根上减少这一类问题。如果你也想练手强烈建议在自己搭的靶场环境里跑一遍完整的“提取私钥—验证配对—抓取密文—解密还原”流程。跑通一次之后你再看普通站点的前端资源眼睛里会多出一根警惕的弦看代码的位置和方式都会不一样。这条利用链虽然简单但它教给你的东西几乎可以迁移到所有前端敏感信息泄露的风险评估中去。 
长河君 · 2026/10/20 17:41:21 · 阅读 1.2k 前端JS文件泄露RSA私钥：从提取到数据解密的完整利用链分析
从JS文件泄露到数据解密一次RSA私钥暴露的完整利用链分析前端JS文件里藏着私钥这件事我遇到过不止一次。有一次做授权测试目标是个企业后台管理系统登录接口做了RSA加密前端代码把password加密后再提交。表面上看起来很正规加密传输嘛但当我习惯性地打开控制台翻Sources时在一个叫login.min.js的文件里看到了字符串BEGIN RSA PRIVATE KEY。当时我就知道这套所谓的加密防御从根上就已经失效了。拿到私钥之后后面的路子其实非常顺定位加密逻辑、还原加密入口、抓取密文、用私钥离线解密——整条利用链在几分钟内就能走通。这篇博文我就把这次RSA私钥暴露的完整利用链拆开来讲包括前端私钥泄露的常见形态、私钥暴露后的价值评估、实际解密操作的每一步细节以及我踩过的几个格式和填充模式的坑。适合做渗透测试、前端开发和安全运维的朋友参考哪怕你是刚入门的安全爱好者跟着操作一遍也能完全理解这套攻击路径的原理和防御思路。1. 从JS文件开始前端私钥泄露的常见形态与定位方法1.1 为什么前端文件会变成“私钥仓库”很多开发团队有一个根深蒂固的误解只要数据在传输前做了加密攻击者截获了也没办法。这个逻辑本身没错但前提是密钥不能跟密文一起暴露。问题在于RSA加密如果要让浏览器端完成加密所需的公钥必须下发到前端。按理说私钥应该留在服务端只做解密但有些项目为了省事直接把解密逻辑也搬到了前端或者把服务端私钥误打误撞打进了静态资源包最后被浏览器下载到了本地。我实际审计过的前端私钥泄露案例来源大概就这几种硬编码在业务JS文件里团队为了赶进度直接把私钥写进utils/encrypt.js注释还写着“这里先用着后面再改”。藏在SourceMap源码映射文件里生产环境的.js.map文件没关闭源码一层层展开后私钥和管理员接口地址一起暴露。混在静态配置JSON中有些SPA会把全局配置打成config.js或env.js里面既有API网关地址、AppId也可能带着一段私钥。构建产物残留开发环境调试用的加密工具类被打包进了生产包开发时的测试私钥忘了删除。这里有一个关键认知前端代码里出现的私钥本质上就不是私钥了而是公开密钥。因为任何一个访问者都能下载JS文件并提取出其中的内容私钥的机密性在前端环境里是不存在的。理解这一点后面才能说清楚为什么私钥暴露会造成那么大的破坏。1.2 快速定位可疑JS文件与关键代码片段的技巧面对一个目标站点我不可能把几十个JS文件从头到尾读一遍。实际做法是先抓特征再人工确认。第一步是打开开发者工具切到Sources面板把JS文件列表拉出来优先看几个可疑位置入口文件通常是app.js或main.js、登录相关的页面路由文件、名字里带encrypt、crypto、security、rsa字样的文件。第二步是直接搜关键词。在Sources面板的搜索框里输入这些高价值字符串BEGIN RSA PRIVATE KEYBEGIN PRIVATE KEY-----BEGINprivateKeysetPrivateKeydecryptJSEncryptcrypto-js搜索结果如果命中直接定位到对应文件结合上下文判断这段私钥是用在哪个接口。第三步可以借助自动化工具去爬取JS文件并做特征匹配。很多开源工具可以把目标域名下的JS资源全部拉下来然后用正则扫描敏感关键字。这类工具能跑出几十个JS文件里所有的可疑字符串省去人工点开每个文件的时间。我自己习惯在扫描结果里再人工过一遍因为自动化工具只负责“找出异常”最终还是得靠人判断哪些异常能串成一条利用链。我遇到过一个小细节有些私钥不是完整写在JS里的而是被拆成了几段字符串运行时会拼接起来再用。比如代码里写const keyPart1 -----BEGIN RSA PRIVATE KEY-----\n;后面再定义keyPart2、keyPart3最后privateKey keyPart1 keyPart2 ...。所以单纯搜BEGIN RSA PRIVATE KEY可能搜不到。遇到这种情况可以搜charCodeAt、join()、concat这类字符串处理函数找到可疑拼接代码后再看内容。实在不行直接在控制台里手动执行一次完整的拼接和加载流程让运行时把私钥打印到console里。提示如果是做授权渗透测试搜索和提取私钥的操作要在测试范围确认后进行。如果只是自己学习强烈建议在本地搭建靶场环境复现不要在未经授权的目标上做这些操作。2. RSA私钥暴露后的价值评估拿到私钥到底能做什么2.1 先说清楚RSA在Web场景里的两种典型用法RSA非对称加密有两个核心能力一个是公钥加密、私钥解密用于保证机密性另一个是私钥签名、公钥验签用于保证完整性和身份认证。在Web前端场景里最常见的还是第一种——登录密码加密传输。正常的流程应该是服务端生成密钥对公钥给前端前端用公钥加密密码服务端用私钥解密。这个设计的核心保护点是即使攻击者截获了传输中的密文没有私钥就还原不出明文。但如果私钥本身跑到了前端JS里这个保护点就完全失效了因为攻击者可以从JS中拿到私钥然后离线对任何密文做解密等同于拿到了明文通道。如果项目里还把私钥用在签名场景危害会更直接。比如前端用私钥给某个请求参数签名服务端用公钥验签以为这样能防止请求被篡改。私钥暴露后攻击者可以用这把私钥伪造任意参数的合法签名构造一个服务端校验完全通过的新请求。我们当时测试的那个系统私钥泄露意味着攻击者不仅能解开登录密码密文还能直接伪造请求签名绕过接口校验。2.2 拿到私钥后要分清“能做什么”和“不能做什么”刚拿到私钥的时候不要急着到处解密先做三件判断第一确认私钥对应的公钥是什么。用OpenSSL命令读取私钥的modulus再去服务端公开接口或JS代码里找公钥对比两者的modulus是否一致。这一步是为了确认私钥没有被替换或误放别解了半天发现解出来的是乱码因为根本不是同一对密钥。第二判断私钥适用的业务场景。在JS代码里搜索这把私钥被引用的位置。如果是在登录模块的decrypt函数里引用那么它解的就是用户名或密码密文如果是在某个支付回调参数里引用那价值就更大了。要顺着引用链去看它会影响哪些接口而不是笼统地说“私钥泄露了”。第三评估密文数据的可达路径。拿到了私钥你还得考虑怎么拿到密文。密文可能在网络请求里、本地存储里、Cookie里也可能在数据库的某个字段里。如果密文在请求里你只需要抓包拿到相应参数即可如果密文存在数据库里那说明攻击者已经拿到一定权限了私钥此时是扩大战果的助推器而不是入口。关联上下文后你才能判断这条利用链的深度。这里要特别提醒一个误区有人以为拿到私钥就能解密所有RSA密文。其实RSA只能解密“用这把私钥对应的公钥加密”的数据如果某个接口用的是另一对密钥的公钥加密那这把私钥就派不上用场。所以私钥的价值评估永远要围绕“它被用在哪里、影响哪些数据”来判断。2.3 验证私钥有效性的标准操作拿到一段私钥字符串先别急着写代码解密先用标准工具验证一下。我习惯先在Linux终端里把私钥内容写进一个private.pem文件然后执行openssl rsa -in private.pem -text -noout如果输出能看到模数、指数、素数等信息说明私钥格式是PEM标准且可解析。如果报错“bad decrypt”或者“unable to load Private Key”说明私钥被加密过或格式不对。接着把服务端公钥也存成public.pem执行openssl rsa -in private.pem -pubout对比输出的公钥模数和服务端下发到前端的公钥模数。模数一致才说明这对密钥是真的配对的。另外要注意私钥的编码格式。常见的有两种PKCS#1格式的私钥块以-----BEGIN RSA PRIVATE KEY-----开头PKCS#8格式以-----BEGIN PRIVATE KEY-----开头。OpenSSL工具和大多数编程库两种都支持自动识别但如果你用某些较旧的库处理可能只认识其中一种。遇到解析不了的情况可以先用OpenSSL转换一下格式openssl pkcs8 -topk8 -nocrypt -in private_pkcs1.pem -out private_pkcs8.pem转换后再验证一遍避免因为格式问题导致后面解密脚本跑不通。3. 完整利用链的实操复现从提取私钥到密文还原3.1 搭一个可复现的靶场场景为了方便说明我定义一套完整模拟场景某后台管理系统登录接口为login.do前端使用JSEncrypt库对密码做RSA加密提交参数为username和passwordCipher。开发人员在JS文件里误将私钥一起打包发布且私钥无密码保护。我们的目标是验证能否从JS提取私钥并还原登录密码明文。这套场景非常适合用本地靶场复现。前端页面有一个login.js包含以下核心代码逻辑var encrypt new JSEncrypt(); encrypt.setPublicKey(-----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...\n-----END PUBLIC KEY-----); var encrypted encrypt.encrypt(document.getElementById(password).value); document.getElementById(passwordCipher).value encrypted;而同一个JS文件的底部有一段看起来毫不起眼的配置代码// 临时方案后续移除 var rsaDecryptKey -----BEGIN RSA PRIVATE KEY-----\nMIICXQIBAAKBgQ...\n-----END RSA PRIVATE KEY-----;这段代码就是私钥的泄露源。实际测试中我们只需要从该文件中提取这段字符串并保存为private.pem。3.2 提取私钥并验证配对关系打开浏览器开发者工具复制JS文件中私钥部分的内容到本地文件。注意复制时要保留换行符和-----BEGIN RSA PRIVATE KEY-----与-----END RSA PRIVATE KEY-----完整标记。如果从Sources面板复制的是单行字符串要注意\n字符在源码里是转义符还是真实换行。如果源码是字符串拼接的写法直接把整个字符串表达式复制到控制台执行得到完整私钥后再保存。保存后执行验证命令openssl rsa -in private.pem -text -noout看到“Private-Key”信息后再导出公钥openssl rsa -in private.pem -pubout -out public_from_pem.pem然后对比前端JS里嵌入的公钥模数。方法是执行openssl pkey -pubin -in public_from_pem.pem -text -noout | grep modulus再对前端公钥执行同样命令模数一致就说明私钥确实对应前端加密用的公钥。这一步非常重要如果不一致说明私钥可能只是开发残留对当前接口没有实际威胁需要继续寻找与其配对的公钥。3.3 定位接口加密逻辑与密文入口密钥验证通过后下一步是在JS代码中找出加密逻辑的完整链路。搜索passwordCipher这个字段名能定位到表单提交函数。然后找到提交前调用加密库的位置一般是encrypt.encrypt(...)或setPublicKey(...)。通过这些调用位置我们能确认两件事哪个接口接收密文参数密文是Base64编码还是Hex编码。JSEncrypt的输出默认是Base64字符串形如X2pR...mZQ。但有些封装代码会再做一层处理比如把Base64转成URL编码、去掉头尾特殊字符甚至用URLSearchParams重新拼装。这些细节都会影响后续解密脚本。我在测试中习惯直接抓一次登录请求把passwordCipher参数的真实值保存下来。同时用开发调试模式把JS加密函数手动执行一遍比对输出格式。确定密文格式后再利用私钥解密。密文入口和格式确认后利用链的后半段就明朗了。3.4 编写解密脚本还原明文数据解密脚本我通常用Python的rsa库实现也可以直接用cryptography库。这里给出一个通用解密脚本处理Base64编码的密文字符串import base64 import rsa # 读取私钥文件 with open(private.pem, rb) as f: private_key rsa.PrivateKey.load_pkcs1(f.read()) def rsa_decrypt(cipher_b64: str) - str: # Base64解码 cipher_bytes base64.b64decode(cipher_b64) # RSA私钥解密 plaintext_bytes rsa.decrypt(cipher_bytes, private_key) # 默认使用UTF-8解码 return plaintext_bytes.decode(utf-8) if __name__ __main__: captured_cipher input(请输入抓包得到的密文: ) print(解密结果:, rsa_decrypt(captured_cipher))这里的核心逻辑就是三步Base64解码、RSA解密、字符集还原。实际跑一遍就会发现如果一切顺利输出的就是登录密码明文甚至因为系统内部还用了这同一把私钥去解密其他敏感数据我们后续还能解密更多接口的密文。但这里有一个高概率踩坑的点填充模式。上述代码默认使用PKCS#1 v1.5填充方式。JSEncrypt库的加密默认就是RSA_PKCS1_PADDING所以用上面的脚本能正常解出。如果你遇到的是OAEP填充模式rsa.decrypt会直接报错这时要用支持OAEP的库来处理from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import padding from cryptography.hazmat.backends import default_backend from cryptography.hazmat.primitives import serialization with open(private.pem, rb) as f: private_key serialization.load_pem_private_key(f.read(), passwordNone, backenddefault_backend()) cipher_bytes base64.b64decode(captured_cipher) plaintext_bytes private_key.decrypt( cipher_bytes, padding.OAEP( mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone ) ) print(plaintext_bytes.decode(utf-8))如果你的目标系统用的是OAEP还得确认哈希算法是SHA1还是SHA256用错了也会解不出来。3.5 渗透测试中的合规边界提醒虽然这条利用链复现起来很快但我必须强调测试边界。完整的私钥提取、密文解密操作只应在以下场景中进行获得了目标系统所有者明确的书面授权测试范围包含前端代码审计和认证机制验证在自建靶场或本地模拟环境中进行学习研究作为应急响应中对已知泄露事件的评估。测试过程中提取到的任何敏感数据不能外传、不能留存超过必要时间、不能用于任何未授权的后续访问。这一点是整个利用链分析中最容易被忽视的部分却是从业者必须守住的底线。注意未经授权对任何现实目标执行这套流程属于违法行为。本文所有操作均基于靶场环境或授权测试场景。4. 常见问题与排查技巧实录4.1 问题速查表我整理了一份实际操作中经常遇到的问题速查表按症状、原因、解决方案排好方便你解密脚本跑不动时逐一排查。症状可能原因解决方法OpenSSL无法加载私钥私钥带BOM头、文件编码不对或私钥被密码保护用hexdump检查文件头保存为UTF-8无BOM若加密则用-passin参数解密结果乱码密文不是Base64编码而是Hex尝试bytes.fromhex(cipher)后解密解密抛错“Decryption failed”密文与私钥不匹配或填充模式不对先验证modulus是否一致再尝试切换PKCS1/OAEP模式前端返回的密文带符号密文被URL编码或HTML实体转义先做urllib.parse.unquote或html.unescape还原私钥里有注释文字代码做了字符串截取或拼接把JS表达式完整执行后再提取过滤非PEM内容解密出的明文是十六进制串系统内部可能还对明文做了Hex编码将十六进制字符串转回ASCII即可这张表里面我特别想强调最后两条因为它们都因为细节问题浪费过我不少时间。拼接私钥的情况最坑因为从开发者工具里复制出来的文本看起来像完整的PEM但只要少了一个\nOpenSSL就报错而带Hex编码的情况则是解出了数据但就是不对最后翻源代码才发现原来加密前还多套了一层。4.2 踩过的几个关键格式坑第一个坑换行符丢失。PEM格式的私钥需要标准换行如果从开发者工具里复制出来时换行符被转成了空格或消失了私钥块就变成一个超长单行OpenSSL大概率解析失败。我习惯复制后先执行wc -l private.pem看看有几行标准PEM私钥应该是至少三行头标记、内容体、尾标记。如果只有一行就用编辑器重新排版配合fold -w 64把内容体折成64列一行。第二个坑本地私钥是DER二进制格式。有些导出工具会生成DER格式私钥文件开头不是-----BEGIN而是0x30 0x82的二进制字节。识别这个很简单用文本编辑器打开看到乱码就知道了。处理方式是用OpenSSL转换openssl rsa -inform DER -in private.der -outform PEM -out private.pem第三个坑解密数据里有填充占位符。严格按标准实现的话RSA解密出来的原始数据是编码后的结构不是直接可读的明文。但JSEncrypt这类库在加密时已经把填充处理好了解密出来往往就是完整明文。你要是用了底层库自己做就得处理填充前缀否则会看到明文前面一堆\x00或者随机字节。最稳妥的办法是直接使用成熟密码库的高层API别自己实现RSA原始运算。4.3 排查脚本的一个调试小技巧解密遇到问题的时候不要反复盲试先用OpenSSL做一次标准验证。拿你抓到的密文Base64字符串解码成二进制后执行# 先用base64解码成二进制文件 echo $BASE64_STRING | base64 -d cipher.bin # 用私钥尝试解密 openssl pkeyutl -decrypt -inkey private.pem -in cipher.bin -out plain.txt如果这一步成功说明问题不在私钥和密文而在你自己写的脚本某个环节如果这里也失败那就要检查密钥配对、填充模式、密文格式了。OpenSSL把“底层的可能性”压缩成一次简单验证能帮你快速缩小问题范围省去在Python和JS中间反复横跳的时间。5. 前端密钥安全与修复建议别让私钥再次“裸奔”5.1 前端密钥管理的第一性原则前端做RSA加密时私钥绝不能出现在浏览器端这是第一性原则。很多人会问那登录密码加密到底该怎么设计标准做法是前端保留公钥加密密码后提交服务端持有私钥负责解密和校验。整个过程中前端代码里不需要也不应该出现解密逻辑。如果业务上确实需要在前端解密某些数据说明设计本身出了问题需要把解密逻辑挪到服务端通过网络接口返回解密后的结果。还有一个场景要格外注意有些团队为了安全把私钥放在本地配置文件里然后程序运行时读取。这种做法在服务端是合理的但一旦文件被放到静态目录下通过HTTP直接访问就和写在JS里没区别了。我之前遇到一个案例私钥文件放在/static/config/目录下文件名是rsa_key.pem加上目录没有做访问控制任何人都可以下载。这类问题暴露出的不是加密强度不够而是资产管理和访问控制失效。5.2 加固方案与日常检测思路修复前端私钥泄露问题我建议从下面几个方向同时入手第一服务端集中管控加解密能力。前端只做密钥加载和加密动作解密统一收敛到后端接口。可以用网关层拦截解密或在服务端增加解密接口前端不接触任何私钥相关代码。第二构建产物做最小化检查。CI/CD流程中加入敏感内容扫描对构建后的JS目录做正则匹配发现BEGIN PRIVATE KEY、password 、secret 等特征直接停止发布并告警。这个检查要放在构建产物上而不是源码上因为问题往往出在打包过程。第三SourceMap生产环境关闭。很多系统出问题就是因为SourceMap没关导致源码和注释全部暴露。建议生产环境不发布SourceMap或使用独立鉴权域名挂载不允许匿名访问。第四定期做外部视角检测。以攻击者的方式扫描自己系统的JS文件用一个通用规则集去匹配私钥、Token、API密钥。跑完一版我建议不仅看检测结果也顺手看一眼命中文件的数量和位置如果在无关紧要的地方命中了敏感字面量说明团队在代码规范上还有改进空间。第五密钥定期轮换。如果过去曾经泄露过密钥可以先用工具批量解密历年密文来评估影响范围然后强制所有客户端重新用新公钥加密。服务端兼容新旧密钥解密一段时间后再彻底移除旧密钥避免一次性切换导致大量用户登录失败。5.3 检测到泄露后的应急响应路径一旦发现私钥泄露别只盯着“删掉代码重新发布”这一步。我建议按这个顺序处理立即确认泄露私钥对应的业务范围用OpenSSL比对公钥和接口圈定受影响的系统尝试从日志、历史流量中确认是否存在已发生的未授权解密行为重点看非工作时间的异常请求生成新的密钥对更新服务端配置和前端公钥在服务端增加解密失败率监控因为旧客户端用旧公钥加密的数据在密钥切换后可能产生一批解密失败日志需要用兼容期来平滑过渡最后复盘问题源头是构建配置把开发目录打进了生产包还是某个同学图方便把私钥写在了业务文件里找到根因后把对应代码评审项加到团队规范里。这一步做扎实比单纯“改一个文件”有意义得多因为同类问题往往会以不同的形式反复出现。6. 最后分享一点个人体会这条从JS文件泄露到数据解密的利用链技术上并不复杂难的是从业者有没有“从文件里翻出私钥”的意识和耐心。我见过不少系统在基础设施层面防御做得非常到位防火墙、WAF、主机加固一样不缺但最后被撕开口子的却是前端JS里一行不起眼的配置代码。所以每次做安全评审我都会提醒团队安全设计不仅要把服务端铜墙铁壁也要把前端静态资产当成攻击面来看任何下发到浏览器的东西默认都是可以被攻击者拿到并分析的。整个排查过程跑下来我的切身体会是私钥泄露很少是孤立事件它往往意味着开发流程中存在“临时方案转正”“开发配置带入生产”“测试设备直接映射公网”等更深层的问题。把发现私钥当作信号而非终点顺着代码去找它为什么出现在那里才能从根上减少这一类问题。如果你也想练手强烈建议在自己搭的靶场环境里跑一遍完整的“提取私钥—验证配对—抓取密文—解密还原”流程。跑通一次之后你再看普通站点的前端资源眼睛里会多出一根警惕的弦看代码的位置和方式都会不一样。这条利用链虽然简单但它教给你的东西几乎可以迁移到所有前端敏感信息泄露的风险评估中去。