宽字节XSS跨站攻击

简介

宽字节跨站漏洞多发生在GB系统编码。 对于GBK编码,字符是由两个字节构成,在%df遇到%5c时,由于%df的ascii大于128,所以会自动拼接%5c,吃掉反斜线。而%27 %20小于ascii(128)的字符就会保留。通常都会用反斜线来转义恶意字符串,但是如果被吃掉后,转义失败,恶意的xss代码可以继续运行。

 

什么是宽字节

GB2312、GBK、GB18030、BIG5、Shift_JIS等这些都是常说的宽字节,实际为两字节。(英文字母占据一个字节,汉字占据两个字节)。宽字节带来的安全问题主要是吃ASCII字符(一字节)的现象。

 

宽字节SQL注入

先来复习下宽字节注入的形成原理:

防御方式:将 ' 转换为 \'

绕过方式:将 \消灭

常规编码

输入 处理 编码 带入SQL 结果
' \' %5c%27 id=1\' and 不能注入

GBK编码

MySQL在使用GBK编码时,会认为两个字符为一个汉字。

输入 处理 编码 带入SQL 结果
%df' %df\' %df%5c%27(運) id=運' and 能注入

两个字符组合,认为是一个汉字

注:前一个ASCII码大于128才能到汉字的范围。

 

宽字节XSS漏洞

宽字节XSS与宽字节SQL注入的不同在于宽字节注入主要是通过

吃掉转义符再正常注入SQL语句,而宽字节XSS主要使用吃掉转义符后注入恶意xss代码。

案例1:

一般情况下,当我们发现一个输入框,想要插入xss代码在里面:

通常做法是通过闭合前面的双引号和注释掉后面的双引号来触发

" />//

但是开发人员一般为了防范我们在其中插入恶意代码,会在显示之前使用过滤器对我们的输入进行转义,我们闭合使用的"被转义为\",这样就导致我们没法闭合。

 

如果使用了GBK等编码,我们就可以利用宽字节xss。构造如下payload:

%c0%22 />//

%c0和%df一样,也是超出了GBK的范围,此时在执行过滤操作时,源代码就变成了

当过滤器发现了%22,然后加入转义(%5c),但在解析的时候碰到%c0,于是%5c与%c0合并成一个特殊字符,我们的"得以保留。

 

案例二:

下面是一个PHP的例子,在magic_quotes_gpc=On的情况下,如何触发XSS?

php header("Content-Type: text/html;charset=GBK"); ?> 
<head>
<title>gb xsstitle>
head>
<script> a="$_GET['x'];?>";
script>

我们会想到,需要使用闭合双引号的方法:

gb.php?x=1";alert(1)//

在magic_quotes_gpc=Off 时源代码会变成:

由于magic_quotes_gpc=On,双引号被转义成\"导致闭合失败

由于网页头部指定了GBK编码,GBK编码第一字节(高字节)的范围是0x81~0xFE,第二字节(低字节)的范围是0x40~0x7E与0x80~0xFE。

gb.php?x=1%81";alert(1)//

此时当双引号会继续被转义为\",最终代码如下:

[0x81]\ 组合成了一个合法字符,于是我们的"被保留下来就会产生闭合,我们就成功触发了xss。

GB2312是被GBK兼容的,它的高位范围是0xA1~0xF7,低位范围是0xA1~0xFE(0x5C不在该范围内),把上面的PHP代码的GBK改为GB2312,在浏览器中处理行为同GBK,也许是由于GBK兼容GB2312,浏览器都做了同样的兼容:把GB2312统一按GBK行为处理。

 

宽字节注入防御

1、使用utf-8,编码宽字节注入;

ps:不仅gbk,韩文、日文等都是宽字节,都有可能存在宽字节注入漏洞。

2、过滤客户端提交的危险字符。

 

参考链接:

https://blog.csdn.net/qq_29419013/article/details/81205291

https://www.uedbox.com/post/14488/

http://book.2cto.com/201301/14515.html

http://itindex.net/detail/47408-xss-%E5%AD%A6%E4%B9%A0-xss

你可能感兴趣的:(宽字节XSS跨站攻击)