ASP.NET Security Fix Now on Windows Update
page 3 of 5
by Scott Guthrie
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 21721/ 43

Useful Notes and Frequently Asked Questions

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. 


View Entire Article

User Comments

No comments posted yet.

Product Spotlight
Product Spotlight 





Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-28 8:16:00 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search