One of the biggest concerns of .NET Developers (and their
clients) is protecting sensitive configuration data such as usernames
and passwords, database connection strings and other global data that
needs to be made easily available application - wide. Of course, web.config
doesn't normally get served by IIS, provided the default mappings are
set in machine.config and not overriden in a local web.config file. But
a lot of people I"ve talked to don't feel comfortable having sensitive
data in web.config. So of course, the first step would be that we can
encrypt the data for starters.
But how to make the data you need available from within
a class library running in the same App Domain, not just from within
your web pages? DLL's can't read configuration data, and they certainly
can't read web.config without writing a custom class to physically load
the web.config or another xml configuration document and do some serious
XPATH. That's overkill, since web.config is already loaded automatically
when the application first starts, and the data in it is cached.
There are a number of solutions to this problem, varying
in complexity and speed. My personal philosophy is that if a hacker can
somehow get to read your web.config file, he's just as likely at that
point to be able to execute arbitrary code of his choice so its already
"too late". Unfortunately, lots of people don't fully understand
the Windows/IIS/.NET security model and because of their naivete, they
naturally decide that they want "overkill" when security comes
into the fray. The result can be an extraordinary amount of additional
coding, and a potential slowdown in the application's performance.
In my recent article on Creating
an XML-Safe DES Encryption Class, I detail how to create a class library
that can encrypt any string of data and Base64 encode the result, making
it safe to store in an XML element without fear of having illegal characters
in the stored string. Here I will present a reasonably elegant solution
to the configuration data problem - one that keeps your data encrypted,
makes it available instantly, and - above all - makes data of almost
any type available from memory, both from your web pages and from your
The key to the technique is based on the expectation
that all your DLL's will be called from some process that originated with
a web user and therefore will be running in the same App Domain that the
web application created when the first request came in. The System.AppDomain
base class is one that is worthy of considerable study.
Application domains, which are represented by AppDomain
objects, provide isolation, unloading, and security boundaries for executing
Multiple application domains can run in a single process;
however, there is not a one-to-one correlation between application domains
and threads. Several threads can belong to a single application domain,
and while a given thread is not confined to a single application domain,
at any given time, a thread executes in a single application domain.
Among many other features, AppDomain offers a CurrentDomain
property that exposes several interesting methods, two of which are GetData()
AppDomain exposes a set of predefined items:
|Value of 'name'
However, in our case we are more interested in the fact
that the GetData and SetData methods allow us to store any data we want
- objects, types, anything that supports ISerializable. Not only that,
but by simply issuing the call:
- we can pull our data out from anywhere in the AppDomain
- whether it's the code in an ASPX or ASMX page or a custom class library
we've called in our code.
So the key to the whole scheme would now go as follows
(you most likely have it already figured out, if you've been with me):
1) Encrypt the stuff we need and store it in web.config
in the appSettings section, which allows us to use ConfigurationSettings.AppSettings("ABCD")
to easily retrieve our data.
2) After reading the data out in Global.asax in the Sub Application_Start,
we decrypt it using our secret key, and store it immediately with name,
value pairs in the System.AppDomain cache.
3) Anytime we need the data, we simply call System.AppDomain.CurrentDomain.GetData("ABCD")
and we're done.
Here is a sample of some custom keys I've stored in the
appSettings section of my web.config:
<!-- Encrypt your data using a key that you remember and place encrypted
data in new keys in this section -->
<add key="ABCD" value="Ni/6UHcq+3r5eEerZ00Kbbd4WDzaH1zx"
<add key="EFGH" value="1CejuTBT3xd6PXj3v2pIvtE0oDTDKcFH"
<add key="IJKL" value="P0FjG5sL5k19aTsI1hHULEVqbU0Tq2SthExjOL
code in global.asax would look like so:
Application_Start(ByVal sender As Object, ByVal e As EventArgs)
' Retrieve Global app settings from Web.config, decrypt, and put in
' AppDomain cache where they are available to all classes in the AppDomain...
Dim fe As Encryption64 = New Encryption64()
Dim ABCD As String = fe.DecryptFromBase64String(ConfigurationSettings.AppSettings("ABCD"),
Dim EFGH As String = fe.DecryptFromBase64String(ConfigurationSettings.AppSettings("EFGH"),
Dim IJKL As String = fe.DecryptFromBase64String(ConfigurationSettings.AppSettings("IJKL"),
fe = Nothing
call you see to "fe" as Encryption64 is a call to my encryption
class. The "12345678" you see as the last method parameter is
the "Secret key"
that is used to both encrypt and decrypt the data. In the event that you
decide you don't want your decryption key exposed in global.asax, you
could simply make a call to a small assembly whose sole purpose is to
return your decryption key. The key value inside the assembly would be
encrypted itself, and part of the function that returns it would be to
decrypt it first. There's a copy of the .NET dll in the code download
for this article; if you want to see the source, visit the article I mentioned
The test web page that is included in the
download has simple code as follows:
Response.Write("ABCD =" & System.AppDomain.CurrentDomain.GetData("ABCD")
Response.Write("EFGH =" & System.AppDomain.CurrentDomain.GetData("EFGH")
Response.Write("IJKL =" & System.AppDomain.CurrentDomain.GetData("IJKL")
And the result you'll see
when you run the page is:
Encrypted global data:
IJKL =Provider=SQLOLEDB.1;Data Source=YourServer;Initial Catalog=YourDatabase;Trusted
You now have
in your hands a simple, very fast, and extensible method for protecting
private data and making it available to your components from an App-Domain
- wide in-memory cache.
the code that accompanies this article
Peter Bromberg is an independent consultant specializing in distributed .NET solutions
Inc. in Orlando and a co-developer of the NullSkull.com
developer website. He can be reached at firstname.lastname@example.org