Presentation given at the August 2014 Sydney Salesforce Developers Group. It looks at the OWASP Top 10 project, and how the vulnerabilities in that list can manifest themselves on the Force.com platform. See the GitHub repo at the following link for the accompanying code: https://github.com/gbreavin/owasp-top10-salesforce

1. Salesforce.com, the OWASP
Top 10 and You!
What do the OWASP Top 10
vulnerabilities look like on
Force.com?

2. About me
What I do:
Senior Technical Consultant at Extentor
6 years working on Force.com
Certs:
Admin 201 and 301
Dev 401 and 501
Sales & Service Cloud Consultant

3. What is OWASP?
Open Web Application Security Project
“… an online community dedicated to web application
security” (Wikipedia, http://en.wikipedia.org/wiki/OWASP)
They have many projects, whose aim is to improve the
security of software applications built, or, in their words:
“…enable organisations to conceive, develop, acquire,
operate and maintain applications that can be trusted.”
(About OWASP, https://www.owasp.org/index.php/About_OWASP)

4. What is the OWASP Top 10?
Every year, OWASP list the top 10 most critical web application
security flaws. The list for 2013 can be found here:
https://www.owasp.org/index.php/Top_10_201
3-Top_10

5. Why is this relevant to Force.com?
• No platform can stop you from doing things you shouldn’t
do
• Alternatively: Force.com cannot stop you from making
mistakes (but in some cases, it will help avoid them)
• So: These flaws can exist in code you write
Think about the types of app you can build – internal apps,
but also customer-facing apps (e.g. Sites-based), and
AppExchange apps.
Knowing these flaws can help you avoid them
(But don’t treat this as a list of the only things to look for)

6. Example code
• This presentation was originally given at the
August 2014 Sydney Salesforce Developers User
Group
• The talk included demonstrations of (most of) the
vulnerabilities
• I can’t demo them to you if you’re reading this,
but you can find the code for the demo and
install them in your org in this GitHub repo:
https://github.com/gbreavin/owasp-top10-salesforce

7. The Top 10

8. 5. Security Misconfiguration
• Out of date software
• Unnecessary features enabled
Examples
• Incorrect OWDs
• Remote site settings
Prevention
• Security setup
• Don’t forget libraries, apps, etc.
• Rely on the database to determine visibility

9. 9. Using Components with Known
Vulnerabilities
• Using software components that have known
flaws
Examples
• JSONP
Prevention
• Keep any libraries, apps etc. up to date
• Read release notes and other Salesforce material
for security best practices

10. 7. Missing Function Level Access
Control
• Lack of checks on access to code functions (rather than
data).
• Remember “System Mode”
Examples
• Visualforce page access
• Web Service access
Prevention
• Profile permissions for Pages & Classes
• Don’t forget Javascript!

11. 2. Authentication & Session
Management
• Insecure ways of authenticating users
• This means during initial auth, and subsequent
accesses
Examples:
• Storing user credentials insecurely
• Session IDs in the URL
• Session IDs don’t timeout
Prevention:
• Let the platform do this for you

12. 1. Injection
• Unsafe use of user provided (or user modifiable) input, that affects
queries against a Database.
Examples:
• Use of Database.query()
• Modifying URL parameters that are used in a query
Prevention:
• Avoid dynamic SOQL where possible
• If using dynamic SOQL, limit anything that is provided or modifiable
by a user – parse input and select appropriate action rather than
plugging it straight into a dynamic SOQL query
• Sharing and security setup

13. 3. Cross Site Scripting (XSS)
• Web applications (usually) present pages to
users based on logic we control.
• XSS exploits ways of malicious parties
smuggling their code into the page that will do
their bidding
• A common proof of XSS vulnerabilities is to
cause a Javascript alert to pop-up (i.e. an alert
that is not triggered by the web application)

14. 3. Cross Site Scripting (XSS)
Examples:
• Non-persistent – e.g. URL Parameters
• Persistent – e.g. message boards
Prevention:
• Visualforce has some built in protections
• Escape input that could be included in a page,
preferably as data enters the system, or before it is
displayed
• Play a game: https://xss-game.appspot.com
• Read up on these attack vectors

15. 4. Insecure Direct Object References
• Failing to check that a user is allowed to access a resource
Examples
• Failing to check resource (e.g. record) access
• Sensitive information visible by admins
• ‘Hackable’ URL Parameters
Prevention
• Sharing and security, use “with sharing”
• Rely on the database to determine visibility
• Encrypted fields
Example Casualty

16. 6. Sensitive Data Exposure
• Inadvertent exposure of sensitive data (duh)
Examples
• Transmitting data in the clear e.g. non-SSL, URLs, Login forms over http
• Unencrypted credit card info
• Incorrect encryption (e.g. hand-rolled methods, unsalted hash)
• Logging
Prevention
• Use platform encryption methods
• Identify sensitive data and how it is used, where it comes from and goes
to, and assess for risks. Work out suitable encryption method
• If possible - don’t store sensitive data (e.g. credit cards)

17. 8. Cross Site Request Forgery (CSRF)
• Accessing resources that make changes to data without
a user intending it
Examples:
• Visualforce pages with action and auto-redirect
Prevention:
• Force.com has an anti-CSRF token protection for POST
requests – so use POST requests.
• Use pages that require manual action before changing
data.

18. 10. Unvalidated Redirects and
Forwards
• Re-directions to pages where either you don’t want users
to go, or where they don’t want to go
Examples
• Spoof URL parameter e.g. url=evil.com
• Malicious attempts to access pages e.g. url=admin
Prevention
• Avoid doing it
• Value look-ups e.g. simple values are accepted, and they
are mapped to approved URL targets, with a sensible
default