What is SQL Injection?
The ability to inject SQL commands into the database engine through an existing application is termed as SQL Injection Attack.
SQL injection is a type of security exploit in which the attacker adds SQL statements through a web application’s input fields or hidden parameters to gain access to resources or make changes to data.
I have already covered this in past, please check my previous post, “How to Secure against SQL Injection?”
HOW Server SQL Server Injections Works ?
Can you describe how SQL Server can be compromised / hacked via SQL Injection ?
Here is a quick DEMO to illustrates, How SQL Server Injection works
If these SQL Server Injects are so vulnerable, then
How can I prevent / Stop SQL Injection ?
The best way is to carefully sanitize user input. SQL Server Injections can be easily avoided if Developers need to either:
- stop writing dynamic queries; and/or
- prevent user supplied input which contains malicious SQL from affecting the logic of the executed query.
There is a beautiful article published by Dave Wichers, which provides a set of simple techniques for preventing SQL Injection vulnerabilities by avoiding these two problems. These techniques can be used with practically any kind of programming language with any type of database. This article is available here.
But this few bullet points, which I do share with my all clients.
- Trust no-one: Assume all user-submitted data is evil and validate and sanitize everything.
- Don’t use dynamic SQL when it can be avoided: used prepared statements, parameterized queries or stored procedures instead whenever possible.
- Update and patch: vulnerabilities in applications and databases that hackers can exploit using SQL injection are regularly discovered, so it’s vital to apply patches and updates as soon as practical.
- Firewall: Consider a web application firewall (WAF) – either software or appliance based – to help filter out malicious data. Good ones will have a comprehensive set of default rules, and make it easy to add new ones whenever necessary. A WAF can be particularly useful to provide some security protection against a particular new vulnerability before a patch is available.
- Reduce your attack surface: Get rid of any database functionality that you don’t need to prevent a hacker taking advantage of it. For example, the xp_cmdshell extended stored procedure in MS SQL spawns a Windows command shell and passes in a string for execution, which could be very useful indeed for a hacker. The Windows process spawned by xp_cmdshell has the same security privileges as the SQL Server service account.
- Use appropriate privileges: don’t connect to your database using an account with admin-level privileges unless there is some compelling reason to do so. Using a limited access account is far safer, and can limit what a hacker is able to do.
- Keep your secrets secret: Assume that your application is not secure and act accordingly by encrypting or hashing passwords and other confidential data including connection strings.
- Don’t divulge more information than you need to: hackers can learn a great deal about database architecture from error messages, so ensure that they display minimal information. Use the "RemoteOnly" customErrors mode (or equivalent) to display verbose error messages on the local machine while ensuring that an external hacker gets nothing more than the fact that his actions resulted in an unhandled error.
- Don’t forget the basics: Change the passwords of application accounts into the database regularly. This is common sense, but in practice these passwords often stay unchanged for months or even years.
- Buy better software: Make code writers responsible for checking the code and for fixing security flaws in custom applications before the software is delivered. SANS suggests you incorporate terms from this sample contract into your agreement with any software vendor.
Can I test my application / Server for SQL Injection?
As part of Quality Assurance, all applications are being tested for potentials SQL Injections. These are mostly used test, which must be performed to avoid potential SQL Injections and these are available mosty all automated QA testing softwares.
-
SQL Injection Detection – Identify sources from where Hacker can pass SQL Injections / User Interfaces.
-
Standard SQL Injection Testing – Test Inputs which are potential SQL Injections.
-
Blind SQL Injection Testing – Ensure the Database Server Error Message are not directly passed on to User.
A great article, Testing for SQL Injection, which describes about all testing techniques with examples.
Tool to test your web application for SQL Injections Threats ?
HAVIJ is one of the tool to test your web application for SQL Injection, Here is a quick demo for using this tool to test your website for SQL Injection.
Is there any Device available, which can Scan SQL Injections ?
There are various products, which are available in market to avoid SQL Injection but these products just filters HTTP querystring values and other HTTP headers to mitigate SQL injection attacks but they not 100% secured. But definitely they do help at web server levels.
The best way to handle is to mitigate the root cause in the application.
