分析 `wp_remote_post()` 函数的源码，它是如何处理 `$_SERVER[‘HTTP_REFERER’]` 以防止未经授权的请求的？ - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众，晚上好！我是今晚的讲师，很高兴能和大家一起探讨 WordPress 中 wp_remote_post() 这个函数的安全机制，特别是它如何对待那个神秘的 $_SERVER['HTTP_REFERER']。准备好了吗？让我们开始今天的 "WordPress 安全夜话"！

开场白：Referer 的爱恨情仇

在 Web 开发的世界里，HTTP_REFERER 就像一个八卦的邻居，总是悄悄告诉你用户是从哪里来的。它记录了用户在访问当前页面之前所在的页面的 URL。理论上，这很有用，可以用来分析流量来源、实现一些简单的安全验证等等。

但是，这位邻居并不可靠！为什么呢？

容易被篡改： HTTP_REFERER 是由客户端（浏览器）发送的，用户可以通过浏览器插件、修改 HTTP 请求头等方式轻易地修改它。
并非总是存在： 用户可以直接在地址栏输入 URL，或者使用书签访问页面，这时 HTTP_REFERER 就不存在。出于隐私考虑，一些浏览器或安全软件也会主动屏蔽 HTTP_REFERER。

因此，完全依赖 HTTP_REFERER 进行安全验证是很危险的！那 WordPress 的 wp_remote_post() 是怎么处理它的呢？让我们深入源码一探究竟。

wp_remote_post() 的身世之谜

wp_remote_post() 是 WordPress 中一个非常重要的函数，用于向指定的 URL 发送 POST 请求。它通常用于插件更新、主题更新、连接外部 API 等场景。它的基本用法如下：

$url = 'https://api.example.com/endpoint';
$args = array(
    'method' => 'POST',
    'timeout' => 45,
    'redirection' => 5,
    'httpversion' => '1.0',
    'blocking' => true,
    'headers' => array(),
    'body' => array( 'username' => 'test', 'password' => 'secret' ),
    'cookies' => array()
);

$response = wp_remote_post( $url, $args );

if ( is_wp_error( $response ) ) {
   $error_message = $response->get_error_message();
   echo "Something went wrong: $error_message";
} else {
   echo 'Response: ' . wp_remote_retrieve_body( $response );
}

这段代码向 https://api.example.com/endpoint 发送了一个 POST 请求，并传递了用户名和密码。如果请求成功，就输出响应内容；如果失败，就输出错误信息。

wp_remote_post() 与 HTTP_REFERER 的关系：你想多了！

令人惊讶的是，在 wp_remote_post() 函数本身的代码中，根本没有直接使用 $_SERVER['HTTP_REFERER']！没错，你没有听错。它专注于构建和发送 HTTP 请求，并处理响应，而不会主动去检查请求的来源是否合法。

但是，这并不意味着 HTTP_REFERER 在整个 WordPress 的安全体系中毫无用处。实际上，HTTP_REFERER 经常被用于其他地方，例如 CSRF 保护。

CSRF 防御：HTTP_REFERER 的间接作用

CSRF (Cross-Site Request Forgery) 是一种常见的 Web 安全漏洞。攻击者通过伪造用户的请求，诱骗用户在不知情的情况下执行某些操作，例如修改密码、发送邮件等。

HTTP_REFERER 可以作为一种简单的 CSRF 防御手段，但它的可靠性前面已经说过了，非常有限。通常，WordPress 会结合使用 Nonce (一次性随机数) 和 HTTP_REFERER 来增强 CSRF 防御的安全性。

下面是一个简单的例子，说明如何在表单中使用 Nonce 和 HTTP_REFERER 进行 CSRF 防御：

生成 Nonce：

$nonce = wp_create_nonce( 'my_form_action' );

在表单中包含 Nonce 和 Referer（隐藏字段）：

<form action="process_form.php" method="post">
    <input type="hidden" name="my_nonce" value="<?php echo esc_attr( $nonce ); ?>">
    <input type="hidden" name="my_referer" value="<?php echo esc_url( wp_unslash( $_SERVER['HTTP_REFERER'] ) ); ?>">
    <input type="text" name="my_field">
    <button type="submit">Submit</button>
</form>

在处理表单时验证 Nonce 和 Referer：

if ( ! isset( $_POST['my_nonce'] ) || ! wp_verify_nonce( $_POST['my_nonce'], 'my_form_action' ) ) {
    wp_die( 'Invalid nonce!' );
}

// 比较 Referer (需要注意的是，这部分验证通常不是强制的，因为Referer容易被篡改)
if ( ! empty( $_POST['my_referer'] ) && strpos( $_POST['my_referer'], home_url() ) === false ) {
  wp_die( 'Invalid referer!' );
}

// Process the form data
$my_field = sanitize_text_field( $_POST['my_field'] );
// ...

这段代码首先生成一个 Nonce，并将其包含在表单的隐藏字段中。然后在处理表单时，验证 Nonce 是否有效。如果 Nonce 无效，就拒绝处理请求。同时，代码也验证了 Referer 是否来自本站，但正如前面所说，这部分验证的可靠性较低，通常作为辅助手段。

重要提示：永远不要只依赖 HTTP_REFERER！

再次强调，永远不要只依赖 HTTP_REFERER 进行安全验证！它只能作为一种辅助手段，用于增强安全性。更可靠的 CSRF 防御方法是使用 Nonce。

wp_remote_post() 的安全考量

虽然 wp_remote_post() 本身不直接处理 HTTP_REFERER，但使用它时仍然需要注意一些安全问题：

URL 验证： 确保你发送请求的 URL 是可信的。避免向未知的或恶意的 URL 发送敏感数据。
数据过滤： 对发送的数据进行过滤和转义，防止 XSS (Cross-Site Scripting) 攻击。特别是当数据来自用户输入时，更要格外小心。
SSL/TLS： 始终使用 HTTPS 协议发送请求，确保数据在传输过程中加密。
错误处理： 妥善处理请求失败的情况，避免泄露敏感信息。

代码分析：看看 wp_remote_post() 内部的 "小秘密"

让我们简单浏览一下 wp_remote_post() 函数的核心代码 (简化版，实际代码更复杂)，以便更好地理解它的工作原理：

function wp_remote_post( $url, $args = array() ) {
    $args['method'] = 'POST';
    return wp_remote_request( $url, $args );
}

function wp_remote_request( $url, $args = array() ) {
    $defaults = array(
        'method' => 'GET',
        'timeout' => 5,
        'redirection' => 5,
        'httpversion' => '1.0',
        'user-agent' => 'WordPress/' . get_bloginfo( 'version' ) . '; ' . get_bloginfo( 'url' ),
        'reject_unsafe_urls' => true,
        // ... other defaults
    );

    $args = wp_parse_args( $args, $defaults );

    // Reject unsafe URLs (security measure)
    if ( $args['reject_unsafe_urls'] && ! wp_http_validate_url( $url ) ) {
        return new WP_Error( 'http_request_failed', __( 'The requested URL is invalid.' ) );
    }

    $http = _wp_http_get_object(); // Get the HTTP transport object

    return $http->request( $url, $args );
}

从代码中可以看到，wp_remote_post() 只是简单地设置了请求方法为 POST，然后调用 wp_remote_request() 函数。wp_remote_request() 函数负责处理请求的参数，并调用底层的 HTTP 传输对象 (通常是 WP_Http 类) 来发送请求。

注意 reject_unsafe_urls 参数，这是一个安全措施，用于验证 URL 的合法性。

总结：HTTP_REFERER 不是万能钥匙

wp_remote_post() 函数本身并不直接依赖 $_SERVER['HTTP_REFERER'] 进行安全验证。 HTTP_REFERER 更多地被用在 CSRF 防御中，但由于其容易被篡改的特性，不能作为唯一的安全保障。

安全最佳实践：

实践	描述
使用 Nonce 进行 CSRF 防御	Nonce 是一种一次性随机数，可以有效地防止 CSRF 攻击。
验证 URL 的合法性	确保你发送请求的 URL 是可信的。使用 `wp_http_validate_url()` 函数验证 URL 的合法性。
对数据进行过滤和转义	对发送的数据进行过滤和转义，防止 XSS 攻击。
使用 HTTPS 协议	始终使用 HTTPS 协议发送请求，确保数据在传输过程中加密。
限制请求来源（如果可能）	如果你的 API 只需要来自特定域名的请求，可以在服务器端验证 `HTTP_ORIGIN` 头。注意：`HTTP_ORIGIN` 比 `HTTP_REFERER` 更可靠，但并非所有浏览器都支持。
实施速率限制	通过限制单个 IP 地址或用户的请求频率，可以防止恶意攻击，如 DDoS 攻击。
定期审查代码和依赖项	定期审查你的 WordPress 代码和使用的插件、主题，确保它们没有安全漏洞。
保持 WordPress 核心和插件更新	WordPress 官方和插件开发者会定期发布安全更新，及时更新可以修复已知的安全漏洞。

结束语：安全之路，永无止境

Web 安全是一个永无止境的旅程。我们需要不断学习新的安全知识，并将其应用到我们的项目中。希望今天的 "WordPress 安全夜话" 能对你有所帮助。记住，安全不是一蹴而就的，而是一个持续改进的过程。

感谢大家的收听！我们下次再见！

发表回复 取消回复

发表回复取消回复