Preventing SQL Attacks
SQL injection attacks
are one of the most dangerous programming errors. (Paul Rubens, 2010) SQL injection attacks are a real
problem for many organizations. SQL injection attacks could “allow hackers to
compromise your network, access and destroy your data, and take control of your
machines” (Paul Rubens, 2010) . Organizations need
to be sure that they determine if they are at risk for SQL injection attacks. Organizations
can easily become victim to an SQL attack if they do not know how to protect their
selves from them.
SQL injection attacks
are very interesting in nature. “The principal behind an SQL injection is
pretty simple. When an application takes user data as an input, there is an
opportunity for a malicious user to enter carefully crafted data that causes
the input to be interpreted as part of a SQL query instead of data” (Paul Rubens, 2010) . Therefore, if an
attacker knows what exactly to try they can easily use SQL injection attacks
for malicious reasons. SQL attacks can cause a loss of confidentiality, data
integrity, and data. (Paul Rubens, 2010) An SQL attack could
even compromise an entire network. (Paul Rubens, 2010)
Organizations
should be prepared to help mitigate the risk of an SQL injection attack. There
are many techniques that an organization can take do to help prevent SQL
injection attacks. More specifically, an organization should do the following:
1. “Trust no-one:
Assume all user-submitted data is evil and validate and sanitize everything” (Paul Rubens, 2010) .
2. “Don't use
dynamic SQL when it can be avoided: Used prepared statements, parameterized
queries or stored procedures instead whenever possible” (Paul Rubens, 2010) .
3. “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” (Paul Rubens, 2010) .
4. “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” (Paul Rubens, 2010) .
5. “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” (Paul Rubens, 2010) .
6. “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”
(Paul Rubens, 2010) .
7. “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” (Paul Rubens, 2010) .
8. “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” (Paul Rubens, 2010) .
9. “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” (Paul Rubens, 2010) .
10. “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” (Paul Rubens, 2010) .
Reference
Paul Rubens. (2010, February 23). 10 Ways to
Prevent or Mitigate SQL Injection Attacks. Retrieved October 26, 2013, from
Enterprise Networking Planet:
http://www.enterprisenetworkingplanet.com/netsecur/article.php/3866756/10-Ways-to-Prevent-or-Mitigate-SQL-Injection-Attacks.htm
