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 - NO

iframe，embed，applet - 是

表格（GET和POST） - 是

脚本 - 是

样式表 - 否

来自样式表的

依赖负载 - 否

重定向 - 是

XHR - 是

不幸的是，

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

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

通过Origin Header进行CSRF保护

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

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

我只是在我的php脚本中实现CSRF保护，我个人使用Chrome对我来说已经足够了，我希望其他浏览器能够很快找到它。

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

HTTP_ORIGIN似乎只包含“protocol”和“domain”，最后没有斜杠： “http://www.example.com” - 即使您从“http://www.example.com/myform/”发送了表单。

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

if ("POST" == $_SERVER["REQUEST_METHOD"]) {
    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以外的PORT（Origin包含不同于80的端口），HTTPS连接以及从不同子域提交表单（例如sub.example.com =＆gt;发布请求）到www.example.com）。

Answer 2

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

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

Answer 3

HTTP是一种纯文本协议。整个请求标题/正文结构可伪造成您想要的任何内容。

Answer 4

这里的人们都在考虑这一切都是错的 - “CORS”标准并非如此，服务器不会被黑客入侵，即使它除了它的功能之外还有帮助。目的是让“浏览者”有办法缓解违反同一原产地政策的请求。如果客户端和服务器位于同一页面上，则“客户端”可以决定是否允许该请求。

显然，让服务器参与您正在帮助安全流程的决策。

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

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

但是Chrome和FF之一的卖点是，它们会帮助你不允许Javascript超出同一个原始沙盒，这意味着默认情况下唯一可以被破坏的东西就是在'攻击者'自己的网站上。或者其他决定不安全的网站。

CORS是一种技术，可以让你说 - 嘿，我希望用户能够从他们使用的其他网站上的javascript中消费我的时髦服务。所以我要将此网站添加到我的例外情况中。这意味着您正在帮助您的授权用户为该特定站点的浏览器安全漏洞。这意味着黑客可以利用的漏洞。因此，您设置服务的关注，对吗？

这意味着默认情况下，任何没有设置CORS的站点都可以从兼容的浏览器中保护Cross Site Scripting（当然，除了错误和黑客）。浏览器将询问此服务是否想要参与原始网站的javascript，如果跨站点显示“我对这个该死的网站一无所知”，那么浏览器的javascript引擎将关闭连接并转储数据。 / p>

总而言之 - CORS并不能帮助您确保安全。它可以帮助您在浏览器中创建漏洞，使用户更安全。但希望以有管理的方式......并且只针对特定的网站..

Answer 5

<强>升级：

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 6

HTTP请求中的所有内容都可以伪造。

HTTP_ORIGIN的安全性如何？

6 个答案: