1. 项目概述当自动化扫描遇上加密接口在安全测试的日常里我们总会遇到一些“硬骨头”——那些对请求和响应进行加密的接口。它们就像披上了一层密码学的铠甲让传统的自动化扫描工具瞬间“失明”。你让SQLMap直接去跑一个请求体被AES加密、响应是Base64编码的接口它大概率会一脸茫然把加密后的乱码当成普通参数结果自然是无功而返。这正是“BurpsuiteGalaxySQLMap三件套”这套组合拳要解决的核心痛点打通自动化漏洞扫描工具与加密接口之间的壁垒实现高效、准确的渗透测试。这套方案的思路非常清晰它不是一个全新的工具而是一个精巧的流程编排。Burpsuite作为中间人代理和流量操控中心负责拦截和修改原始请求Galaxy插件则扮演“解密/加密引擎”的角色在Burpsuite内部对流量进行实时加解密处理最后处理后的明文流量再被导向SQLMap进行自动化漏洞检测。简单来说就是让专业的工具做专业的事并通过一个“翻译官”Galaxy让它们能互相理解。我之所以花时间折腾这套方案是因为在实际的授权测试和众测项目中遇到使用国密SM4、自定义AES、甚至前后端协商动态密钥的接口越来越普遍手动测试效率低下且容易遗漏必须找到一种可持续的自动化方法。这篇文章就是一份从环境搭建、插件配置、到实战调试和避坑的完整指南。无论你是刚开始接触安全测试的新手还是已经有一定经验但被加密接口困扰的工程师都能从中找到可落地的步骤和解决问题的思路。我们将绕过那些泛泛而谈的理论直接切入实操分享我在多次实战中积累的配置心得和踩过的坑。2. 核心工具链解析与选型考量为什么是Burpsuite、Galaxy和SQLMap这个组合这背后是基于功能互补性和工作流顺畅度的深度考量。市面上并非没有其他方案但这个组合在灵活性、可控性和社区支持上达到了一个很好的平衡。2.1 Burpsuite不可替代的流量枢纽Burpsuite的核心价值在于其强大的中间人代理Proxy和可扩展的插件架构Extender。它能够无缝拦截、查看、修改和重放所有经过它的HTTP/HTTPS流量这为我们操作加密请求提供了最基础的“手术台”。更重要的是它的Intruder模块用于模糊测试Repeater模块用于手动调试Scanner模块用于被动扫描这些功能在与后续自动化工具联动时都能发挥作用。选择Burpsuite而非Fiddler或Charles主要是因为其在Web安全领域的生态更成熟插件体系尤其是支持Java的更为丰富便于集成像Galaxy这样的加解密处理器。2.2 Galaxy插件加解密的桥梁Galaxy是这套方案中的关键“齿轮”。它是一个开源的Burpsuite插件主要功能是对Burpsuite拦截到的请求和响应进行编码/解码、加密/解密、哈希等转换操作。它的强大之处在于支持自定义JavaScript脚本这意味着无论接口使用何种奇葩的加密算法标准AES、RSA或自定义的国密SM2/SM4甚至是一些魔改算法只要你能用JavaScript实现其加解密逻辑就能集成到Galaxy中实现流量的自动化解密和重新加密。注意Galaxy插件本身不提供现成的加密算法。它提供一个执行JavaScript的环境你需要根据目标接口的加密方式自行编写或寻找对应的JS加解密函数。这要求测试者具备一定的逆向分析能力能从前端代码或APP逆向中提取出加密逻辑。2.3 SQLMap自动化注入检测的利刃SQLMap是自动化SQL注入检测的标杆工具。它的强大在于庞大的检测载荷payload库、智能的布尔盲注和时间盲注检测机制、以及数据提取能力。我们这套方案的核心目的就是将经过Galaxy解密后的、明文的HTTP请求交给SQLMap去进行深度检测。SQLMap会像处理普通接口一样对参数进行篡改、探测从而发现潜在的SQL注入漏洞。工具链工作流程总结流量捕获浏览器/APP配置代理指向Burpsuite。请求拦截Burpsuite拦截到发送给目标加密接口的请求请求体为密文。Galaxy解密通过配置好的Galaxy规则自动调用JS脚本将请求体解密为明文。人工审核/修改在Burpsuite的Proxy或Repeater中你可以看到解密后的明文并可进行手动修改。导向SQLMap将解密后的完整HTTP请求包括Headers、Cookies保存为文件或通过Burpsuite的“Send to Intruder”等功能配合--proxy参数让SQLMap直接使用Burpsuite作为代理从而让SQLMap接收到的是明文流量。SQLMap扫描SQLMap对明文参数进行注入测试。响应加密可选如果响应也是加密的同样可以配置Galaxy对响应进行解密以便Burpsuite或SQLMap能正确解析检测结果。3. 环境准备与核心配置实战理论清晰后我们进入实战配置环节。这里每一步都至关重要配置不当会导致整个流程无法跑通。3.1 Burpsuite与Galaxy插件安装首先确保你已安装Java环境JRE 8或11兼容性较好。从Burpsuite官网下载专业版或社区版。社区版功能有限但对于理解本流程足够。专业版功能更全建议支持正版。Galaxy插件的安装步骤如下从GitHub仓库下载Galaxy的Jar文件如galaxy.jar。打开Burpsuite进入Extender标签页 -Extensions-Add。在“Extension type”下拉菜单中选择Java。点击“Select file...”按钮选择你下载的galaxy.jar文件。点击“Next”Burpsuite会加载插件。加载成功后在Extender的“Loaded”列表中会看到“Galaxy”且其状态为“Enabled”。安装成功后你会在Burpsuite顶部菜单栏看到一个新的“Galaxy”菜单项。3.2 编写你的第一个加解密脚本这是最具挑战也最核心的一步。你需要分析目标应用的加密逻辑。常见的方法有浏览器开发者工具查看前端JavaScript文件搜索encrypt、AES、CryptoJS等关键词。APP逆向使用Jadx、Frida等工具分析移动端APP的加密方法。网络抓包对比捕获多个请求观察相同参数在不同请求中密文的变化推测加密模式和密钥。假设我们分析出目标接口使用AES-128-CBC模式加密密钥key为1234567890123456初始向量iv为abcdefghijklmnop填充方式为PKCS7。我们需要为Galaxy编写一个解密脚本。在Burpsuite中点击Galaxy - Config打开配置界面。这里我们可以定义多个“Processor”处理器。点击“Add”新建一个。NameAES_Decrypt_Request清晰命名便于管理Type根据处理位置选择。如果只处理请求选Request只处理响应选Response两者都处理选Both。这里我们先选Request。Execute选择JavaScript。Engine默认的Nashorn即可。在下方巨大的代码框中编写我们的JS解密函数。这里需要一个关键的JS加密库比如CryptoJS。Galaxy内置了不它没有内置。我们需要手动引入。通常的做法是将CryptoJS的完整源码一个很大的js文件复制粘贴到Galaxy脚本的开头部分。你可以从CryptoJS的GitHub仓库找到crypto-js.js文件。以下是一个高度简化的示例脚本框架// 1. 引入CryptoJS (此处需粘贴完整的CryptoJS库代码篇幅过长以下用伪代码表示) // ... [完整的CryptoJS库代码] ... // 2. 定义解密函数 function decryptAES(ciphertextBase64) { var key CryptoJS.enc.Utf8.parse(1234567890123456); // 密钥转为WordArray var iv CryptoJS.enc.Utf8.parse(abcdefghijklmnop); // 初始向量 // 假设密文是Base64编码的 var encrypted CryptoJS.enc.Base64.parse(ciphertextBase64); // AES解密CBC模式PKCS7填充 var decrypted CryptoJS.AES.decrypt( { ciphertext: encrypted }, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 } ); // 将解密结果转为UTF-8字符串 return decrypted.toString(CryptoJS.enc.Utf8); } // 3. Galaxy处理器主函数 function process(utils, message) { // utils提供了工具方法message是HTTP消息对象 var request message.getRequest(); // 获取请求字节数组 var requestInfo utils.analyzeRequest(request); // 分析请求 var bodyOffset requestInfo.getBodyOffset(); // 请求体起始位置 var requestBody utils.bytesToString(request.slice(bodyOffset)); // 提取请求体字符串 // 假设请求体就是直接的Base64密文 try { var decryptedBody decryptAES(requestBody); // 用解密后的明文替换原请求体 var newRequest utils.buildRequest( utils.bytesToString(request.slice(0, bodyOffset)) decryptedBody ); message.setRequest(newRequest); } catch(e) { // 解密失败处理可以打印日志 utils.out(解密失败: e.message); } }实操心得在实际操作中请求体往往不是单纯的密文可能是JSON格式其中某个字段如data或encryptedData的值才是密文。你的脚本需要先解析JSON提取特定字段解密然后再将解密后的内容可能也是一个JSON字符串写回该字段最后重组整个请求体。这需要更精细的字符串处理。配置完成后记得勾选该Processor的“Enabled”复选框。现在当你通过Burpsuite代理发送一个加密请求时在Proxy的“Intercept”标签页或“HTTP history”中看到的请求体应该已经是解密后的明文了。3.3 配置SQLMap与Burpsuite联动让SQLMap扫描解密后的流量主要有两种方式方式一保存请求文件后扫描这是最直接的方法。在Burpsuite的Proxy历史记录或Repeater中找到一条解密后的完整请求明文状态。右键点击选择“Copy to file”将其保存为一个文本文件例如request.txt。这个文件包含了完整的HTTP请求头和方法、路径、参数。然后使用SQLMap的-r参数指定该文件进行扫描sqlmap -r request.txt --batch --level 3 --risk 2--batch表示非交互模式自动选择默认选项。--level和--risk提高检测强度和深度。方式二通过Burpsuite代理实时扫描这种方式更自动化适合对多个接口或参数进行测试。首先在Burpsuite的Proxy - Options中确保代理监听器通常为127.0.0.1:8080是运行的。然后让SQLMap通过Burpsuite的代理发送请求。你需要先配置Galaxy对响应也进行解密如果响应加密因为SQLMap需要解析响应来判断注入是否成功。创建一个新的Galaxy ProcessorType选择Response编写对应的响应解密脚本。最后运行SQLMap时指定代理sqlmap -u http://target.com/api/encrypted_endpoint --dataid1 --proxyhttp://127.0.0.1:8080 --batch这里-u和--data的参数看起来是明文的但实际上当请求经过Burpsuite代理时会被Galaxy先加密你需要另一个Request类型的Processor来做加密然后再发送给服务器。服务器的加密响应回来再被Galaxy解密最后返回给SQLMap。这就要求你配置一对Galaxy Processor一个用于请求加密一个用于响应解密。重要提示方式二对Galaxy脚本的健壮性要求极高。加密/解密过程必须完全可逆任何差错都会导致请求格式错误或SQLMap无法识别响应。建议先从方式一开始确保单个请求的解密和扫描成功再尝试方式二。4. 实战中的复杂场景与深度避坑指南掌握了基础流程但在真实战场上会遇到各种复杂情况。下面是我总结的几个典型场景和对应的解决方案。4.1 场景一动态密钥与签名机制很多安全的接口不仅加密还会加入时间戳、随机数nonce和签名signature。例如请求体加密后还会在URL或Header中附带一个签名签名算法可能是MD5(加密体密钥时间戳)。服务器端会验证签名是否匹配且时间戳在有效期内。挑战SQLMap在自动化测试时会频繁修改参数值注入payload这会导致加密体内容变化。如果我们只静态地解密请求修改明文后再用固定的密钥加密回去但签名没有随之重新计算那么服务器会因签名验证失败而拒绝请求。解决方案在Galaxy脚本中集成签名计算。你的JavaScript脚本需要做两件事一是解密请求体二是在你修改了明文参数后重新加密时动态计算新的签名。这意味着你的脚本需要能获取到时间戳、并按照同样的算法生成签名然后更新请求中的签名字段。使用Burpsuite的Macro宏配合Session Handling Rules。这是一个更高级但更自动化的方法。首先在Burpsuite的Project options - Sessions中创建一个宏Macro这个宏能模拟完成一次完整的登录或获取动态密钥的请求并从响应中提取出密钥、令牌等信息。然后创建一条会话处理规则Session Handling Rule在每次SQLMap通过代理发送请求前都先执行这个宏来更新当前会话的密钥和签名信息。最后在Galaxy脚本中不再使用硬编码的密钥而是从Burpsuite的会话上下文中读取这些动态值。这套组合拳能较好地处理带会话状态的加密接口。4.2 场景二非标准加密或国密算法你可能遇到国密SM2/SM4算法或者前端进行了自定义的魔改例如多次加密、异或等。挑战CryptoJS等常见库不直接支持国密算法。魔改算法更无现成库可用。解决方案寻找JS实现在GitHub等平台搜索“sm-crypto”、“sm4 js”等关键词通常能找到国密算法的纯JavaScript实现。将这些实现的JS代码整合到你的Galaxy脚本中。逆向移植如果只有Java或Python的实现你需要将其逻辑“翻译”成JavaScript。这需要对算法本身和两种语言都有一定理解。使用Jython插件如果算法逻辑极其复杂用JS重写困难可以考虑使用Burpsuite的Jython插件。你可以用Python编写加解密函数利用现有的gmssl等库然后通过Jython插件在Burpsuite中调用。Galaxy本身也支持Jython引擎。但这会引入Python环境依赖增加复杂度。4.3 场景三SQLMap误报与性能优化当接口响应被加密后即使解密其内容结构也可能比较特殊如统一的JSON包装{“code”: 200, “data”: “...”}这可能会干扰SQLMap的布尔判断逻辑导致误报或漏报。挑战SQLMap通过对比真假条件如id1和id1’ and ‘1’’2下响应内容的差异来判断注入点。如果解密后的响应总是包含大量固定模板文本差异不明显SQLMap可能无法识别。解决方案使用--string或--not-string参数告诉SQLMap在响应中寻找一个始终存在或始终不存在于成功响应中的字符串。例如如果正常解密后的响应总包含status:success可以添加--stringstatus\:\success。这能极大提高检测准确率。使用--tamper脚本如果加密算法要求参数格式固定如长度需为16的倍数SQLMap的payload可能会破坏这种格式导致请求被服务器直接拒绝。你可以编写一个tamper脚本在payload被发出前先对其进行处理如补位然后再交给Galaxy加密。不过更常见的做法是确保Galaxy的加密脚本足够健壮能处理各种长度的输入。控制扫描速度与目标对加密接口的扫描会比普通接口慢因为每个请求都多了加解密开销。使用--threads参数控制并发数建议调低如--threads2并使用-p参数明确指定需要测试的参数避免盲目全参数扫描节省时间。5. 调试技巧与常见问题排查实录即使按照指南操作你也可能会遇到各种问题。下面是一个快速排查清单基于我踩过的坑整理而成。问题现象可能原因排查步骤与解决方案Galaxy插件加载失败Jar文件不兼容、Java版本问题、依赖缺失1. 检查Burpsuite和Java版本。尝试使用Java 8。2. 从官方GitHub releases页面下载最新稳定版Jar。3. 在Extender的“Errors”标签页查看具体错误信息。请求解密后乱码或报错1. 加解密算法/模式/填充不匹配。2. 密钥或IV错误。3. 请求体格式判断错误非纯密文。1.核对算法细节用已知的明文-密文对验证你的JS解密函数。单独写一个HTML页面测试你的CryptoJS代码。2.检查编码确保密钥、IV、密文的编码UTF-8, Hex, Base64与前端完全一致。3.日志调试在Galaxy脚本中使用utils.out()打印中间变量如原始请求体、解密后的Buffer等观察每一步的结果。SQLMap扫描无结果No injection1. 请求未成功到达SQLMap代理设置错误。2. 响应未被正确解密SQLMap无法解析。3. 目标参数确实不存在注入点。1.验证代理链路先用浏览器配置Burpsuite代理访问一个http网站看流量是否能正常拦截。再用curl -x http://127.0.0.1:8080 http://example.com测试代理是否通畅。2.检查响应解密在Burpsuite中手动重放一个请求查看Raw或Hex视图确认Galaxy解密后的响应是明文HTML/JSON。确保响应解密Processor已启用且正确。3.提高检测等级尝试增加--level和--risk值并使用--techniqueBEUSTQ指定所有检测技术。服务器返回签名错误或令牌过期1. 动态签名未更新。2. 时间戳过期。3. 会话Cookie/Token失效。1.启用Session Handling如4.1所述配置宏和会话规则来自动更新令牌和签名。2.检查时间戳同步确保你的脚本生成的时间戳与服务器时间同步考虑时区。可以使用从服务器响应中获取的时间来校准。3.手动更新会话先手动在浏览器中完成一次登录或令牌刷新操作获取新的Cookie/Token再在Burpsuite的Proxy - HTTP history中找到该请求右键“Send to Repeater”或“Copy to file”给SQLMap使用。扫描过程极其缓慢每个请求都经历完整的加解密和签名计算。1.优化脚本检查JS脚本是否有低效循环或操作。尽量使用原生方法。2.限制扫描范围使用-p指定少数关键参数使用--skip跳过静态参数如token。3.调整SQLMap参数降低--threads增加--delay减少对服务器的压力也避免因请求过快导致的封禁。一个关键的调试习惯永远不要黑盒操作。在将请求交给SQLMap之前务必在Burpsuite的Repeater模块中手动测试你的Galaxy加解密流程。发送一个原始加密请求观察解密后的明文是否正确修改一个参数再观察重新加密后的请求用“Send”按钮手动发送看服务器是否返回正常响应。只有手动流程完全走通自动化流程才有可能成功。这套“BurpsuiteGalaxySQLMap”的组合其精髓不在于工具本身而在于将加密接口的加解密逻辑通过可编程的脚本Galaxy固化下来并嵌入到自动化测试流程中。它要求测试者不仅会使用工具更要理解目标应用的安全通信机制。一旦这套管道搭建完成你就能像扫描普通接口一样对加密接口进行持续、批量的安全检测将重复劳动自动化从而将精力聚焦在更复杂的逻辑漏洞和业务漏洞挖掘上。这个过程充满挑战但每成功破解一个加密接口的自动化扫描你对Web安全整体流程的理解就会加深一层。