Monday, 29 March 2010

Book Review: Beginning ASP.NET Security

If you're doing web development with ASP.NET, you need this book. Simple as, end of.

And I'm not just saying that because I'm mentioned in it (page 235 for those of you playing along at home).

When I heard Barry was writing a book, I knew it'd be a good one to get, having seen Barry speak on security topics at several user groups and conferences. And now I've read it I can see it's going to become one of those books that never gets put away neatly on a shelf, it's always going to be open on someone's desk. Experienced developers shouldn't be put off by the 'Beginning ...' in the title, this book is for every ASP.NET/MVC/Silverlight/WCF developer who has security concerns. Which should be all of you.

The approach of the book is task-oriented; each chapter describes one or more vulnerabilities that a web developer may come across, and then describes how to mitigate against them. I started learning right from the first technical chapter, which covers validation: there are several things I've picked up about the ASP.NET validator controls, including how to validate input data against a .NET data type and how to write a custom validator. Cross-Site Request Forgery isn't quite what I thought it was either. Of course, things like Cross Site Scripting and SQL injection are covered, but also some of the more obscure vulnerabilities that are traps for the unwary; I'd never heard of things like traversal attacks and XPath injection. There is an excellent chapter on encryption covering all the options available in the .NET Framework for encypting and decrypting your data, although I'd have liked to see for each type of encryption some more suggested scenarios in which each method is appropriate. Coming right up-to-date Barry also covers how to use external authentication providers like OpenId, *ahem* LiveId and Windows Identity Foundation, and finally has a whole chapter on securing MVC applications, lest the lack of Viewstate and auto-encoding <%: tags leads MVC developers to believe there's nothing more they need to do.

Right, I'm off to do a security review of all our live sites. I may be some time...

Wednesday, 3 March 2010

What's New in AppFabric Caching Beta 2

Typical - just as I get an AppFabric Beta 1 caching cluster up and running for Edge UG this month, they release Beta 2!

This is, by all accounts, now a feature complete release for v1.0 with the RTM expected in Q3 this year. There is, however, no Go Live licence here, unlike Visual Studio. Let's take a look at AppFabric B2 and see what's changed (from a caching perspective)...

What's New in Installation
First of all, this release is aligned with the Release Candidate of .NET 4.0 and VS2010, so the dependency on the .NET Framework is moved up from the beta to the .NET 4.0 Release Candidate. Note that if you're removing the .NET 4.0 Beta in order to install AppFabric, you need to do this in Control Panel|Programs and Features, and uninstall the .NET 4.0 Framework Extended first, then the the .NET 4.0 Client Profile.

The installer seems to have had quite a bit of time spent on it for this release.
The set of features to install is largely the same as we saw in Beta 1, with the addition of an administration piece for the Dublin workflow component.

Post-installation, the AppFabric caching service has been renamed and no longer refers to the Velocity codename; it also now is not marked as a CTP (unlike the caching service in Appfabric Beta 1 which still showed as CTP4).

Installation and configuration have been decoupled into two separate wizards, which should make it possible to reconfigure a cluster without having to un- and re-install.The configuration wizard can be started at the end of installation, or separately from the Start menu.

What's New in Configuration
As before when configuring the caching piece you have to decide whether to store configuration information in SQL Server or using XML and a network share. There's still no guidance on when you should use one or the other, although included in this release is a comprehensive help file.

Selecting the SQL Server provider and clicking the Configure button opens this sub-dialog where you can build up the connection string to the configuration database. It's now explicit that if you enter the name of a database that doesn't exist and select the 'Create...' checkbox then the configurator will go and create the database for you. If you're adding a server to an existing cluster, then the 'Register...' checkbox is the one to select; if you unselect both checkboxes you lose the ability to enter any connection string information. However there seems to be a slight bug in that whether you create a new database from scratch or register a server to an existing database, when you return to the main configuration screen you can still choose whether you are creating a new cluster or joining an existing cluster.
As before, the configurator allows you set the size of the cluster to optimise the clusters' performance. The help file states that 'once you set the cluster size during configuration, you cannot change it later', however it's unclear how this fits in with the ability to re-run the configurator from the Start menu.

As I run my Velocity VM cluster with Windows Firewall disabled, I'm pleased to see that the Cache Node configuration page now detects when the firewall is disabled and accordingly disables the firewall exceptions checkboxes. This is a change to Beta 1 where the Velocity installer log would register a warning if the firewall was disabled.

What's New in Powershell
In a change from previous installs, there doesn't seem to be a Velocity Administration Powershell console installed by default; to access the Velocity Powershell commands you need to run up Powershell and then run 'import-module DistributedCacheAdministration'. Or you can add it to your Powershell profile - run 'get-help profiles' for details on doing this.
Looking at the list of Powershell commands available it seems that, unforgivably, there's still no commandlets for managing regions.The Install-Data and Install-Bits cmdlets that were in Beta 1 have disappeared.

A new feature is that it seems you can now use Powershell on any server with the Velocity cmdlets installed to manage any Velocity cluster, by using the 'Use-CacheCluster' cmdlet with a connection string to a configuration store (though the documentation talks about a connection string which implies this only works with the SQL Server provider). This cmdlet sets the context of subsequent commands e.g. Start-CacheCluster, Restart-CacheCluster. This enables you to manage multiple clusters from a server that isn't in any cluster. If you're running Use-CacheCluster on a server that is inside a cluster and has Cache Administration (from the installer) set up, you don't need to use any parameters, the current cluster is implied.

What's New in Client Configuration
The assemblies that you need to add to a project to use Velocity have been renamed, to Microsoft.ApplicationServer.Caching.Core.dll and Microsoft.ApplicationServer.Caching.Client.dll (in Windows\System32\AppFabric). The namespace has changed again, to Microsoft.ApplicationServer.Caching. And the requirement to also reference the Fabric assemblies has been removed, so there's only two references to add which makes the whole thing seem much cleaner.
The MSDN article on setting up the client environment states that there is a problem with referencing these DLLs as Visual Studio is unable to browse to Windows\System32\AppFabric, and that you need to hand-edit the project file to include these references. This seems to be incorrect, as I've just done it - I suspect that this may be due to the fact I'm running Visual Studio under an account which is an administrator on the server and thus has access to everything.
A couple of the old annoyances when writing client code are still there:
  • DataCacheFactory.GetCache is still not a static method, you still need to new up a DataCacheFactory.
  • Some of the code around using DataCacheServerEndpoints seems to have been refactored a little bit, but it still runs on an array, not a List(Of DataCacheServerEndPoint). But you can, of course, still get round this by using a List(Of DataCacheServerEndpoint) and then calling .ToArray on it.
That's all I've discovered that's new (for now), but I'll post more updates as I discover things!