手把手教你检测和防御Apache Solr SSRF漏洞（CVE-2021-27905）

从原理到实战：深度剖析Apache Solr SSRF漏洞的检测与立体防御

最近在帮一家电商平台做安全审计时，他们的搜索服务引起了我的注意。这套基于Apache Solr构建的商品检索系统，处理着每天数百万次的查询请求，是业务的核心组件之一。在常规的端口扫描和配置检查后，一个历史漏洞的线索让我警觉起来——CVE-2021-27905，一个影响几乎所有Solr版本的SSRF漏洞。更让人不安的是，官方至今没有发布修复版本，这意味着无数仍在运行的Solr实例可能暴露在风险之下。

这不是一个简单的配置错误，而是深植于Solr数据处理机制中的设计缺陷。攻击者能够利用这个漏洞，从内部网络探测到敏感文件读取，甚至可能作为跳板发起更复杂的攻击。对于企业安全团队来说，理解这个漏洞的运作原理，掌握有效的检测方法，并构建多层次的防御体系，已经成为保护搜索服务安全的必修课。本文将带你深入这个漏洞的技术细节，分享我在实际环境中验证过的检测脚本，并提供一套可立即落地的加固方案。

1. 漏洞本质：为什么Solr的SSRF如此特殊？

要理解CVE-2021-27905，我们首先需要抛开对SSRF（服务器端请求伪造）的常规认知。大多数SSRF漏洞源于应用程序对外部URL的过度信任，但Solr的情况完全不同——它源于一个特意设计的功能特性被滥用。

1.1 核心机制：Streaming API的双刃剑

Solr的Streaming API原本是为了增强数据处理的灵活性而设计的。想象一下这样的场景：你的搜索服务需要从多个外部数据源实时聚合信息，可能是内部API、云存储服务，或者其他微服务。Streaming API允许Solr直接读取这些远程资源，将其作为索引或查询的一部分。

问题的关键在于requestDispatcher.requestParsers.enableRemoteStreaming这个配置开关。当它被开启时，Solr会接受并处理stream.url参数指定的任意URL。从设计上看，这为数据集成提供了便利；但从安全角度看，它打开了一扇危险的大门。

{
  "set-property": {
    "requestDispatcher.requestParsers.enableRemoteStreaming": true
  }
}

上面的JSON正是开启这个“潘多拉魔盒”的指令。一旦执行，Solr就会开始信任客户端提供的URL参数。

1.2 攻击链的完整拼图

一个完整的攻击通常包含三个关键步骤：

1. 信息收集阶段：攻击者首先需要了解目标Solr实例的结构。通过访问/solr/admin/cores端点，可以获取所有可用的Core名称——这是后续攻击的“目标清单”。

2. 权限提升阶段：利用Config API修改核心配置。这里有个微妙之处：默认情况下，远程流处理是关闭的。攻击者需要先通过API调用将其开启，而这个操作通常不需要特殊权限。

3. 利用执行阶段：在远程流处理启用后，攻击者可以通过stream.url参数指定任意协议的资源。不仅仅是HTTP/HTTPS，还包括file://、gopher://、dict://等协议，这使得攻击面大大扩展。

注意：很多企业误以为“内网服务”就是安全的，但SSRF漏洞恰恰能够绕过网络边界限制。攻击者可以利用Solr作为代理，访问那些原本无法从外网直接到达的内部系统。

1.3 影响范围的严峻现实

这个漏洞最令人担忧的特点是其广泛的影响范围：

• 版本全覆盖：从早期版本到8.8.1，所有Apache Solr版本均受影响
• 无官方补丁：Apache官方将其标记为“设计特性”而非漏洞，拒绝提供修复
• 默认配置风险：虽然远程流处理默认关闭，但许多生产环境为了集成需求会主动开启
• 权限要求低：大多数情况下，攻击者不需要认证即可完成攻击链

下表对比了Solr SSRF与传统SSRF的主要差异：

2. 实战检测：从手动验证到自动化扫描

检测Solr SSRF漏洞不能仅仅依赖漏洞扫描器的通用规则。在我的经验中，许多商业扫描器对这个漏洞的检测要么过于保守（漏报），要么过于激进（误报）。最好的方法是结合手动验证和定制化脚本。

2.1 手动验证的四步法

当你怀疑某个Solr实例可能存在漏洞时，可以按照以下步骤进行手动验证：

第一步：服务发现与指纹识别

首先确认目标确实是Apache Solr。除了常见的端口（如8983、3333），还可以通过以下特征识别：

# 使用curl获取Solr基本信息
curl -s "http://target:8983/solr/" | grep -i "solr\|apache"

# 检查管理界面是否可访问
curl -I "http://target:8983/solr/admin/cores"

如果返回包含Apache Solr或solr关键词，且能正常访问管理端点，基本可以确认目标。

第二步：核心信息枚举

获取可用的Core列表是攻击的前提，也是检测的重要环节：

http://target:8983/solr/admin/cores?indexInfo=false&wt=json

这个请求会返回JSON格式的响应，其中包含所有配置的Core名称。记下这些名称，它们将是后续测试的目标。

第三步：配置状态检查

对于每个发现的Core，检查其当前配置状态：

# 检查特定Core的配置
curl "http://target:8983/solr/[core_name]/config"

在返回的配置信息中，搜索requestDispatcher.requestParsers.enableRemoteStreaming字段。如果值为true，说明该Core已经处于风险状态。

第四步：安全验证测试

这里需要特别注意：永远不要在生产环境直接测试漏洞利用。正确的做法是使用无害的验证方法：

# 使用本地回环地址测试，避免对外部系统造成影响
curl "http://target:8983/solr/[core_name]/debug/dump?param=ContentStreams" \
  -F "stream.url=http://127.0.0.1:8983/solr/admin/info/system"

如果返回了系统信息，说明远程流处理功能已启用且正常工作。此时应立即记录并进入修复流程。

2.2 自动化检测脚本开发

对于拥有大量Solr实例的企业，手动检测显然不现实。我开发了一个Python检测脚本，它平衡了检测效率和安全性：

#!/usr/bin/env python3
"""
Solr SSRF安全检测脚本
设计原则：只检测，不利用，避免对目标系统造成影响
"""

import requests
import json
import sys
from urllib.parse import urljoin

class SolrSSRFDetector:
    def __init__(self, base_url):
        self.base_url = base_url.rstrip('/')
        self.session = requests.Session()
        self.session.headers.update({
            'User-Agent': 'Mozilla/5.0 (安全扫描)',
            'Accept': 'application/json'
        })
        
    def check_solr_instance(self):
        """验证目标是否为Solr实例"""
        try:
            response = self.session.get(
                urljoin(self.base_url, '/solr/'),
                timeout=10
            )
            return 'solr' in response.text.lower()
        except:
            return False
    
    def enumerate_cores(self):
        """枚举所有可用的Core"""
        cores = []
        try:
            url = urljoin(self.base_url, '/solr/admin/cores')
            params = {'indexInfo': 'false', 'wt': 'json'}
            response = self.session.get(url, params=params, timeout=10)
            
            if response.status_code == 200:
                data = response.json()