Abstracting DB Schema from Web Forms
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
Abstracting DB Schema from Web Forms
by Greg Willits-2
::
Rate this Message:
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 -------------------------------------------------------------------------- |
|
|
|
|
|
Re: Abstracting DB Schema from Web Forms
by kuza55
::
Rate this Message:
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. 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. 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. - Alex "kuza55" http://kuza55.blogspot.com/ On 16/08/07, Greg Willits <lists@...> 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 > -------------------------------------------------------------------------- > > ------------------------------------------------------------------------- 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 -------------------------------------------------------------------------- |
|
|
Re: Abstracting DB Schema from Web Forms
by Greg Willits-2
::
Rate this Message:
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@...> 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 -------------------------------------------------------------------------- |
|
|
Re: Abstracting DB Schema from Web Forms
by Jason Troy
::
Rate this Message:
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 -------------------------------------------------------------------------- |
|
|
RE: Abstracting DB Schema from Web Forms
by Auri Rahimzadeh
::
Rate this Message:
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@... [mailto:listbounce@...] On Behalf Of Jason Troy Sent: Saturday, August 18, 2007 12:57 PM To: webappsec@... 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 -------------------------------------------------------------------------- |
|
|
Re: Abstracting DB Schema from Web Forms
by Greg Willits-2
::
Rate this Message:
On Aug 18, 2007, at 9:57 AM, Jason Troy wrote:
> 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.... Jason, thanks for the effort and the feedback. Obviously the point isn't to use obscurity in lieu of actual defensive programming against injection, I was just wondering how many people did it as an extra "layer" (however thin it may be). The more concentric rings of difficulty/defense, the better I figure. These days I do it as much for separation of data/view as anything else (so view/form code can interact with db, web services, etc). As for extra work, I've created a general purpose mapper / ORM-ish layer doing all the translation, and throughout the app I can use the abstracted name, so it really doesn't feel like extra work at all when coding -- even when creating new apps. So, I guess it floats my boat, but it's not a tsunami. -- 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 -------------------------------------------------------------------------- |
|
|
Re: Abstracting DB Schema from Web Forms
by hiltond
::
Rate this Message:
I think this could be a good practice. For a secure application, you want as many levels of security as possible, and obfuscation, while not as powerful as some other security measures, does provide a layer of defense.
As I understand it, you're mainly doing this to prevent outsiders from gaining knowledge about your database schema to prevent malicious SQL calls from your app server, which could be solved by appending something random to your meaningful field names. I have a question about another possible use: protecting encrypted data. Is it easier to crack an encrypted string if you know values in the string, the length of the original string, or the data type of the original string? If it is indeed easier, your obfuscation could be used to help secure encrypted data from cracking. So if I had a column named '8akdb' filled with encrypted strings, it would provide no additional meta information to someone who had the data, as opposed to naming the column 'ABC_zipcode', which provides information about original string length, data type, and finite potential values. Anyone have any thoughts? |
|
|
Re: Abstracting DB Schema from Web Forms
by Serg B
::
Rate this Message:
I think that the DBA responsible for the database you are encrypting
may have something to say about it... Obfuscating client-side code such as JavaScript is fine, when it is being generated for the client (not in the repository), however obfuscating a database schema is suicidal. Not to mention a maintenance nightmare. In my opinion this is a poor trade between security and usability. It also implies securit-by-obscurity approach which is not a very sustainable (or secure) solution. I suggest some alternatives: Parameter binding (Java: Hibernate, PHP: PDO, Perl: DBI, etc). Disable all error messages form being rendered to the client. Use stored procedures. Implement correct input data validation. Implement correct output data validation. Basically everything one should be doing anyway. Additionally, if you want to be a little more sneaky you could also introduce an intermediate messaging layer or some sort of XML abstraction between the application and the database. Cheers, Serg Hibernate On Dec 15, 2007 9:30 AM, hiltond <nabble@...> wrote: > > I think this could be a good practice. For a secure application, you want as > many levels of security as possible, and obfuscation, while not as powerful > as some other security measures, does provide a layer of defense. > > As I understand it, you're mainly doing this to prevent outsiders from > gaining knowledge about your database schema to prevent malicious SQL calls > from your app server, which could be solved by appending something random to > your meaningful field names. I have a question about another possible use: > protecting encrypted data. Is it easier to crack an encrypted string if you > know values in the string, the length of the original string, or the data > type of the original string? If it is indeed easier, your obfuscation could > be used to help secure encrypted data from cracking. So if I had a column > named '8akdb' filled with encrypted strings, it would provide no additional > meta information to someone who had the data, as opposed to naming the > column 'ABC_zipcode', which provides information about original string > length, data type, and finite potential values. Anyone have any thoughts? > > -- > View this message in context: http://www.nabble.com/Abstracting-DB-Schema-from-Web-Forms-tp12169061p14339834.html > Sent from the Web App Security mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > Sponsored by: Watchfire > Methodologies & Tools for Web Application Security Assessment > With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! > > https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F > ------------------------------------------------------------------------- > > ------------------------------------------------------------------------- Sponsored by: Watchfire Methodologies & Tools for Web Application Security Assessment With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F ------------------------------------------------------------------------- |
| Free embeddable forum powered by Nabble | Forum Help |
