CSRF safe Custom button linked to Apex method

Question

I'm looking for a technique to execute Apex code from a custom button added to the Opportunity object in a way that protects the user against CSRF.

The current approach being used comes from the question - Custom Button or Link to a Visualforce page with a custom controller. Essentially:

1. There is an Opportunity Custom Button with the Content Source set to "Visualforce Page".
2. The Content for this button is set to a Visualforce page that uses Opportunity for the standardController, has an extension apex class entered and an action for a method in that class
3. The action method returns a PageReference to another custom Visualforce page, including adding a parameter with the Opportunity Id.
4. This second custom Visualforce page does the bulk of the actual work, including making web service callouts and performing DML operations before redirecting the user back to the Opportunity.

The issue with this approach is that the second custom Visualforce page is retrieved via an HTTP GET, pulls parameters from the query string, and performs update/insert DML operations with no CSRF protection. This is being picked up by the Force.com Security Source Code Scanner.

I should add that this apex code is deployed as both a managed and a unmanaged package, hence the extra work to redirect to the target Visualforce Page using a PageReference. This ensures the namespace prefix is added if required.

How can I avoid the CSRF issue?

I don't want to add a form to the second visualforce page with a button that they must press to start the process (and hence picking up the ViewStateCSRF protection in the postback). From the users perspective they have already pressed the button to perform the operation.

I've asked this question before on the developer force forum and didn't come up with a solution - Cross-Site Request Forgery (CSRF/XSRF) safe Custom Button action

Perhaps I should be trying to move the code out of the controller for the second visual force page and using the extension to the stand controller instead?

I could switch to a Javascript callback to an Apex Web Service (as suggested in Call a apex method from a custom button and How invoke APEX method from custom button), but it seems a bit messy and I'm not sure if I'd just be opening up another range of security issues with the web service.

Hesperidin

Answer 1

I booked Partner Security Office Hours with Salesforce and discussed this issue directly with them.

What I'm trying to do isn't currently supported if CSRF protection is required (I.e. to publish to the App Exchange). They suggested two alternative approaches:

1. Create an intermediate form in a Visualforce page that triggers the sensitive Apex Code. Hence picking up the built in CSRF protection.
2. Override the Opportunity Detail page (using apex:Details to display similar information). This new Visualforce page would include a similar form post back to option 1 to invoke the sensitive APEX code and get automatic CSRF protection.

---

Another approach that doesn't use custom buttons is to embed/inline a Visualforce page (see Embed a Page on a Standard Layout) containing just the required button within the standard page layout.

The embedded Visualforce page must use the standard object controller (Opportunity in my case) to appear in the list of available Visualforce pages on the standard page layout. The Visualforce page itself can be very minimal with just a commandButton inside a <apex:form>. The label of the Visualforce page can also be displayed in the page layout.

<apex:page id="embeddedPage" StandardController="Opportunity" extensions="OpportunityExtensionController" showHeader="false" standardStylesheets="true">
<apex:form >
    <apex:commandButton value="CSRF Safe Button" action="someMethodInTheExtensionClass" />
</apex:form>

public with sharing class OpportunityExtensionController {

    private final Opportunity opportunityFromController;

    public OpportunityExtensionController(ApexPages.StandardController controller) {
        opportunityFromController = (Opportunity)controller.getRecord();        
    }

    public PageReference someMethodInTheExtensionClass() {

        // Perform directly here within the postback rather than redirecting to another page to prevent against XSRF

        System.debug('opportunityFromController.Id:' + opportunityFromController.Id);
    }
}

This should protect against CSRF as the commandButton will pick up the "com.salesforce.visualforce.ViewStateCSRF" hidden input with the post back to the server inside the resulting iframe.

---

I've raised the Idea Invoking Apex code from the standard Entity Details pages with CSRF protection to see if they can add support for this directly with custom buttons.

Hesperidin

Answer 2

Why don't you use a JavaScript button in the first place to launch the second page? Bypass the first page altogether.

Salesforce will apply merging to the script before rendering (so you can use {!Opportunity.Id} to include opp id in the second URL) and you can simply redirect the browser to your second page.

Boong

The main issue I have is that when the user arrives at the second page via an HTTP GET request they are open to CSRF as the second page will take the query string parameter and perform Insert and Update operations as well as Web Service callouts. Also, with Javascript I can't reference the target visualforce page in such a way that works both in and out of a managed package due to the namespace prefix. – Hesperidin

Ok, #1 you can use URLFOR or $Page.pagename or their combination to reference the page. This should fi your namespace issue. Second, CSRF should only fire for form actions, it is my understanding that you have no such thing in page 2, no? Essentially your extension constructor does all the work? If so, your page will still be open to CSRF no matter what, you cant solve this without having salesforce rendering the form (with token) and then submitting it from onloaded. But (and its a big but) you don't solve the CSRF with this (see next comment) – Boong

You don't solve it because the malicious site with knowledge of your page can still send a GET request with query string and have the salesforce create a token for it and kindly submit it for them as well. – Boong

Thanks for persevering with this. With regards to using Javascript, when I previously tried to use URLFOR with $Page.pagename in a custom button [I got an error] (#8497942). Perhaps I should revisit this as it may work now? – Hesperidin

For the main CSRF issue. I'm looking for a way to have a custom button on the Opportunity page that executes Apex code without leaving the user open to CSRF or needing to push a second button on a subsequent page. As you point out, the current approach with the second visualforce page is never going to solve this as it isn't using a form submission with the token. Maybe I need to be looking closer at the Javascript solutions? E.g. Javascript Remoting – Hesperidin

Unfortunately any solution that does not rely on salesforce rendering a form and user posting it back is open to CSRF. You will just make the security hole more "exotic" but you wont remove it. Sorry. – Boong