I am trying to migrate an old aspx site that was built using GeneXus .Net Generator. Looking at the web.config I see keys with database connection information but it is encrypted
<add key="Connection-Default-User" value="******" />
<add key="Connection-Default-Password" value="*******" />
I don't know how to generate those encrypted values. Googling, the only place I saw someone referencing to those keys was this page: Web Model - .NET Generator Manual of GeneXus X.
Here is a sample value (from that page):
<add key="Connection-Default-User" value="Elj20MqY44RPdvT8FEpDD0==" />
But no details on it.
Any help on knowing how to generate those encrypted values is appreciated.
In your generated applications's bin folder, there is an utility called GxConfig.exe. When you run it, if it finds the web.config file it will modify it, otherwise it will create a new one (you may need to copy the file from your web server).
You can find more information in the GxConfig page from the Community Wiki.
Quoting that page:
In order to configure the database access parameters in production,
the Gxconfig tool is provided for each datastore.
It allows specifying a database Name, server, user password included
in the web.config file (web environment) or Client.exe.config file
(win environment and reorganization). The username and password are
encrypted in the same way as it is done in the GeneXus environment.
Related
This post is somewhat similar to the link below. Unfortunately, I do not have enough reputation to ask a question there, so I am asking it here.
Confused on what is the correct procedure on storing passwords in Web.config for Azure deployment
The post above seems to work well if you are deploying to Azure because Azure provides a UI for you to store sensitive data, such as; passwords and keys. Thus, negating the need for an external file. However, if I am not deploying to Azure, then this functionality is assumed to not be available via other web hosting companies and so that answer does not apply.
My question is this, what is the best way to protect sensitive data both from being transmitted over the internet and from malicious users who manage to get the *.config file containing the sensitive data? Some ideas that I have though of are below.
1.) Place the sensitive data in an external file (AppSettingsSecrets.config) that is two folders up on the directory tree?
2.) Place the sensitive data in an external file (AppSettingsSecrets.config) that is in the same project, but set the file's build action to None?
3.) Place the sensitive data in the web.config file, but encrypt the section of the file that contains the sensitive data?
The reason for securing sensitive data within the *.config file itself is that in the event a malicious user manages to get the file containing the sensitive data they will be prevented from reading the sensitive data. All three options only seem to address the first question (preventing sensitive data data from being transmitted over the internet), but option 3 only seems to also address preventing malicious users who get the *.config file from reading the sensitive contents. If that is the case, then it seems like all three options are moot with respect to what file to put the sensitive data and where that file is located; just encrypt the portion of the web.config file that contains the sensitive data and move on. Am I missing something?
I created two handy batch files that encrypt and decrypt the appSettings and connectionStrings sections of the web.config file:
EncryptWebConfig.bat
#ECHO OFF
REM ENCRYPT THE CONTENTS CONTAINED IN THE appSettings SECTON OF THE WEB.CONFIG FILE
C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pef "appSettings" "Folder path to web.config"
REM ENCRYPT THE CONTENTS CONTAINED IN THE connectionStrings SECTON OF THE WEB.CONFIG FILE
C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pef "connectionStrings" "Folder path to web.config"
REM PAUSE FOR VERIFICATION ON THE SCREEN OF WHAT HAPPENED.
PAUSE
#ECHO ON
DecryptWebConfig.bat
#ECHO OFF
REM DECRYPT THE CONTENTS CONTAINED IN THE appSettings SECTON OF THE WEB.CONFIG FILE
C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pdf "appSettings" "Folder path to web.config"
REM DECRYPT THE CONTENTS CONTAINED IN THE connectionStrings SECTON OF THE WEB.CONFIG FILE
C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pdf "connectionStrings" "Folder path to web.config"
REM PAUSE FOR VERIFICATION ON THE SCREEN OF WHAT HAPPENED.
PAUSE
#ECHO ON
I will try to give my suggestion which was already mentioned by you. The most secure way is do not put sensitive data in web config as much as possible and if their's really a need you MUST encrypt it using this method which is option 3 and move on!
Hold on, move on to what? You must move on to other security aspect of your application. Securing web config section doesn't guaratee full protection. You must harden your server, secure communication, pentesting or conduct online vulnerability test and even source code scanning. It may sounds overkill and rediculus but if you really want to mitigate security issues those I mentioned is a must. I say mitigate because now a days you and me are not secure any more! Not unless you are not connected to the internet. :)
Update : These are the tools that may help you. Some are free and some are not. It's not limited only to this
OWASP - for pentesting (free)
Nessus - for system hardening (enterprise)
CIS CAT - tech stack like OS, Database, WebServer etc. (membership only)
IBM AppScan - for source code scanning (enterprise)
If you don't want to bother doing on your own, you can delegate this security testing in third party like whitehatsec.
Alright, that's all that I have. I'm out! :)
I need to generate machineKey in my web application installer and put it into the application's web.config. How can I do this?
We need to split the answer in two:
Generate the Machine Key: You will need to implement a custom action to generate the Machine Key (There are many tutorials about creating custom actions so I won't cover that here, review the links below). The important part is the code to generate the Key, review these links: C#, Powershell. You can store the result on an installer property, you may need to make it a secure property to avoid it to apear on the installer logs.
Add the value to the Web.config: Now that you have the key, you can use some of the wix custom actions to modify the web.config, you can use XmlConfig or XmlFile. With this you will be able to modify the Xml file to add the machineKey node using the property created on the previous step. Review the links below for reference on how to use these to update the configuration file.
IMPORTANT: The machineKey element is only valid in the Web.config file at the root of your application and is not valid at the subfolder level.
Additional links:
Adding a Custom Action
Editing Web.Config Connection string settings with Wix
Custom actions with C#
How to pass parameters to the custom action?
I've had a very frustrating experience on putting an MVC 5 app on Azure. I have been reading the following page: http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure
But what I haven't managed to put in my head is the following:
Security Warning: Do not add your secrets .config file to your project or check it into source control. By default, Visual Studio sets the Build Action to Content, which means the file is deployed. For more information see Why don't all of the files in my project folder get deployed? Although you can use any extension for the secrets .config file, it's best to keep it .config, as config files are not served by IIS. Notice also that the AppSettingsSecrets.config file is two directory levels up from the web.config file, so it's completely out of the solution directory. By moving the file out of the solution directory, "git add *" won't add it to your repository.
And:
Security Warning: Unlike the AppSettingsSecrets.config file, the external connection strings file must be in the same directory as the root web.config file, so you'll have to take precautions to ensure you don't check it into your source repository.
The problem is the following: When I upload the Web.config file with the external files without being included I get hit by "The System cannot find the file specified", so for it to go away I must include the .config files defeating the purpose of Microsoft's post.
I really really really do not understand. I have added the connectionStrings and appSetting's keys in Azure's portal. What is the correct and secured way of putting my passwords and secrets online? What am I missing? Is it because I'm running in Debug mode?
According to this:
How can I secure passwords stored inside web.config?
There is nothing to worry about accessing the Web.config file...
But that just defies Microsoft's post.
Thanks.
I find the following technique to be the easiest way to do this.
Instead of putting the deployment values of these settings into the web.config, I keep the test values in there instead. I then put the deployment values into the Application Settings section of the Azure Website via the Azure Portal:
When the website runs, these settings will take precedence over what is in the web.config. This helps me avoid externalized files, allows me to keep sane development configuration that the team can share, and makes deployment very easy.
The best way is to set your secrets in the Connection Strings section of the portal. Any values set there will override values you specify in your web.config file.
This way they are only exposed to people who have admin access over the site itself. Having full access to the source won't even be enough to get the secret values.
More details here
I have a web application that we publish and provide for users to install and run on their local network. They choose whether they run it as an internet, or intranet application.
When we publish the application we label the folder with the publish date (e.g. 20140815) so we know which version they have. However, when they contact support, it is a pain for them to get on the server to see the folder information.
I want to add an appsetting for cloudVersion and display it on the license page so they can easily provide it from wherever if needed. Also, they feel better seeing the version increase so they know they are getting value with the service contract.
<add key="cloudVersion" value="20140815"/>
I would like to automate the version in the appsettings. I was hoping I could use a Web.Config transform to set it with a dynamic yyyymmdd, but can't see how to do that and have found nothing in my web search.
<appSettings>
<add key="cloudVersion" value="GETDATE()" xdt:Transform="Replace" xdt:Locator="Match(key)"/>
</appSettings>
Is this possible? If so, how? If not, is there a better approach to achieve the same result?
Short of finding a great solution for this, I have elected for the following:
After publication, I run a bat file that does the following:
copy the published directory and rename with today's date
update the Web.Config appSetting value
compress the updated directory using 7zip
upload the compressed directory to Google Drive so my support team can provide it to our users.
You can see how I modified the string here:
bat file to modify web.config setting
Most of my websites include one LIVE (production) and two TEST environments which are accessible via three different domain names e.g.
www.mysite.com
test1.mysite.com
test2.mysite.com
Each of the above are IIS Websites which point to the same physical versioned folder when they are all running the same version of the website.
What I typically do when releasing a new version is to place the new version into a new physical folder e.g. /inetpub/wwwroot/mywebsite/v41/ and point one of the TEST sites to that version of the site and test it. Once passed, the LIVE (and other TEST) websites are also repointed to the new version (e.g. v41).
Now my problem is this. Each website has its own database (TESTs have a copy of LIVE which can be refreshed via a couple of SQL BACKUP/RESTORE commands) however, the three sites are all "looking" at the same web.config file and therefore the same Database Connection Strings (either a System.Data.SqlClient or System.Data.EntityClient provider).
Is there any way that I can configure web.config to provide different connectionStrings based on the domain name/IIS website of the incoming request?
Maybe a tag or an attribute that qualifies a given tag?
I've looked all over for a solution but not yet found one.
Thanks in advance,
BloodBaz
there are two ways to manage multiple environment Specific Web.config file....
using t4 template,below is the link for that
http://ilearnable.net/2010/08/02/t4-for-complex-configuration/
VS Configuration Manager and create new "LIVE", "test1", "test2" build configurations for your project,check out the link
http://weblogs.asp.net/scottgu/archive/2007/09/21/tip-trick-automating-dev-qa-staging-and-production-web-config-settings-with-vs-2005.aspx
hope this helps..
why not split your config file up so connectionStrings.config is its own file. Then you can deploy everything and not overwrite that connectionString file.
where you normally would put the connectionString do this
<connectionStrings configSource="connectionStrings.config" />
Then create a file named connectionString.config
<?xml version="1.0"?>
<connectionStrings>
</connectionStrings>
Alternatively you can create another build option other than just release/debug. You can have web.config transforms that output a different config file depending on which one is selected.
I had a similar problem; I solved it by setting up all the database connection info in the same web config file, and then writing a handler that decides on the fly, based on the request and context, which environment it's in and uses that database.