HTTP_ORIGIN 的安全性如何？

Question

我想查明来自第三方网站的传入 HTTP_REQUEST 调用是否来自我定义的域列表。

我知道可以使用HTTP_REFERER来查找第三方域在哪里，但它不够安全。人们可以欺骗它或使用 Telnet 来伪造它。

那么，HTTP_ORIGIN 怎么样？它是从所有浏览器发送的吗？安全吗？

另外，人们可以在 HTTP_REQUEST 调用中伪造 REMOTE_ADDR 吗？

Answer 1

HTTP_ORIGIN 是一种防范 CSRF（跨站请求伪造）请求的方法。目前它仅由 Chrome 实现（截至 2011 年 11 月）。我测试了 Firefox 和 Opera，但都失败了。

它在请求标头中的名称是Origin。在我的 PHP 脚本的服务器上，我将其视为 $_SERVER 数组中的 HTTP_ORIGIN。仅在某些情况下，当需要针对 CSRF 的保护时才发送此标头（仅 POST 就足够了）。以下是所有请求的列表，无论是否设置：

https://wiki.mozilla.org/Security /Origin

• 锚标记 - 否
• 窗口导航 - 否
• IMG - 否
• iframe、嵌入、小程序 - 是
• 表单（GET 和 POST） - 是
• SCRIPT - 是
• 样式表 - 否
• 来自样式表的依赖加载 - 否
• 重定向 - 是
• XHR - 是

不幸的是，Origin 标头仅在 Chrome 中实现。它于 2010 年 1 月在 Google Chrome 博客上首次发布：

http://blog.chromium.org/2010/01/security-in-deep-new-security-features.html

通过 Origin 标头进行 CSRF 保护

Origin 标头是一项新的 HTML5 功能，可帮助您保护网站免受跨站请求伪造 (CSRF) 攻击。在 CSRF 攻击中，恶意网站（例如attacker.com）指示用户的浏览器向目标服务器（例如example.com）发送HTTP 请求，从而迷惑example.com 服务器执行某些操作。例如，如果 example.com 是网络邮件提供商，CSRF 攻击可能会欺骗 example.com 将电子邮件转发给攻击者。

Origin 标头通过识别哪个网站生成请求来帮助网站防御 CSRF 攻击。在上面的示例中，example.com 可以看到请求来自恶意网站，因为 Origin 标头包含值 http://攻击者.com。要将 Origin 标头用作 CSRF 防御，站点应仅在响应 (1) 缺少 Origin 标头或 (2) 具有带有白名单值的 Origin 标头的请求时修改状态。

我只是在我的 PHP 脚本中实现 CSRF 保护，我个人使用 Chrome，所以这对我来说已经足够了，我希望其他浏览器很快就能赶上 Chrome。

有趣的是，Mozilla 发明了该安全功能，因为您可以在其网站上阅读大量有关 Origin 标头的文档，但他们仍然没有时间实现它;-)

HTTP_ORIGIN 似乎只包含 protocol 和 domain，末尾没有斜杠：
“http://www.example.com” - 即使您从“http://www.example.com/myform/”提交表单。

PHP 脚本中针对 CSRF 的简单保护：

if ($_SERVER['REQUEST_METHOD'] == 'POST') {
    if (isset($_SERVER['HTTP_ORIGIN'])) {
        $address = 'http://'.$_SERVER['SERVER_NAME'];
        if (strpos($address, $_SERVER['HTTP_ORIGIN']) !== 0) {
            exit('CSRF protection in POST request: detected invalid Origin header: '.$_SERVER['HTTP_ORIGIN']);
        }
    }
}

该脚本仍然可以升级以支持 80 以外的端口（Origin 包含与 80 不同的端口）、HTTPS 连接以及从不同子域（例如 sub.example.com）提交表单。 com => 向 www.example.com 发布请求）。

Answer 2

HTTP_ORIGIN 既不是由所有浏览器发送，也不安全。

浏览器发送的任何内容都不能被认为是安全的。

Answer 3

这里的人们的想法都是错误的——“CORS”标准并不是为了让服务器不会被黑客攻击，即使它除了它所做的之外还有帮助。目的是让“浏览器”能够减轻违反同源策略的请求。如果客户端和服务器位于同一页面，则“客户端”可以决定是否允许该请求。

显然，通过让服务器参与决策，您可以帮助安全过程。

但它不能保护服务器免受未经授权的访问——这就是密码和 cookie 的用途。

客户端可以是（正如有人提到的）一个telnet工具，其中制作的每一个东西都是假的。

但是 Chrome 和 FF 等的卖点之一是，它们将通过不允许 Javascript 超出同源沙箱来帮助您，这意味着默认情况下唯一可能受到损害的是“攻击者自己的网站。或其他决定不安全的网站。

CORS 技术可以让您说——嘿，我希望用户能够通过他们使用的其他网站上的 javascript 来使用我的时髦服务。所以我要把这个网站添加到我的例外中。这意味着您正在帮助您的授权用户在该特定站点的浏览器安全性中找出漏洞。这意味着黑客可以利用一个漏洞。因此，您在设置服务时非常谨慎，对吗？

这意味着，默认情况下，任何未设置 CORS 的站点都可以免受来自兼容浏览器的跨站点脚本攻击（当然，排除错误和黑客攻击）。浏览器会询问该服务是否要参与源站点的 javascript，如果跨站点说“我对这个该死的站点一无所知”，那么浏览器的 javascript 引擎将关闭连接并转储数据。

综上所述，CORS 并不能帮助您确保安全。它可以帮助您在浏览器的能力上造成漏洞，从而使用户更加安全。但希望以一种托管的方式..并且仅适用于特定网站..

Answer 4

HTTP 是一种纯文本协议。 ENTIRE 请求标头/正文结构可以伪造为您想要的任何内容。

Answer 5

HTTP 请求中的一切都可以伪造。

Answer 6

升级：

function isOriginAllowed($incomingOrigin, $allowOrigin)
{
    $pattern = '/^http:\/\/([\w_-]+\.)*' . $allowOrigin . '$/';

    $allow = preg_match($pattern, $incomingOrigin);
    if ($allow)
    {
        return true;
    }
    else
    {
        return false;
    }
}

$incomingOrigin = array_key_exists('HTTP_ORIGIN', $_SERVER) ? $_SERVER['HTTP_ORIGIN'] : NULL;
    $allowOrigin    = $_SERVER['HTTP_HOST'];

    if ($incomingOrigin !== null && isOriginAllowed($incomingOrigin, $allowOrigin))
    {
        exit("CSRF protection in POST request: detected invalid Origin header: " . $incomingOrigin);
    }

示例：

• http://media.mydomain.com TRUE
• http://offline.mydomain.com TRUE
• http:// domen1.mydomain.com TRUE
• http: // domen_1.mydomain.com TRUE
• http:// domen-1.mydomain.com TRUE
• http:// ololomydomain.com FALSE
• http:// mydomain.com TRUE
• http:// pro.mydomain.com TRUE
• http:// super.pro.mydomain.com TRUE
• http://super.pro.fakemydomain.com FALSE
• http://pro.fakemydomain.com FALSE

Answer 7

更新，截至 2021 年：

HTTP_ORIGIN 几乎得到所有浏览器的完全支持，请参阅：
https://developer.mozilla.org/en- US/docs/Web/HTTP/Headers/Origin#browser_compatibility