O
Oenone
I've been working on migration of my company's VB6 ASP system to VB2005 over
the last year or so, and am currently presenting my findings and recommended
course of action to our management team. One of the concerns that has been
raised is with regard to the .dll files that form our service being placed
into a directory within the publically available web site (i.e., the bin
directory).
We have long held the view that private files (configuration files, DLLs,
etc.) should be held in a directory above the web site so that it is
absolutely impossible for them to be accessed via IIS. With ASP.NET of
course, all DLLs are required to be placed in the bin/ directory inside the
public web site.
I understand that the ASP.NET IIS process specifically denies access to bin/
and all of its subdirectories but (and not meaning to sound anti-MS here)
Microsoft's track record on security is not exactly top notch, and there are
concerns among the team about the safety of DLLs placed here.
(The GAC is not an option for us in this instance due to the mechanism we
use to deploy and audit DLLs.)
Have any of you had similar concerns within your organisations? How have you
addressed these to the satisfaction of all involved? Are there any official
Microsoft documents addressing this issue that I could use?
Thanks in advance for any help or suggestions anyone can offer.
the last year or so, and am currently presenting my findings and recommended
course of action to our management team. One of the concerns that has been
raised is with regard to the .dll files that form our service being placed
into a directory within the publically available web site (i.e., the bin
directory).
We have long held the view that private files (configuration files, DLLs,
etc.) should be held in a directory above the web site so that it is
absolutely impossible for them to be accessed via IIS. With ASP.NET of
course, all DLLs are required to be placed in the bin/ directory inside the
public web site.
I understand that the ASP.NET IIS process specifically denies access to bin/
and all of its subdirectories but (and not meaning to sound anti-MS here)
Microsoft's track record on security is not exactly top notch, and there are
concerns among the team about the safety of DLLs placed here.
(The GAC is not an option for us in this instance due to the mechanism we
use to deploy and audit DLLs.)
Have any of you had similar concerns within your organisations? How have you
addressed these to the satisfaction of all involved? Are there any official
Microsoft documents addressing this issue that I could use?
Thanks in advance for any help or suggestions anyone can offer.