Database Reference
In-Depth Information
SQL Injection
An API programthat accesses MySQL or MariaDB and is available to the public, on the
Web or from some other public access point, could be used to attack the database server.
Someone could maliciously manipulate the data given to the web page containing a script,
or the application that sends data to the server through an API. Specifically, a hacker could
embed an SQL statement in the data to be injected into the database. This is known as
SQL
injection
. The purpose could be to destroy data, retrieve sensitive or valuable information,
or create a user with all privileges and then access the server to steal information.
The vulnerability is related to the fact that string values are contained in quotes. To inject
SQL into a string value, a hacker just needs to close the open quote, add a semicolon, and
then start a new SQL statement. With numeric values, one can add an extra clause without
a quote and get at data.
For an example of an SQL injection, let's look the SQL statement used in the PHP API sec-
tion, but without a placeholder. Suppose we embedded the
$search_parameter
vari-
able inside the SQL statement like this:
$sql_stmnt =
"SELECT common_name, scientific_name
FROM birds
WHERE common_name LIKE '%
$search_parameter
%'"
Instead of entering a common name of a bird, suppose that a hacker entered the following
when using the API program, including the single quotes:
'; GRANT ALL PRIVILEGES ON *.* TO '
bad_guy
'@'
%
'; '
That will change our SQL statement to read like this:
SELECT
common_name
,
scientific_name
FROM
birds
WHERE
common_name
LIKE
'%'
;
GRANT ALL
PRIVILEGES
ON
*.*
TO
'bad_guy'
@
'%'
;
'%'
;
This results in three SQL statements instead of just the one intended. The hacker would re-
ceive a blank list of birds for the first. More important, based on the second SQL statement,
the system might create for him a user account with all privileges, accessible from any-
where and without a password. If the user account within the API programhas
GRANT TO
and
ALL
privileges for all of the databases, the
bad_guy
user account would be created
and have unrestricted access and privileges. The last bit of the malicious SQL statement
would just return an error because it's incomplete and doesn't contain an SQL statement.
