RE: Abstracting DB Schema from Web Forms

["Auri Rahimzadeh" <auri () auri net>]

Even though I didn't see the original message for some reason, I suggest the following:

* Always check your data, regardless of who it's from. An integer should be an integer. A text field with 4 characters 
should be a text field with 4 characters. Your business rules in your objects should support strong awareness of the 
data to be received and react accordingly. Learn regular expressions and validate with those, too.

* *Always* used stored procedures and always verify the data you pass into them is the data you're expecting. If you 
can't use stored procedures and must use direct SQL, use parameterized queries with proper typing and *PREPARE* your 
statements first. In ADO.NET you can use the .Prepare() statement. As Jason said, "only" obscuring just hides bad 
coding practices - it's still just as exploitable.

* Always have proper error handling around your code so you don't show potentially sensitive information. Log your 
errors and review them later, and show a friendly error message to the user ("We messed up, whoops.").

* Always, always, always secure your database permissions. Best practices include having separate accounts for read and 
write access, sometimes even more stringent accounts for certain types of read/write access and certain objects. And 
nobody should ever have DROP or admin or non-standard table access (drop, create table, and so forth) *and* have remote 
access into the app (i.e. Web or Web Service).

* Read good books, like Writing Secure Code 2 and The 10 Deadly Sins of Software Development (at least, I think that's 
the name of it <grin>).

Good luck!

Auri Rahimzadeh
President, Senior Engineer, The Auri Group, LLC
Author, Hacking the PSP, www.hackingpsp.com

-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of Jason Troy
Sent: Saturday, August 18, 2007 12:57 PM
To: webappsec () securityfocus com
Subject: Re: Abstracting DB Schema from Web Forms

On 8/15/07, Greg Willits  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.

I asked my co-workers your question - here's what a couple said:

--------------------------------------------------
In some cases I have recommended against using form names the same as
column names. But it is standard practive - even for large highly
secure applications. Protecting aganst SQL injection is done by making
sure that anything passed in from a user cannot harm your database.

-Mark
--------------------------------------------------
I see that it does add a level of security (assuming you don't have
detailed debugging enabled, or some other hold that allows them to know
the field names).  Assuming they find an exploitable SQL injection
vulnerability, if you abstract the field names, they may not know
exactly what field to manipulate to increase their credits (or whatever).

BUT, I'm sure they can still wreak some havok.  The probably can't drop
the table without knowing the table name, and they shouldn't be able to
drop the database without having proper permissions (you did setup
permissions properly, didn't you?).  But I'm sure they could find
something bad to do.

ANYWAY, no matter that security it adds, I don't think its worth the
increased time development would take with obscure fieldnames.
- Ryan
--------------------------------------------------
I think the reason you don't see obscuring your field names as a "best
practice" is because that's all it does - obscure things. For example:
Do you buy extra cars and rotate them in and out of your fleet on a
regular basis to people don't know what you drive?
Do you have your neighbor park their car in your drive, or drive your
car when you're on vacation so others won't know you're not home?  (My
guess is a resounding "no")

While we're at it, we could label our tables "a", "b", "c" - or use Unique IDs.

I was at a security conference "the other day" and heard someone say
"just append drop sales to the value in the cookie or URL" and I saw
the "oh crap" look on several people's faces. (come on people, protect
the border, don't hide it)

In conclusion, I think I'm going to vote for "whatever floats your
boat" - but its not a practice we'll soon follow unless there's a good
reason to do so. I'll continue to validate input before I do anything
with it.

- Jason

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