ASafaWeb

A lot has changed in the Microsoft technology world in the last 7 years since I launched ASafaWeb in September 2011. Windows XP is no longer the dominant operating system (Win 7 actually caught up the month I launched ASafaWeb). Internet Explorer is no longer the dominant browser (Chrome was in 3rd place back then). Windows Server has gone from 2008 R2 to 2012 to 2012 R2 to 2016 to 2019. And lastly, .NET has gone through a heap of different versions (as has Visual Studio) from 4.x to Core 1 and now Core 2 (and minor versions within them). My own personal focus has also changed moving from corporate life to independence. From development and architecture to security....

A Twitterer sent me this a few days ago: .@troyhunt you've got SSL issues in Chrome 58+ on @ASafaWeb pic.twitter.com/qtUiMxV9tW — Jonathan (@Eonasdan) April 13, 2017 Now normally when I get a report about an SSL thing not working (by which we mean TLS, but we say SSL anyway), I jump on over to SSL Labs (see?!) and run a report I can then direct people to. This usually provides emphatic proof that the SSL configuration is fine and they've just got an old client or some funky MitM stuff going on in their local network. However, this time was different: "Grade will be capped to T". Now I didn't immediately realise what...

Remember view state? For that matter, do you even remember web forms?! I kid because although MVC is the new hotness in the world of building ASP.NET websites, web forms remains the predominant framework due to both the very long tail of sites already built on it and the prevalence of developers with skills in this area who haven’t made the transition to MVC (indeed some people argue that they can happily cohabit, but that’s another discussion for another day). Anyway, back to view state. When we entered the world of .NET more than a decade ago now, view state was the smoke and mirrors that turned that stateless HTTP protocol into something that actually...

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...

The unfortunate reality of the web today is that you’re going to get hacked. Statistically speaking at least, the odds of you having a website without a serious security risk are very low – 14% according to WhiteHat’s State of Web Security report from a couple of weeks ago. Have enough websites for long enough (as many organisations do), and the chances of you getting out unscathed aren’t real good. There’s this great TEDx talk by Jeremiah Grossman titled Hack Yourself First where he talks about the importance of actively seeking out vulnerabilities in your own software before the evildoers do it for you. In Jeremiah’s post about the talk,...

Since a very young age, many of us have been taught that C is for cookie and that apparently, “That’s good enough for me”. Except it’s not – the hidden depths of the cookie were never really explored so is it any wonder that after being ingrained with such a trivial view of cookies from such a young age that so many of us are handling them in an insecure fashion? You see, there’s far more to cookies than meets the eye and I want to delve into a couple of aspects that when configured poorly, can pose serious risks to website security. Most of the time when I see these two...

There are two security principles which I hold dearly but are often counterintuitive: Users should be able to create any conceivable password they desire – no limits! All input should be treated as hostile and properly sanitised against a whitelist. This is counterintuitive advice in so far as that second point has always been partially supported natively by ASP.NET request validation. I say “partially” because it’s not the final word in request validation and you should always properly whitelist your allowable input in addition to the native framework defences. That said, you should always (at least wherever possible) leave request validation enabled and in the past I’ve been critical of those who don&...

Remember hash DoS? This was that very clever yet equally nasty little attack which meant that if you formatted the parameters in a post request juuuuust right you could take down an ASP.NET website with a mere single request. Bugger. This made for a rather unpleasant Christmas and New Year period for a number of people at Microsoft as well as sys admins the world over. Microsoft had rapidly released a the MS11-100 critical patch or in other words, the stop-what-you’re-doing-and-install-it-RIGHT-NOW patch. But it wasn’t really a patch per se in that it didn’t fix the underlying vulnerability which was related to hash collisions. Instead, it stopped an attacker from posting more than...

I started building ASafaWeb – the Automated Security Analyser for ASP.NET websites – about a year back to try and automate processes I found I kept manually doing, namely checking the security configuration of ASP.NET web apps. You see, the problem was that I was involved in building lots of great apps but folks would often get little security configurations wrong; a missing custom errors page, stack traces bubbling up or request validation being turned off among numerous other web app security misdemeanours. The thing is, all these things are very easily detected remotely without any access to the source code, you just need to make a few HTTP requests and draw some conclusions based on the structure...

Let me pose a question: What’s the difference between these two URLs: http://[mydomain]/?foo=<script> http://[mydomain]/?foo=<script> Nothing, right? Let’s plug that into two different browsers and see what they think: Ok, now it’s just getting weird and this brings me to the topic of the day: Recently a friendly supporter of ASafaWeb contacted me and said “Hey, how come ASafaWeb isn’t correctly identifying that my site is throwing custom errors?” Naturally the first thing I did was to run a scan on the site using my favourite Google-sourced browser: I then double checked it manually in the browser and proceeded to tell...