« Return to Thread: Abstracting DB Schema from Web Forms
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
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
« Return to Thread: Abstracting DB Schema from Web Forms
| Free embeddable forum powered by Nabble | Forum Help |
