ASafaWeb

A 23-post collection

Understanding (and testing for) view state MAC in ASP.NET web forms

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

Dynamic security misconfiguration scanning with OnCheckin and ASafaWeb

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

Hack yourself first – how to go on the offence before online attackers do

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

C is for cookie, H is for hacker – understanding HTTP only and Secure cookies

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

Do you allow XSS in your passwords? You should!

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