HTTP_ORIGIN有多安全? [英] How secure is HTTP_ORIGIN?

查看:412
本文介绍了HTTP_ORIGIN有多安全?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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



我知道HTTP_REFERER可以用于了解第三方域名的位置,但不够安全。人们可以欺骗它或使用Telnet来伪造它。



那么HTTP_ORIGIN怎么样?是否从所有浏览器发送?是否安全?



此外,人们可以在HTTP_REQUEST调用中伪造REMOTE_ADDR吗?

解决方案

HTTP_ORIGIN是一种防范CSRF(跨站点请求伪造)请求的方法。目前仅由Chrome实现(截至2011年11月)。我测试了Firefox和Opera - 但他们失败了。其请求头中的名称为Origin。在我的php脚本的服务器端,我在$ _SERVER变量中看到它是HTTP_ORIGIN。此标头仅在某些情况下发送,当需要对CSRF的保护时(只有POST应该足够)。以下是所有请求的列表,无论是否设置:



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



锚点标签 - NO



窗口导航 - NO



IMG - NO



iframe,embed,applet - YES



表单(GET和POST) - 是



SCRIPT - 是



样式表 - 否



样式表中的依赖加载 - 否



重定向 - 是



XHR - 是



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



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


CSRF通过原始标题保护



Origin标头是一种新的HTML5功能,可帮助您保护您的网站免受跨 - 请求伪造(CSRF)攻击。在CSRF攻击中,恶意网站(attacker.com)指示用户的浏览器向目标服务器(例如example.com)发送HTTP请求,这将使example.com服务器混淆以执行某些操作。例如,如果exam​​ple.com是一个网络邮件提供商,CSRF攻击可能会欺骗example.com向攻击者转发电子邮件。



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


我正在我的php脚本中实施CSRF保护,我个人使用Chrome,这对我来说足够了,我希望其他浏览器可以很快抓到chrome。 p>

有趣的是,Mozilla发明了该安全功能,您可以在其网站上阅读该Origin标题的许多文档,但仍没有时间实施it; - )



HTTP_ORIGIN似乎只包含协议和域,最后没有斜线:
http://www.example.com - 即使您将表单从 http://www.example.com/myform/



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

 $ address = HTTP://。$ _ SERVER [ SERVER_NAME]; 
if(strloc($ address,$ _SERVER [HTTP_ORIGIN])!== 0){
exit(POST请求中的CSRF保护:检测到无效的Origin标头:$ _ SERVER [HTTP_ORIGIN ]);
}
}
}

此脚本仍可升级以支持除80以外的端口(源包含不同于80的端口),HTTPS连接,以及从不同子域(例如sub.example.com =>发布请求到www.example.com)提交表单。 p>

I want to find out whether an incoming HTTP_REQUEST call from a third party website is coming from the list of domains that I defined.

I know that HTTP_REFERER can be used to find out where the third party domain is, but it is not secure enough. People can spoof it or use Telnet to fake it.

So, how about HTTP_ORIGIN? Is it sent from all browsers? Is it secure?

Also, can people fake the REMOTE_ADDR in a HTTP_REQUEST call?

解决方案

HTTP_ORIGIN is a way to protect against CSRF (Cross Site Request Forgery) requests. Currently it is implemented only by Chrome (as of Nov 2011). I tested Firefox and Opera - but they failed. Its name in request header is "Origin". On server side in my php script I see it as "HTTP_ORIGIN" in $_SERVER variable. This header is sent only in some cases, when protection against CSRF is required (only POST should be sufficient). Here is list of all requests whether it is set or not:

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

Anchor tag - NO

Window navigation - NO

IMG - NO

iframe, embed, applet - YES

Form (GET and POST) - YES

SCRIPT - YES

stylesheets - NO

dependent loads from stylesheets - NO

Redirects - YES

XHR - YES

Origin header is implemented only in Chrome, unfortunately. It was announced first in January 2010 on Google Chrome's blog:

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

CSRF Protection via Origin Header

The Origin header is a new HTML5 feature that helps you defend your site against cross-site request forgery (CSRF) attacks. In a CSRF attack, a malicious web site, say attacker.com, instructs the user's browser to send an HTTP request to a target server, say example.com, that confuses the example.com server into performing some action. For example, if example.com is a webmail provider, the CSRF attack might trick example.com into forwarding an email message to the attacker.

The Origin header helps sites defend against CSRF attacks by identifying which web site generated the request. In the above example, example.com can see that the request came from the malicious web site because the Origin header contains the value http://attacker.com. To use the Origin header as a CSRF defense, a site should modify state only in response to requests that either (1) lack an Origin header or (2) have an Origin header with a white-listed value.

I am just implementing CSRF protection in my php script, I personally use Chrome so that is sufficient for me, I hope other browsers will catch chrome soon.

What is funny, is that Mozilla invented that security feature, as you can read lots of documentation of that Origin header on its website, but they still didn't had time to implement it ;-)

HTTP_ORIGIN seems to contain only "protocol" and "domain", without slash at the end: "http://www.example.com" - even if you sent the form from "http://www.example.com/myform/".

A simple protection against CSRF in PHP script:

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"]);
        }
    }
}

This script could still be upgraded to support PORT other than 80 (Origin contains the port when it's different than 80), HTTPS connections, and submitting the forms from different subdomains (ex. sub.example.com => posting request to www.example.com).

这篇关于HTTP_ORIGIN有多安全?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆