文章总结： 文章分析了SharePoint漏洞CVE-2025-53771，通过日志分析确定了漏洞入口点在SPRequestModule.BeginRequestHandler，发现了Referer头处理的绕过技术，除了已公开的/_layouts/SignOut.aspx外，还可以使用/_layouts/15/SignOut.aspx来绕过安全检查，这对流量检测和漏洞防护有重要意义。 综合评分： 87 文章分类： 漏洞分析,WEB安全,漏洞预警

浅谈SharePoint漏洞之CVE-2025-53771

原创

MG

不吃猹的瓜

2025年7月25日 19:05 日本

又到了几个月一次的逼逼时刻，最近逐渐回归到漏洞上来了，但因为漏洞这玩意儿写起来真的太费时间了，并且最近也没遇到什么感兴趣的漏洞，所以断更了很长很长很长时间。这两天遇到一个比较有意思的漏洞，所以笔者马上就上号开新坑了！最后反正都会慢慢慢慢慢填完的，笔者慢慢写，大家慢慢看。还是那句话，由于笔者知识水平有限，其中有误的地方也欢迎各位读者留言讨论。

前情提要

前两天笔者看到微软修了Pwn2Own上的SharePoint利用链：ToolShell，当时并没当回事（活该挖不到洞！）。但在补丁日后没多久，微软发了此利用链的绕过通告，直接贴一个官方通告：

Microsoft … SharePoint Server customers by exploiting vulnerabilities partially addressed by the July Security Update. Microsoft has released security updates that fully protect customers using all supported versions of SharePoint affected by CVE-2025-53770 and CVE-2025-53771.

当时各种信息乱飞以及微软奇奇怪怪的通告，以至于看公开信息愣是没看明白这俩漏洞是什么情况，所以直接上DnSpy！在本篇中先讲讲CVE-2025-53771，下一篇再讲CVE-2025-53770。

SharePoint 前置知识

此部分均由大模型生成，不保证百分百正确！

SharePoint 是微软推出的一个基于Web的智能协作与文档管理平台，SharePoint的结构是一个层层嵌套的结构，有三个部分：

Web Application (Web 应用程序)

这是 SharePoint 层次结构中的最高容器，

• 定义：一个 Web 应用程序本质上是在 Windows Server 的 IIS 中创建的一个网站。它有自己唯一的 URL (例如 http://intranet.mycompany.com)、端口号和应用程序池。

• 作用：

• 逻辑边界：它是网站集 (Site Collection) 的逻辑容器。一个 Web 应用程序可以包含数千个网站集

• 安全和认证边界：它定义了用户如何登录

• 数据库关联：每个 Web 应用程序至少关联一个内容数据库 (Content Database)。这个数据库存储了其下所有网站集和网站的内容（如文档、列表项等）。

Site Collection (网站集)

网站集是 Web 应用程序内部的下一级容器，是管理和内容组织的核心单位。

• 定义：一个网站集由一个顶级网站 (Top-Level Site) 以及其下属的所有子网站 (Subsites) 构成。

• 作用：

• 管理边界：网站集有自己独立的管理员、权限体系、功能集和存储配额。例如，网站集回收站、审计日志、功能开关都在这个级别进行管理。

• 内容共享：网站集内的所有网站可以共享导航、品牌外观（母版页）、内容类型、网站栏等资源，便于保持一致性。

• 数据库存储：一个网站集的所有内容必须存储在同一个内容数据库中。

Site (网站 / SPWeb)

网站（在对象模型中称为 SPWeb）是我们进行日常工作的实际场所。

• 定义：网站是网站集内部的一个具体工作空间，用于展示信息和进行协作。网站集中的第一个网站被称为“顶级网站”，在它下面可以创建层级化的“子网站”。

• 作用：

• 协作空间：每个网站都可以包含自己的列表、库、页面和子网站。

• 权限细分：虽然网站继承自网站集的权限，但您可以为每个网站（甚至列表、库、文件夹或单个文件）设置独特的权限，实现更精细的访问控制。

• 功能模板：创建网站时，需要选择一个模板，例如“团队网站 (Team Site)”、“沟通网站 (Communication Site)”或“项目网站 (Project Site)”，这些模板预置了不同的功能和布局来满足特定需求。

以上都是必要的废话，可以帮助我们更好更快的了解产品，知道产品有哪些功能，哪些进程，哪些服务。

漏洞分析

在Exchange系列之二CVE-2021-26855填坑中，提到了在分析超大型Web应用时，面临的第一个难点就是如何确定入口点，在Exchange系列文章中也提到了一种定位入口点的方法。这里就不再赘述，但在这篇中想介绍另一种笔者经常使用偷懒大法：从日志入手。

定位日志的方式有很多，比如说文件搜索，比如说行为监控，这里就不一一列举了，直接给出SharePoint的日志路径：C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\LOGS。日志内容如下：

可以看到SharePoint记录了很多日志，涉及很多进程。但根据漏洞描述，我们可以定位到漏洞发生在w3wp进程中，所以我们只需要关注相关日志即可。

在仔细遍历日志后发现了一个熟悉的老朋友，SPRequestModule.BeginRequestHandler，看过Exchange分析文章的读者都知道，这个函数不就是ASP.NET用于处理请求的入口！继续往下看，可以看到一整条完整的调用链，这里截取部分展示，感兴趣的读者可以自行探究：

SPRequestModule.BeginRequestHandler
 -> SPRequestModule.PostAuthenticateRequestHandler
  -> SPRequestModule.PostAuthorizeRequestHandler
    -> SPRequestModule.PostResolveRequestCacheHandler
     -> ....

SPRequestModule不难猜出是一个继承于IHttpModule的类，IHttpModule 是传统 ASP.NET 框架中的一个核心组件接口。它允许开发人员介入 ASP.NET 的 HTTP 请求处理管道，像一个“过滤器”一样，在请求到达最终处理程序之前或处理完成之后，执行自定义的逻辑。SPRequestModule的逻辑也很清晰：对每一个请求，先鉴权再授权，再做后续的操作。

到此为止，已经大致了解了SharePoint的请求逻辑，那接下来要做的就是要回到漏洞通告，找到可能有问题的地方进行分析，上截图：

说句题外话，微软的漏洞通告写的真随意，笔者没记错的话在最开始的时候，漏洞类型为路径穿越。言归正传，从漏洞挖掘的角度上来看，肯定会先从鉴权逻辑开始进行分析，废话不多说上DnSpy！

遍历函数，发现了一个很可疑的地方：

1. 获取了请求的Referer
2. 对请求和Referer做一系列的判断

具体的判断逻辑不做展开，感兴趣的可以自己分析。这里只说一些公开PoC中没有涉及到的点，做流量检测的读者可以关注一下。在已公开的PoC中Referer都是/_layouts/SignOut.aspx，但通过分析不难看出除了可以使用此Referer之外，还能使用/_layouts/15/SignOut.aspx，具体原因如下图所示：

复现结果：

查看原文：《浅谈SharePoint漏洞之CVE-2025-53771》