Speaking of URL encoding, you may think of the URL encoding vulnerability N years ago. It's a pity that I was born at the wrong time. When I came into contact with the Internet, the loophole had long since disappeared.
Closer to home, what is URL encoding? Take a look at the definition I copied from the Internet:
Quote: URL encoding is a format used by browsers to package form input. The browser gets all the names and values from the form and sends them to the server as part of the URL or separately, using name/value parameter encoding (removing untransmittable characters, sorting the data, etc.). In either case, the form input format on the server side looks like this:
theName=Ichabod+Crane&gender=male&status=missing&headless=yes
URL encoding follows the following rules: Each name/value pair is separated by an ampersand; each name/value pair comes from the form separated by = characters. If the user does not enter a value for the name, the name will still appear, but with no value. Any special characters (that is, those that are not simple seven-bit ASCII, such as Chinese characters) will be encoded in hexadecimal with the percent sign %, including of course special characters like =, &, and %.
Haha, you understand, in fact, the URL encoding is the hexadecimal ASCII code of a character. However, there is a slight change. You need to add "%" in front. For example, "", its ASCII code is 92, and the hexadecimal value of 92 is 5c, so the URL encoding of "" is . So what about the URL encoding of Chinese characters? It's very simple, look at the example: the ascii code of "Hu" is -17670, the hexadecimal is BAFA, and the url encoding is "%BA%FA". Haha, you know how to convert it.
We usually don't use URL encoding, because IE will automatically convert the non-numeric letters you enter into the address bar into URL encoding. So for the browser http://blog.csdn.net/l%61ke2 is equivalent to http://blog.csdn.net/lake2 (note that I replaced a with %61 in the first URL) . Haha, maybe you have remembered that someone suggested adding "#" in the database name to prevent it from being downloaded, because IE will ignore the following letters when encountering #. The cracking method is very simple - replace # with url encoding #. I originally tried to use URL encoding to avoid injection checks, but it failed because the server would convert the URL encoding into characters.
Wait, I seem to be off topic, haha, sorry :)
SQL injection is very popular now, so some people have written some anti-injection scripts. Of course, the ideas are different and the results are very different. Dear readers, please take a look at part of the code of ××SQL universal anti-injection asp version below.
Fy_Url=Request.ServerVariables("QUERY_STRING")
Fy_a=split(Fy_Url,"&")
redim Fy_Cs(ubound(Fy_a))
On Error Resume Next
for Fy_x=0 to ubound(Fy_a)
Fy_Cs(Fy_x) = left(Fy_a(Fy_x),instr(Fy_a(Fy_x),"=")-1)
Next
For Fy_x=0 to ubound(Fy_Cs)
If Fy_Cs(Fy_x)<>"" Then
If Instr(LCase(Request(Fy_Cs(Fy_x))),"and")<>0 then
Response.Write "An error occurred!"
Response.End
End If
End If
Next
The idea is to first obtain the submitted data, use "&" as the demarcation to obtain and process the name/value group, and then determine whether the value contains the defined keywords (for simplicity here, I only leave "and"). If so, it's an injection.
At first glance, the value is checked and there seems to be no problem. Haha, yes, there is no problem with value, but what about name?
Its name/value group value comes from Request.ServerVariables("QUERY_STRING"), haha, sorry, something went wrong here. Request.ServerVariables("QUERY_STRING") is to get the string submitted by the client. The URL encoding will not be automatically converted here. Haha, if we URL encode the name and then submit it, haha, then the check can be bypassed. For example, if the parameter is ph4nt0m=lake2 and lis0, the program can detect it at this time; if you submit %50h4nt0m=lake2 and lis0 (URL encoding p), the program will judge the value of %50h4nt0m, and %50h4nt0m will be converted to ph4nt0m. , so the value of %50h4nt0m is empty, thus bypassing the detection.
Wait, why can the check be bypassed if the name is not decoded but the value cannot be bypassed? Because the value of value is taken from Request(Fy_Cs(Fy_x)), the server will decode it.
How can the program be improved? As long as you can get the decoded data submitted by the client, just change the statement to get the name to For Each SubmitName In Request.QueryString.
Haha, thank you for your patience in reading my article^_^
lake2