EMwI插件更新:防XSS攻击

8月底的时候External Media without Import插件在github上收到一个pull request。对方指出我的代码存在XSS漏洞。惭愧,直到最近才腾出时间仔细研究他说的问题。插件的1.0.2版本合并了对方的pull request,修复了该漏洞。


在修复之前,我的插件中有如下代码(点击查看源文件):


function admin_post_add_external_media_without_import() {
	$info = add_external_media_without_import();
	$redirect_url = 'upload.php';
	if ( ! isset( $info['id'] ) ) {
		$redirect_url = $redirect_url .  '?page=add-external-media-without-import&url=' . urlencode( $info['url'] );
		$redirect_url = $redirect_url . '&error=' . urlencode( $info['error'] );
		$redirect_url = $redirect_url . '&width=' . urlencode( $info['width'] );
		$redirect_url = $redirect_url . '&height=' . urlencode( $info['height'] );
		$redirect_url = $redirect_url . '&mime-type=' . urlencode( $info['mime-type'] );
	}
	wp_redirect( admin_url( $redirect_url ) );
	exit;
}

这个函数将width 、height 和mime-type等信息通过urlencode编码后设置为url的参数,然后重定向到该url。在url的响应函数中,我调用了urldecode读取来这些信息:


<label><?php echo __('Width'); ?></label>
<input id="emwi-width" name="width" type="number" value="<?php echo urldecode( $_GET['width'] ); ?>">
<label><?php echo __('Height'); ?></label>
<input id="emwi-height" name="height" type="number" value="<?php echo urldecode( $_GET['height'] ); ?>">
<label><?php echo __('MIME Type'); ?></label>
<input id="emwi-mime-type" name="mime-type" type="text" value="<?php echo urldecode( $_GET['mime-type'] ); ?>">


问题就出在这段响应函数的代码中。从$_GET中取出的值已经是经过urldecode 的。对$_GET再调用urlencode就可能会出问题。比如$info['mime-type'] = 'image/svg+xml' 的情况下,urlencode( $info['mime-type'] )的结果是'image%2fsvn%2bxml' , $_GET['mime-type']的值已经是解码后的'image/svn+xml' ,再对它调用一次urldecode就变成了'image/svn xml' ,这就导致了错误的mime-type。PHP官方文档对这个问题也有说明


然而直接使用$_GET也有安全性问题。以响应函数中将mime-type的值显示在输入框的代码为例,假设我们直接将$_GET的值打印到input的value中:


<input id="emwi-mime-type" name="mime-type" type="text" value="<?php echo $_GET['mime-type']; ?>">

这种情况下如果$_GET['mime-type'] 的值当中包含一段可执行代码,那其中的代码就会在浏览器中执行。比如,如果url的末尾是mime-type="><script>alert(window.location.hash)%3B<%2Fscript>"#Attack!,那么上面的php代码在浏览器中的输出就会变成下面这样:


<input id="emwi-mime-type" name="mime-type" type="text" value="\"><script>alert(window.location.hash);</script>"\"">

(上面这行代码是在Chrome中实验得出的结果,其中的\可能是浏览器自己转义加上的。)

于是用户浏览网页的时候,alert 调用就会被执行,弹出Attack!提示框。

这样会有什么问题呢?假如有一个恶意用户老王。他构造了一个url,url的mime-type(或其它任意参数)实际包含了一段老王自己编写的代码。然后他把这个url发给小红让小红点击。不明就里的小红点击了这个url之后,由于网站的PHP代码不够健壮,将$_GET 直接输出到了网页中,因此老王的代码就得以在小红的浏览器中执行。这时老王的代码就可以做很多事,比如窃取小红浏览器里的cookie,以及存储在localStorage里的用户名、密码等隐私信息。

老王的这种手段就叫XSS攻击,全称Cross-Site Scripting,跨站脚本攻击。其原理和SQL注入类似,均是利用网站后台代码的漏洞,在参数里填入可执行代码,从而将攻击者的代码注入到本不允许其执行的地方(在XSS场景中就是用户浏览器,在SQL注入场景中则是后台数据库),从而实现攻击者的目的。

为了应对XSS攻击,就需要对$_GET 的值做些处理,对其中的特殊字符进行转义,比如将<转换成&lt;,然后才能将其输出到网页的html中。WordPress为此提供了一个很方便的函数:esc_html (见:https://codex.wordpress.org/Function_Reference/esc_html)。这个函数不但会对html特殊字符进行转义,还会检查非法的UTF-8字符,考虑了各种情况。

因此将$_GET 的值输出到网页之前应先对其调用esc_html ,于是上文将$_GET 的值打印到input的value中的代码应改为:


<input id="emwi-mime-type" name="mime-type" type="text" value="<?php echo esc_html( $_GET['mime-type'] ); ?>">

这样整个$_GET['mime-type'] 的值都会被当成纯字符串而不存在被执行的可能。

值得一提的是,现代主流浏览器大都已经对XSS攻击采取了防护措施。比如在Chrome上浏览含有XSS漏洞的网页的话,其实会被Chrome拦截(Safari也一样):




如果要重现上文写到的XSS漏洞,允许攻击者代码执行的话,需要从命令行启动Chrome,并且用--disable-xss-auditor 选项关闭Chrome的XSS检查。Mac上的启动命令如下:


'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome' --disable-xss-auditor

本文在我的独立博客上的地址:http://zxtechart.com/2017/10/24/emwi-xss/

阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zzxiang1985/article/details/78325387
文章标签: Web开发 PHP WordPress
个人分类: Web
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭