June 23, 2017 markhartnady

Securing your CRM code base

Securing your CRM code base

Any Salesforce admin or developer worth their salt in deployments will know that no Apex classes or Triggers will be making their way to a Production org without adequate code coverage. Salesforce devs need to write Unit Tests to sufficiently cover at least 75% of their code.

✔ Big green tick to Salesforce for enforcing quality on the platform and protecting against possible regression and class integrity.

What is not required however, is a code scan to highlight any potential security vulnerabilities. This is a recommended best-practice for any code deployment, however the practicalities of this can sometimes be outweighed by the benefits. I.e., there are costs involved with code scans.

At the time of writing, Salesforce does offer a free code scan service available here however there are no guaranteed service levels and depending on server activity, it could be days before your code scan results are returned (if ever). Premium services are available such as The Checkmarx solution for scanning Apex & Visualforce (and other languages such as Javascript) code.

If your company is not convinced in investing an Apex code scanning solution however, there are some best-practices you can implement:

SOQL Code Injections

Take care of passing SOQL as a String parameter to database functions, such as:

    String mySOQL = 'select id from account';
    List accounts = (List) Database.query(mySOQL);

Where “mySOQL” can be intercepted and manipulated (for example, through URL parameters). A safer way to execute the above code would be:

    List accounts = [select id from account];

Sometimes using the Database.Query function cannot be avoided (e.g. in the case of dynamic generation of SOQL), however if it can be, avoid!

Cross-site Scripting

Cross-site scripting (XSS) enables attackers to inject client-side scripts into web pages viewed by other users. One of the best preventative measures you can make to avoid XSS attacks in Salesforce is to avoid overriding the default “escaping” of characters within a Visualforce component as such:

<apex:outputText value=”val” name=”output1″ escape=”false” />

“Escape” within the context of VF page components is a Boolean value that specifies whether sensitive HTML and XML characters should be escaped in the HTML output generated. An escape character is a character which invokes an alternative interpretation on subsequent characters in a character sequence. Setting this Boolean to “false” may be a security risk because it allows arbitrary content, including JavaScript, that could be used in a malicious manner.

Cross-site Forgery

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. For example, CSRF occurs when a user visits a malicious web page that makes their browser send requests to your application that the user did not intend. The best way to avoid this is to configure your Visualforce Pages and components to require CSRF protection on GET requests when editing the page in Salesforce:

There are many more examples of how to reduce your vulnerabilities, however these practices are probably the best spend of resource to mitigate risks in your Apex code.

Tagged: , , , ,

About the Author

markhartnady Salesforce ninja