On Mon, 13 Aug 2007 16:55:34 -0400 Art Protin <[EMAIL PROTECTED]> wrote:
> >It may seem adequate, but it isn't. Table/column names from external
> >sources have to deal with the exact same set of data injection issues
> >that values from external sources do.
> It is a mistake to say "the exact same set of data injection issues" for
> while they
> are data injection issues, they are not exactly the same.
> Table names are a different type than are column names
> which are different from strings or integers.
> A valid string is any string of characters shorter than some maximum
> that uses characters from some acceptable character set.
> Processing a string parameter involves simply checking the
> length and character set.
> Processing an integer involves simply checking sign and size constraints.
>
> A column name is much more constrained than that,
> no only must its characters be from a more limited alphabet,
> the name is not case sensitive, and the name must, depending on the
> operation,
> either exist or not exist within a specified table definition.
You can use delimited identifiers for column and table names in most
SQL dialects. If you do that, pretty much everything you just said is
false.
> While I vaguely recollect doing an application that did construct queries,
> using data from the GUI to select tables and columns, I have only done that
> once and do not remember why that seemed appropriate at the time.
In this case, you control the set of column and table names, so
checking them for validity is trivial - you make sure the one the user
gave you is in the set you expect (presumably using the same list you
used to generate whatever the user selected from), and you're done.
The real issue is when you're trying to build a database where the
user - not you - control the table and column names (because, for
instance, you're interface with some non-SQL data storage and want to
reuse their names - data on pdas and on in systems monitoring tools
are the ones I've run into). SQL makes that possible via the delimited
identifier mechanism. And this is where that set of data injection
problems arises.
> If this were a more common practice, we would be further along in defining
> how to do it in a "standard" way. Sorry.
So is there any chance of getting that written up as something to
appear in dbapi 3? I've already written one proposal, and would be
glad to create more....
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
