记得以前在看文章的时候说,有的时候 改变一下URL编码就可以绕过一些防住入的代码。实现注入。
今天抽时间 把url编码从新学习了一下,做个简单的笔记吧。
首先百度一下:URL编码的介绍:
介绍中使这样定义url编码的:
url编码是一种浏览器用来打包表单输入的格式。浏览器从表单中获取所有的name和其中的值 ,将它们以name/value参数编码(移去那些不能传送的字符, 将数据排行等等)作为URL的一部分或者分离地发给服务器。
从定义中,实现URL编码的过程是发生在浏览器端的,也就是在客户端实现的.浏览器把特殊的字符和不能用简单的七位ASCII实现编码的字符,通过URL编码传递给了 服务器。
例如:
在FireFox中输入:
/admin/module/sys/test.php?id=" (%22 = ")
查看 提交的请求头信息:
GET /admin/module/sys/test.php?id=%22 HTTP/1.1
浏览器把这些字符经过了URL编码处理,之后送给了服务器。
既然这个URL编码是在客服端实现的,那么我们把正常的字符也采用url编码的形式提交的话,结果是什么呢?
and 1=1 url(%61%6E%64%201%3D1)
url中输入:
?id=%61%6E%64%201%3D1
test.php的内容如下:
echo $_GET['id'];
结果如下:
and 1=1
这说明了,可以在本地提交正常字符URL编码的形式,提交给了服务端是可行的。
在客户端的 url编码就是这样处理的,遇到不能识别的 或者是浏览器内部制定的 字符的时候,浏览器就把这些字符进行URL编码的处理,如果是正常的能识别的字符的话就不经过url编码的处理。当我们把一个浏览器能识别的字符通过url编码处理之后在传递给浏览器的话,那么浏览器直接把这些内容传递给了 服务器。
url编码在客户端的传递总结就是这样了,
那么下面我们说一下,在服务端是怎么处理的呢?
看例子:
test.php的代码如下:
$id = $_GET['id'];
if($id == "\""){
echo "me too";
访问 ?id="
结果 :
me too
从这里可以看出来 在服务端自动把 URL进行了解码处理。
再来看一下我们常用的 url编码的诸如把:
1 and 1=1 url(1%20%61%6E%64%201%3D1)
修改test.php的代码:
$id = $_GET['id'];
if($id == "1 and 1=1"){
echo "buxuan";
访问:
?id=1%20%61%6E%64%201%3D1
结果是:
buxuan
按照这样结果的话,那么通过URL编码来实现注入的话是根本行不通的啊,涛涛电脑知识网,那网上好多大牛为什么说可以通过在中方法能实现注入呢 ?
资料上说 是一些asp的防注入脚本中,用来获取客户端的数据的时候调用的是Request.ServerVariables("QUERY_STRING") 来获取url中的内容,涛涛电脑知识网,依靠这个内置的函数获取过来的URl中的内容都是没有结果解码处理的内容.
其实利用url编码注入的漏洞,知识针对那些在防注入程序中是利用Request.ServerVariables("QUERY_STRING")取来的URL。
现在对PHP比较熟悉:
就拿php来说吧,
test.php
echo $_SERVER['QUERY_STRING'];
访问:
?id=1%20%61%6E%64%201%3D1
输出的结果是:
id=1%20%61%6E%64%201%3D1
简单的整理一下url编码在服务端处理:
通过$_GET $_POST $_COOKIE 获取过来的参数都是结果url解码之后的数据。
通过$_SERVER 得到的 内容都是没有经过url解码处理的数据。
应该是和php的处理机制的问题吧
$_SERVER直接 获取url中的内容 ,而 $_GET $_POST 等 是接受了处理之后的内容。
作者: