频道栏目
首页 > 安全 > 网站安全 > 正文

浏览器差异带来的不仅仅是“XSS风险”

2011-03-12 13:08:05           
收藏   我要投稿
5up3rh3iblog

先看xeyeteam的文章《浏览器urlencode策略差异导致XSS风险》以及余先生的博文《浏览器差异带来的XSS风险1》,又是一个标准问题...

当Ryat牛看到这篇文章后感同身受,就在我的上一个blog里提到的《boblog任意变量覆盖漏洞》里,在测试的时候就出现过这个问题:

『start』
// go.php

$q_url=$_SERVER["REQUEST_URI"];
@list($relativePath, $rawURL)=@explode(/go.php/, $q_url);
$rewritedURL=$rawURL;
...
$RewriteRules[]="/page/([0-9]+)/([0-9]+)/?/";
// 这个正则看上去很严谨,但是没有使用^和$来限制开头与结尾[可能是为了适应程序自身的需要]:)
...
$RedirectTo[]="index.php?mode=\1&page=\2";
...
foreach ($RewriteRules as $rule) {
    if (preg_match($rule, $rewritedURL)) {
        $tmp_rewritedURL=preg_replace($rule, <.$RedirectTo[$i].<, $rewritedURL, 1);
// 对$rewritedURL进行匹配和替换,并使用<来标记匹配的部分
// 经过这样的处理后$tmp_rewritedURL主要分为三部分:
// i.第一个<前面的部分
// ii.两个<之间的部分
// iii.第二个<后面的部分
        $tmp_rewritedURL=@explode(<, $tmp_rewritedURL);
        $rewritedURL=($tmp_rewritedURL[2]) ? false : $tmp_rewritedURL[1];
// 这段代码的主要目的是解决之前的正则限制不够严格的问题
// 程序员希望通过这段代码去掉i和iii,使$rewritedURL仅保留ii
// 注意这里还对iii做了限制,按照程序员的想法,iii这部分应该是不存在的:)
// 这部分代码逻辑的关键就在于<这个字符,但遗憾的是我们是可以随意注入<的:p
        break;
    }
    $i+=1;
『end』

在这个漏洞的测试的时候,这个问题直接影响到了Ryat牛的测试进程,最后写程序提交才完成...

所以我大体YY一下作者所用<处理变量的理由:‘我再想bob的作者是不是误认为request_url里的< "啥的本来就该被编码  所以才放心的用<来分割 ’

当然这一切都是我们的主观臆断!!

这个故事说明一个问题,浏览器这次的“urlencode策略差异”,可以导致程序员“错觉”,从而导致悲剧的结果!这个和《各个语言格式标准不同导致的安全问题》有着异曲同工的效果 :)
上一篇:浏览器差异带来的XSS风险1
下一篇:新浪微博的重大安全漏洞,可能导致微博帐号被轻易盗用
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站