In my blog post earlier in the week I answered a few commonly asked questions about the security updates.
Below are a few additional notes based on help we’ve provided a few customers
who have applied the update:
Do I Really Need to Apply this Update?
Yes. This update fixes security vulnerabilities that are
publically known. You must install this update patch to be safe.
Make Sure You Apply the Update on All Servers in a
Web-Farm
Because the patch modifies the encryption/signing behavior
of certain features in ASP.NET, it is important that you apply it to all
machines in a web-farm. If you have a mix-match of patched/un-patched
systems you’ll have forms-authentication, webresource.axd, and
scriptresource.axd requests succeed/fail depending on which server they hit in
the farm (since the encryption used would be different across them).
Persistent Forms Authentication Cookie Behavior
After you apply the security update, visitors who have a
persistent forms authentication cookie (the “remember me” scenario on login)
will no longer be logged into your site – and will need to login again.
The ASP.NET Forms Authentication system by default automatically handles this
scenario for you – and will redirect visitors with a pre-patch
forms-authentication cookie to the login page you’ve configured for your
site. No error page is displayed – the behavior the end-user sees is the
same as if the cookie had timed out. This is a good user experience and
doesn’t require you to take any additional steps to ensure un-interrupted
traffic to your site.
Note: We have had a few customers report problems with
persistent forms-auth cookies that turned out to be issues either in their
application code, or in a third party logging component they used.
Specifically, this application code attempted its own decryption of the forms
authentication cookie and threw exceptions when the cookie did not decrypt
successfully. If after applying the security update you see issues with people
who have saved forms authentication cookies visiting your site you might also
be encountering this. There are two ways you can fix it: 1) update your code
to not throw exceptions to end-users in these cases, or 2) modify the name of
the forms-auth cookie that ASP.NET’s Forms Authentication system uses.
Approach #2 is easy and doesn’t require any code changes - just modify the
<forms name=".ASPXAUTH"/> configuration section in your
web.config file and switch to a different cookie name. This will prevent
your code from throwing exceptions because the old cookie failed to decrypt
(instead the system will ignore the old cookie and issue all new cookies under
the new cookie name you’ve configured).
Forms Authentication can continue to work across
ASP.NET Versions
ASP.NET supports the scenario where you have multiple
applications on a server, and share the same forms-authentication cookie ticket
across all of them. It also supports the scenario where different applications
on the site use different versions of ASP.NET. For example, one part of
the site might be built with ASP.NET 2.0, another part with ASP.NET 3.5 SP1,
and another part ASP.NET 4. This continues to be supported with the security
update.
Note: If you are going to share the forms-authentication
ticket across .NET 2 and .NET 3.5 SP1 or .NET 4.0 sites, then we recommend
having .NET 2.0 SP2 installed to do so.
Make sure servers in a Web Farm use the same service pack of
.NET 2 on all machines
We have seen an issue with a customer where they were
running a site distributed across multiple servers in a web-farm, and some of
the servers were running .NET 2.0 SP1 and others were running .NET 2.0
SP2. The URLs for webresource.axd and scriptresource.axd end up being
different across the two Service Pack flavors when the security patch is
applied – which can cause problems if your web-farm doesn’t consistently use
the same service pack. You should make sure that the same service-pack of
.NET 2.0 is installed across all the machines in a web-farm if they are running
the same application across all of them.