I have a website about to go live. I'm wondering what I should be doing about the connectionstring in the web.config. Do I obfuscate it and it so how?
Thanks!
The standard method is to encrypt it. http://ondotnet.com/pub/a/dotnet/2005/02/15/encryptingconnstring.html
However, another good option is to store it in the registry and set the permissions so that only the asp.net runtime can access it.
See this article: http://msdn.microsoft.com/en-us/library/ff649224.aspx and this KB: http://support.microsoft.com/kb/821616
Although I do have to say that using the registry does tend to complicate deployment and using text/staging servers a bit. We did it... ONCE and then went back to encrypting.
You can encrypt the <connectionStrings> section in your web.config - see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI
Here is an example for the same;
http://whatilearnttuday.blogspot.in/2012/02/use-of-configurationproviders-to.html
Since you didn't provide any information about this in your question I will assume you have credentials in your connection string.
From a security perspective you should try to avoid this, use Windows Authentication if possible. Obviously this requires that you have access to an Active Directory environment and all the servers are deployed in it.
If not, it's always better to lock down the web-server instead of trying to make sure that files on disk are secure from tampering by different users.
If even this is not possible then I would follow the approach given by the other replies, encrypting the sensitive content with DPAPI.
You could simply encrypt your entire web.config file:
See the steps here:
http://www.proworks.com/blog/archive/encrypting-your-webconfig/
Related
I currently have an ASP.NET website that has an encrypted connection string within it's web.config file. The settings are in the general AppSettings section, not the ConnectionString section. Within the application code we manually decrypt the connection string at run time as needed.
While working on refactoring the site, I came across a method that Microsoft once suggested which involves running an aspnet_regiis command in order to insert encrypted data directly into the ConnectionString section of the web.config file. This suggested method is now considered Retired Content although it doesn't say why (other than a small reference that some of the links may no longer be valid).
Here's the site I'm referring to:
How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI
My questions are basically - Should I bother refactoring the existing functionality to use Microsoft's once recommended way? I believe it would be more efficient than the current process. Also, why would this method be considered Retired Content? Is there a better way to do this, rather than my site supporting the encrypt/decrypt methods?
I've search Google & StackOverflow for other ways of doing this, but they all seem refer to Microsoft's way - or the way I currently have it implemented.
Maybe the site/doc you're referring to is marked as obsolete, but the technology behind is not. Here are the official links, not marked as obsolete:
DpapiProtectedConfigurationProvider Class (with an example), there is also the RsaProtectedConfigurationProvider that is capable of encrypting sections
Encrypting Configuration Information Using Protected Configuration
Encrypting and Decrypting Configuration Sections
ASP.NET IIS Registration Tool (Aspnet_regiis.exe) with the -pe option
I would definitely use this technology.
I'm guessing that they say the documentation is considered retired content because it was written for the .NET 2.0 framework. That being said, as Simon said, the technology behind it is still good to use.
The nice thing about using aspnet_regiis to encrypt your web.config file is that it is transparent to the application. You can write your logic assuming that the appSettings or connectionStrings sections are not encrypted, and if they are are encrypted using this method the .NET framework will take care of decrypting them before giving you the value.
One thing to keep in mind with using this method is that it will encrypt the entire appSettings section. If you open your web.config once it's encrypted you will not see any of the keys, but just a big encrypted hunk of data.
I seen some asp.net developers encrypt ConnectionStrings that was included in separate config file. Why they did that ? I know that config files are unreadable from the client side/browser! Is it possible to access to this kind of files ?
You can't rule out that the web box is compromised.
Also, you don't want the web admins to know passwords to databases.
You need to remember that config files cannot be obtained by the browser just because .config extension is in the list of restrictions in IIS metadata. It may be possible to get them from the server in other way or some misconfiguration problem may allow them to be downloaded.
They can be accessed by maintenance personnel, backup operators or others that have access to the disk without going through the website. That´s one example.
If you upload your web.config file with custom errors set to "off", any errors produced by your web application will display your code. This could even include lines from your config files and this could include the "ConnectionStrings" making them visible to the public.
To every organization the most important thing to them is their data
This is done where there are multiple developers working on the same
application
Sometimes, new developers are also enrolled in the team. Exposing each & every aspect of your database, system, login name, machine name is never a good approach
There is chance of information leak in production, testing Q/A phase etc.
This comes really handy when there is a code theft within an organization, atleaset your data is safe from an outside intrusion as the connection strings were encrypted
Can you bear the risk if someone has access to your database & perform a table/schema drop or a delete all from your tables?
MSDN: How to secure connection strings when using a datasource
I've a dataconfiguration.config encrypted file for an application on ASP.NET Framework 3.5
I need to change my connection string, how can i decrypted and read this file?
Security it's not an issue, I'm on a development enviroment.
Any tip will be preciated.
Thanks.
A common way to encrypt ASP.NET configuration sections (such as ConnectionStrings) is to use Protected Configuration. However if your file does not read as XML, this method was not used or was not the only level of encryption used. It sounds like maybe there was a third party tool involved.
If I were you, I would probably create a new config file, and find everywhere in the project the old config file was referenced to point things at the new file.
If that is not possible, maybe you'd have better luck posting a question in a general cryptography category or doing some searches on the subject. I know some encryption can be identified by look at the encrypted data. Some encryption schemes are designed specifically to hide that though. Good luck.
I know there are already a few questions on SO about the oracle padding exploit but none of them explain how it downloads the web.config. I run a couple of ASP .NET apps which I have already tested using Microsoft recommended mitigation factors but i'm still scared that people will be able to get the web.config.
Can someone please explain how they do this or even provide a link to a tool that I can use to test my site with. I find that the official explanation of this part of the attack is really lacking.
The attack that was shown in the
public relies on a feature in ASP.NET
that allows files (typically
javascript and css) to be downloaded,
and which is secured with a key that
is sent as part of the request.
Unfortunately if you are able to forge
a key you can use this feature to
download the web.config file of an
application (but not files outside of
the application).
Guys - the answer is that once they have obtained the machineKey, they can use that key to fetch the files using another feature in ASP.NET
"In ASP.NET 3.5 Service Pack 1 and ASP.NET 4.0 there is a feature that is used to serve files from the application. This feature is normally protected by the machine key. However, if the machine key is compromised then this feature is compromised. This goes directly to ASP.NET and not IIS so IIS's security settings do not apply. Once this feature is compromised then the attacker can download files from your application - including web.config file, which often contains passwords.
Versions of ASP.NET prior to ASP.NET 3.5 SP1 do not have this feature, but are still vulnerable to the main machine key attack."
(see the post at the bottom of here: http://forums.asp.net/t/1603799.aspx from the asp.net team)
Scott Guthrie has a post which explains it to some extent.
This blogpost is pretty interesting: http://www.gdssecurity.com/l/b/
also read this:
How serious is this new ASP.NET security vulnerability and how can I workaround it?
afaik it goes like this:
these are hit: webresource.axd and scriptresource.axd, both use an encrypted/signed value that asp.net tries to check if its valid
because of differences in the response when the files are or not valid, they can make the padding attack.
once the attack is successful they can generate a request for a resources as if it were originally emitted from asp.net
Now, as far as I knew, both of those are supposed to serve embedded resources, but I guess that's not the case (Scott Gu did mention in his post's comments those are the ones being used in the attack showed).
The following post may be interesting for this thread:
http://blog.mindedsecurity.com/2010/10/breaking-net-encryption-with-or-without.html
FYI, a patch for this bug has been released on Windows Update.
http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx
We're migrating one of our sites to ASP.Net. We do not want to use integrated security, which uses the windows account to connect to sql server (not going to get into why, its just out of the question). We created a username and password to connect to SQL Server, and would like to use that username and password, however, we also do not want other developers to see this information (easily read from the web.config).... I know it can be encrypted, but it can just as easily be decrypted by the developers - plus encryption has a performance hit.
Is there any solution to this problem?
here's a good tutorial on Encrypting Configuration Information in ASP.NET 2.0 Applications
Just don't give the other developers the key
Alternatively, you can lock down the authentication for SQL via installed certificates. This way you are setting security based on the client not the user. http://msdn.microsoft.com/en-us/library/ff649255.aspx
Our standard practice is to have one "Developer Login" used in the development database that has limited access and have a different username/password for the production box. Developers do not have access to the production box, only the lead developers, and then the production web.config is copied over via the deployment script.
Do the developers need access to the web.config file? If so, I think you may be out of luck. If not, meaning that they do not ever need to change the web.config file, change the permissions on it so that only admins and the asp.net process can read the file.
In my experience, it tends to be difficult to hide that kind of thing from your internal devs. Even encrypting the config infroamtion in the webconfig would still show if your developers just stepped through the code...
I would guess that, if you HAD to do this, you could create a private constant string in the code for your DB string and then use Dotfuscator or similar on the compiled application. Obviously, the source code itself would also have to be encrypted or your developers otherwise prevented from accessing it.
You can't really protect the password from developers - besides, what sense does it make?
What you can do is to have separate development server to which developers have access and production environment, to which they don't.
Don't developers ever need to log on directly to database to run some tests or something? if they do, it would make sense to do the test using the same account that is used by the application, otherwise the test results may not reflect reality.
prompt for the password, when you connect for the first time and track the passowrd in session. Now only you'll be able to connect the database from anywhere. Redirect all those to application-unavailable page to rest of the users that they don't have the password.