Last week I wrote about Gootkit’s futile attack on ASafaWeb and then a funny thing happened: Suddenly my Google Analytics keyword results become very Gootkit-centric:

I see this as meaning either there is a lot of interest in Gootkit at the moment or there is not a lot of information available on what it is. Or both. Interestingly though, the activity appears to have ramped up right about the time of my initial post. The search results all turn up results in late September this year including Gootkit auto-rooter scanner – hello, Gootkit auto-rooter scanner and the log files for weee-recycling.com (c’mon guys, don’t put your logs on public display!)

Let me try and both answer what it is and provide a bit of info on some anti-Gootkit defences.

With the private beta testing of ASafaWeb having gone quite nicely and a good whack of time then dedicated to both fixing stuff and implementing new features, it’s time to do something about this ugly duckling. I truly believe that the user experience is an absolutely fundamental factor in the success of a site and it really deserves some serious attention so rather than just hack it out, I’m going to approach it quite methodically and write about it as I go.

Here’s the story of ASafaWeb’s emergence from UX mediocrity to what will hopefully become a cohesive, engaging design.

On Saturday morning I woke up to 120 emails from ASafaWeb, not because it really likes me but because it was in pain! One thing I did very early on with the project was to implement elmah and make sure I get an email notification when anything happens that shouldn’t. It won’t stay this way (for reasons you’re about to see), but it’s a good way of keeping an eye anything that goes wrong very early on.
What elmah does is keeps a nice little log of all the things that happen on your site which shouldn’t; internal server errors, illegal URL formats and most importantly in this context, page not found errors (the classic HTTP 404). You can also log your own custom messages as well, but that’s another story. Elmah makes all this wonderful information available via a custom handler which gives you all the details right within your site (don’t forget to secure this!)

When news came through recently about the Bondi Westfield shopping centre’s new “Find my car” feature, the security and privacy implications almost jumped off the page:

“Wait – so you mean all I do is enter a number plate – any number plate – and I get back all this info about other cars parked in the centre? Whoa.”

If that statement sounds a bit liberal, read on and you’ll see just how much information Westfield is intentionally disclosing to the public.

Here’s a new entry for the “stupid things on my part which weren’t obvious because of obscure error messages” book. Actually, the error message makes some sense in retrospect but then again, everything is always a lot clearer after the fact.

The scenario in this instance relates to the following three tables in ASafaWeb:

What these guys are describing is that when a log entry of a scan is created, it may have many entries of the X-Powered-By header (this comes through as a comma delimited collection). A typical way of normalising this relationship is to drop a mapping table in the middle, in this instance the “LogXPoweredByHeader”. The cardinality displayed above is just what we’d expect in this scenario.

When I wrote about Building a safer web with ASafaWeb earlier in the week, I talked about using the process to share some experiences. This one made me go a bit cross-eyed and it’s a combination of an idiosyncrasy within ASP.NET routing and a more philosophical question about the semantic intent of a route.

The situation was that I needed to construct a URL on the ASafaWeb website which contained the address of the site to be scanned and could be accessed via an HTTP GET request. The reason I want to tackle it this way is so that this URL can be passed around in the fashion of “Hey, look at the scan result I just got” and all the information required to execute an identical scan is encapsulated within the address.

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.