Dvwa_ SQL for php code auditing and dvwa_ SQL _PHP for php auditing

Dvwa_ SQL for php code auditing and dvwa_ SQL for php auditing. Dvwa_ SQL for php code auditing and dvwa_sql0x00 for php auditing have been transferred to the onenote column, so I haven't published any new articles for a long time, but it is necessary to think about it, dvwa_ SQL for php code auditing and learning over the past few days, and dvwa_ SQL for php auditing
0x00

I 've been switching to the onenote column, so I haven't published any new articles for a long time, but it's quite necessary to think about it. I 've been learning php code auditing in the past few days, so let's start with these articles first!

First of all, let's start learning through dvwa, the top ten testing platforms. here, we will bring the reference links. thank you for sharing.

1. http://drops.wooyun.org/papers/483

2. http://www.lxway.com/86980986.htm is_numeric function bypass

3. http://www.cnblogs.com/Safe3/archive/2008/08/22/1274095.html character encoding bypasses wide byte injection

0x01

Here we will first introduce the simplest low-level php code

　　

$ Id = $ _ GET ['id']; // no filtering is performed, anti-injection processing $ getid = "SELECT first_name, last_name FROM users WHERE user_id = '$ ID' "; $ result = mysql_query ($ getid) or die ('
' . mysql_error() . '
');

We can see that this code does not actually process the id, leading to the SQL Injection Vulnerability. OK and all kinds of injection are acceptable. we will not detail it here!

0x02

Medium level, code:

$ Id = $ _ GET ['id']; $ id = mysql_real_escape_string ($ id); // Here, the id is Escaped. $ getid = "SELECTfirst_name, last_nameFROMusersWHEREuser_id = $ id ";

The mysql_real_escape_string function escapes the id parameter. common escape operations include:

• '=> \'
• "=> \"
• \=> \\
• \ N => \ n

Here I think there should be two methods to bypass this process:

1. numeric injection

Because this function is mainly used to process character-type special characters, we can inject them without special characters, that is, numerical injection.

　　

Construction: 1 untion select user, password from users

In this way, you can obtain the account and password in the users Table. of course, if you do not know how to change the name of the item table, what should you do? OK. We can try to use union bool injection.

Construction: 1 + union + select + 1, (select + case + when + char (72) = (select mid (table_name,) from information_schema.tables limit) + then + 2 + end)

Here, the values in char () need to be converted and limit, which may take a relatively long time. we can write a python script (ps: First occupies a pitfall ), in fact, latency injection can also achieve this effect.

2. wide byte injection

The mysql_real_escape_string method for escaping the parameter is to add a '\' and its url encoding is % 5c. in this way, we add % df % 5c % 27 to the parameter, where % df % 5c is a valid gbk character

After processing this function, we can find that it will change to % df % 5c % 5c % 27. in this way, % df % 5c will swallow a % 5c and become a gbk character + \\\'

The escape character of mysql is '\', which is equivalent to injecting a single quotation mark.

Construction: 1% df % 5c % 27% 20 | 1 + -- +

The same problem exists with the addslashes function. For more information, see the link at the beginning of this article.

0x02

High-level php code

$ Id = $ _ GET ['id']; $ id = stripslashes ($ id); // remove the slash $ id = mysql_real_escape_string ($ id) in the parameter ); // escape the special characters in the id if (is_numeric ($ id) {// determine whether it is a value or a numerical string...

Well, in this way, I think it is quite safe. The first two functions process injection of the numeric type, and then the is_numeric function processes the numeric injection.

However, this can still cause SQL injection, but it is a secondary injection, and the restrictions are harsh, but there is still a chance to cause injection.

For example, execute an SQL statement.

　　

　　insert into test(type) values($s);   

The input string $ s = 0x31206f722031

In this way, we can know that this is a hexadecimal number. we can use this function to detect and decode the hexadecimal number. we can find that the actual value of $ s is '1 or 1'

So what will the database look like?

　　

As you can see, the database transcodes the hexadecimal number to 1 or 1. then, the database value will be taken into another SQL statement without being processed, resulting in a secondary injection. therefore, when writing code, we cannot blindly trust the data in the database, and we still need to perform detection when extracting the data.

0x03

The code in the SQL section is analyzed here. if there are any errors, please click it!

Prepare SQL blind in the next article :)

0x00 has been transferred to the onenote column, so I haven't published any new articles for a long time, but it is very necessary to think about it. these days...