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