DevOps Zone is brought to you in partnership with:

Troy Hunt is a Software Architect and Microsoft MVP for Developer Security. He blogs regularly about security principles in software development at troyhunt.com and is the author of the OWASP Top 10 for .NET developers series and free eBook of the same name. Troy is also the creator of the recently released Automated Security Analyser for ASP.NET Websites at asafaweb.com. Troy is a DZone MVB and is not an employee of DZone and has posted 63 posts at DZone. You can read more from them at their website. View Full User Profile

Dynamic Security Misconfiguration Scanning with OnCheckin and ASafaWeb

06.21.2013
| 2418 views |
  • submit to reddit

Here’s the thing about security – you can’t just “do it” then move on. What I mean by this is that it’s a continuous process and thinking that you only need to just implement some secure coding standards or scan the website once before go live leaves a great big hole in your process.

For example, the other day I wrote about how insecurity is easy where I talked about how Black and Decker had exposed ELMAH logs. This is the tiniest of security misconfigurations which can easily happen at any time but it meant that they ended up with the credentials from a significant portion of their customer base publicly accessible – ouch! Ok, this also involved storing plain text passwords in cookies in order to facilitate the “remember me” function (no, really), but the point is in how easy it was to make a simple change that blew a massive hole in the side of their security profile.

This brings me to the point of the post: security misconfiguration happens and you need to start looking for it bang after you publish the site. Exposed ELMAH logs is one thing but simple security misconfiguration changes you can screw up on release of an ASP.NET website go well beyond that; custom errors, tracing, request validation and the way your cookies are configured to name but a few. Each of these can be configured to leave a site vulnerable in literally just a few seconds.

For the last couple of years I’ve provided a service to detect these problems in a live site – ASafaWeb. The value proposition of ASafaWeb has always been that on demand, you can scan your live ASP.NET website and it will report on these security misconfigurations. Now I’m very happy to share how ASafaWeb has been integrated intoOnCheckin (the brainchild of Doug Rathbone) to provide continuous deployment for ASP.NET websites as a cloud-based service.

OnCheckin - Cloud Powered Deployment

Here’s how it works: Firstly, you plug it into source control:

Configuring source control

Then you configure the deployment:

Configuring deployment

Then finally you review everything and tick the box to run the ASafaWeb scan after every deployment:

Configuring ASafaWeb

That’s it – job done! Now each time the scan runs there’ll be a little ASafaWeb tab and a nice report on how the scan went:

The ASafaWeb report in OnCheckin

What I really like about this is the continuous nature of the process. Every time that build runs, the site is going to get scanned and so long as you’re keeping an eye on the results you shouldn’t have sneaky security misconfigurations making their way through to production. Well at least not for very long!

The other thing about this integration is that it’s another step towards publicly releasing the ASafaWeb API. Yes, there’s an API and in fact it’s been used extensively as the magic behind the ASafaWeb Scheduler which gives you the ability to scan your sites on a regular basis (I mentioned it’s free, right?!). The intention has always been to open the API up for anyone to consume I reckon including it into the continuous integration cycle is a fantastic use-case.

To that effect, if you’re involved in a similar project and would like to integrate ASafaWeb then I’d love to hear from you. I’m happy to open it up to beta testers who want to contribute feedback and I know there are a ton of good ideas out there for how it might be used.

Published at DZone with permission of Troy Hunt, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)