Clarity has a vulnerability to Cross Site Request Forgery (CSRF) Attacks

Document ID : KB000004017
Last Modified Date : 14/02/2018
Show Technical Document Details
Issue:

In 2011, a recent security audit by a third-party Security consultancy highlighted the following issue in Clarity 12.1:

"The Team discovered that the web application did not offer any protection against Cross-site Request Forgery attacks. This was confirmed due to the fact that no unique token was supplied in every request. The replaying of a request i.e. editing a user account is repeatable numerous times without any requirement for a unique token bound to sessionID."
The approach taken by CA to remedy this vulnerability is to implement the Synchronizer Token method, securing all http GET actions invoked in the code.
Solution:
The prevention of CSRF attacks is handled through the use of Session Tokens. While navigating within the Clarity application, you may encounter a detection of a possible CSRF attack. There may be some actions carried out by an end user which will result in the following error message appearing on screen:
Clarity PPM 12.1.3: " ERROR 500 - Internal Server Error"
Clarity PPM 13.1: "Security Violation: CSRF Attack" followed by instructions on what caused the error and what to do to recover. Before refreshing the page, write down the Request ID listed on the error message page.
Clarity PPM 13.2: "An expired request has been detected. Request has been cancelled", followed by instructions on what caused the error and what to do to recover. there is a checkbox for "Do not show this message again" which will suppress the error dialog.
Due to the unique token synchronization, you might encounter the security error if your session times out or if you attempt to bookmark a page that requires a token. This situation can be cleared by using the 'Back' button or Clarity History page to navigate back to the calling page, refreshing the page and/or logging out and back in.
CA has endeavored to remedy all known navigation issues that might trigger a CSRF security violation. However, if you encounter a CSRF error page that cannot be cleared, the following steps outline the actions to be taken by your Clarity PPM System Administrator. Different versions of Clarity implement different CSRF strategies. Refer to the section of this article based on your Clarity version.
Note: If you are a CA Clarity PPM On-Demand customer, please report the details to CA Clarity Support.

Environment:
CA Clarity PPM 12.1CA Clarity PPM 13.0CA Clarity PPM 13.1
Cause:

This issue has been documented as CLRT-63076 and is resolved in the following versions.
Resolved in Clarity 12.1.3 Generic Patch. Reference TEC570813.
No plans to resolve in Clarity 13.0 and 13.1 - when on this version, use the strategies outlined above.
Resolved in Clarity 13.2

Resolution:

Clarity 13.2:
CA has introduced a new, configurable set of CSRF strategies for Clarity 13.2. The allowed configurations are:
• none - no CSRF token is generated nor is any request validated. This is the default setting for on-premise installations. Recommended if Clarity is behind your corporate firewall. Upgrading customers will have this setting automatically.
• request - This implements the same strategy used in Clarity 13.1. This strategy generates a new token for each request and validates against a limited size cache in the user session. Due to the possibility of cache exhaustion, this strategy can lead to false-positive validation errors, especially for users who work with multiple tabs open in Clarity.
• session - a single token is generated for the user session and that is used for validation. This is the recommended strategy for on-demand SaaS and hosted installations; and for on-premise customer installations where Clarity is outside the corporate firewall.
Configuration is done by manually setting an attribute of the applicationServer element in the properties.xml file:
1. Stop the app and bg services on your application server
2. Open the properties.xml file for editing
3. Use this sample as an example of where to edit the setting:
<applicationServer vendor="tomcat" useLdap="false" home="c:\ca\tomcats\apache-tomcat-7.0.26" adminPassword="secret" externalUrl="" tokenCacheStrategy="session">
<applicationServerInstance id="app" .../>
<applicationServerInstance id="nsa" .../>
</applicationServer>
4. Restart the app and bg services
5. Synchronize the properties.xml file changes across all applications servers if Clarity is running in a clustered environment
Upgrading To Clarity 13.2: The tokenCacheStrategy setting is automatically set to none. No further action is required.

Clarity PPM 12.1.3:
1. Check the app-niku.log
2. Look for the message 'The request could not be completed due to a conflict with the current state of the resource'. The message will also specify the action id for which the security check has failed.
Example:
ERROR 2013-03-08 11:38:24,560 [http-80-7] web.WebActionController (admin: 5016871__4AEAF7D8-F49A-4FA1-863B-2E97ADC3BDC9:npt.myDashboardsFilter) com.niku.union.web.WebException: The request could not be completed due to a conflict with the current state of the resource

From the example log, the action that caused the issue is npt.myDashboardsFilter.

If the message 'The request could not be completed due to a conflict with the current state of the resource' is not found in the log, contact CA Support. This may be an application error and not a CSRF error.

3. Locate the CMN_OPTION_EXEMPTED_ACTION_VALUES.xml file delivered as part of the 12.1.3 patch. Continue to Step 4 below, in the section for 12.1.3, 13.0, 13.1 Versions
Clarity PPM 13.0 and 13.1:
1. The CSRF Security Violation error page in the application contains the Request ID of the failing action.
2. If the error page is no longer available for your reference, follow Steps 1 and 2 in the Clarity PPM 12.1.3 section, checking the app-ca.log.
3. Contact CA Support and ask for the CMN_OPTION_EXEMPTED_ACTION_VALUES.xml file

12.1.3, 13.0, 13.1 Versions:
4. Copy the file CMN_OPTION_EXEMPTED_ACTION_VALUES.xml from TEC567263.zip file to the following location:
     $CLARITY_HOME/database/schema/post-upgrade

5. Open the CMN_OPTION_EXEMPTED_ACTION_VALUES.xml for editing
6. Look for the variable actions_list (comma separated)
    ORACLE: actions_list varchar(2000) := 'Enter actions here';
     MSSQL: SET @actions_list = 'Enter actions here'

7. In actions_list variable, add the Request ID for the action(s) that caused the exception. If there is more than one action, separate the IDs by commas. Please ensure that there are no spaces. If there is only one action, then do not add comma. Save the file.
8. Execute the dbpatch command to apply the changes:
     $CLARITY_HOME\bin>dbpatch -install -file $CLARITY_HOME\database\schema\
     post-upgrade\CMN_OPTION_EXEMPTED_ACTION_VALUES.xml -apply

9. Ask the end user to clear their browser caches. They should not see an exception for the same action.

Additional Information:

Additional Note For System Administrators for Clarity 13.1:
If your organization deploys Clarity behind your organization's firewall, you can manually override the CSRF protection. CA Technologies does not recommend that organizations make this change; however, we are disclosing this setting should your system administrator determine that turning the CSRF protection off is needed.
Disabling CSRF Protection for Clarity 13.1
1. Stop the app service on your application server
2. Open the properties.xml file for editing
3. Add a new applicationServer attribute with the name of tokenCacheCapacity and set the value to zero. Use this sample as an example of where to place it:
<applicationServer vendor="tomcat" useLdap="false" home="c:\ca\tomcats\apache-tomcat-7.0.26"    adminPassword="admin" externalUrl="" tokenCacheCapacity="0"><applicationServerInstance id="app" serviceName="Niku Server" rmiPort="23791" jvmParameters="-Xmx2048m -Xms512m -XX:MaxPermSize=192m -Dsun.lang.ClassLoader.allowArraySyntax=true" maxThreads="200" programParameters=""
distributed="false" runJobScheduler="false" useSSO="false" maxConcurrentJobs="10" runProcessEngine="false"   messageTimeToLive="120" messageReceiverInterval="5" exceptionRunInterval="normal"/>
<applicationServerInstance id="nsa" serviceName="Niku System Admin Server" rmiPort="23792" jvmParameters=" -Xmx512m" programParameters="" exceptionRunInterval="normal"     </applicationServer>

4. Restart app service
5. Synchronize the properties.xml file changes across all applications servers if Clarity is running in a clustered environment

 

 

Disabling CSRF Protection for Clarity 15.x
1. Stop the app service on your application server
2. Open the properties.xml file for editing
3. Update the applicationServer element and add or update the attribute with the name of tokenCacheStrategy and set the value to “none". Use this sample as an example of where to place it:
<applicationServer vendor="tomcat" useLdap="false" home="c:\ca\tomcats\apache-tomcat-7.0.26" adminPassword="admin" externalUrl="" tokenCacheStrategy="none">
 <applicationServerInstance id="app" serviceName="Niku Server" rmiPort="23791" jvmParameters=" -Xmx2048m -Xms512m -XX:MaxPermSize=192m -Dsun.lang.ClassLoader.allowArraySyntax=true" maxThreads="200" programParameters="" distributed="false" runJobScheduler="false" useSSO="false" maxConcurrentJobs="10" runProcessEngine="false"
 messageTimeToLive="120" messageReceiverInterval="5" exceptionRunInterval="normal"/>
<applicationServerInstance id="nsa" serviceName="Niku System Admin Server" rmiPort="23792" jvmParameters="-Xmx512m" programParameters="" exceptionRunInterval="normal"/></applicationServer>

File Attachments:
TEC567263.zip