网站漏洞防护之服务端请求伪造SSRF的端口黑白名单

SSRF（服务端请求伪造）的核心风险在于攻击者能够控制服务器发起请求的目标地址。端口黑白名单机制，就是在服务器发出请求前设置的最后一道安检关卡。它不关心你请求的是什么域名，只盯着你要访问的端口号。如果端口不在白名单里，或者命中了黑名单，请求就会被直接拦截，根本发不出去。这是一种简单粗暴但极其有效的纵深防御手段。

为什么单纯限制域名还不够

很多开发者认为，只要把请求目标限制在特定的域名白名单里就万事大吉了。这种想法存在严重的安全盲区。攻击者可以通过DNS重绑定攻击，让一个合法的域名在通过验证后解析到内网IP。更常见的情况是，企业内部的服务本身就运行在合法域名指向的服务器上，只是监听了不同的端口。比如，你的Web应用只允许请求api.company.com，但这个域名对应的服务器上可能同时运行着Redis（6379端口）、MySQL（3306端口）或者未授权访问的管理后台（8080端口）。如果不对端口进行限制，攻击者就能通过SSRF漏洞直接探测和攻击这些本不该暴露的内部服务。端口黑白名单，就是为了堵住这个口子。

端口黑名单策略：默认放行，重点封堵

黑名单策略的逻辑是，除了明确列出的危险端口外，其他所有端口的请求都允许放行。这是一种相对宽松的配置方式，主要目标是快速阻断针对常见高危服务的攻击。实施黑名单时，必须覆盖那些能够产生直接危害的端口。典型的黑名单端口包括：

数据库与缓存服务端口：如MySQL的3306、Redis的6379、MongoDB的27017、PostgreSQL的5432、Memcached的11211。这些服务如果没有设置密码或使用弱密码，通过SSRF可以执行数据窃取、篡改甚至服务器命令执行。

敏感的内部服务端口：如Solr的8983、Elasticsearch的9200和9300、Hadoop的50070和50075、Docker守护进程的2375和2376。这些服务往往承载着大量内部数据，且管理接口可能存在未授权访问漏洞。

常见的Web管理端口：如Tomcat的8080、JBoss的8080和9990、WebLogic的7001和7002。这些管理后台一旦被访问，可能通过弱口令或漏洞直接获取服务器权限。

邮件服务端口：如SMTP的25、465、587。攻击者可以利用SSRF漏洞，以内网服务器的身份发送垃圾邮件或钓鱼邮件，难以追踪。

其他高危端口：如FTP的21、SSH的22、Telnet的23。虽然直接利用这些端口进行复杂交互有一定难度，但可以用于端口探测、服务版本识别，甚至在某些条件下进行暴力破解。

黑名单的维护是一个持续对抗的过程。攻击者会不断发掘新的可利用服务端口，你的黑名单列表也需要随之更新。它的最大缺陷在于，无法防御针对未知端口或非常规端口部署的服务。只要有一个危险端口没被列入黑名单，防护就会出现缺口。

端口白名单策略：默认拒绝，最小权限

白名单策略是更严格、更推荐的安全实践。它的逻辑是，只允许请求访问明确许可的端口，其他所有端口的请求一律拒绝。这完全符合最小权限原则，将攻击面压缩到了极致。在配置白名单时，你需要精确梳理业务需求。一个典型的Web应用，其服务端请求通常只需要访问外部的HTTP和HTTPS服务。因此，最基础的白名单只包含80和443端口。

如果业务需要调用特定的第三方API，而这个API部署在非标准端口上，比如8443，那么就把8443加入白名单。如果有从特定文件服务器拉取资源的需求，且文件服务器只开启了21端口，那就只加21端口。白名单的配置过程，本质上是一次对业务请求目标的彻底盘点和收敛。任何新业务上线，如果需要请求新的端口，都必须经过安全评估并更新白名单。这种方式能有效防御所有已知和未知的端口攻击，包括那些利用非标准端口部署的恶意服务。它的挑战在于，初期配置可能因为业务梳理不清而导致正常功能受阻，需要更精细的运维管理。

实战中的精细化配置：协议与地址的结合

在实际的代码实现中，端口黑白名单不应孤立存在，需要与协议和地址解析结果紧密结合。一个完整的防护逻辑应该是分步骤的：

第一步，解析用户输入的URL，提取出协议（Scheme）、主机名（Host）和端口（Port）。

第二步，进行DNS解析，将主机名解析为具体的IP地址。这一步至关重要，因为攻击者可能直接提供IP地址形式的URL，绕过域名检查。

第三步，检查解析出的IP地址是否为内网地址。如果是，且业务不需要访问内网，则直接阻断。这是防止攻击者直接攻击内网的第一道防线。

第四步，根据解析出的IP地址和提取出的端口，执行端口策略检查。如果配置的是白名单，判断端口是否在允许列表中；如果是黑名单，判断端口是否在禁止列表中。如果命中阻断规则，则终止请求。

第五步，所有检查通过后，才能发起真正的网络请求。

在代码实现上，需要特别注意对IP地址格式的规范化处理。攻击者可能会使用各种技巧来绕过字符串匹配的检查，例如使用短地址IP表示法（如127.1代表127.0.0.1）、八进制或十六进制IP表示法、或者在URL中添加额外的认证信息（如http://username:password@host:port）。一个健壮的实现，应该使用系统内置的、经过充分测试的URL解析和IP地址解析库来完成这些工作，而不是自己编写脆弱的正则表达式。

代码实现示例：一个健壮的校验函数

下面是一个用Python实现的示例，展示了如何结合IP检查和端口白名单来构建一个相对健壮的SSRF防护函数。这个函数的核心思想是：先解析URL，再解析IP，最后检查IP范围和端口。

import socket
from urllib.parse import urlparse
import ipaddress

# 定义允许访问的端口白名单
ALLOWED_PORTS = {80, 443, 8080, 8443}

# 定义内网IP段
PRIVATE_NETWORKS = [
    ipaddress.ip_network('10.0.0.0/8'),
    ipaddress.ip_network('172.16.0.0/12'),
    ipaddress.ip_network('192.168.0.0/16'),
    ipaddress.ip_network('127.0.0.0/8'),
    ipaddress.ip_network('169.254.0.0/16'),
]

def is_safe_url(target_url):
    try:
        # 1. 解析URL，提取协议、主机名和端口
        parsed_url = urlparse(target_url)
        hostname = parsed_url.hostname
        scheme = parsed_url.scheme.lower()
        
        # 只允许HTTP和HTTPS协议
        if scheme not in ('http', 'https'):
            return False, "不支持的协议"

        # 如果没有指定端口，根据协议设置默认端口
        port = parsed_url.port
        if port is None:
            port = 443 if scheme == 'https' else 80

        # 2. 解析域名为IP地址。这里使用socket.gethostbyname，它会返回一个IP字符串。
        # 注意：这只会返回一个IP，如果域名绑定了多个IP，实际请求可能连接到其他IP。
        # 更严谨的做法是使用socket.getaddrinfo并遍历所有结果进行检查。
        resolved_ip = socket.gethostbyname(hostname)
        ip_addr = ipaddress.ip_address(resolved_ip)

        # 3. 检查IP地址是否为内网地址
        for network in PRIVATE_NETWORKS:
            if ip_addr in network:
                return False, f"禁止访问内网地址: {resolved_ip}"

        # 4. 检查端口是否在白名单中
        if port not in ALLOWED_PORTS:
            return False, f"端口 {port} 不在允许的白名单中"

        # 所有检查通过
        return True, "URL安全"

    except socket.gaierror:
        return False, "域名解析失败"
    except ValueError as e:
        return False, f"IP地址解析错误: {e}"
    except Exception as e:
        return False, f"URL安全检查发生未知错误: {e}"

# 使用示例
test_urls = [
    "https://www.example.com",        # 安全
    "http://192.168.1.1:8080",        # 内网地址，不安全
    "http://example.com:3306",        # 数据库端口，不安全
    "ftp://ftp.example.com",          # 不支持协议，不安全
    "http://example.com:8443/api",    # 安全，如果8443在业务白名单中
]

for url in test_urls:
    safe, msg = is_safe_url(url)
    print(f"URL: {url:<40} 安全: {safe:<5} 原因: {msg}")

这个示例代码清晰地展示了分层防御的思路。它不是一个可以直接复制粘贴到生产环境的最终方案，而是一个展示了核心逻辑的框架。在生产环境中，你还需要考虑异步请求、连接超时设置、禁用不必要的请求方法（如GET之外的POST、PUT等）、以及处理302重定向带来的二次请求风险。特别是重定向，攻击者可以先提供一个合法的外部URL，然后通过302重定向将请求引导至内网地址。因此，必须禁用自动重定向跟随，或者在每次重定向后都重新执行完整的安全检查流程。

绕过技术与防御的持续对抗

攻击者绕过的技术一直在演进，防御策略也需要不断升级。除了上面提到的IP地址格式混淆和DNS重绑定，还有一些高级手法需要警惕。例如，利用IPV6地址绕过IPV4的内网检查。如果你的服务只检查了IPV4的内网地址，攻击者就可以使用IPV6格式的内网地址（如::1代表本地回环地址）来绕过。因此，在检查内网地址时，必须同时覆盖IPV4和IPV6。

另一个高级威胁是“DNS Rebinding”的变种，攻击者可以控制DNS服务器，使其在第一次解析时返回一个合法的外网IP，通过你的IP检查，然后在极短的时间内，第二次解析返回内网IP，而你的HTTP客户端库恰好使用了这第二次解析的结果去建立连接。防御这种攻击，最有效的方法是在DNS解析后、建立TCP连接前，再次对最终连接的IP地址进行一次检查和确认。一些语言的安全库已经提供了这类功能，可以绑定在连接建立的回调函数上。

端口黑白名单机制是SSRF防御体系中不可或缺的一环，但它绝不能单独作战。它必须与协议限制、域名白名单、内网IP隔离、禁用危险协议（如file://、gopher://）、以及及时的依赖库更新等措施结合起来，形成一个纵深、立体的防御网络。没有银弹，只有不断加深的护城河。