It is generally being reported across the web that the use of SQL injection attacks by distributers of pornographic materials and malware is on the rise. Injection attacks will try to add url links, script containing popups, redirects to malware sites or inapropriate text to your site's database. Once inserted these unwanted materials will manifest in your site's visitors browsers. Yours visitors will of course blame you!
An SQL injection attack is where an unwelcome user of a web site passes code to the server that is designed to execute in the database layer. Code is usually passed on the query string or in the post and masquerades as known parameters for existing pages.
Many developers fail to realise the significance or the sophistication of these attacks. Some developers wrongly believe that attacks can only be made against pages that are designed to write to the database, however this is not the case. Most attacks will be leveraged on pages that simply retrieve records from a database.
There are many different defences against SQL Injection and the most security aware sites will implement many of these together. Methods include:-
1. Securing the database user
2. Using parameterised queries to access the database
3. Validating that all user input from post, query, cookies etc is validated to a known pattern
4. Searching inputs for known database keywords and injection characters
The above list is roughly in order of importance yet many developers over the years have elected to stop injection by item 4, searching for known injection characters and keywords.
The current rise in successful attacks is in part down to the use of encoding to pass the injection code in a form that does not contain any recognisable database keywords or injection characters until it is decoded at the database layer by which time it is too late to do anything about it.
The most important method is, however, to secure the database such that the database user object used by your website has the lowest possible privaledges allowing them to do only that which you intended they could do.
Even this is, of course, less than simple and there are a number of things that administrators often overlook.
If your site never updates the database then all is well and you can provide the database user with readonly access the the table ensuring that no attack will succeed.
If, like many, you are trying to capture shopping cart details, contact requests or simply log access then it is likely you will be providing write access to tables. Where this is the case then the most important protection against an injection attack is to ensure that the attacking script will not be able to gain access to a list of table names - typically this will stop all automated scripts as without the table names it is not possible to construct valid SQL statements.
Sadly Microsoft SQL (and others) make it all too easy to gain access to table names. Try running the following statements on your MS SQL database using a user that in your opinion only have read and write access to the web database and no access to the master tables
SELECT * FROM sysobjects
or
SELECT * FROM sys.tables
The second command will only succeed in MS SQL 2005 and above.
It is likely that your "secure user" can execute these commands and if so your site is open to the most prevalent set of injection attacks.
It is a simple process to resolve these insecurities by running the following commands whilst connected to the relevant database(s) as an administrator.
DENY SELECT ON sysobjects to [databaseusername]
DENY SELECT ON syscolumns to [databaseusername]
where [databaseusername] is the user object used by your web code to access the database
If you are running on MS SQL 2005 or above (including SQL Express) you should also deny access to the SYS Schema with the following additional command whilst connected to the relevant database(s) as an administrator.
DENY VIEW DEFINITION TO [databaseusername]
It should not be impossible for any script to gain access to the objects necessary to read the table names in your database and although not perfect you have made a significant step towards greater security.
