18. März 2014 11:27
18. März 2014 11:49
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
18. März 2014 11:55
18. März 2014 13:49
19. März 2014 10:48