Preventing SQL Injection Attacks on your Joomla! Websites

Date Submitted: November 11 2008 11:33 am
This article is extracted from:
Joomla! Web Security

Joomla!, a very popular content management system (CMS) is as you may know an easy-to-deploy-and-use content management system. This ease of use has lent itself to rapid growth of both the CMS and extensions for it. You can install it on almost any host, running Linux or Windows. This highly versatile software has found itself in such lofty places as large corporate web portals, and humble places such as the simple blog.

Joomla! itself is inherently safe, but misconfiguration of the CMS, vulnerable components, hosts that are poorly configured, and weak passwords can all contribute to the downfall of your site. Hence, it's always better to ensure the security of your site.

In this article by Tom Canavan, we will take a look at how SQL injection attacks can occur to your Joomla website, how we can test for SQL injection attacks, and how to stop SQL injection.

Mark Twain once said, "There are only two certainties in life-death and taxes." Even in web security there are two certainties: It's not "if you are attacked", but "when and how" your site will be taken advantage of.

There are several types of attacks that your Joomla! site may be vulnerable to such as CSRF, Buffer Overflows, Blind SQL Injection, Denial of Service, and others that are yet to be found.

The top issues in PHP-based websites are:

  • Incorrect or invalid (intentional or unintentional) input

  • Access control vulnerabilities

  • Session hijacks and attempts on session IDs

  • SQL Injection and Blind SQL Injection

  • Incorrect or ignored PHP configuration settings

  • Divulging too much in error messages and poor error handling

  • Cross Site Scripting (XSS)

  • Cross Site Request Forgery, that is CSRF (one-click attack)

SQL Injections
SQL databases are the heart of Joomla! CMS. The database holds the content, the users' IDs, the settings, and more. To gain access to this valuable resource is the ultimate prize of the hacker. Accessing this can gain him/her an administrative access that can gather private information such as usernames and passwords, and can allow any number of bad things to happen. When you make a request of a page on Joomla!, it forms a "query" or a question for the database. The database is unsuspecting that you may be asking a malformed question and will attempt to process whatever the query is. Often, the developers do not construct their code to watch for this type of an attack. In fact, in the month of February 2008, twenty-one new SQL Injection vulnerabilities were discovered in the Joomla! land.

SQL Injection is a query put to an SQL database where data input was expected AND the application does not correctly filter the input. It allows hijacking of database information such as usernames and passwords, as we saw in the earlier example.
Most of these attacks are based on two things. First, the developers have coding errors in their code, or they potentially reused the code from another application, thus spreading the error. The other issue is the inadequate validation of input. In essence, it means trusting the users to put in the RIGHT stuff, and not put in queries meant to harm the system. User input is rarely to be trusted for this reason. It should always be checked for proper format, length, and range.

Testing for SQL Injections
The following examples are known good tests to detect some SQL Injection vulnerabilities.

Check for input vulnerabilities using "Single Quotes", as used in the following login form:

howdy' OR 1=1- -

This popular method is sometimes used in the form of a URL and you may see it appended to the INDEX.PHP in your log as follows:

/index.php?id=howdy' OR 1=1 - -

You may also wish to try inputting one of these popular methods:

' OR 1=1 - -

" OR 1=1 - -

'OR 'x'='x

There are several more methods and this only scratches the surface of SQL Injections. They attempt to pass unchecked INPUT to the database, which will try to divulge an answer, rather than providing no answer.

Note that you may see the use of the keyword UNION in your logs (see earlier examples). This is usually an early indicator that an attempt is being made on your site.

To learn more about SQL Injections from a developer's point of view, please refer to the following:

A Few Methods to Prevent SQL Injections
This is somewhat beyond the scope of this article, but the following are some things to touch upon:

Developers should ALWAYS validate the user input, that is, test for type, length, format, and range, and always consider what malicious input may be thrown at the queries.

DO NOT assume anything about the user input. For example, you shouldn't assume that an upload box for images won't be used for some other purpose. You should restrict the uploads to file types that you want to accept.

How will your application behave if a malicious user enters a 100-megabyte JPG where your application expects a username?

What will happen to your site if a DROP TABLE statement is embedded in a text field? What about a database command such as INSERT?

The answer is: Always enforce the size. If the maximum input is 2 Meg, then enforce it. Don't allow bigger inputs because your users might be unhappy. If the maximum character length should be eight, do not allow inputs beyond it. This will prevent a buffer overfl ow, and other madness.

Test the content of the string variables and accept only the expected values. Reject entries that contain binary data, escape sequences, and comment characters. This is a common technique.

DO NOT ALLOW SQL statements directly from the user input. Provide a solid user interface that validates the users' input and then uses it.

String concatenation is the primary point of entry for a script injection. So NEVER concatenate user input that is not validated, and has been checked to ensure that it has no nasty payloads.

ALWAYS assign user rights within your SITE (including you) with the LEAST privileges needed. This keeps down the possibility of using the unnecessary privileges to take over the site.

NEVER connect to the database as an admin, superadmin, or the database owner. Always keep these particular users for administrative use only.

And According to PHP.NET

"Check if the given input has the expected data type. PHP has a wide range of input validating functions, from the simplest ones found in Variable Functions and in Character Type Functions (for example, is_numeric(), and ctype_digit() respectively), and onwards to the Perl compatible Regular Expressions support.

If the application waits for numerical input, consider verifying data with is_numeric(), or silently change its type using settype(), or use its numeric representation by sprintf()."

There are commercially available tools such as Accunetix that can test for SQL Injections, and several sites that list recent and past extension vulnerabilities.

In essence, test your system using some of the methods mentioned, provide it an input that is totally off the wall, or find some of the exploits and try them on your test server.

Lastly, keeping your system patched is probably one of the best methods to prevent SQL Injections.

About the Author
A twenty-three year veteran of the Computer Business, and a Data Center Technology Consultant to Fortune-1000 Companies, Tom Canavan is a Certified Ethical Hacker and has a degree in Robotics and Numerical Control. He is author of the book Dodging the Bullets – A Disaster Preparation Guide for Joomla! Based Websites.

This article is extracted from:
Joomla! Web Security

Secure your Joomla! website from common security threats with this easy-to-use guide

  • Learn how to secure your Joomla! websites

  • Real-world tools to protect against hacks on your site

  • Implement disaster recovery features

  • Set up SSL on your site

  • Covers Joomla! 1.0 as well as 1.5

  • For more information, please visit