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_at_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
--------------------------------------------------------------------------
Received on Aug 16 2007
Intro
