CachingHandler Removed from EntLib 5.0 for Security Concerns?

Topics: Policy Injection Application Block
Jun 10, 2010 at 2:00 PM
Edited Jun 10, 2010 at 2:04 PM

The 5.0 documentation states that the Policy Injection Caching Handler was removed due to previously documented, unresolvable security concerns and "cache contamination".  I searched around and the only security/contamination issue that I can find documented is the fact that if you cache the response to a method call whose behavior varies base on the currently authenticated user (or any other out of band information for that matter) then of course the handler is not aware of this and may return values intended for one user to subsequent users.  

What I am trying to confirm is if this is the only reason for which the handler was removed from 5.0.  Or are there other concerns that I need to know about if I choose to continue to use it?

I am concerned that there is a deeper security issue. If the aforementioned is the only concern, then why was the handler removed from 5.0?  In 4.1 the documentation clearly indicated the risks but let you use the handler.  Has someone decided that this type of risk is serious enough that we should not use caching with AOP anymore?  That seems a bit much for those of us who just need to cache a bunch of user-agnostic static lookup data.

Lastly, the documentation for 5.0 states that if we still want to use the caching handler, it has been moved to the Enterprise Library Contrib project.  I have looked in both the 5.0 and 4.1 contrib code base and cannot find it.  I did find it in the Ent Lib 4.1 code base.  Can someone tell me where I might find it in the contrib project?

--Ken

Jun 10, 2010 at 7:01 PM

There were both the security concerns you mentioned and general concerns about robustness. There were chances of collision in the hash keys which made it very difficult to ensure there weren't cache collisions. Basically, we couldn't see a way to get it working correctly without a TON of additional time, which we didn't have.

The Microsoft security bar has gotten more stringent in the year since Entlib 4.1 was released. It used to be acceptable to ship with the given warning. Now it is not.

 

Jun 16, 2010 at 2:56 PM

Hi,

I've been tasked to investigate whether the upgrade from Enterprise library 4.1 to 5 will cause our existing web application any problems. We currently use Policy Injection for logging, exception handling and CACHING.

We're interested in using the Data Annotation funcionality that EntLib 5.0 provides, but not at the expense of losing the Policy Injection Cache Call handler (which has been dropped in Entlib 5.0).

You mentioned unresolvable security concerns in your post, but is it still a concern if we cache user-agnostic static lookup methods? It wasn't quite clear from the post above.

I understand that security and collision problems were encountered in the Cache Call handler, but where does that leave us if we still want to upgrade to EntLib 5?

What are our options, as we are between a rock and a hard place?

One soluction would be to lift the Cache handler source code from 4.1 and use that in conjuction with Entlib 5.0.
What are the implications of doing that and is there a better solution?

Many thanks.

- Ray -

 

 

 

 

 

Jun 17, 2010 at 5:35 AM

Pulling the code from Entlib 4.1, and updating it 5.0, is pretty much your only option short of rewriting it from scratch. Getting the code running shouldn't be hard.

The security concerns were around leaking information between users, so if that's not an issue for your app, it's not an issue for your app. It was way too small a "well, it's ok in this one tiny circumstance" to get it past Microsoft security review.

The other major issue was the use of the ASP.NET cache as the storage mechanism. Turns out I was wrong and we found out that the ASP.NET cache doesn't scavenge properly in non-web applications. But again, you're in a web app already so that should work fine.

The other major problem is that there's no good way to determine a unique key for the combination of inputs. As a result, there is a non-zero probability of collision between different sets of inputs, and there's no way to tell if you're getting a false hit in the cache.

Evaluate these factors, decide for your application, and move forward.

 

Jun 17, 2010 at 9:22 AM
ctavares wrote:

Pulling the code from Entlib 4.1, and updating it 5.0, is pretty much your only option short of rewriting it from scratch. Getting the code running shouldn't be hard.

The security concerns were around leaking information between users, so if that's not an issue for your app, it's not an issue for your app. It was way too small a "well, it's ok in this one tiny circumstance" to get it past Microsoft security review.

The other major issue was the use of the ASP.NET cache as the storage mechanism. Turns out I was wrong and we found out that the ASP.NET cache doesn't scavenge properly in non-web applications. But again, you're in a web app already so that should work fine.

The other major problem is that there's no good way to determine a unique key for the combination of inputs. As a result, there is a non-zero probability of collision between different sets of inputs, and there's no way to tell if you're getting a false hit in the cache.

Evaluate these factors, decide for your application, and move forward.

 

Thanks for the quick reply. This is very helpful. 

We can live with the security limitations in our app, but we'll have to think hard whether we can live with the collisions. It really boils down to risk vs performance. Many thanks for the help.