«

Simply put, best practices say to:

1) Put ConnectionString info in to web.config for easier editing (and
disallow the need to recompile code if settings change).

2) Encrypt the ConnectionString section using the aspnet_setreg.exe utility.
This encrypts the data on the IIS/OS level disallowing someone with file
level access the ability to read the plain text .xml.

3) In memory variables of secure data should be encrypted, and only
decrypted when needed. You should then dispose of the decrypted string in
memory to minimize a memory dump exposure of said sensitive strings.

However, it is my understanding that the web.config is read in to memory at
application start-up, and even if the contents are encrypted, they are stored
in plain text in memory (see "Security Note" here:
http://msdn2.microsoft.com/en-us/lib...as(vs.80).aspx). Our security
guys are telling us that a buffer-overflow attack on our web app would expose
these connection strings. They are then asking us to use a custom
encrypt/decrypt routine to read these variables when needed.

My problem is that:

1) While that's fine if you write custom Data Access Layers and build all
your connection and data objects from scratch in code, you'll loose some of
the cool "automagic" stuff you get by dragging and dropping objects in VS
2005. For instance, how do I tell my wizard created DataSet TableAdapter to
use my custom encrypt/decrypt routine when looking for a connection string?
Can you easily extend some base class? How easy is it to modify the
generated code? I've read blogs warning against this for various reasons.

2) Is this even a legitimate security risk? Are we correct in our
assumptions (strings stored in plain text in memory, persisted after use)?
You may argue against the likely hood of this type of memory attack, but
that's not the position I want to start from. Ideally, I want to be as
secure as possible without have to write custom DAL's for every little page.
Is this a trade-off we have to live with?

Thoughts?

Thanks in advance for any guidance you may provide.

> 2) Is this even a legitimate security risk? Are we correct in our
> assumptions (strings stored in plain text in memory, persisted after
> use)? You may argue against the likely hood of this type of memory
> attack, but that's not the position I want to start from. Ideally, I
> want to be as secure as possible without have to write custom DAL's
> for every little page. Is this a trade-off we have to live with?

Well - against whom do you wanna protect this data?

To read random process memory you need to run win32 code in the context of
your app - or attach a debugger to the process.

Debugging requires quite high OS privileges.

Separate your apps into different process (the IIS application pool feature)
to isolate memory from other code running on that server (if that is a concern).
I wouldn't bother encrypting stuff in memory. If someone is able to read
your memory - you got a much bigger problem.

-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

> Simply put, best practices say to:
>
> 1) Put ConnectionString info in to web.config for easier editing (and
> disallow the need to recompile code if settings change).
>
> 2) Encrypt the ConnectionString section using the aspnet_setreg.exe
> utility.
> This encrypts the data on the IIS/OS level disallowing someone with
> file
> level access the ability to read the plain text .xml.
> 3) In memory variables of secure data should be encrypted, and only
> decrypted when needed. You should then dispose of the decrypted
> string in memory to minimize a memory dump exposure of said sensitive
> strings.
>
> However, it is my understanding that the web.config is read in to
> memory at application start-up, and even if the contents are
> encrypted, they are stored in plain text in memory (see "Security
> Note" here:
> http://msdn2.microsoft.com/en-us/lib...as(vs.80).aspx). Our
> security guys are telling us that a buffer-overflow attack on our web
> app would expose these connection strings. They are then asking us to
> use a custom encrypt/decrypt routine to read these variables when
> needed.
>
> My problem is that:
>
> 1) While that's fine if you write custom Data Access Layers and build
> all your connection and data objects from scratch in code, you'll
> loose some of the cool "automagic" stuff you get by dragging and
> dropping objects in VS 2005. For instance, how do I tell my wizard
> created DataSet TableAdapter to use my custom encrypt/decrypt routine
> when looking for a connection string? Can you easily extend some base
> class? How easy is it to modify the generated code? I've read blogs
> warning against this for various reasons.
>
> 2) Is this even a legitimate security risk? Are we correct in our
> assumptions (strings stored in plain text in memory, persisted after
> use)? You may argue against the likely hood of this type of memory
> attack, but that's not the position I want to start from. Ideally, I
> want to be as secure as possible without have to write custom DAL's
> for every little page. Is this a trade-off we have to live with?
>
> Thoughts?
>
> Thanks in advance for any guidance you may provide.
>