Since installing rollup 6 we have been getting intermittent ‘Access Denied’ messages as per the forum entry below.

Since installing rollup 6 we have been getting intermittent ‘Access Denied’ messages as per the forum entry below.
http://social.microsoft.com/Forums/en/crmdevelopment/thread/57032ef6-c690-4ab2-a7e1-21f1081e5350?prof=required
We have added an additional key (HKLM>Software>Microsoft>MSCRM>IgnoreTokenCheck (Dword)=1) and the issue does appear to have been resolved.
Have any other customers experienced this issue? What security implications might there be to adding this key entry?
Thanks in advance

============
Another MVP that wants to be unnamed for now had this to say about it.

I think I’ll restrict my answer to this audience for now, as I have a tendency to get into trouble when blogging about this registry value.

The token checks are designed as a protection against cross-site request forgery (CSRF) attacks. The general idea is that CRM will generate a new token when you submit an initial request (e.g. opening a form), when you save the data, the client code will send the token along with any data to update, and the server will check the token to see if it’s valid. There are a couple of schools of thought on the necessity of this:

1. 1. One view is that, in a well-designed system like CRM, data modification can only occur via the POST method (and not a GET – i.e. you don’t modify data solely by passing information on the query string). Internet Explorer security settings will not allow cross-site POSTs. As a result, you would only be subject to a CSRF attack via a successful cross-site scripting (XSS) exploit. And if you are suffering an XSS exploit, you’ve got bigger problems than worrying about a CSRF. So, token checks don’t really make a difference, and can be disabled
2. 2. The other view is that you should always defend in depth when it comes to application security. So, even though other security mechanism should make the token defence redundant, you still implement it anyway

============
Corey Hanson had this to say:

I found an issue that is included in Update Rollup 7 that may be related. The repro steps in the issue are

1. Deploy CRM with https protocol and do NOT specify the port number (which is default to 443 then).
2. Open an existing Account or create an account
3. Update the value for "Account Number" and save it.
4. Update this value again in the same form.
5. Click Save button.

I'm assuming that the steps 2-5 could be other actions as well to repro the issue, so possibly the marking the appointment as completed could be as well.

If you contact support there is a COD available for this issue, if you want to see if it resolves your scenario. The case would be free of charge since it is due to a bug in UR6. Or you can wait till UR7 is released on March 8th, 2012.

Thanks

---

Corey Hanson, Dynamics CRM Supportability PM

============

Another MVP that wants to be unnamed for now had this to say about it.

I think I’ll restrict my answer to this audience for now, as I have a tendency to get into trouble when blogging about this registry value.

The token checks are designed as a protection against cross-site request forgery (CSRF) attacks. The general idea is that CRM will generate a new token when you submit an initial request (e.g. opening a form), when you save the data, the client code will send the token along with any data to update, and the server will check the token to see if it’s valid. There are a couple of schools of thought on the necessity of this:

1. 1. One view is that, in a well-designed system like CRM, data modification can only occur via the POST method (and not a GET – i.e. you don’t modify data solely by passing information on the query string). Internet Explorer security settings will not allow cross-site POSTs. As a result, you would only be subject to a CSRF attack via a successful cross-site scripting (XSS) exploit. And if you are suffering an XSS exploit, you’ve got bigger problems than worrying about a CSRF. So, token checks don’t really make a difference, and can be disabled
2. 2. The other view is that you should always defend in depth when it comes to application security. So, even though other security mechanism should make the token defence redundant, you still implement it anyway

=========
As I am sure you are aware Microsoft and CRM specifically work under the defense in depth philosophy. The WRPC token scheme is like you said designed to help reduce the surface area of forgery and single click attacks. Because the tokens use both page and timestamps this reduces the ability for man in the middle play backs.

Overall, I would only suggest using this registry key when doing load simulation (the reason the setting exists at all), or when it is needed due to a regression as this case. As Corey replied on the public thread a COD hotfix is available for this issue and is a much better solution.

Posted in: CRM 2011 UR Issues