Today sees the release of AntiXSS v4.2 in order to address MS12-007. As AntiXSS is a developer tool developers need to download the latest version, test, then deploy the web sites using the library. nuget has also updated – if you’ve added AntiXSS via nuget you’ll need to update the package.

It is recommended you test and apply the new version as soon as possible.

The vulnerability only affects the HTML sanitizer. The sanitizer has been changed to remove all CSS it encounters, this new behaviour means that if you were expect CSS formatting to remain after sanitization this is no longer the case.

In addition to the change necessary to correct the vulnerability there are a few new features;

• Minimum Requirements.
  You can now, once again, use the encoder libraries with .NET 2.0. The installer will create directories for each framework version supported, .NET 2.0, .NET 3.5 and .NET 4.0 which contain an optimized version of the encoders for that platform.

• Invalid Unicode no longer throws an exception.
  Invalid Unicode characters are now replaced with the Unicode replacement character, U+FFFD. Previously, when encoding strings through HtmlEncode, HtmlAttributeEncode, XmlEncode, XmlAttributeEncode or CssEncode invalid Unicode characters would be detected and an exception thrown.

• UrlPathEncode added.
  The encoding library now has UrlPathEncode which will encode a string for use as the path part of a URL.

• .NET 4.0 encoder support.
  There’s finally an official way to swap AntiXSS into the framework. If you are using .NET 4.0 ensure you are using the .NET 4.0 version of the encoding library and then edit your web.config and add the encoderType attribute to the httpRuntime element; i.e.
  <httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary"/>

The nuget package does not swap out the encoder as nuget configuration transforms can’t be made framework version specific yet so you will have to do that manually. Source code will uploaded to codeplex within the next few days.

Remember that downloading the new version is not enough – you will need to update your projects to use the new version then publish them to your web servers.

This release has also merged code from the .NET framework, taking some of their hard work in integrating the core AntiXSS functions into v4.5. There are some performance improvements in encoding.

It’s rather strange for me reviewing Web Application Security - A Beginner's Guide given that I've written a book on the same topic, but as I know one of the authors, Bryan Sullivan and McGraw Hill offered me a copy for review it seems rather churlish not to.

Bryan and Vincent Liu have produced a book which is technology agnostic, covering web security via principles rather than sample code. It is a complete beginner’s book, suitable for a developer who has never thought about security before or for a manager to try to figure out just what the heck their developers are talking about and why they want to spend some extra development time locking something down.

As the book is principle based it’s easy to read through, each chapter does contain a lot of information about the topic under discussion – for example the authorization chapter covers not just where to authorize but types of permissions, controls, client side attacks, exploits, session management and SSL. The book doesn’t stay just on the server application, it reaches out to browser security, database security, file server security and how to build security into your processes and development cycle.

This isn’t a book a developer can use to solve their problems, rather it’s a book that should send them off to learn more about their specific languages or frameworks. The advice contained inside is practical though and provides checklists for readers to use to ensure they’re thinking in the right way. You’ll end up knowing what the problems are and how to solve them in theory, but to learn how to solve them in practice for your system is left as an exercise for the reader. This isn’t a bad thing at all, when you hunt down and figure out the solution on your own, or research further with other books or resources the resulting solution may stick with you for longer, rather than just having the code given to you on a plate.

If you’re a developer than already knows some of the risks you may be better off with a book targeted at your area of expertise. If you haven’t thought about security yet, or even better, you’re a student who is just starting out on web application development then this book is for you. Frankly I’d like to ram it into the brain of every student currently doing any development courses at university, the knowledge gained would save us all a lot of trouble in a few years time.

Oh how I have wanted to sing about this for months, now it’s public …

Due to the popularity of the Microsoft AntiXSS Library, ASP.NET 4.5 now incorporates core encoding routines from version 4.0 of that library.

The encoding routines are implemented by the AntiXssEncoder type in the new System.Web.Security.AntiXss namespace. You can use the AntiXssEncoder type directly by calling any of the static encoding methods that are implemented in the type. However, the easiest approach for using the new anti-XSS routines is to configure an ASP.NET application to use the AntiXssEncoder by default. To do this, add the following attribute to the Web.config file:

<httpRuntime ... 
  encoderType="System.Web.Security.AntiXss.AntiXssEncoder, System.Web, 
    Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

When the encoderType attribute is set to use the AntiXssEncoder type, all output encoding in ASP.NET automatically uses the new encoding routines.

These are the portions of the external AntiXSS library that have been incorporated into ASP.NET 4.5:

• HtmlEncode, HtmlFormUrlEncode, and HtmlAttributeEncode
• XmlAttributeEncode and XmlEncode
• UrlEncode and UrlPathEncode (new)
• CssEncode

♫ I’ve got code in the framework, I’ve got in the framework ♫

I was a guest on two podcasts last week, just in case you’re interested.

The first was RunAs radio, discussing the DigiNotar hack with Richard Campbell and its consequences for IT administrators. This was followed the next day by Developer Book Club, a rather interesting idea created by Helen Emerson where developers talk about 3 books which influenced their development careers.

Hot on the tails of Rachel Appel calling me a security expert a couple of weeks ago I persuaded Scott Hanselman to destroy his reputation and record a Hanselminutes with me. As is usual with any podcasts I take part it I meander around anything meaningful, but I blather about web security, Lulzsec and more.

If you want to follow real security experts on twitter the ones I follow are

• Window Synder 
• Katie Moussouris
• Richard Johnson
• Jeremiah Grossman
• Iftach Ian Amit
• Lurene Grenier
• Charlie Miller
• Billy Rios
• Dan Kaminsky
• Gunnar Peterson
• Jeremy Dallman
• Mike Andrews
• Michael Howard
• Christofer Hoff
• Adam Shostack
• Dinis Cruz
• Microsoft Security Response

I’ve also listed the MS Developer Security MVPs in a twitter list.

(I knew there was a reason I didn’t do a lot of podcasts though)

Now my DevSecNerdRage™ has calmed down I thought it might be guess at what went wrong with Citibank and how you, as a developer, can avoid making the same mistake. From reports in the New York Times it appears the attackers had a valid login and password for a Citibank credit card site and once in they changed the account number in the URL. This is a great example of Insecure Direct Object Access.

I can imagine the code / configuration doing one thing; (all code in this post is pseudo code)

if (IsAuthenticated)
{
  LoadAccount(Request.QueryString["accountNumber"]);
}

Its not the first time this has happened on a high profile system – a few years back junior doctors had their information exposed by the system they were using to apply for placements, MTAS, in much the same way. Rather than just account numbers this exposed criminal convictions, phone numbers and even sexual orientation.

So how to we approach fixing this? First let’s secure the direct object reference. Right now at work I’m rewriting a system which controls SSL Certificate issuance within Microsoft. Each request has a request ID, and the URLs work as you would expect, example.com/create, example.com/view?id=1 and so on. Each database record has a CreatedBy field, and so when someone tries to view the record I do something like

CertificateRequest certificateRequest = repository.GetRequest(id)
if (certificateRequest == null)
{
    RedirectToAction("Not Found");
}
if (certificateRequest.CreatedBy != User.Identity.Name)
{
    // Unauthorized
    // Set off big whooping sirens and flashing lights
    RedirectToAction("Unauthorized");
}

That’s fine for my little system, but perhaps not for a bank, or an extranet exposing orders. Why not? Well I could write a crawler that starts with an id field of 1 and counts upwards. Even if I wasn’t authenticated I’d get an Unauthorized result if I hit a valid request. This would enable me to work out how many orders, or accounts are in a system. This sort of information leak in an order system might be interesting to a competitor – all they do is keep incrementing until they get a “not found” error and now they know how many orders your company has taken. With a credit card system you could use this to discover active account numbers if you have different results for unauthorized and not found errors.

So we need to change the direct object reference to an indirect object reference. An indirect object reference is a non-primary, non-sequential key, which resolves back to the object you want. The usual way to do this is to have a mapping column in your record, which you guarantee is unique and non-sequential. If you’re thinking of a GUID right now beware – guids issued quickly, one after the other have a high degree of predictability, you could go from d129b4ad-212f-4d7d-93a6-0d681efa4793 to d129b4ad-212f-4d7e-93a6-0d681efa4793 easily, especially if you’re fixing up an existing table and adding a new column for an indirect reference and let SQL generate them as a default value for existing rows. If that is the case, add the column, then have a little command line program or stored procedure which goes through your table line by line and pauses for a random amount of time, generates the GUID, and then inserts it.

However we can get better security than this. The perfect indirect object reference is unique on a per user basis. If, for example, I have three accounts with my bank, and I have a drop down to switch between them then I could do the following:

<select>
  <option value="1">Checking</option>
  <option value="2">Savings</option>
  <option value="3">Credit Card</option>
</select>

Now we have unique, per user, identifiers. Our loading code would become something like

AccountDetails accountDetails = repository.GetAccountDetails(id, User.Identity.Name)
if (accountDetails == null)
{
    RedirectToAction("Not Found");
}

We’ve taken away the direct object reference and made the account dependant on an indirect object reference which is user specific. The ownership check has become a core part of loading the account. If you’re worried about an attacker working out how many accounts a user has in this scenario remember that in order to get to the page they’re going to have to have valid credentials, so they can see the drop down anyway.

In addition to all of this if you’re passing these via query strings you could use tamper-proof linking, where you create an HMAC of the parameters you want to protect and append that as a parameter to the URL, validating it when the new page is loaded.

Insecure Direct Object Reference is covered in the SDL Threat Modelling tool and is easily discovered in code reviews. Yes both threat modelling and code reviews have a security tax associated with them, they do take additional time, but as you do them and get used to them you’ll find the tax becomes smaller and smaller. It will never go away, but then do you want to be caught up and embarrassed as badly as Citibank was this week?

Last month I was rather pleased to welcome Troy Hunt into my little band of Developer Security MVPs. He’s been doing a bunch of blog posts on the OWASP Top 10 list for ASP.NET developers. Check them out, he’s almost finished.

This makes me bang my head on the desk

In the Citi breach, the data thieves were able to penetrate the bank’s defenses by first logging on to the site reserved for its credit card customers.

Once inside, they leapfrogged between the accounts of different Citi customers by inserting various account numbers into a string of text located in the browser’s address bar. The hackers’ code systems automatically repeated this exercise tens of thousands of times — allowing them to capture the confidential private data.

As if insecure direct object references aren’t bad enough, it’s the quotes from the security “expert” that really rankle;

It would have been hard to prepare for this type of vulnerability.

Bullshit. Utter bullshit. If, as the NY Times reports, it was a simple matter of changing URLs once you had a login it would not be hard to prepare for this. This should have been caught in even the simplest automated review. This was not sophisticated or ingenious, as reported, this was boringly simple. It does however point to an industry wide failure in developer education. OWASP has had Insecure Direct Object references on it’s Top 10 list for years. It’s in the SDL Threat Modeling tool. Any security firm worth its salt checks for this, and I’d guess CitiBank employ a few. So why aren’t developers mitigating what are, to me, obvious faults. Why do we still suffer SQL injection? Cross Site Scripting? And what the hell can we do about it?

In celebration of the bright shining thing in the Seattle sky (I haven’t seen it in a while, I’m scary) I’ve pushed new source for the AntiXSS encoding libraries to codeplex, including specific support for swapping out the default encoders in .NET 4.0.

As this is only a beta there are no binaries, you will need to grab the source yourself and compile. Replacing the default encoders in .NET 4.0 will require you to use the DLL from the Net4 project and to make a web.config change to the httpRuntime node as follows

<httpRuntime encoderType="Microsoft.Security.Application.AntiXssEncoder, AntiXssLibrary"/> 

The runtime encoder feature should work with both WebForms and MVC (either the webforms or Razor view engines).

Nothing else has changed, please feel free to log any weird encoding bugs you see on codeplex, especially if you swap out the default controller - this may cause hiccups with 3rd party controls which make assumptions about encoding.

So for the past few months I’ve been working on internal projects (hence no blogging – there’s nothing to share). For one of the projects, a complete rewrite of an internal site currently in ASP (woohoo, VBScript!) to MVC. Admittedly it’s only MVC 2.0  for various reasons and boy, do I regret that choice after seeing the new 3.0 tools at MIX.

Obviously MVC gives me (and my minions) the opportunity to test properly and part of that is code coverage. However I had real problems getting it to work, every time I turned code coverage on the MVC project MSTest would barf with Could not find WebDev.WebServer40.Exe. Why on earth would it want that? I don’t need the web application spun up, I’m just testing the controllers. I bugged a couple of mailing lists, and even went nuclear and emailed Phil Haack. He suggested starting a new test project, so I did, enabled code coverage, checked all the project boxes and still got the problem. Bum.

After having a couple of days messaging with AntiXSS (there will be a new beta of the encoding library soon with ASP.NET 4.0 swap out support) I went back to this. I loaded up the test projects in notepad and did a compare, nothing was particularly different. I removed a couple of odd references which referred to web tests, still nothing. So, in a fit of desperation I loaded up the local.testsettings file in notepad … and there was something strange,

<CodeCoverage keyFile="ssladmin.snk" xmlns="">
    <Regular>
        <CodeCoverageItem binaryFile="SSLAdmin.Model\bin\Debug\SSLAdmin.Model.dll" pdbFile="SSLAdmin.Model\bin\Debug\SSLAdmin.Model.pdb" instrumentInPlace="true" />
        <CodeCoverageItem binaryFile="SSLAdmin.Repositories\bin\Debug\SSLAdmin.Repositories.dll" pdbFile="SSLAdmin.Repositories\bin\Debug\SSLAdmin.Repositories.pdb" instrumentInPlace="true" />
    </Regular>
    <AspNet>
        <AspNetCodeCoverageItem id="62cc324d-bf2f-4a6d-9b97-85aaec4d6e77" name="SSLAdmin.Web" applicationRoot="/" url="localhost:0/" />
    </AspNet>
</CodeCoverage>

What on earth is that ASP.NET node? That looks rather suspicious. Turns out that’s the culprit. What I had done was simply check the projects in the code coverage detail dialog;