I remember when I was reading the article, sometimes I could change the URL encoding to bypass some protected code. Implement injection.
Today, I took the time to learn about url encoding. Make a simple note.
First, Baidu: URL encoding introduction:
Http://baike.baidu.com/view/204662.htm
This section defines the url encoding as follows:
Url encoding is a format used by a browser to package form input. The browser obtains all names and values from the form, and encodes them with the name/value parameter (removing characters that cannot be transferred, ranking data, and so on) as part of the URL or sent to the server separately.
In the definition, the URL encoding process occurs on the browser side, that is, on the client side. the browser passes the special characters and the characters that cannot be encoded using simple seven-character ASCII to the server through URL encoding.
For example:
In FireFox, enter:
Http://www.bkjia.com/admin/module/sys/test. php? Id = "(% 22 = ")
View submitted request header information:
GET/admin/module/sys/test. php? Id = % 22 HTTP/1.1
The browser encodes these characters and sends them to the server.
Since this URL encoding is implemented at the client end, what is the result if we submit normal characters in the form of url encoding?
And 1 = 1 url (% 61% 6E % 64% 201% 3D1)
Enter in url:
Http: // 172.16.100.59/admin/module/sys/test. php? Id = % 61% 6E % 64% 201% 3D1
The content of test. php is as follows:
Echo $ _ GET ['id'];
The result is as follows:
And 1 = 1
This shows that it is feasible to submit the normal Character URL encoding form locally to the server.
In this way, the client url encoding is handled. When there are unidentifiable or internally specified characters in the browser, the browser will perform URL encoding for these characters, if it is normal to recognize other characters, it will not be url encoded. When we pass a character that the browser can recognize to the browser after url encoding, the browser directly passes the content to the server.
This is the summary of url encoding transfer on the client,
So next let's talk about how to handle it on the server?
Example:
The code for test. php is as follows:
$ Id = $ _ GET ['id'];
If ($ id = "\""){
Echo "me too ";
Access http: // 172.16.100.59/admin/module/sys/test. php? Id ="
Result:
Me too
It can be seen from this that the URL is automatically decoded on the server side.
Let's take a look at our common url encoding, such:
1 and 1 = 1 url (1% 20% 61% 6E % 64% 201% 3D1)
Modify the code of test. php:
$ Id = $ _ GET ['id'];
If ($ id = "1 and 1 = 1 "){
Echo "buxuan ";
Access:
Http: // 172.16.100.59/admin/module/sys/test. php? Id = 1% 20% 61% 6E % 64% 201% 3D1
The result is:
Buxuan
According to this result, URL encoding does not work. Why do many online experts say that injection can be implemented through the method in the middle?
Some asp injection script is used to obtain client data and call Request. serverVariables ("QUERY_STRING") to get the content in the url. The content in the URl obtained by using this built-in function is not decoded.
In fact, the url encoding injection vulnerability is used to address URLs that are obtained using Request. ServerVariables ("QUERY_STRING") in anti-injection programs.
Now familiar with PHP:
Let's talk about php,
Test. php
Echo $ _ SERVER ['query _ string'];
Access:
Http: // 172.16.100.59/admin/module/sys/test. php? Id = 1% 20% 61% 6E % 64% 201% 3D1
The output result is:
Id = 1% 20% 61% 6E % 64% 201% 3D1
Simply sort out the url encoding on the server:
Parameters obtained through $ _ GET $ _ POST $ _ COOKIE are the decoded data of the result url.
The content obtained through $ _ SERVER is data that has not been decoded by url.
It should be a problem with the php processing mechanism.
$ _ SERVER directly obtains the content in the url, while $ _ GET $ _ POST and so on accept the processed content.
By http://hi.baidu.com/bxhack/item/8c9ab4342448453c2f20c45e