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)
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:
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.
asppick
Member
494 Points
516 Posts
Architecture question security hole
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??
BrockAllen
All-Star
27498 Points
4893 Posts
MVP
Re: Architecture question security hole
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?
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/
atconway
All-Star
16846 Points
2756 Posts
Re: Architecture question security hole
Jun 28, 2012 05:34 PM|LINK
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:
http://msdn.microsoft.com/en-us/library/53tyfkaw.aspx
Encrypting and Decrypting Configuration Sections:
http://msdn.microsoft.com/en-us/library/zhhddkxy(v=vs.90).aspx
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.