Let's remove PHP entirely from the equation for a moment.
SQL injection allows an attacker to manipulate the SQL query to be what he or she wants the query to execute. This can be dumping the contents of the database, modifying data, and even code execution.
The example you provided is indeed vulnerable to SQL injection. For the purposes of demonstration, let me simplify it a little:
mysqli_query($conn, "SELECT trans FROM dictionary WHERE word = '$search'");
Given a value of
security, the resulting query would appear like this:
SELECT trans FROM dictionary WHERE word = 'security';
This is innocent and normal. However, given the following, an attacker can obtain the version of MySQL that you are running:
' @@version -- -
This would cause the query to result in the following:
SELECT trans FROM dictionary WHERE word = '' @@version -- - ';
Ultimately, depending on permissions and configuration, an attacker can jump from one database to another in your database server, read files from the filesystem, or execute code. Here is an example of how an attacker can read files from a Linux-based OS:
' LOAD_FILE('/etc/passwd') -- -'
This then would result in the following query:
SELECT trans FROM dictionary WHERE word = '' LOAD_FILE('/etc/passwd') -- -'
There are a couple of things to keep in mind at this point:
- Not all SQL injection vulnerabilities are the same
- Techniques to read files, execute code, and dump databases will vary widely from language, backend database server, and the circumstances surrounding the vulnerability itself
Regardless, I would highly, highly, highly recommend that an SQL injection vulnerability be fixed through parametrization or whitelisting of user input depending on the needs of the functionality in question.
I started off with removing PHP from the discussion because SQL injection is not language and framework dependent - it impacts any language that allows database connectivity. Regardless of language, user input should be treated with suspicion and handled appropriately.