Websites get hacked. Lots. This year alone we’re looking at some absolute whoppers; Sony, EVE Online, Sony, pron.com, Sony, MySQL.com, did I mention Sony?
Many times, the gateway to successful website exploits is simple misconfiguration. Custom errors were left off and thus leaked internal code. Or request validation was turned off which opened up an XSS flaw. These risks are often then leveraged to do other nasty stuff.
The thing is, many of these are also easily remotely detectable – certainly the bad guys know this. What I mean is that configuration vulnerabilities are apparent just by making the right requests to the website. Not “hacking” it in any sort of malicious context, just simply making some innocuous requests and inspecting the responses. This is what ASafaWeb does – the Automated Security Analyser for ASP.NET Website - and I’m very happy to now introduce it at asafaweb.com
It’s dynamic analysis, but not as we know it
There are some great dynamic security analysis tools out there which run against live websites and attempt to do all manner of nasty things in order to identify where vulnerabilities lie. These are advanced, thorough but also often complex and expensive. Don’t get me wrong – they’re fantastic tools – but there can be a significant barrier to entry.
I wanted to create something simple. I mean really simple. So simple, in fact, that you just plug the URL you want to scan into asafaweb.com and you’re off and running:
What this means is that right now, you’re about 30 seconds away from running an ASafaWeb scan of your site. It’s not going to go to anywhere near the extent of the fancy dynamic analysis tools (i.e. it won’t attempt malicious activity like SQL injection), but it will get you very quick answers about some fundamentals.
It’s for ASP.NET, but not exclusively so
ASafaWeb, by its very name, is targeted at ASP.NET websites. Looking for risks such as custom errors configuration is not going to do you any good in a PHP app. You can still scan a PHP site, but many of the results will come back clean as it cannot exhibit the same risks.
Having said that, other risks are common across technologies. For example, the risk of redirecting from HTTP to HTTPS (run a scan on a site that does this to understand why).
It’s not just about finding risks
Successfully finding configuration problems is great and ASafaWeb will do that just fine for many remotely detectable risks. But I also want it to be about education; it’s an opportunity to contextualise information about how to secure an application. That’s why each finding explains why it’s important and how to rectify it:
As part of this education, each scan also explains how it ran. In the example above, ASafaWeb was able to cause an internal error message by posting invalid View State. By causing an HTTP 500, ASafaWeb was then able to inspect how the app was handling errors. I want this process to be transparent; there are no black boxes in ASafaWeb.
It’s not just for security newbies
Most .NET devs know the fundamentals already. For example, most of us know that custom errors should be configured with a default redirect so there’s no yellow screen of death and particularly no stack trace. Yet many sites get out there into wild with this incorrectly configured, even the sites owned by the pros (I know – I’ve tested them).
The thing is, it’s very easy for this to happen unintentionally. For example, get a config transform wrong or apply the wrong build configuration. Or someone was just testing then forgot about it. It’s very easy to do and ASafaWeb lets you automate those checks many of us manually do after a release.
It’s easy to share scans
Each scan has a URL you can share which deep links directly to a scan of a site. Not a static result mind you (ASafaWeb doesn’t store any identifiable information about the sites it scans), but a link which will cause the scan to execute when loaded. It looks like this:
http://asafaweb.com/Scan?Url=isnot.asafaweb.com
The idea is that scans can be shared. It means you can test a website then pass that URL around – “Hey, we haven’t disabled tracing on our production site”. Certainly this is the way I’m going to be using it.
It’s very, very early days…
As of today, there are four scans performed by ASafaWeb. Also as of today, there are about a dozen more in the pipeline. I wanted to get something out there early that was simple enough to be easily manageable and that I could refine quickly in response to feedback. It’s about laying a solid foundation that can then be built on top of.
What you’ll see over the coming months is me blogging about configuration vulnerabilities, demonstrating how they can be exploited then adding the test into ASafaWeb so you can check your own sites.
…and it’s still beta
Being in “beta” is a bit of a get out of jail free card “Yeah, that bit doesn’t work so well, it’s in beta dontchaknow?” But it also means that feedback is really, really important. If you use ASafaWeb and it doesn’t do what you expect or you have great ideas for what it should do, send me an email, tweet me or use the comments below. Good, bad or otherwise, I really want to hear your feedback.
Go forth and test
That’s it – it’s now launched! There’s more background information on the About page and details about how each scan runs on the Scans overview page. Plus there’s also the recent blog posts I’ve made under the ASafaWeb tag in case you want to understand a bit more of the background. ASafaWeb is also on Twitter @ASafaWeb and I do monitor that account and will start tweeting from it so feel free to mention or follow it.
That’s it for now, I really hope this tool is of benefit. It’s early days, but there are exciting things to come. Go forth and scan!