"Your submission token does not match your session token" warning message...

[jwawa1]

We're in the process of implementing the High Security Settings plugin, and all's going well. But we're encountering the "Security Warning" notifications, as mentioned in the wiki article. (http://wiki.service-now.com/index.php?title=High_Security_Settings#Notifications)

It's directly related to the glide.security.use_csrf_token property (System Security -> High Security Settings -> "Enable usage of a secure token to identify and validate incoming requests. This token is used to prevent cross site request forgery attacks."). It's simple enough to disable this anti-CSRF feature and voila, no more Security Warnings on approvals. Users won't call the Help Desk worried about "Security Warning" messages if I do that, but I don't like disabling security features if I don't really have to (for legitimate functional reasons, for instance). So I'm curious what others are doing.

* Are you just disabling the setting, and along with it, CSRF protection?
* Are you leaving it enabled and telling users to IGNORE the Security Warning message when doing approvals and just click Continue?
* Are you modifying the message itself (if so, please tell me how) to give your users a better understanding of what's happening? (End users don't typically understand messages like "Your submission token does not match your session token". All they perceive is an "ERROR message" every time they go to work an Approval. Just rewording the message might be enough to allow for CSRF protection and, at the same time, not alarming end users (or encouraging them to develop a bad habit of ignoring Security Warnings).
* Or are you doing something else entirely that I haven't thought of?

Thanks,
-Joe

[Valor1]

Joe, are you using Single Sign On? If so (and you're using SAML v2.0), there's not a real reason to enable CSRF protection, and will sometimes cause this issue. I could be wrong, but I believe SAML tokens have a natural expiry of thier own--you must re-authenticate for every new session, and re-authenticate for each terminal.

In other words, the SSO application takes care of this check for you.

[jwawa1]

Hi Valor. We do use SAML 2, but we also use LDAP authentication (predominantly LDAP.)

I'm not sure using SAML2 necessarily protects you from CSRF, though, does it? It's true that you must re-authenticate for every new session, and re-authenticate for each terminal, but wouldn't it be true that a user's session would (or at least could) still be vulnerable to CSRF at any time when there's a valid session on that workstation (whether it's LDAP or SAML either one, for that matter)? I agree that automatically expiring sessions would help, but am I on the right track here (that all that's really needed for CSRF is a valid session and a lack of a second authentication step like the Security Warning message)? (I don't pretend to be an expert on SAML or CSRF, so forgive me if I'm not understanding things correctly.)

Also, just for information purposes, I received the Security Warning message on an instance that has external authentication disabled (no SAML), so I don't think Service-Now's Security Warning is something you'd only see with SAML configurations.

In our case, I don't think that matters either way, though, since we do both SAML and LDAP Auth. Just to be safe, I'd prefer to have CSRF protection, if possible. In fact, I don't mind the intercepting "Security Warning" message and the extra click. It's more the verbiage that seems problematic to me -- because I doubt end users are going read that message and understand that the added step (telling them to click the Confirm button to continue) is simply a security precaution, and not a security error.

I'd like to understand this better if SAML truly does mitigate CSRF (even though we don't do only SAML here), but I'm also curious if there's a way to modify the text displayed within the Security Warning message itself. If so, we could keep the CSRF protection enabled, regardless.

Thanks,
-Joe

[john_andersen]

I am not a security buff, but as I understand it, CSRF attacks happen against sites that already have a session and are authenticated. SAML in servicenow only takes part in Authentication, not session handling. The Session handling is the same in ServiceNow regardless of whether you are using SSO, LDAP, or local login.

Therefore, I wouldn't look at SAML (or other authentication) for this, but rather look at ServiceNow's session handling.

Sorry, I don't have the answer you are seeking with regard to CSRF vulnerabilities in ServiceNow, but I can direct you away from looking into the authentication methods.

[jwawa1]

Thanks John.
I think the question I'm left with then is, is there a way to customize the text of the Security Warning message itself?

Thanks!
-Joe