mur*_*lai 31 php dns http-request
我想知道来自第三方网站的传入HTTP_REQUEST调用是否来自我定义的域列表.
我知道HTTP_REFERER可以用来找出第三方域的位置,但它不够安全.人们可以欺骗它或使用Telnet伪造它.
那么,HTTP_ORIGIN怎么样?是从所有浏览器发送的吗?它安全吗?
此外,人们可以在HTTP_REQUEST调用中伪造REMOTE_ADDR吗?
Cza*_*zak 58
HTTP_ORIGIN是一种防止CSRF(跨站点请求伪造)请求的方法.目前它仅由Chrome实施(截至2011年11月).我测试了Firefox和Opera - 但他们失败了.它在请求标题中的名称是"Origin".在我的php脚本的服务器端,我在$ _SERVER变量中将其视为"HTTP_ORIGIN".只有在需要保护CSRF时才会发送此标头(仅POST应该足够).以下是所有请求的列表:是否已设置:
https://wiki.mozilla.org/Security/Origin
锚标签 - 没有
窗口导航 - 没有
IMG - 没有
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对我来说已经足够了,我希望其他浏览器能很快得到Chrome.
有趣的是,Mozilla发明了这种安全功能,因为你可以在其网站上阅读那些Origin标题的大量文档,但他们仍然没有时间实现它;-)
HTTP_ORIGIN似乎只包含"协议"和"域",最后没有斜杠:" 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"]);
}
}
}
Run Code Online (Sandbox Code Playgroud)
此脚本仍可升级为支持80以外的PORT(Origin包含不同于80的端口),HTTPS连接以及从不同子域提交表单(例如sub.example.com =>发布请求到www.example) .COM).
cee*_*yoz 26
HTTP_ORIGIN 既不是由所有浏览器发送也不是安全的.
浏览器发送的任何内容都不能被视为安全.
Ger*_*ill 13
这里的人都在考虑这一切都是错的 - "CORS"标准并非如此,服务器不会被黑客攻击,即使它除了它的功能之外还有帮助.目的是让"浏览者"有办法缓解违反同一原产地政策的请求.如果客户端和服务器在同一页面上,则"客户端"可以决定是否允许该请求.
显然,让服务器参与您正在帮助安全过程的决策.
但它不会保护服务器免受未经授权的访问 - 这就是密码和cookie的用途.
该客户端可以(有人提及)的telnet工具,在这里制作的每一件事情都是假的.
但其中一个Chrome和FF等卖点是,它们会帮助你不允许Javascript超出同一个原始沙箱,这意味着默认情况下唯一可以被破坏的东西就是'攻击者自己的网站.或者其他决定不安全的网站.
CORS是一种技术,可以让你说 - 嘿,我希望用户能够从他们使用的其他网站上的javascript中消费我的时髦服务.所以我要将此网站添加到我的例外情况中.这意味着您正在帮助您的授权用户为该特定站点的浏览器安全漏洞.这意味着黑客可以利用的漏洞.因此,您设置服务的关注,对吧?
这意味着默认情况下,任何没有设置CORS的站点都可以从兼容的浏览器中保护Cross Site Scripting(当然,除了错误和黑客).浏览器将询问此服务是否想要参与原始网站的javascript,如果跨站点显示"我对这个该死的网站一无所知",那么浏览器的javascript引擎将关闭连接并转储数据.
总而言之 - CORS并不能帮助您确保安全.它可以帮助您在浏览器中创建漏洞,使用户更安全.但希望以有管理的方式......并且仅针对特定网站..
一切都在HTTP请求可以伪造。
升级:
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);
}
Run Code Online (Sandbox Code Playgroud)
例:
| 归档时间: |
|
| 查看次数: |
65082 次 |
| 最近记录: |