전문 관리 > Windchill 환경 구성 > Windchill Considerations for Security Infrastructures > 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.
1. Problems with the client or network infrastructure breaking the mechanism used to validate user requests.
2. Software problems causing a false positive report.
3. A legitimate CSRF attack.
The following steps should be followed when you are alerted to possible CSRF attacks:
1. Update to the latest maintenance release for your version of Windchill to get the latest software fixes.
2. Apply the latest security update patch for your current Windchill maintenance release to get the latest security fixes.
For more information, see the Security Update Patch download page.
3. Ensure the user is not using Internet Explorer 8 in compatibility mode to access Windchill. This mode causes Internet Explorer to send out truncated requests that do not include the CSRF nonce. Compatibility mode is not supported starting with Windchill 10.0.
4. Review the symptoms and security logs to determine whether this might be a legitimate CSRF attack on your system.
a. 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 Windchill page, it may be a false positive that needs to be fixed in Windchill.
Signs that it may be an attack include:
▪ The error occurred when navigating or clicking a link in another web page or application not related to Windchill.
▪ The error occurred when clicking a link in an email that cannot be validated as originating from Windchill.
▪ The error is accompanied by an unexpected request to authenticate with Windchill if the user was not already authenticated.
▪ The Windchill user interface does not appear normal.
▪ The Windchill URL or hostname does not appear correct.
b. 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. Use the process specified in step A to determine if it was a legitimate attack.
c. 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. Use the process specified in step A to determine if it was a legitimate attack.
For more information, see Creating a Security Audit Report.
d. 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. Use the process specified in step A to determine if it was a legitimate attack.
For more information, see Creating a Security Audit Report.
5. Contact PTC Technical Support if you believe 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:
logger.appsec.name=com.ptc.core.appsec
logger.appsec.level=ALL
logger.utilHttpParameters.name=org.apache.tomcat.util.http.Parameters
logger.utilHttpParameters.level=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.
6. 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.