首先先来看一个简单的asp实例
这段代码从URL处获得参数username的值,然后显示在页面中。
可见%00之后的内容没有保存到变量中。
下面在网站中直接上传asp程序
可见网站阻止上传
利用Burp工具来实现0x00的截断,首先上传ma1.asp[空格]1.jpg获取到上传请求,随后点击action,并选择Send to Repeater
在Repeater选项卡中点击要更改的字节,(该网站将空格变为了+),将表示+的0x2b改为0x00,
通过上面的结果可知当asp代码file = Request.Form("file")得到文件名时,0x00之后的内容已经被删除了。
所以如果想利用0x00来达到攻击的目的,相应的网站代码也必须是存在截断上传漏洞的,而此例中的代码不具有此漏洞。
类似的来看看php中的情况
过程和asp的类似
上传ma2.php 1.jpg
在repeater中更改相应的字节 0x20->0x00
回头在看proxy中相应的字节已经被更改
最终显示的结果是
可见$_FILES['file']['name']在得到文件名时0x00之后的内容已经不见了,如果在此基础上判断后缀名是否合法,则肯定不能通过。
这段代码从URL处获得参数username的值,然后显示在页面中。
可见%00之后的内容没有保存到变量中。
下面在网站中直接上传asp程序
可见网站阻止上传
利用Burp工具来实现0x00的截断,首先上传ma1.asp[空格]1.jpg获取到上传请求,随后点击action,并选择Send to Repeater
在Repeater选项卡中点击要更改的字节,(该网站将空格变为了+),将表示+的0x2b改为0x00,
然后点击Go,返回到proxy中,查看hex可见更改已经起效。
通过上面的结果可知当asp代码file = Request.Form("file")得到文件名时,0x00之后的内容已经被删除了。
所以如果想利用0x00来达到攻击的目的,相应的网站代码也必须是存在截断上传漏洞的,而此例中的代码不具有此漏洞。
类似的来看看php中的情况
过程和asp的类似
上传ma2.php 1.jpg
在repeater中更改相应的字节 0x20->0x00
回头在看proxy中相应的字节已经被更改
最终显示的结果是
可见$_FILES['file']['name']在得到文件名时0x00之后的内容已经不见了,如果在此基础上判断后缀名是否合法,则肯定不能通过。
综上所述,0x00不是针对所有基于白名单的后缀名检查都能绕过,代码的实现过程中必须存在截断上传漏洞。
========================================================================================
还可以使用 %00编码 方式直接修改 具体如图