
SQL Injection Attack: What is it, and how to prevent it.

The way that Yahoo! was hacked, SQL Injection attack, is the same
method as many other hacks in the news recently: SQL Injection. SQL
Injection attacks are common for the following reasons:
• The prevalence of SQL Injection vulnerabilities
• Databases are attractive targets because they typically contain critical application information
• The approach (i.e., the hack) is not new and is well documented on dozens of forums
While Tech Crunch reported
that many users were employing ridiculously weak passwords such as
“12345” and “password”, having a strong password, as I wrote about
recently in Fighting back against Anonymous, LulzSec and the global cyber insurgency, is worthless if the site servers or applications are not configured or patched appropriately.
So, what is a SQL Injection attack?
The point of an SQL Injection attack is to compromise a database,
which is an organized collection of data and supporting data structures.
The data can include user names, passwords, text, etc.
Structured
Query Language is the programming language used to manage data in a
database; more appropriately, a relational database management systems
(RDBMS). The types of management systems that employ Structured Query
Language include Microsoft SQL Database, Oracle, MySQL, PostgreSQL, and
others.
A simple example to get basic table name information would be the following:
Select * from table_name :
This
statement uses a wildcard (*) to return the contents of the table. The
hack could also include inserting information into the database, like a
new user for the purposes of doing bad things.
insert into users(username,userid) values("HackerBob","hb123");
The
point of the hack is not just to get information from the target site.
Depending on the intention of the malicious hooligans attacking you, it
can include to bypass logins, to access data as in the Yahoo! case, to
modify the content of a website as when hackers replace the website with
a new front page, or simply shutting down the server. Often it is a
combination of the above.
Step one of the attack is to scan
sited to see if a vulnerability exists. Believe it or not, a hackers
best friend is Google. Employing Google Dork, a hacker is able to search
for vulnerabilities using Google tricks. After a site is identified a
hacker will attempt to gain a foothold and search for files containing
usernames and directories that are known to contain sensitive data.
The
attack is opportunistic and does not take a lot of research or a large
team to pull off. Infact, you can go to Google directly and enter one of
the following commands as illustrated in a Ethical Hacking Tutorial online:
• inurl:index.php?id=
• inurl:gallery.php?id=
• inurl:article.php?id=
• inurl:pageid=
From the listing of sites that Google returns, you will then need to checked each site for vulnerabilities.
www.TargetSite.com + inurl:index.php?id=
In
fact the first site that comes back when you run inurl:article.php?id=
in a Google browser is also the topic of discussion on a hacker site HackeForums.net. The discussion starts:
“http://www.targetsite.org/article.php?id=129.
SQL The website is listed as having only one column, so I run into
problems when I try to...” The forum allows for collaboration between
hackers. Yikes!
I found an email for the targeted site and
contacted them regarding the vulnerability. Hopefully, they will forward
the email to someone who can take appropriate action.
The good news here is that these attacks are very simple to prevent or avoid. The Open Web Application Security Project has a SQL Injection Prevention Cheat Sheet, which outlined primary and additional defenses.
The primary defenses that are used to fight include,
• Prepared Statements (Parameterized Queries) - Parameterized
queries force developers to define all the SQL code, then pass in each
parameter to the query, which allows the database to distinguish between
code and data, regardless of what input is supplied.
•
Stored Procedures - a stored procedure is defined and stored in the
database itself, and then called from the application rather than
something that a user is allowed to enter.
• Escaping all
User Supplied Input - Each DBMS supports one or more character escaping
schemes specific to certain kinds of queries. If you then escape all
user supplied input using the proper escaping scheme for the database
you are using, the DBMS will not confuse that input with SQL code
written by the developer, thus avoiding any possible SQL injection
vulnerabilities.
Additional Defenses include
• Least
Privilege – or minimizing the privileges assigned to every database
account, so that users have enough permission to do their job, but no
more.
• White List Input Validation - Input validation is
used to detect unauthorized input before it is processed by the
application, thereby preventing the attack
Have you experienced an SQL Injection hack at your organization? How did your organization combat the attack? Let me know.