从零开始：四个实战案例详解SRC中的信息泄露与未授权访问

对于许多刚接触安全研究的师傅们来说，安全响应中心（SRC） 的漏洞挖掘常常让人感觉无从下手。入门阶段，从一些较为常见且易于理解的中低危漏洞开始实践，是建立信心、积累经验的有效途径。保持耐心，即便暂时没有收获，熟悉大型企业的业务逻辑本身也是一种学习。本文将通过一系列来自真实场景的简单案例，帮助你快速定位并理解那些容易被发现的漏洞。

信息泄露漏洞实战

信息泄露是SRC挖掘中最常见的一类问题，通常由接口设计或权限验证不当导致。以下案例均围绕接口信息泄露展开。

案例一：JS文件泄露内部数据

在登录某个平台后，通过对前端资源的分析，发现一个异步加载的JavaScript文件。对该文件发起请求，其响应内容中直接包含了公司内部人员的敏感信息字段，例如email。

请求示例：

GET /p_...docs.36fa5457.async.js HTTP/2
Host: ...
Cookie: ...

响应片段：

＂OLM＂:function(n,e,t){＂use strict＂;...
＂email＂:＂...(敏感信息)＂

该JS文件作为应用的一部分，本不应包含真实业务数据，此处却泄露了内部邮箱信息。

案例二：API接口暴露员工信息

同样是在一个已登录的平台内，通过分析网络请求，定位到一个审查媒体资源的API接口。该接口在响应中返回了创建者的详细信息，包括用户ID、姓名和邮箱。

请求路径：
GET /api/v1/...o-review/media

响应JSON结构：

{
  "code": "da",
  "mediaId": "",
  "mediaName": "thumb",
  "createUser": {
    "userId": "AI0h",
    "userName": "liu",
    "email": "liu@xxx.com"
  }
}

在另一个类似的接口 GET /api/...review/medias 中，也发现了包含 createUser 对象（含 userId, userName, email 字段）的响应数据，造成了员工信息的泄露。

案例三：数据包直览用户手机号

此案例更为直接。在平台内进行常规操作（如首页搜索）时，无需特意寻找隐藏接口，仅通过抓包分析常规请求的响应，即可看到其他用户的手机号信息。

请求示例：

GET /web/home/search?pageNo=1&pageSize=10&category=&isAi=true HTTP/2
Host: ...
Cookie: ...

响应数据：

{
  "code": 0,
  "data": {
    "list": [
      {
        "id": 480,
        "userId": 12,
        "phoneNumber": "188406..."
      },
      {
        "id": 390,
        "userId": 15,
        "phoneNumber": "1768021..."
      }
    ]
  }
}

案例四：特定功能接口泄露手机号

通过资产测绘或目录扫描，发现两个特定功能的接口 .../logic1 和 .../loaderuser。访问这些接口，会返回包含用户手机号的JSON数据。

对 .../logic1 接口的POST请求与响应：

POST /l/logic1 HTTP/1.1
Host: xxxxxxxx
Content-Type: application/json

{
  "communityPhone": "137xxxx11326",
  "communityIntegralNum": "123456"
}

对 .../loaderuser 接口的POST请求与响应示例：

POST /loaderuser HTTP/1.1
Host: xxx.com
Content-Type: application/json

{
  "communityPhone": "1884 8753",
  "commuter": "xxx"
}

以上信息泄露案例的共同特点是：漏洞点明确（多为API接口），利用过程简单（直接访问或构造简单参数），危害直接（泄露敏感个人信息）。新手在挖掘时，应重点关注应用与后端交互的所有接口，仔细检查其响应数据。

未授权访问漏洞实战

未授权访问是另一类高频漏洞，指无需登录或验证即可访问本应受限的功能或数据。

案例一：项目创建与管理接口未授权

访问一个平台时，发现其某功能模块存在未授权访问。虽然直接访问某些路径（如 .../#/undefined/）可能看似无实际危害，但通过分析页面引用的JS文件，发现了一个疑似创建项目的API端点。

首次尝试调用该创建接口，返回“项目名称不能为空”的错误提示，这反而证实了接口的存在。

GET /project/create HTTP/2
Host: <obscured>.com

HTTP/2 200 OK
Server: nginx
{
  "code": "1002",
  "succ": false,
  "message": "项目名称不能为空"
}

根据接口名create推断其功能，尝试添加name参数，成功创建项目。

GET /project/crea?name=test HTTP/2

HTTP/2 200 OK
Server: nginx
{
  "result": "6ac36cea-f7df-48fd-b885-38addf410ff0",
  "succ": true
}

随后，通过另一个项目列表接口 GET /milestone/projects，可以查看到刚刚创建的项目，确认了未授权创建与查询的完整漏洞链。

{
  "result": {
    "projects": [{
      "name": "test",
      "milestones": [],
      "errors": ["缺少进度信息"]
    }],
    "succ": true
  }
}

案例二：文件下载接口未授权

在某网站，登录界面无注册入口，导致无法进入系统。但通过猜测或信息收集，发现了一系列文件下载接口（如 /xxx/service.doc， /xxx/player.docx， /xxx/manager.docx），无需任何认证即可直接下载合同等内部文件，造成商业信息泄露。

案例三：高危数据批量泄露

此案例危害等级较高，通过两个不同的未授权接口，批量泄露了用户的身份证、手机号、邮箱等核心敏感信息。

• 接口A： GET /api/user/cert/certs
  该接口泄露了个人实名认证信息，包括邮箱、真实姓名和身份证号码。

  {
  "verifier": "zou...ine...com",
  "id": 3297,
  "realName": "Ji...",
  "idCardNum": "342...37618"
  }

• 接口B： GET /api/enterprise/certs
  该接口泄露了企业联系人信息，包括姓名、手机号和邮箱。

  {
  "verifier": "gaom...@g...com",
  "id": "5296...",
  "contactName": "高乱离",
  "contactPhone": "186...875"
  }

这类涉及大量公民个人身份信息（身份证、手机号）的未授权访问，通常可评定为高危漏洞。

案例四：测试环境直接进入后台

该案例最为简单直接。访问某个特定URL（通常为测试或临时环境地址），页面未做任何权限校验，直接跳转至系统管理后台。后台内可能包含测试概览、资源管理、节点配置等敏感功能和数据，构成严重的未授权访问漏洞。

总结与入门建议

对于SRC挖掘新手而言，初期目标不应定得过高。从本文展示的案例可以看出，许多中低危漏洞的挖掘并不依赖高深的技术，而在于细致的观察、耐心的测试和对业务逻辑的理解。核心思路可以归纳为以下几点：

1. 紧盯接口：使用 Burp Suite、浏览器开发者工具 等，记录和分析应用的所有网络请求，重点关注API、/api/、/v1/等路径。
2. 大胆测试：对发现的任何接口，尝试在未登录、无Cookie、无Token的状态下直接访问（未授权测试）。在已登录状态下，尝试修改请求参数，观察是否返回了超出当前权限的数据（越权测试）。
3. 审查数据：仔细检查每一个服务器响应，不仅是JSON，还包括JS、CSS甚至注释，寻找隐藏的敏感信息、调试信息或内部网络地址。
4. 保持心态：挖掘SRC是一个概率游戏。正如原文作者所言：“感觉有危害就提,反正不过也不扣钱。” 每一次提交，无论是否被确认，都是宝贵的经验积累。将每一次测试视为学习企业系统架构和 网络/系统 交互逻辑的机会。

希望这些源自真实环境的简单案例，能为你打开SRC漏洞挖掘的大门，助你收获第一个漏洞报告。

参考资料

[1] 入门SRC简单漏洞案例， 微信公众号：mp.weixin.qq.com/s/fylKHOG1HHSOjBKW507Ecw

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。