Re: DB2 - SQL Injection

[<cris_dewitt () hotmail com>]

In-Reply-To: <BAY20-F554B6A6F95D6B05A69570B8610 () phx gbl>

Hey, this is from my friend who knows something about DB2 - I have no clue what he's talking about, but
ya'll will...cd

As for your SQL injection friends, this may be a start:

Your login identity is accessible through the variable USER. With WebSphereconnections are typically made by a powerful 
user and pooled, securityprovided by the application. Since the app seems pretty weak in this respect, your friend 
probably has a powerful connection (lots ofauthorization) at his disposal.

The login user is the default schema you are associated with when you login, though this can be changed. The schema 
provides a space within which youcan search for tables, so you don't have to try every table in the system(though there 
really aren't usually all that many tables). Using SYSIBM.SYSTABLES you can find the tables in your schema with select 
NAME from SYSIBM.SYSTABLES where CREATOR = USER

There is also a SYSIBM.SYSCOLUMNS table you can use to query for the names of columns in a table:
select NAME from SYSIBM.SYSCOLUMNS where TBCREATOR = '<schema name here>' and TBNAME='<table name here>'

There are also useful views built over these system tables, like SYSCAT.TABLES and SYSCAT.COLUMNS, that have the 
advantage that they're more likely to be the same from release to release.

The simple solution to this whole (SQL injection) problem seems pretty clear, or am I missing something? Just don't 
generate SQL by manipulating text. Use embedded SQL, use prepared statements, use stored procedures, use ...