Re: Abstracting DB Schema from Web Forms

[kuza55 <kuza55 () gmail com>]

I'm not sure about the separation of UI/logic, but the most common
approach to this (that I know of) in regards to security is to use an
unknown table (or column) prefix, rather than renaming the columns
completely, because it still provides a layer of obscurity, while
still being fairly self explanatory for anyone who has access.

Having said that, its fairly useless in most cases since you can query
INFORMATION_SCHEMA database for table and column info. Now while it
might be possible (and probably pragmatic) to deny access to those
tables (or the MS equivalent of sysobjects and syscolumnnames for sql
server or msysobjects and msyscolumns for access or whatever else
other databases support) in most cases that's not done.

And even if it is; while most prefixes are 3 characters or so which is
rather short, nothing says you can't make them a bit longer, then it
would make things much harder to brute force.

Also, since the prefix for all the tables (and columns?) is the same
its much easier for developers to write ${prefix}_email than to lookup
what the name of the field they need to query is called. Though they
could probably use $column['email'] just as easily, and you'd just
have to include that hash table everywhere.

 - Alex "kuza55"
http://kuza55.blogspot.com/

On 16/08/07, Greg Willits <lists () gregwillits ws> wrote:
> I have a question whether this practice I'm  about to describe is
> good, unnecessary, or just falls within the "whatever floats your
> boat" category.
>
> While I'm well aware of the pitfalls and fallacies of "security by
> obscurity," it also seems that after implementing protections against
> known attack vectors to abuse insider knowledge of a system, if you
> can hide something important, then by all means you should (or at
> least _could_).
>
> Specifically, the practice of using database column names verbatim as
> web form input fields seems like an unnecessary exposure of something
> you'd just as soon not have people know.
>
> Certainly if all vectors for sql-injection are closed, then one can
> argue if the schema were published it's of no value. Still, if we
> follow the idea of erecting multiple barriers, then a non-published
> schema (though a mere obscurity countermeasure) seems prudent to me.
>
> I'm aware that if an app has SQL injection vectors, then fields names
> are probably the least of one's worries, but nevertheless, it seems
> that for the cost of a simple mapping abstraction, a db's schema can
> remain completely unknown.
>
> It seems like such a simple and obvious step to me, yet I never see
> it discussed. Every database connected web app example I've ever seen
> uses database field names as form input names. Try even searching for
> discussions of the topic, and I just don't find any.
>
> What does this tell me? Abstracting table field names is
> "unnecessary," but I just can't reconcile myself to that.
>
> Either way I find abstracting the schema to be useful for separation
> of UI and logic, but I started doing it for the perceived security
> value, and continue to wonder if promoting that value is real or just
> smoke.
>
> Looking for educated opinions. <deep_breath> OK, I'm ready to be
> vindicated or humiliated :-)
>
> -- greg willits
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: Watchfire
>
> The Twelve Most Common Application-level Hack Attacks
> Hackers continue to add billions to the cost of doing business online
> despite security executives' efforts to prevent malicious attacks. This
> whitepaper identifies the most common methods of attacks that we have seen,
> and outlines a guideline for developing secure web applications.
> Download today!
>
> https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
> --------------------------------------------------------------------------

-------------------------------------------------------------------------
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online 
despite security executives' efforts to prevent malicious attacks. This 
whitepaper identifies the most common methods of attacks that we have seen, 
and outlines a guideline for developing secure web applications. 
Download today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
--------------------------------------------------------------------------