Sponsored by:

.NET

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

Time travelling with dates and time zone conversions in .NET

Here’s a little magic trick in .NET: In ASafaWeb I have a facility to schedule scans at a certain time of day. Because I want to be all warm and fuzzy and user friendly, when people sign up to the service I ask for their time zone then whenever they schedule a scan they enter the time of day they’d like it to happen in their local time and I pull some magic tricks to make it happen. The process has been working flawlessly since the middle of last year – until this weekend when I started getting error notifications that something was amiss. You see, the magic trick involved taking the time of day in...

Stored procedures and ORMs won’t save you from SQL injection

This content is now available in the Pluralsight course "Ethical Hacking: SQL Injection" Everybody knows the easiest way to save yourself from SQL injection is to use object relational mappers (ORMs such as Entity Framework) or stored procedures, right? Often I see this becoming a mantra: “You don’t need to worry about SQLi if you’re using [Entity Framework | stored procedures]”. I also see the mantra blindly repeated and it’s wrong, very wrong. Of course this isn’t new to many people but it’s worth a recap of just how easy SQLi in poorly implemented code using ORMs or stored procedures. So let’s exercise some SQLi...

Metadata file could not be found in a solution path with escaped spaces

After a short exchange of friendly but accusatory cross-continental messages, I’ve learned something new about .NET projects today. Let me start with the symptoms as that’s the first thing I Googled for and how I suspect others will find this and save themselves some pain in the future. Let’s say you have a solution like this: This is a brand newie right out of the box to demonstrate the problem. The web project references the ClassLibrary project as a project reference. In other words, the project file contains something like this: <ProjectReference Include="..\ClassLibrary\ClassLibrary.csproj"> <Project>{705479f2-2820-44ea-a983-f03c70ae0754}</Project> <Name>ClassLibrary</Name>...

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

Fixing hash DoS good and proper (and breaking ASafaWeb)

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

Welcome to the ASafaWeb scheduler

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

Stronger password hashing in .NET with Microsoft’s universal providers

Last month I wrote about our password hashing having no clothes which, to cut to the chase, demonstrated how salted SHA hashes (such as created by the ASP.NET membership provider), offered next to no protection from brute force attacks. I’m going to assume you’re familiar with the background story on this (read that article before this one if not), but the bottom line was that cryptographic hashing of passwords needs to be way slower. Not half the speed or even one tenth of the speed, it needs to be thousands of times slower. The conclusion of the post was frankly, a little unsatisfying. Why? Because it essentially said “If you take my favourite technology...

Our password hashing has no clothes

In the beginning, there was password hashing and all was good. The one-directional nature of the hash meant that once passed through a hashing algorithm the stored password could only be validated by hashing another password (usually provided at logon) and comparing them. Everyone was happy. Then along came those pesky rainbow tables. Suddenly, huge collections of passwords could be hashed and stored in these colourful little tables then compared to existing hashed passwords (often breached from other people’s databases) at an amazing rate of knots thus disclosing the original plain text version. Bugger. So we started seasoning our passwords with salt. Adding random bytes to the password before it was hashed introduced unpredictability which was the kryptonite...