RE: Abstracting DB Schema from Web Forms

["Chris Vann" <Chris () elserinteractive com>]

Greg,

In certain applications, your approach might be considered very useful.
More often, however, I find the fact that form names and column names
match is a simple coincidence by way of common sense (i.e. fname,
firstname, givenname and subtle variations are all common ways to refer
to a particular piece of data).  If you were to use off-the-wall names
for your form fields, your database columns would still be
semi-guessable. If you were to use obscure database field names instead,
then your database maintenance would become an unthinkable nightmare.

I think in this case, it's a matter of theoretical benefit vs. practice,
and I don't think the theoretical benefit is worth the maintenance
nightmare for most scenarios.  Indeed, as you yourself said, if the fact
that your form field names match your database field names is of
considerable concern in a given scenario, then it is likely that you
have greater underlying security issues to worry about anyway. In cases
where this is not true, then by all means, take the extra step, if
you're willing.

I just don't think it's practical in most scenarios, myself.

Regards,
Chris
  


-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
On Behalf Of Greg Willits
Sent: Wednesday, August 15, 2007 12:26 PM
To: webappsec () securityfocus com
Subject: Abstracting DB Schema from Web Forms

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
--------------------------------------------------------------------------