MYSQL Solution SQL injection of the alternative method of detailed _mysql

The example in this article describes the alternative way MySQL solves SQL injection. Share to everyone for your reference, specific as follows:

Interpretation of the problem

I think the cost of this problem can be as high as billions of dollars a year. This article is to talk about, assuming we have the following SQL template statement:

SELECT * from T where f1 = ' {value1} ' and F2 = {value2}

Now we need to populate the statement based on user input values:

Value1=hello
value2=5

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

SELECT * from T where f1= ' Hello ' and f2=5

The problem is that an attacker could construct the following user input values:

Value1=anything ' or 1=1 or f1= ' whatever
value2=5

A good final statement becomes:

SELECT * from T where f1= ' anything ' or 1=1 or f1= ' whatever ' and f2=5

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

Description of the general solution

SQL is an axiom of arbitrariness and consistency, and token and derivation rules form its axiomatic basis. One of the words to note is "arbitrariness". and SQL equivalent of the public physics and chemistry countless. For this arbitrary equivalence representation, every valid statement can be accurately mapped to the legitimate statements in SQL, as are other languages. In this arbitrary equivalence representation, if a statement is illegal, it is also illegal in SQL. It is not possible for an attacker to construct a rule that satisfies any possible arbitrary and SQL equivalence.

Strategy 1: Expand the template statement with another syntax, based on different derivation rules

Example 1: Prefix language

SQL uses infix notation Note 1. Infix notation is equivalent to the Lisp-style prefix notation Note 2. Infix and prefix:

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

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

Example statement for prefix notation:

(SELECT * T (and (= F1 ' {value1} ') (= f2 {value2}))

The statement is equivalent. They are semantically extensional. Automatically converting the infix notation of SQL into prefix notation or other representations is not a problem. However, an attacker's injection is not legal in terms of prefix syntax:

Copy Code code as follows:

(SELECT * T (= F1 ' anything ' or 1=1 or a= ' whatever ') (= F2 5))

Syntax error. What the attacker wants is:

Copy Code code as follows:

(SELECT * T (or (= F1 ' anything ') (or (=1 1) (and (= a ' whatever ') (= F2 5))))

This is different. An attacker's injection cannot output a valid prefix language.

Example 2: Euler notation

Another alternative would be to named sizable Euler notation. From prefix notation to Euler:

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

The statement in the example:

Select (*,t,and (= (F1, ' {value1} '), = (f2,{value2}))

The injected statement will receive a syntax error:

Copy Code code as follows:

Select (*,t,and (= (F1, ' anything ' or 1=1 or a= ' whatever '), = (f2,5)))

The attacker would have wanted to write:

Copy Code code as follows:

Select (*,t,or = (F1, ' anything ', or (= (1,1), and (= (A, ' whatever '), = (f2,5))))

The attacker is doing the wrong thing. His injection simply did not notice the chosen arbitrary notation.

Example 3: Object tagging method (notation)

There is also an alternative method of object tagging. Prefix representations to objects:

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

Examples of code:

T.where (f1.= (' {value1} '). and (F2.= ({value2})). Select (*)

The infusion is once more broken into the grammar:

T.where (f1.= (' anything ' or 1=1 or a= ' whatever '). and (F2.=5)). Select (*)

I no longer provide the correct answer, and the reader can act as an exercise to see what the attacker should be.

Strategy 2: Choose any other token for SQL

Keyword is often an arbitrary token in a language. What matters is their place in the derivation, not the arbitrary manifestation of them. You can always replace the existing keyword with other keyword and switch back and forth. For example, we can convert the keyword in the following SQL statement to what we call "arbitrary brainfuck": "

Copy Code code as follows:

{"Select": "Iph0ohki", "*": "Iezoh4xa", "from": "Aezi5uja", "where": "ooj4ax4n", "=": "Eequ2zad", "(": "Eid5aera", ")": " Soo2uach "," or ":" Ocaig5es "}

For argument's sake, we'll map the operands to a semi arbitrary structured sequence:

T <=> @phai1Oa6 @t@
Hello <=> @phai1Oa6 @hello@

PHAI1OA6 is any selected sequence of characters. For the current situation, examples:

SELECT * from T where f1 = ' {value1} ' and F2 = {value2}

has become:

Iph0ohki iezoh4xa Aezi5uja @phai1Oa6 @t@ ooj4ax4n @phai1Oa6 @f1@ eequ2zad ' {value1} ' @phai1Oa6 @and@ @phai1Oa6 @f2@ Eequ2zad {value2}

This is a legal, arbitrary brainfuck language. After being injected, we got the following:

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, it contains token ' or ' and ' = ' that are illegal in any brainfuck language. Our grammar says that you have to use this:

or <=> ocaig5es
= <=> Eequ2zad

These token are also not operands, as they will only be treated as:

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

In other words, the injected statement becomes illegal and unusable.

Strategy 3: Validating invariants

Do you count the number of token in the template statement example below?

[1] SELECT [2] * [3] from [4] T [5] where [6] f1 [7] = [8] ' {value1} ' [9] and [a] f2 [one] = [one] {value2}
12 A. After the template is populated, the total must still be 12, but we see the result of the attacker:

[1] SELECT [2] * [3] from [4] T [5] where [6] f1 [7] = [8] ' anything ' [9] or [ten] 1 [one] [[] 1 [] or [a] [15] = [1 6] ' whatever ' [[] and [] f2 [19] = [20] 5

There are now 20 token. The violation of such invariants exposes a problematic place. The same applies to the expression of the same statement, in addition to the arbitrary, Brainfuck language. The template's padding simply cannot cause a change in the number of token.

In fact, you can try to use the other invariants and validate them after the fill. Attackers must be consistent with them.

Conclusion

Some people advocate that programmers should be more careful when populating SQL templates. The problem with SQL injection is that you need to be more careful about programming. Obviously, this approach is not a solution. People still have errors in validating user input values and eventually accept malicious user input values. In other words, it is impossible to solve this problem simply by working harder for all of us.

The real solution is the arbitrariness of the SQL statement itself and the requirement that all existing invariants conform to the rules of any equivalent structure. It can be done automatically without the programmer's intervention.

An attacker would have to conform to an unknown, arbitrary rule of brainfuck syntax. Trying to conform to a set of unknown rules will be a difficult problem to solve. As a result, attackers often fail to succeed.

More information about MySQL interested readers can view the site topics: "MySQL Log operation skills Daquan", "MySQL Transaction operation skills Summary", "MySQL stored process skills encyclopedia", "MySQL database lock related skills summary" and "MySQL commonly used function large summary"

I hope this article will help you with the MySQL database meter.