Re: DB2 - SQL Injection

From: cris_dewitt@hotmail.com
Date: Tue Feb 22 2005 - 16:08:11 EST


('binary' encoding is not supported, stored as-is) 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 ...



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:17 EDT