Coding, Geekery

Bootstrap Your App for Free Part 3: Security and Naming

In my last few entries, I have outlined how I was able to build my Bookmarkinator app for free thanks to a variety of tools and platforms out there (no credit card or limited time demo software either!). I followed it up with some resources that you could host your app for free as well (no credit card either!). That takes us to the final step which helps polish our app and make it look bonafide: security and domain names.

Continue reading “Bootstrap Your App for Free Part 3: Security and Naming”
Coding

Dev Principle #7: Avoid Common Code Vulnerablities

I had a guest post over at my company’s blog, reflecting a bit on some of the coding vulnerabilities that still plague us today…

https://www.freshconsulting.com/dev-principle-7-avoid-common-code-vulnerabilities

Continue reading “Dev Principle #7: Avoid Common Code Vulnerablities”

Quick Tip
Coding

Quick Tip – IAM S3 Policy for DeployBot

For one of the projects I’m working on, we’re using DeployBot to handle deploying our code from our bitbucket repository to an AWS S3 bucket. For security reasons, we want to keep the IAM policy a restrictive as possible, so that it can only add/remove files in that bucket. However, DeployBot needs to be able to connect to S3 and get a list of buckets to provide a list for you to choose from in the deployment wizard. After a little bit of tweaking, this is the IAM policy that worked for me.

Continue reading “Quick Tip – IAM S3 Policy for DeployBot”

Coding

Encrypt that Connection String Pronto!

I?m pulling this one out of the ?oldie but a goodie? based on a deployment I was doing today.

If you have a database connection string that has the password sitting in clear text in your web.config file, you might have some security woes. Granted IIS does a good job and making sure end users can?t get to your web.config file through the browser, you may wind up having other security holes that would expose this data.

I distinctly remember back in the 1.1 days working out a scheme with some fellow developers to protect out connection strings by actually having them sit in a separate file on the server (our ever beloved homer.ini file) and writing a library that would find this mystery file, do some fancy decryption, create a connection object, and return it to the calling code. It was a nice solution, but tricky to establish and even trickier to maintain.

The .Net Framework 2.0 came out a short time later and eliminated all of these woes by creating an executable that will encrypt your connection strings for you! In order to do this, simply log on to the server, open the command prompt, and enter the following command:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pef "connectionStrings" [PhysicalPathToApplication] -prov "DataProtectionConfigurationProvider"

Note: Even if you?re using the 3.0 or the 3.5 Framework, you?ll still want to reference your version 2.0 folder for the encryption, since the 2.0 core is still used for the subsequent versions of the framework.

Note: If the physical path to your application directory has any spaces in it, you?ll want to wrap the path around quotation marks.

That?s all there is to it! There are a lot of great benefits to using this encryption:

  • IIS will use a key unique to the server, so that even if somebody gets ahold of the encrypted web.config file, they won?t be able to decrypt the section.
  • Your .Net will automatically decrypt the connection string on the fly, so you don?t need to modify any of your code that digs into the connectionStrings section of your web.config file to retrieve it.
  • You can use this same process to encrypt other sections of your web.config file as well (have some appSettings values you don?t want anybody to see?). Simply change the ?connectionStrings? parameter to the appropriate section.

If you need to decrypt the connection string to verify/modify any settings, the command is identical, except you change the ?pef parameter to ?pdf:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pdf "connectionStrings" [PhysicalPathToApplication]

No provider details needed on the decryption.

If the server unique encryption key is insufficient, or you need a more global way of managing your encryption, you can also use your own RSA generated keys to manage the encryption/decryption. More details on that can be found here.

Enjoy your hassle free encrypted connection strings!