|Sign-Up for Free Exclusive Services:||Portals|||||eNewsletters|||||Web Seminars|||||dataWarehouse.com|||||DM Review Magazine|
|Covering Business Intelligence, Integration & Analytics||Advanced Search|
Enterprise Architecture View:
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.
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.
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:
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:
On the back end, list Accounts executes the following SQL code:
select * from accounts where account_id='
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:
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!
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 email@example.com.
|View Full Magazine Issue|
|E-Mail This Column|