Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search

View all Portals

Scheduled Events

White Paper Library
Research Papers

View Job Listings
Post a job


DM Review Home
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

Buyer's Guide
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

About Us
Press Releases
Advertising/Media Kit
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Enterprise Architecture View:
The Weakest Link, Part 2

  Column published in DM Review Magazine
March 2003 Issue
  By Michael Jennings and Paul Clip

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!


For more information on related topics visit the following related portals...
Enterprise Intelligence.

Michael Jennings is a recognized expert with more than 20 years of information technology experience and speaks frequently on business intelligence/architecture issues at major industry conferences and has been an instructor at the University of Chicago's Graham School. He is a co-author of the book Universal Meta Data Models and a contributing author of the book Building and Managing the Meta Data Repository. He works for EWSolutions, a GSA schedule and Chicago-headquartered strategic partner and systems integrator dedicated to providing companies and large government agencies with best-in-class business intelligence solutions using data warehousing, enterprise architecture and managed meta data environment technologies (www.EWSolutions.com). He may be reached directly via e-mail at MJennings@EWSolutions.com.

Paul Clip is a managing security architect at @stake, the world's leading independent digital security consulting firm. Clip has more than 10 years of IT and security experience and is a technical lead for @stake's Application Security Center of Excellence. He can be reached at pclip@atstake.com.

Solutions Marketplace
Provided by IndustryBrains

Autotask: The IT Business Solution
Run your tech support, IT projects and more with our web-based business management. Optimizes resources and tracks billable project and service work. Get a demo via the web, then try it free with sample data. Click here for your FREE WHITE PAPER!

Manage Data Center from Virtually Anywhere!
Learn how SecureLinx remote IT management products can quickly and easily give you the ability to securely manage data center equipment (servers, switches, routers, telecom equipment) from anywhere, at any time... even if the network is down.

Increase Your Existing Data Center Capabilities
Robert Frances Group believes that the enterprise data center is undergoing significant and sustained transformation?and that Azul Systems has delivered on a new approach to delivering processing and memory resources to enterprise applications...

Design Databases with ER/Studio: Free Trial
ER/Studio delivers next-generation data modeling. Multiple, distinct physical models based on a single logical model give you the tools you need to manage complex database environments and critical metadata in an intuitive user interface.

Free EII Buyer's Guide
Understand EII - Trends. Tech. Apps. Calculate ROI. Download Now.

Click here to advertise in this space

View Full Issue View Full Magazine Issue
E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2006 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.