IN Injection Vulnerability

By jmdcw

 
I have written many times about IN injection. Maybe programmers don't read this article, so .... I was asked by Kobayashi today. I saw this vulnerability again when I was looking at a piece of source code. I have nothing to worry about. Let's take a look.
 
The usage code of the in method is as follows:
 
Dim id
Id = request. form ("id ")
Conn. Execute ("delect from table name where name =" & name & "and id in (" & id &")")
 
For this vulnerability, I used to use the IIF function. Its syntax is: IIF (logical expression, true expression, false expression ), when the logical expression is true, for example, 1 = 1, "true expression" is returned. If the expression is 1 = 2, "false expression" is returned ". Suppose the statement I constructed is: "IIF (select len (user) from [Table] where id = a user id value) = guess value), 1, 2 )", here, "the ID value of a user" is the ID value of the user to be guessed. If it is true, 1 is returned; otherwise, 2 is returned, and then the value is passed to the id: id in (1) or id in (2). in this way, find a truth from the two, and then brute force crack the value to be guessed.
 
Is there any other way besides IIF? Of course, you can directly add parentheses. For example, you can directly submit the statement in the above ID:
 
1) and (select len (user) form [Table] where id = id of a user) = prediction value and 1 in (1
 
IN this way, brackets match the brackets IN. Later, you only need to change the prediction value IN the commit statement to guess the length of the user name.
 
If this vulnerability occurs in the SQL database, it is simpler. First, use this statement to check whether it is a SQL database.
 
1) and user> 0 and 1 in (1
 
If an error is returned with a user name, it is the SQL database. Then, try multiple statements:
 
1); another SQL statement --
 
Of course, if you want to use the IN vulnerability for rapid injection, I personally feel that it is faster to use the injection and forwarding pages I have previously written.