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, using 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 be familiar with it. Sound familiar?

Well, kudos to you. At least you recognize an easily missed security hole of accidentally exposing sensitive application data through what's 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 make the attacker's life much easier.

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

Azure Website Connection Strings

Assuming your web application is running with a connection string similar to the following:

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

The Azure Websites service makes it extremely easy to maintain 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 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 the 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.

Note: When working with Visual Studio, it is possible for some of the described Azure connection string setups to be taken care of for you depending on whether you configured Azure originally at the onset of your web application.

This article is about bringing to light what Azure will do for you when it comes to making connection strings 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 many possible scenarios 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 procedure 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.