000035579 - In RSA Identity Governance & Lifecycle the warning 'No CSRF guard token was found in the submitted request' is encountered during login

Document created by RSA Customer Support Employee on Apr 4, 2018
Version 1Show Document
  • View in full screen mode

Article Content

Article Number000035579
Applies ToRSA Product Set: Identity Governance & Lifecycle
RSA Version/Condition: 6.9.1
IssueIn RSA Identity Governance & Lifecycle, the following warning is encountered during login:

No CSRF guard token was found in the submitted request


See the errors found in Admin Errors in the UI (Admin > Admin Errors):
 
No CSRF guard token error



The warnings below are found in the aveksaServer.log:


Scenario 1



09/21/2017 09:19:45.654 WARN (http-0.0.0.0-8443-5) [com.aveksa.UI] com.aveksa.gui.core.GuiFramework.handleSecurityError(GuiFramework.java:520) - No CSRF guard token was found in the submitted request. This may indicate an attack on the server. Request is blocked.:

Login ID: 20378
Request: https://myaccess.server.com/aveksa/main?ReqType=GetPage&PageID=LoginPage&Action=Submit
Referrer: https://myaccess.server.com/aveksa/main?SSOLogin=false
com.aveksa.server.core.SecurityException: No CSRF guard token was found in the submitted request. This may indicate an attack on the server. Request is blocked.
at com.aveksa.gui.core.GuiFramework.handleSecurityError(GuiFramework.java:520)
at com.aveksa.gui.core.ACMFramework.handleSecurityError(ACMFramework.java:451)
at com.aveksa.gui.util.security.CSRFGuard.validateCRSFToken(CSRFGuard.java:63)
at com.aveksa.gui.pages.PageManager.handleRequest(PageManager.java:277)
at com.aveksa.gui.pages.PageManager.handleRequest(PageManager.java:254)
at com.aveksa.gui.core.MainManager.handleRequest(MainManager.java:176)
at com.aveksa.gui.core.MainManager.doGet(MainManager.java:125)
at com.aveksa.gui.core.MainManager.doPost(MainManager.java:411)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.aveksa.gui.core.filters.LoginFilter.doFilter(LoginFilter.java:67)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.aveksa.gui.util.security.XSSFilter.doFilter(XSSFilter.java:20)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:701)
09/21/2017 09:19:45.669 ERROR (http-0.0.0.0-8443-5) [com.aveksa.UI] com.aveksa.gui.core.MainManager.showRequestError(MainManager.java:356) - XXX.XX.XX.XXX invalid request: https://myaccess.server.com/aveksa/main?ReqType=GetPage&PageID=LoginPage&Action=Submit


 


Scenario 2



06/11/2015 12:22:26.936 WARN (http-0.0.0.0-8443-127) [com.aveksa.UI] com.aveksa.gui.core.GuiFramework.handleSecurityError(GuiFramework.java:494) - No CSRF guard token was found in the submitted request. This may indicate an attack on the server. Request is blocked.:

Login ID: x111111
Request: https://myaccess.server.com/aveksa/main?ReqType=GetPage&PageID=LoginPage&Action=Submit
Referrer: https://myaccess.server.com/aveksa/main?
com.aveksa.server.core.SecurityException: No CSRF guard token was found in the submitted request. This may indicate an attack on the server. Request is blocked.
at com.aveksa.gui.core.GuiFramework.handleSecurityError(GuiFramework.java:494)
at com.aveksa.gui.core.ACMFramework.handleSecurityError(ACMFramework.java:407)
-----
06/11/2015 12:57:08.534 INFO (http-0.0.0.0-8443-71) [com.aveksa.UI] com.aveksa.gui.core.LoginLogout.loginUser(LoginLogout.java:54) - User logged in: x111111::SessionCount=16::UserCount=16
06/11/2015 12:57:21.534 WARN (http-0.0.0.0-8443-71) [com.aveksa.server.help.HelpManager] Can't find Help mapping for pageID=ReviewReportDetailDashboard
06/11/2015 13:00:52.029 ERROR (http-0.0.0.0-8443-126) [com.aveksa.UI] com.aveksa.gui.components.table.core.DefaultTableModel.getObjects(DefaultTableModel.java:178)

CauseEssentially any time you POST data to the product, and you have an active session, the posted data has to include a Cross Site scripting Forgery (CSRF) token that matches the one in your sessions.

The first time you login, the POST for the login page doesn’t do this check, because you don’t have a session yet. If you log in successfully, we generate a secure random token and stick it in the session. We also include the token as a hidden value on all forms the product generates. From that point forward, as long as that session is active, any requests that come from the browser will include the token (because we put it in all the forms before serving them to the client), and we can match it to the session. Any POST that comes from somewhere else -- that is, not from the UI generated for this user by our product -- won’t have the token, and will fail.

If you are seeing this error on login, then it means the system thinks you already have a active session. You might be working in different tabs of the same browser or something like that or the session is still active.

This is the most common problem when a CSRF error is generated. And this is the logic that happens with CSRF token. In some cases, even if the session is terminated the token will be valid for a while and becomes invalid and in some cases the token becomes invalid once the session is terminated. But this doesn't create any harm in the environment.
Resolution If you are seeing this error on login, then it means the system thinks you already have an active session. You might be working in different tabs of the same browser or something like that or the session is still active.

Attachments

    Outcomes