Thanks for the response, Alex.
On Aug 15, 2007, at 7:48 PM, kuza55 wrote:
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.
OK, but _in a way_ that confirms my position--that some form of
obscurity is practiced. That is to say, at least you've heard of ways
to accomplish it.
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.
In my case I do have access to this denied. The application can only
access the specific database (and portions of the application are
even restricted to specific tables via db user definitions).
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.
In my method, my web app framework maps all field names to
alternative names which correspond to html inputs where used, and
throughout the application one uses those abstracted names for
display and even for queries (I have a layer to rewrite queries on
the way out, and to map data objects on the way in). So as far as the
programmer is concerned there's never the field ABC to deal with,
only data element XYZ.
From a UI/logic standpoint, this allows abstracted data sources. UI
code that displays news for example can display integerated RSS and
database stories. There's other uses as well, but they'r not every
day uses for sure.
So, yeah, I can see the hassle factor in using completely different
names when writing code from scratch, but I have that addressed. I
was just wondering whether anyone ever did any form obscurity as a
means of being at least a little difficult to put together a schema
based on forms.
Thanks for the feedback.
-- greg willits
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
--------------------------------------------------------------------------
