The Curious Case of the Missing Azure Connection String

You’re new to Azure and you’re working on deploying your shiny new web application to Azure’s Website service. But you’re storing your web application in a public repository like GitHub, BitBucket or CodePlex.  Currently, through any number of possible techniques you have managed to keep your connection strings out of public view by not checking it in.   Now you’re trying to figure out how to continue committing to your repository and deploy to Azure without having to commit your connection string just so Azure Websites can know about.  Sound familiar?

Well, kudos to you.  At least you recognize an easily missed security hole of accidentally exposing sensitive application data through whats referred to as security misconfiguration.  Azure Website connection strings makes this potential security rule, easier to follow.  But first, why is it sensitive data?

 

Security Misconfiguration

Security misconfiguration is a serious security flaw so much so that OWASP has moved it up from #6 to #5 of its 2013 top 10 web application security flaws.  Aptly named, connection strings within our web application is one of the gateways to a prized position, our application data.  I have talked about leaky application data before, but this is a vulnerability that really makes attackers life a lot easier.

When self-hosting a web application, not only do we have to secure information such as connection strings, but at a deeper level we have to ensure that access to such files is not available as well.  But this isn’t a article on an securing an application file resources, so let’s bring it back to what Azure Website’s can do to make our life easier when it comes to securing our application’s connection strings.

 

 Azure Website Connection Strings

Assuming your web application is running with a similar connection string as below:

<add name=”shpt” connectionString=”…..”/>

 

Azure Websites service makes it extremely easy to keep information such as our web.config connection strings out of our repository of choice.  Within Azure’s management portal under the Website service, you can select the “Configure” tab.

 

From here we can scroll down to the Connection Strings area to find where you can specify an Azure Website connection strings.  Here you can add a new connection string who’s name matches the name=”” field you specified in your web.config.

 

 

 

Now, when your application is committed to your repository and building and deployment processes occur, Azure will swap out and replace the connection string you have listed where the names match with the one that Azure possesses.

[alert type=”info” icon=”icon-help-2″]NOTE: When working with Visual Studio, it is possible for some of the described Azure connection string setup to be taken care of for you depending on whether you configured Azure originally at the onset of your web application.[/alert]

This article is about bringing to light what Azure will do for you when it comes to making connections string available to your web application.  But, a problem that might have jumped out to you is “how do you make a connection string available to you for local development as well?”

 

Having Your Cake and Eating It Too

When it comes to connecting to a local database, ensuring that local database connection information is not publicly available, all the while ensuring Azure has the proper connection strings available can be tricky.  There are a number of different scenarios that you might find yourself in.  Therefore, I will throw out a few approaches people might take to juggle that typical scenario.  This is by no means an exhaustive list.

 

Web.config Transforms

Use a web.config transform as outlined in this MSDN article.  This allows you to have a separate file that contains the specific database connection information for your connection string.  Then the placeholder for the connection string in your web.config is replaced appropriately with the correct database connection string that is retained in the separate file.

 

ConfigSource Attribute

Another approach is using the “configSource” attribute of the “connectionStrings” element in your web.config to specify a separate file similar to the one in option #1 but a little less verbose.  There is a bit more to this option but you can read a detailed overview and approach to this here as well as the benefits it offers.

In either case, the security benefit is gained when we apply a separation of concerns to our web.config AND ensure that this separation is safeguarded.  Any security benefit will be diminished if we don’t ensure that this additional file is not leaked through a public repository or other means.

 

Conclusion

This was a short one, but the purpose of this article was just to point out what the Azure Website service is capable of doing via convention to help safeguard important web application information without having to break a cardinal security rule.  In addition, it brings to light the importance of ensuring that we keep important application information secured and don’t commit what is deemed security misconfiguration.  Information such as your database connection strings can expose incredible security holes in our application and it is up to you to ensure you have implemented the proper security hardening steps and Azure Website Connection Strings make this easier.   In the very near future, I will be putting up the article that details how you can ensure your web application doesn’t fall prey to security misconfiguration.  So stay tuned.