FAQ-000250 - CSRF and DML Security Issues / Testing and Verification

To reproduce and test for CSRF vulnerabilities in your application, follow these steps: 1. **Understand the Vulnerability**: CSRF attacks exploit the trust a web application has in the user's browser, forcing authenticated users to execute unwanted actions. 2. **Identify Vulnerable Endpoints**: Look for endpoints that perform state-changing operations (e.g., insert, update, delete) and are triggered without user interaction, such as on page load or through GET requests. 3. **Simulate the Attack**: - Create a malicious HTML form or script mimicking a legitimate request to the vulnerable endpoint. - Include the necessary parameters to execute the action. 4. **Test Without CSRF Protection**: - Temporarily disable CSRF protection mechanisms to confirm the vulnerability. - Submit the malicious request and check if the action is executed without requiring user authentication or confirmation. 5. **Validate CSRF Protection**: - Implement CSRF tokens in your application. For Visualforce pages, avoid placing state-changing operations in action methods (like constructors, getters, or action attributes) that execute on page load. - Test again by attempting the malicious request. It should fail if proper CSRF protection is in place. 6. **Use Automated Tools**: Tools like ZAP or Burp Suite can help identify CSRF vulnerabilities by scanning your application. 7. **Review Code**: Check for state-changing operations in Apex controllers, Visualforce pages, or Lightning components triggered on instantiation or without user interaction. 8. **Reproduce and Document**: Document the steps to reproduce the vulnerability, including screenshots and exploitation details, for clarity during testing and review. For more detailed guidance, refer to Salesforce's secure coding practices and documentation on CSRF protection.

The main issue identified was outdated and potentially confusing information in step 5 about the `confirmationTokenRequired` attribute. This attribute doesn't exist in Visualforce and could mislead developers. The recommendation was updated to reflect proper CSRF protection practices by avoiding state-changing operations in methods that execute on page load. The ApexCSRF rule was selected because the FAQ discusses CSRF vulnerabilities in Apex controllers, specifically mentioning 'state-changing operations in Apex controllers' and operations 'triggered on instantiation or without user interaction,' which directly matches what this rule detects. The VfCsrf rule was selected because the FAQ specifically mentions 'Visualforce pages' and discusses CSRF protection for Visualforce, including the problematic reference to `confirmationTokenRequired` that was corrected. The FAQ's focus on testing CSRF vulnerabilities in Visualforce pages aligns with what this rule is designed to catch.