Mike extends a special thanks to Paul Clip for his invaluable contribution to this month's column.

Security threats can compromise your Web-enabled data warehouse environment, whether it is accessible through the Internet or buried deep within your internal network. Do you really know for sure if your data warehouse implementation is secure?

This is the second portion of a three-part column on security vulnerabilities of the data warehouse environment. This installment examines four of the most common application vulnerabilities found in front-end business intelligence applications, many of which involve input validation. How well an application defends itself against malicious or erroneous user input directly correlates to its level of susceptibility and ease of exploit. Next month's column will examine measures that can be applied to increase the security of your data warehousing environment to minimize your risk of exposure.

Information Leakage

Often the first activity an intruder will perform is to look for information leakage ­ any clue that could help in mounting a successful attack. The most obvious place to look is in Web pages themselves. HTML and JavaScript comments often reveal useful information such as application version numbers, hidden variables, code or links that have been commented out but still function if called. For example, one product reveals the full directory path where data files were being stored, enabling an attacker to use another exploit to download them directly, bypassing application-level checks.

Parameter Manipulation

Parameter manipulation is a rather broad description of a very simple fact: It is possible to tamper with every piece of information and every parameter sent by the browser to the server which is why security practitioners frequently admonish never to trust user input. In its simplest form, the parameters being changed are typically found in URLs. Let us examine the following scenario where users can select an account to view its details: https://server/listAccount?acct=13302

It is easy for users to change the acct parameter to a value other than "13302," hoping that the reporting application will not verify whether the account information it displays actually belongs to the user requesting it.

One step up in complexity brings us to modified HTML form fields, specifically hidden fields. HTML forms are typically used when requesting that the user fill out multiple fields (e.g, as part of a report request). Most fields are visible, but often an application will embed application-specific information in Web pages via hidden fields.

Obviously, the information may be hidden, but it is still accessible. Anybody can view the HTML source to look for these fields, and application security tools such as @stake WebProxy make it very easy to see how the application responds when variables are modified on the fly.

What such attacks can achieve is highly dependent on the functionality invoked by the form. For example, a portal login form has two hidden fields:

Simply swapping the values of the success and failure variables would display the main customer page, even though the login actually failed.

Cross-Site Scripting

One of the most notorious security attacks, cross-site scripting (CSS), results in an attacker's ability to execute code (typically JavaScript) on another user's browser. Let us step through an example. A disgruntled business analyst wants to access an ad hoc reporting application with the same access rights as his manager. The analyst knows that he will then be able to view the salaries of the manager's other employees.

Rather than staying late after work and searching the manager's office for the password (studies have shown that as much as 70 percent of passwords are found within 10 feet of the required computer), the analyst does something sneakier. He has noticed that the bulletin board functionality of the Web site allows posting of both text messages and HTML. Therefore, he cleverly creates a message for the manager to read with the following code:

Running a Web server on his workstation, the analyst waits for the trap to close. As users view the manager's message on their browsers, they are unwittingly executing the analyst's embedded JavaScript. All it does is connect to the analyst's Web server, request an image and, at the same time, disclose that particular user's cookie. Reviewing the log files, the analyst can now use various tools to hijack other users' sessions because their only unique identifier is their cookie ­ which the analyst now has. The analyst may need to try a number of cookies before finding the manager's cookie. Alternatively, he could have created a message specifically for the manager. Once the analyst has the cookie, he deletes the original message, leaving virtually no trace of the crime.

SQL Injection

Many reporting applications allow users to enter SQL queries. Often, applications that do not support SQL queries are designed to append a user's input to SQL queries directly. Both of these actions can create just the opportunity an attacker needs to perform SQL injection. SQL injection attacks find ways to insert SQL code into applications in order to gain control of a system.

Let us build on our parameter manipulation example. Instead of just supplying a different account number, suppose we supplied SQL code:

https://server/listAccount? acct=100132'+OR+1=1;­

On the back end, list Accounts executes the following SQL code:

select * from accounts where account_id=' '

Where is replaced by the user-supplied account number. What happens when our SQL code is passed to the server? The query becomes (in HTTP, a plus sign denotes a space):

select * from accounts where account_id='100132' OR 1=1;­'

The first part looks normal, but the "OR 1=1" will cause the where clause to always be true. Therefore, all rows are returned, potentially revealing confidential data.

SQL injection can also be used in other ways. Think of what could have happened if an attacker had submitted this:

https://server/listAccounts? acct=100132';drop+table+accounts;­

Finally, actual SQL may not be the only code executed on the database. Many DBMSs have a host of stored procedures installed by default. Some even enable running any executable already present on the database server itself. So much for putting your server behind two layers of firewalls!

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access