SQL Injection and SQL Injection

SQL Injection and SQL Injection

This article is a translation and copyright belongs to the original author.

• Original source: https://bitcoinrevolt.wordpress.com/2016/03/08/solving-the-problem-of-sql-injection-requires-another-approach/

• Author (author): eriksank

Explanation

I think the annual cost of this problem can be as high as billions of dollars. In this article, we will talk about the following SQL template statements:

select * from T where f1 = ‘{value1}’ and f2 = {value2}

Now we need to fill in the statement based on the user input value:

value1=hellovalue2=5

We get the following SQL statement and submit it to the database:

select * from T where f1=’hello’ and f2=5

The problem is that attackers can construct the following user input values:

value1=anything’ or 1=1 or f1=’whatevervalue2=5

After splicing, the final statement becomes:

select * from T where f1=’anything’ or 1=1 or f1=’whatever’ and f2=5

The attacker successfully changed the syntax of the template statement. This problem occurs not only in SQL, but also in any language that uses templates, such as HTML and shell scripts.

General Solution description

SQL is the principle of randomness and consistency. token and derived Rules constitute the basis of the Internet. Note that one word is "arbitrary 」. The equivalence with SQL is countless. For any equivalent expression, each legal statement can be accurately mapped to a legal statement in SQL, and other languages are also similar. In this arbitrary equivalent expression, if a statement is invalid, it is also invalid in SQL. Attackers cannot construct rules that can satisfy any possible and arbitrary SQL equivalence.

Policy 1: according to different derived rules, use another syntax to extend the template statement Example 1: prefix Language

[NOTE 1 ]. The infix notation is equivalent to the prefix notation of the lisp style [NOTE 2 ]. Infix and prefix:

a OP1 b OP2 c <=> (OP1 a (OP2 b c))

A, B, and c are identifiers or values, and OP1 and OP2 are operators or functions.

Example Statement of prefix Notation:

(select * T (and (= f1  ‘{value1}’) (= f2 {value2})))

This statement is equivalent. They are semantic extensions. It is no problem to automatically convert the infix notation of SQL into prefix notation or other notation. However, injection by attackers is invalid in terms of prefix Syntax:

(select * T (and (= f1  ‘anything’ or 1=1 or a=’whatever’) (= f2 5)))

Syntax error. What attackers want is:

(select * T (or (= f1 ‘anything’) (or (=1 1) (and (= a ‘whatever’) (= f2 5)))))

This is different. Attackers cannot output a valid prefix language for injection.

Example 2: Euler's notation

Another alternative method is to calculate Euler's notation. From infix notation to Euler:

a OP1 b OP2 c <=> OP1(a,OP2(b,c))

Statement in the example:

select( *,T,and(=(f1,'{value1}’),=(f2,{value2})))

The injection statement will have a syntax error:

select( *,T,and(=(f1,’anything’ or 1=1 or a=’whatever’),=(f2,5)))

The attacker originally wanted to write:

select( *,T,or(=(f1,’anything’,or(=(1,1),and(=(a,’whatever’),=(f2,5))))))

The attacker is doing something wrong. The injection didn't even notice any tag method selected.

Example 3: object notation)

Another alternative is the object tag method. From prefix notation to object:

a OP1 b OP2 c <=> a.OP1(b).OP2(c)

Sample Code:

T.where(f1.=(‘{value1}’).and(f2.=({value2})).select(*)

Injection breaks down the syntax again:

T.where(f1.=(‘anything’ or 1=1 or a=’whatever’).and(f2.=5)).select(*)

I no longer provide the correct answers. Readers can use them as exercises to see what attackers should write.

Policy 2: select any other token for SQL

Keyword is often any token in a language. What is important is their location in the derived rules, rather than their arbitrary embodiment. You can always replace the existing keyword with another keyword and convert it back and forth. For example, we can convert the keyword in the following SQL statement into what we call "any brainfuck 」:

{“select“:”iph0ohKi”, “*“:”ieZoh4xa”, “from“:”aeZi5uja”, “where“:”OoJ4aX4n”, “=“:”eeQu2Zad”, “(“:”eiD5aera”,”)“:”Soo2uach”, “or“:”Ocaig5Es”}

For the sake of argument, we will map the operands to a semi-arbitrary structured sequence:

T <=> @phai1Oa6@T@hello <=> @phai1Oa6@hello@

Phai1Oa6 is an arbitrary character sequence. For the current situation, example:

select * from T where f1 = ‘{value1}’ and f2 = {value2}

Changed:

iph0ohKi ieZoh4xa aeZi5uja @phai1Oa6@T@ OoJ4aX4n @phai1Oa6@f1@ eeQu2Zad ‘{value1}’ @phai1Oa6@and@ @phai1Oa6@f2@ eeQu2Zad {value2}

This is a legal and arbitrary brainfuck language. After injection, we get:

iph0ohKi ieZoh4xa aeZi5uja @phai1Oa6@T@ OoJ4aX4n @phai1Oa6@f1@ eeQu2Zad ‘anything‘ or 1=1 or a=’whatever’ @phai1Oa6@and@ @phai1Oa6@f2@ eeQu2Zad 5

As you can see, the tokens contained in it are 'or' and '='. They are invalid in any brainfuck language. In our syntax, you must use the following:

or <=> Ocaig5Es= <=> eeQu2Zad

These tokens are not operands, because they can only be considered:

or <=> @phai1Oa6@or@= <=> @phai1Oa6@=@

In other words, the injected statements become invalid or unavailable.

Policy 3: Verify the invariant

How many tokens are in the following template statement examples?

[1] select [2] * [3] from [4] T [5] where [6] f1 [7] = [8] ‘{value1}’ [9] and [10] f2 [11] = [12] {value2}

12. After the template is filled, the total number must still be 12, but we can see the results caused by the attacker:

[1] select [2] * [3] from [4] T [5] where [6] f1 [7] = [8] ‘anything’ [9] or [10] 1 [11] = [12] 1 [13] or [14] a [15] = [16] ‘whatever’ [17] and [18] f2 [19] = [20] 5

Now there are 20 tokens. In violation of such constants, problems are exposed. It is also applicable to the representation of the same statement, except for any brainfuck language. The filling of the template cannot change the number of tokens.

In fact, you can try to use other constants and perform verification after filling. Attackers must be consistent with them.

Conclusion

Some people advocate that programmers should be more careful when filling in SQL templates. To cope with SQL injection, you only need to be careful in programming. Obviously, this method is not a solution. People still encounter errors in verifying user input values, and finally accept malicious user input values. In other words, it cannot be solved simply by the effort of all of us.

The real solution is that the SQL statement itself is arbitrary and requires that all existing constants comply with any equivalent structure rules. It can be automatically completed without the intervention of programmers.

Attackers have to comply with an unknown and arbitrary brainfuck syntax rule. It will be difficult to solve to comply with an unknown set of rules. Therefore, attackers often cannot win.

Note

• Note 1: infix notation (or infix Notation) is a general expression of arithmetic or logical formulas. An operator is in the middle of an operand in the form of infix (for example, 3 + 4 ). Compared with prefix expressions (for example, + 3 4) or suffix expressions (for example, 3 4 +), the infix expressions are not easily parsed by computers, but are still used by many programming languages, because it is applicable to common usage. Https://zh.wikipedia.org/wiki/%E4%B8%AD%E7%BC%80%E8%A1%A8%E7%A4%BA%E6%B3%95
• NOTE 2: Polish notation (Polish notation, or Polish notation) is a logical, arithmetic, and algebraic representation. It is characteristic that operators are placed before operands, therefore, it is also called prefix notation. Https://zh.wikipedia.org/wiki/%E6%B3%A2%E5%85%B0%E8%A1%A8%E7%A4%BA%E6%B3%95

Translation:Alternative solution to SQL Injection | LABA porridge