locked
IgnoreTokenCheck RRS feed

Answers

  • 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


    Jamie Miley
    Check out my about.me profile!
    http://mileyja.blogspot.com
    Linked-In Profile
    Follow Me on Twitter!

    • Proposed as answer by Jamie MileyModerator Tuesday, February 21, 2012 6:59 PM
    • Marked as answer by ThatIsAll Wednesday, February 22, 2012 12:13 PM
    Tuesday, February 21, 2012 6:59 PM
    Moderator

All replies

  • Has anyone got any thoughts on this?

    Thanks

    Tuesday, February 21, 2012 12:55 PM
  • I tried to draw attention to it with my blog even, but had no luck.  I will ask the MVP's as I wonder about this too.

    Jamie Miley
    Check out my about.me profile!
    http://mileyja.blogspot.com
    Linked-In Profile
    Follow Me on Twitter!

    Tuesday, February 21, 2012 3:43 PM
    Moderator
  • 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


    Jamie Miley
    Check out my about.me profile!
    http://mileyja.blogspot.com
    Linked-In Profile
    Follow Me on Twitter!

    Tuesday, February 21, 2012 4:41 PM
    Moderator
  • 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


    Jamie Miley
    Check out my about.me profile!
    http://mileyja.blogspot.com
    Linked-In Profile
    Follow Me on Twitter!

    • Proposed as answer by Jamie MileyModerator Tuesday, February 21, 2012 6:59 PM
    • Marked as answer by ThatIsAll Wednesday, February 22, 2012 12:13 PM
    Tuesday, February 21, 2012 6:59 PM
    Moderator
  • Many thanks for taking the time to respond.  Really appreciate it :)
    Wednesday, February 22, 2012 12:14 PM
  • Here is another note I got on it:

     

    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.

     


    Jamie Miley
    Check out my about.me profile!
    http://mileyja.blogspot.com
    Linked-In Profile
    Follow Me on Twitter!


    Wednesday, February 22, 2012 3:12 PM
    Moderator
  • Hi all,

    From the above conversation, I am still unable to come to a conclusion on whether to go with the registry key changes or not. Does it has serious security issues? I know UR7 has fix for this. However, due to time constraints I am looking for the other options with UR6.

    So, anyone has a call on this? Thanks in Advance.


    Vikranth http://howto-mscrm.blogspot.com "Please Mark it as answer if it helps in resolving your query"

    Monday, June 11, 2012 6:37 PM