In case it’s not already pretty obvious by now, there are a bunch of websites out there which have some rather glaringly large vulnerabilities in them. Or at least they did have, then they were hacked in spectacular fashion and security suddenly became important to them. But of course we only hear about the big ones whilst hoards of smaller attacks go by unreported and very often, unnoticed.
The thing about web app security is that it can be a complex subject. It’s pretty fair to say that it’s a discipline all of its own within software development and it can be a specialised one at that. Even the “low hanging fruit” such as XSS and SQL injection – the ones that are easy to defend against with modern frameworks – are often poorly understood.
To that effect, over the last year and a bit I’ve been writing about the OWASP Top 10 specifically targeted at .NET developers. The idea has been to take the great work done by the folks at OWASP and contextualise into my favourite language so that developers actually have a practical guide to implementing it. As a rough indication of the depth behind some of these topics, I churned out nearly seven and a half thousand words just to describe insecure cryptographic storage. Like I said, security can be complex.
Because I want to help .NET developers easily build a safer web, I came up with ASafaWeb.
What’s ASafaWeb?
It’s an acronym for Automated Security Analyser For ASP.NET Websites with a few letters capitalised to imply intent. Ok, it’s a bit lengthy, but do you know how hard it is these days to find a name that’s available as both a .com and a Twitter account and actually has some meaningful significance to it?! Anyway, I now have ASafaWeb.com and @ASafaWeb.
Let me begin by addressing what it’s not right up front: it’s not a dynamic security analysis tool the likes of Netsparker or Burp Suite. Tools in this class are very advanced and offer features to perform all kinds of attacks against applications built on a whole range of platforms. They also cost money (sometimes a lot of money), and whilst excellent products, they usually require some commitment from the operator to learn their nuances.
ASafaWeb is by design, a basic tool. The aim is to look for common security configuration issues specifically within ASP.NET websites then provide resources to help harden the site. In fact in many ways it’s like WCSA, the Web.config Security Analyser.
The point of difference with ASafaWeb is that it runs directly against a live site – any live site – and it requires nothing more than a URL. It won’t perform any potentially breaking scans and the whole process will be over in seconds at the most. And it will be free :)
Why bother?
Whilst this is an unequivocally a basic tool, it will still find configuration flaws in many web sites. In fact some of these sites will probably surprise you, but I’ll leave them nameless for now…
The sort of flaws I’m talking about are things like custom errors being off, YSODs with stack traces being returned, tracing still on, debug mode enabled and many, many more I won’t go into detail about just now. These are predominantly configuration issues and whilst not exactly the gaping hole that an out-and-out SQL injection flaw is, they may be used to exploit other vulnerabilities within the software. Let’s call them the gateway drug of ASP.NET app vulnerabilities.
One of the problems with configuration related security problems is that it’s easy for glitches to slip through. One day you’re doing some local testing with custom errors off and tracing on then next thing you know (or often don’t know), you’ve deployed the app without the proper production configuration settings (many people are still deploying it wrong and not using config transforms).
But the other reason I’m doing this – and this is the purely selfish one – is that it gives me a chance to play with some very cool technology I’ve wanted to do something practical with for a while. I talk about it a little on the about page of the current website (not much there today), but the app tier is MVC 3, EF, jQuery and some very cool libraries via NuGet. The hosting is courtesy of AppHarbor and if you haven’t heard about these guys before, it’s basically the coolest thing since sliced bread.
Actually, that last paragraph is not entirely selfish as it does give me a bunch of material to write about and share with the community. In fact I’ve got half a dozen blog posts in progress right now and I think there’s some very interesting stuff in there. It helps that I’m loving working with these tools and actually producing something for a change which is not something I normally do on a regular basis these days.
How will it work?
It’ll work a little bit like this:
Behind the scenes it’s simply making a series of HTTP requests and running some rules against the responses to ascertain how the target site is configured. It will explain the purpose of each scan, how it’s executed and then how to fix the configuration if something is broken.
I have a very alpha version of it running already and I’m pretty happy with the results. The tricky bit is that there’s a lot of variance in how different configurations respond, for example when you’re talking web forms versus MVC or you’re looking at response headers which tend to differ based on the host’s configuration.
What next?
I’m getting close to the point of asking for some input from people who know something about ASP.NET and / or web app security so if you’re one of these people and you’ve got five minutes free to try firing some URLs at it, drop me a line. Obviously the functional side of it is pretty critical and I don’t want to end up producing one of those tools that constantly spits out false positives at people.
The other thing is that I’ve done absolutely nothing on UI yet. Visual presentation is pretty important to me plus I want the thing to play nice across different platforms and devices so there’s a bit of investment required there yet. Once the left side of the brain needs a bit of exercise I’ll break out Photoshop and get to work on that.
I’ll also kick it off with a baseline of useful scans but that certainly won’t be the end of it. I’ve got a nice little product backlog of scans I’d like to add but don’t want to put everything on hold simply for the sake of delivering 100% completeness on day one. Iterative delivery, thank you very much.
Finally, I’ve got a bunch of other ideas in the pipeline around potential integration points and automation I’d like to explore more once the core system is bedded down. Actually, I think some of the potential is pretty cool.
When’s all this magical goodness coming?
Like I said earlier, if you’re happy to play crash-test-dummy then you’re welcome to take a look at that early alpha release. Otherwise I expect there’ll be something I can open up publically over the next couple of months. I want to make sure I take the opportunity to write about some of the positive experiences (particularly with the likes of AppHarbor), during the development process whilst the thoughts are fresh.
So in summary, ASafaWeb will be intentionally basic but also easily consumable without the barriers of either knowledge or cost. If you can build a .NET web app, this will make sense to you and hopefully it will actually make things a little safer out there.