SQL injection is the exploitation of a vulnerability related to SQL databases. The vulnerability is usually caused by a programming bug in a program that accesses the database. Due to this programming error, an attacker can inject database commands and, depending on the individual case, read further data from the database, change or delete data without authorization or even take control of the entire database server. Relational database management systems (RDBMS) such as Oracle, MySQL and Microsoft SQL Server are popular in the market as they are considered as reliable and avoid inconsistencies in the data sets, they have been set as the established standard for databases in most companies for decades. But, SQL injection is one of the common types of attacks on databases via web applications, so it is important to learn how to protect your business. Successful exploitation of a SQL injection requires:
- A SQL database, for example MySQL, Microsoft SQL Server, Db2
- An application program in which attackers can enter data, such as a login, a product search in an online shop or a contact form on the web
- The application can forward the data to the database
- A programming error in the application program when passing the data
- The programming error is that the application program does not pass on the input data to the database as pure data, but generates the database query from this data. This allows an attacker to attempt to target parts of the database query.
In the database query language SQL, some characters have a special meaning, in particular:
- the apostrophe enclose text data
- the quotation mark to enclose text data (some databases only)
- the backslash so as not to interpret the following character as a special character
- the semi-colon to separate a database command from the next database command
- a double hyphen to ignore the rest of the line (comment)
An attacker uses these characters specifically to carry out the attack. To run queries and edit the data in the database, Structured Query Language (SQL) is usually used.
How SQL Injection Usually Happens
For example, a webshop product search Server, run queries in a database and returns the results to the webshop as a search result. The stored information is vulnerable to so-called SQL injection, which injects arbitrary code into database queries. Attackers can also modify cookies to infect the query of the web application. The same is possible via server variables such as HTTP headers. Fake headers containing any SQL can inject this code into the database if the web application does not clean up this input either.
How to Prevent SQL Injection
To prevent SQL injections, user-entered data must not be readily incorporated into a SQL statement. Input data can be checked for the properties of expected values. However, the safest way is to keep the data away from the SQL interpreter at all. You can do without cutting the input. The technique for this are bound parameters in Prepared Statements. The data is passed as a parameter to an already compiled command. The data is thus not interpreted and SQL injection is prevented. Stored procedures, on the other hand, do not provide general protection against SQL injection, especially if the SQL code of the function is not known.
However, security precautions can also be taken on the database server-side. For example, the users with whom a Web application authenticates to the database server should have only the privileges that it needs. Thus, at least some of the possible attacks can become ineffective.
If a web server operator has no control over the applications, the use of Web Application Firewalls (WAF) can at least partially prevent SQL injection vulnerabilities from being exploited. Regardless of the control over the applications, an operator of a web server can additionally increase security through the targeted use of a WAF, since many WAFs offer not only defensive but also prophylactic measures.
It is not difficult to rebuild existing programs in such a way that SQL injections are no longer possible. The main problem of most programmers is a lack of knowledge about these types of attacks. In PHP, the PHP Data Objects library is available for database access.
Example without Prepared Statement:
$dbh->exec("INSERT INTO REGISTRY (name, value)
VALUES (".$dbh->"($name,PDO::PARAM_STR).", ".$dbh->"($value,PDO::PARAM_INT).")");
Example with Prepared Statement:
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
- Use input validation and filtering for user-submitted data. This will help to prevent dangerous character injections.
- It is safe to use prepared statements, or stored procedures and avoid dynamic SQL
- Update regularly
- Patch regularly
- Monitor SQL statements with tools (like Stackify)
- Use a web application firewall
- Limit privilage of the MySQL users (grant all not always required, you can test with different levels of privileges)
- Offload comment, search etc to third party server
- Consider to deactivate pingback, trackback functions in web applications
- Block port 3306
A comprehensive and detailed description of all relevant protective measures can be found in the SQL Injection Prevention Cheat Sheet from OWASP. If there is a loophole despite cleaning effort, it is necessary to restrict the privileges of database users. Commands such as “DROP TABLES”, should not be executable in a web application with a high risk of attack.
As for WordPress, new vulnerabilities are discovered each day. Use reputed plugins and avoid using null themes. Who has nulled the costly theme likely has worse money making idea.