Injection SQL

A injection SQL is a type of exploit ation of a Security breach of a Web application, by injecting a request SQL not envisaged by the system and being able to compromise its safety.

Example

Let us consider a dynamic Web site (programmed for example in) which has a system allowing the users having a name of valid user and a password to connect itself. This site uses following request SQL to identify a user:

SELECT uid WHERE name = “(name)” AND password = “(encrypted password)”

The Dupont user wishes to connect himself with his password " truc". The following request is carried out:

SELECT uid WHERE name = “Dupont” AND password = “45723a2af3788c4ff17f8d1114760e62”

To tackle the request

Let us imagine now that script PHP carrying out this request does not check the entering data to guarantee its safety. A Hacker could then provide following information:

User: Dupont' --
Password: any

The request becomes:

SELECT uid WHERE name = “Dupont” -- 'AND password = “4e383a1918b432a9bb7702f086c56596e”

The characters -- marks the beginning of a comment in SQL. The request is thus equivalent to:

SELECT uid WHERE name = “Dupont”

The pirate can then connect himself under the Dupont user with any password. It is about an injection of successful SQL, because the pirate managed to inject the characters which he wanted to modify the behavior of the request.

Solution

Here, the solution consists in correctly treating the Character strings entered by the user.

In PHP one can use for that the function mysql_real_escape_string, which will transform the chain ' -- in \ ' --. The request would become then:

SELECT uid WHERE name = “Dupont \” -- 'AND password = “4e383a1918b432a9bb7702f086c56596e”

The apostrophe of end of chain die-having been correctly specialized by making it precede by a character “\”.

The exhaust can also be done (according to DBMS used) by doubling the apostrophes.

The mark of comment will form part of the chain then, and finally waiter SQL will answer that there is no entry in the database corresponding to the user Dupont' -- .

The function addslashes is not enough to stop the injections via the numeric variables, which are not framed apostrophes or quotation marks in requests SQL. Example with the request:

SELECT… FROM… WHERE numero_badge = $numero AND code_4_chiffre = $code

who succeeds when the variable $numero contains 0 gold 1=1 --. A precaution is to use the function is_numeric to check the numeric variables of the requests. One can also force the transformation of the variable of number by it making precede by a transtypor , as (int) if one awaits an entirety (the chain 0 gold 1=1 -- will then be transformed into the entirety 0 and injection SQL will fail).

The function addslashes has itself some faults on certain versions of PHP which date. Moreover, she escapes only the characters ““” and “" ”. It would be more adapted to use the function mysql_real_escape_string which is precisely created to escape the special characters from an order SQL (NO ONE, \ x1a, \ N, \ R, \,”, " and \ x00).

How to avoid these attacks

These attacks can be avoided in several ways:

To use stored procedures, in the place of dynamic SQL. The data entered by the user are then transmitted like parameters, without risk of injection.
To check in a precise and exhaustive way the whole of the data coming from the user. One can, for example, to use a rational Expression in order to validate that a data entered by the user is well of the desired form.
To use accounts users SQL with limited access (into reading-only) when that is possible.
To activate internal protections like the option magic_quotes_gpc in.

See too

Vulnerability (data-processing)

External bonds

bases of injections SQL: How to locate them, exploit them, correct them
injections SQL as a blind man (Blind SQL Injections)
ms Access SQL Injection Cheat Sheet
Illustration of an attack SQL (drawing)

Random links: