By the nature of my business, I have to perform security audits of the source code of web applications.
Lots of web apps and lots of code ...
In this article I would like to share one simple (very simple) truth and statistics that I derived and repeatedly checked during the last three years of viewing tons of PHP code.
It is no secret that vulnerabilities of the introduction of database operators (SQL injections) are the most common of all server-side web application vulnerabilities. There are platforms and frameworks where such things are almost completely excluded, for example, ORM and other things. But statistics stubbornly tells us about the absolute prevalence of web applications on the Internet with simple concatenated SQL queries. In addition, there are cases where ORM generally can not be applied. For example, when not only the parameters of expressions should depend on user data, but also the logic of the query at the operator level.
So, let's begin.
')
Useless character escaping
Found in 83% of PHP web applications vulnerable to SQL injections
The use of shielding characters such as
mysql_escape_string
mysql_real_escape_string
addslashes
without framing quotes. Most often manifested in numeric parameters (all kinds of * _id).
Example
$sql = "SELECT user FROM userslist WHERE userid=".mysql_real_escape_string($_GET['uid']);
In appearance, this is a safe code, but only in appearance. The most frequent template of SQL injection in PHP has crept in here. To attack this vulnerability from an attacker, you simply do not need to use "\ x00 \ r \ n \ x1a characters in the attack vector.
For example:
/index.php?uid=-777 UNION SELECT password FROM userlist
Search in code
Complicated by the semantics of the language. For a simple search, you can use egrep:
egrep -Rin "(select|update|insert|delete|replace).*(from|set|into).*(mysql_escape_string|mysql_real_escape_string|addslashes)" . | grep -v "[\"']['\"]"
The logic of the search expression is to find all the lines in which there is no sequence of quotation marks to the left of the filtering functions ('', "", "','"). The method, of course, is far from 100%, but it is impossible to require semantic analysis from a regular expression.
For the convenience of displaying information, you can highlight the function in the color in the console:
egrep -Rin "(select|update|insert|delete|replace).*(from|set|into).*(mysql_escape_string|mysql_real_escape_string|addslashes)" . | grep -v "[\"']['\"]" | egrep --color "(mysql_escape_string|mysql_real_escape_string|addslashes)"
To protect against this template vulnerability, it is best to use a type conversion.
It is always faster and more reliable than all sorts of filtering and screening.
For the example above, the patch might be:
$sql = "SELECT user FROM userslist WHERE userid=".intval($_GET['uid']);
At this short essay is over. I urge all web developers to try to stole their sources for such constructions. Better yet, expand the above search script for people.