《白帽子讲 Web 安全》之服务端请求伪造（SSRF）深度剖析：从攻击到防御

引言

在当今复杂的网络环境中，Web 应用安全犹如一座时刻需要精心守护的堡垒。随着技术的不断演进，各类安全威胁层出不穷，其中服务端请求伪造（SSRF）正逐渐成为令开发者与安全从业者头疼的一大难题。吴翰清在《白帽子讲 Web 安全》中对 SSRF 进行了深入探讨，接下来让我们详细梳理这一安全隐患的相关知识。

SSRF 攻击简介

定义

服务端请求伪造（Server Side Request Forgery，SSRF）本质上是一种严重的 Web 应用漏洞。攻击者通过精心构造特定的参数值，诱使 Web 应用将外部输入参数当作 URL 来处理，进而驱使服务端去访问那些服务器程序原本预期之外的 URL。这些输入参数形式多样，既可以是不完整的 URL，也能是单纯的域名、IP 地址或者端口值等。

示例

以提供翻译服务的网站为例，正常情况下用户提交网页 URL 供网站进行翻译操作。但倘若该网站存在 SSRF 漏洞，攻击者便有机可乘。他们提交恶意 URL，网站服务器在毫无察觉的情况下，按照指令访问该恶意 URL，甚至可能因此访问到内网资源，导致敏感信息泄露等严重后果。比如攻击者提交 “http://192.168.1.100/internal_secret_file”，若服务器未做有效防范，就会尝试访问内网 IP 对应的敏感文件。

SSRF 漏洞成因

1.用户输入处理不当

许多 Web 应用在处理用户输入时过于草率。当使用用户输入来构造 HTTP 请求的 URL 时，却没有进行全面且严格的验证与过滤。像是未仔细检查 URL 所采用的协议是否合法，是常见的 HTTP/HTTPS，还是潜藏风险的 file、gopher 等协议；对域名的合法性以及端口值是否处于合理范围也未加以核实。以 Python 的 Flask 框架为例，如果代码编写如下：

from flask import Flask, request

app = Flask(__name__)

@app.route('/fetch')
def fetch():
    url = request.args.get('url')
    # 这里没有对url进行任何验证就直接使用
    response = requests.get(url)
    return response.text

如此一来，用户输入的任何 URL 都可能被服务器访问，极大地增加了 SSRF 风险。

2.使用未经验证的第三方库或框架

在开发过程中，不少开发者依赖各种第三方库或框架来加快开发进度。然而，部分未经充分安全验证的库或框架，在处理 URL 请求环节存在安全漏洞，极易被攻击者利用。例如某些老旧版本的 HTTP 请求库，在处理 URL 重定向等操作时，没有对目标 URL 进行严格检查，攻击者可借此构造恶意请求，突破应用的安全防线。

3.缺乏安全配置

服务器自身的配置若存在缺陷，同样会为 SSRF 攻击敞开大门。比如服务器未对可访问的 URL 范围做出明确限制，或者未严格检查请求来源，使得攻击者能够轻易绕过安全限制。以 Nginx 服务器为例，如果配置文件中没有设置合理的访问控制规则，像以下错误配置：