SQL Injection is the exploitation of a vulnerability in the context of SQL databases, through the lack of masking or review of meta results in user input. The hacker tries, on the application or the CMS like WordPress (MySQL), to get the access to the database and inject own database commands. The goal is to spy out data, changing its meaning or to obtain the control over the server as basically softwares like WordPress stores all information in these database.
Basics of SQL Injection
SQL injection is possible if data such as user input reaches to the SQL interpreter. This happens because the user input can contain characters that have the SQL interpreter special function and allow running database commands even without full priviledge. Such SQL metacharacters include the backslash character (backslash), the quotes, the apostrophe and semicolon.
Often such gaps are CGI scripts and programs to find the data as web content or emails. Taking such a program before the owner can correct it, an attacker through the strategic use of function characters inject additional SQL commands or manipulate the queries so that the additional data can be changed or displayed. In some cases it is also possible to access a shell access to get what usually means the ability to compromise the entire server.
For various reasons we are avoiding to provide examples of SQL Injection. One can see such an example here :
Countermeasures for SQL Injection
Often filter or masking metacharacters are used in user input. This can mitigate the risk of SQL injection or eliminate it. In general, the Web application for the input of data needs to mask accordingly, that is basically responsible for this exploit. The simpler and safer way is, however, to keep all the data away from the SQL interpreter. The data is passed as a parameter to an already-compiled command. The data may not be interpreted and an SQL injection prevented. As a side benefit user can get a better performance too.
But also on the part of the database server there is need to meet the safety precautions. They should the user with which a Web application authenticates itself with the database server, possess only the privileges that they actually need. Thus, at least some of the possible attacks are ineffective.
Obviously, for this reasons, it is important to take regular backups.