SQL Injection is one of the most common website security vulnerabilities in which the programmer carelessly applies user input to a database command.
For example, a vulnerable website for Super Big Data Innovators allows users to
view profile pages for its corporate staff. The web address
http://superbigdatainnovators.com/profiles/jappleseed is supposed to show the
profile for it’s CEO Johnny Appleseed. The profiles for its other officers are
similarly available by replacing
jappleseed with their username.
The implementation of this page performs a query against the content
database to the effect of
Get me the user data for user _____ where the blank
would be filled in from the URL. For example, on the page
the blank would be
/profiles/mmouse, it would be
But what if a mischievous user typed in the URL
/profile/jappleseed and then delete the users table?
If the website programmer did not account for this, the command to the database
Get me the user data for user jappleseed and then delete the users
table. The database has no way of knowing that this was not the intended
command: it just does as its told.
- SQL injection can lead to the disclosure of sensitive data including user profile data, passwords or other PII.
- Privileged financial or proprietary information can be leaked to unauthorized users
- Malicious users can damage the database by performing mass delete operations.
- Use SQL Parameters. Most databases allow the query to separate command from
parameter. For example,
Get me the user data for user $1. Parameters: $1 -> "jappleseed".
- Use proper and wrapping of data. If this was used, the database command would
Get me the user profile for user 'jappleseed'. If the prankster sends extra data, it would sill be contained inside the quote:
Get me the user profile for user 'jappleseed and delete the products table'. The database would not find a user with username
jappleseed and delete the products tableand so the page would report a not found error. Database APIs provide functions to properly wrap data so that even if the bad data contains a
'character, the query would still be safe.
- Secondarily, configure database permissions so the web server only has access to the data it needs. For example, it needs read-only access to the products table but will need to write changes to the user table when users change their passwords or profile information. This should not be the primary mitigation technique, but is a nice extra.
- In a vulnerable site, every single query must be manually audited by a qualified software developer.