Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

Apex Secure Coding Considerations

Apex is an on-demand language that extends the Force.com platform by providing the ability to write applications that run on salesforce.com servers. Unlike other general-purpose languages such as C# or Java which can be used to build many different types of applications, Apex is more limited in scope and focused on building business applications. While building applications or performing a security code review of an Apex application there are some special considerations to know that are specific to Apex and the Force.com platform.

SOQL Injection

  • Apex applications utilize SOQL, which is a proprietary but simplified and limited version of SQL. SOQL queries are constructed similar to SQL:

query = 'select * from users where username = \'' +username + '\' and password =\'' + password + '\'';

  • SOQL queries are also vulnerable to injection attacks in much the same way that SQL queries are vulnerable when user-supplied input is not properly sanitized before being used in a request sent to the database server.
  • One solution for preventing SOQL injection is similar to preventing SQL injection: Use prepared statements with bind variables:

query = [select * from users where user= :username and password=:password];

Cross-Site Scripting

  • Cross Site Scripting (XSS) is an attack where an attacker is able to modify a webpage to contain a malicious client-side script. This type of attack may be used to steal sensitive information such as usernames and passwords, perform session hijacking, remotely control or monitor the user's browser, or to impersonate a web page.
  • The Force.com platform provides output validation on all standard Visualforce components e.g. <apex:outputText> encode the characters within the components (< becomes &lt;). However this behavior can be overridden by setting the escape="false" attribute.

<apex:outputText escape="false">

  • Additionally, Custom JavaScript and S-Controls that give direct access to the HTML page also provide no XSS protection. In these cases, exact-match or whitelist input validation and output validation should be performed.

Cross-Site Request Forgery (CSRF)

  • CSRF is an attack where forged requests are made on behalf of an authenticated victim when the victim visits a malicious web page. The Force.com platform implements an anti-CSRF token to prevent this attack. Every form includes the token as a hidden field and the platform checks the validity of this token for POST submissions.

Finally, Apex applications hosted on the Force.com platform have the Secure flag set for all sensitive cookies by default. Apex applications can also use "Custom Settings" to store sensitive data such as encryption keys and passwords on the server. When configured correctly, this data will only be available programmatically to the Apex code within the package.