Security of .dll files within a web site's bin/ directory

[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.

--

(O)enone

[Karl Seguin [MVP]]

I think you'll find little material on the issue. If you trust that files
will be safe outside the public view, why not trust that they'll be safe in
the bin folder? If microsoft's track record is so bad, you shoudln't trust
IIS's ability to keep people outside the site's root and more than you
should trust ASP.NET's ability to keep people away from dlls.

What I might recommend though is that you look at obfuscation. While I think
your dll's are as secure as your server itself, it might help address some
concerns. If, for any reason, someone gets access to your dlls, they'll
atleast have a hard time making any sense out of them.

There are many different .NET obfuscators out there, here's a popular
choice:
http://www.preemptive.com/

Karl
--
http://www.openmymind.net/

"Oenone" <oe****@nowhere.com> wrote in message
news:e$**************@tk2msftngp13.phx.gbl...

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.

--

(O)enone