Administration > Cross-Site Request Forgery > Troubleshooting Cross-Site Request Forgery Issues
  
Troubleshooting Cross-Site Request Forgery Issues
Cross-site request forgery (CSRF) errors can occur for a number of different reasons:
Problems with the client or network infrastructure breaking the mechanism used to validate user requests
Software problems causing a false positive report
A legitimate CSRF attack
Follow these steps when you are alerted to possible CSRF attacks:
1. Update to the latest maintenance release for your version of PTC FlexPLM to get the latest software fixes.
2. Apply the latest security update patch for your current PTC FlexPLM maintenance release to get the latest security fixes.
For more information, see the Security Update Patch download page.
3. Ensure that the user is not using Internet Explorer 8 in compatibility mode to access PTC FlexPLM. This mode causes Internet Explorer to send out truncated requests that do not include the CSRF nonce.
4. Review the symptoms and security logs to determine if this is a legitimate CSRF attack on your system. Signs of an attack include the following:
The error occurred when navigating or clicking a link in another web page or application not related to PTC FlexPLM.
The error occurred when clicking a link in an email that cannot be validated as originating from PTC FlexPLM.
The error is accompanied by an unexpected request to authenticate with PTC FlexPLM if the user was not already authenticated.
The PTC FlexPLM user interface does not appear normal.
The PTC FlexPLM URL or hostname does not appear correct.
5. Determine the source of the problem.
If the problem is reported by a user, work with the user to determine when they were getting the error and what action they were trying to complete. If the error occurred when performing a legitimate action on a legitimate PTC FlexPLM page, it might be a false positive that needs to be fixed in PTC FlexPLM.
If the warning is found in a security audit report, review the report for information about the user, session identifier, IP address, date, time, and request that generated the warning. Contact the user listed in the report and determine what they were doing when the error occurred.
If the warning comes in an email to the administrator, run a security audit report to get information about the user that generated the warning. Contact the user listed in the report and determine what they were doing when the error occurred. For more information, see “Creating a Security Audit Report” in the Windchill Help Center.
If the warning is found when browsing the log files, run a security audit report to get information about the user that generated the warning. Contact the user listed in the report and determine what they were doing when the error occurred. For more information, see “Creating a Security Audit Report” in the Windchill Help Center.
6. Contact PTC Technical Support if you believe that you have identified a false positive or if you need further assistance.
a. Enable additional debug information by adding the following lines to the <Windchill>\codebase\WEB-INF\log4jMethodServer.properties file:
log4j.logger.com.ptc.core.appsec=ALL
org.apache.tomcat.util.http.Parameters=TRACE
b. Reproduce the issue.
c. Include the log file information in your contact with PTC Technical Support. For more information, see “System Configuration Collector” in the Windchill Help Center or the Windchill Specialized Administration Guide.
7. If you suspect that a user was a target of a legitimate CSRF attack, work with your internal IT security team to address the issue.