Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Jun 28, 2012 05:34 PM by atconway
Jun 23, 2012 07:24 PM|LINK
I was discussing with one of senior collegue yesterday about the our current website architecture and he says there is a security hole in current design.
Our website, it is deployed on server (ex: X001) accessing our db server (Z001).
The way our website is designed is,
1. A web application project references BusinessDB (its a DLL, see point 2) for DB operations. Connection strings defined in web.config
2. BusinessDB designed as
-- Business Layer (A Class library) calls Data Library (another class library, which calls SQL procedure (A DB on server Z001)
Question: where is the security hole here??
Jun 23, 2012 08:34 PM|LINK
It's unclear if or where there is a securty hole in the information you provided. There might be or there might not -- just not enough information.
Why not ask him/her what they think the security hole is?
Jun 28, 2012 05:34 PM|LINK
Connection strings defined in web.config
Based strictly on the information you provided, the main security hole might be the plain text connection strings in the web.config. Now someone would have to hack into the server to read this file (ASP.NET will not allow it) so it's a stretch but
you should for best practice encrypt those and any other sensitive data settings.
I encrypt sections of my web.config for production apps all the time. Super simple once you have the process down. The following article will give you help on how to do this:
Encrypting Configuration Information Using Protected Configuration:
Encrypting and Decrypting Configuration Sections:
The only other scenario might be if the Sr. developer was worried about delegation across boundries. You mentioned going from UI to BLL to DAL which access the database. He/she might be questioning if the context of the client is being delegated all the
way through the layers, so that when the stored procedure is being called it is by the user's context and not the NETWORK SERVICE or some other impersonated account. This would be required if you had very granular SQL permissions set up by each database object
and wanted authentication using the user's context on each call.