Hacking Book | Free Online Hacking Learning

Home

sql injection in php code auditing

Posted by truschel at 2020-03-26
all

Author: x1a0t (member of the code audit team of Xin'an Road)

The audit of SQL injection in code audit is very common, so how to audit a SQL injection?

As a rookie, the most common way is, of course, to crash - that is, to check where SQL is added or deleted in the code one by one and find the injection point. Of course, it is necessary to master certain methods to fight, otherwise it will take time and have little effect. Here is my personal summary of the kowtow process, for reference only

This article takes iwebshop5.1 as an example to see my audit process:

By collecting vulnerability information and checking function code in the early stage, we learned that CMS wrote methods to get variables in IREQ class and methods to filter in ifilter class. Take a look at the act method that will be used throughout this CMS:

The protection code is relatively long and the effect is very good. If it is used correctly, it will not be a problem. The second parameter of the filtered method specifies the form of the filter. If the second parameter is passed in string or not, the variable content will be escaped.

OK, the key point is coming. If you receive the incoming parameters, you need to escape them. Once the programmer splices the SQL statements with no quotation marks, it will lead to SQL injection. So, we can knock down such a possible vulnerability point to search the code

According to the situation, use the editor's global regular matching ifilter:: act \ (. +'string '\) and ifilter:: act \ (. + [^'] {1} \) (please don't mind if you write the regular badly), search the foreground code, after all, the foreground SQL is harmful. Then follow up the code until the part of the SQL statement

IFilter::act\(.+'string'\) IFilter::act\(.+[^']{1}\)

Here's where I find the code: Controller / seller.php: 1498

/controller/seller.php:1498

Finally, the content received by $ID will enter the goods_class:: catchild to view:

$id goods_class::catChild $catDB->query

The filtering of select is only matched by two forms. We can make complaints about select%0a and select (and the other ones). This kind of anti injection code usually needs attention at the beginning of audit, and it will affect the direction of vulnerability point if it is strictly prevented.

select%0a select( ()

Loophole utilization

1. Register the merchant account, pass the background audit (reappearance can directly add merchants in the background), and then add a classification in the commodity classification for blind time annotation

2. The front desk logs in to the merchant management, and the structure is similar to the following data package

URL:

/index.php?controller=seller&action=categoryAjax

POST:

id[]=0 and if(ascii(substr((select%0aadmin_name from admin),1,1))%3d97,sleep(10),1)&parent_id=0

(the table name admin here does not need to add a prefix, CMS will add it automatically)

Of course, using sqlmap to run blind injection is more convenient:

summary

Here are two more vulnerability points that may cause SQL injection and the keywords searched in the editor:

SQL statements written or spliced directly, global regular matching ['"] {1} [select| update| insert| delete]

['"]{1}[select|update|insert|delete]

Possible vulnerability points exist in SQL operation functions, such as where function in ThinkPHP, where \ (. + [\ $\.] for global regular matching

where\(.+[\$\.]

As a novice, read more code, do not rush to success, and finally willing to like the code audit of novice friends, eventually become a big man!