Secure Development on the Salesforce Platform - Part I

March 10, 2016
Secure Salesforce Development
on the Salesforce Platform

Speakers
Max Feldman
Product Security Engineer
Lehan Huang
Web Application
Security Engineer
Vinayendra
Nataraja
Product Security Engineer
@vinayendra

Forward-Looking Statement
Statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve
risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of
salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other
than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth,
earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of
belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for
our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate
of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with
completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability
to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our
limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential
factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year
and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are
available on the SEC Filings section of the Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and
may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are
currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

Go Social!
Salesforce Developers
The video will be posted to YouTube & the
webinar recap page (same URL as registration).This webinar is being recorded!
@salesforcedevs / #forcewebinar

▪ Don’t wait until the end to ask your question!
– Technical support will answer questions starting now.
▪ Respect Q&A etiquette
– Please don’t repeat questions. The support team is working
their way down the queue.
▪ Stick around for live Q&A at the end
– Speakers will tackle more questions at the end, time-
allowing.
▪ Head to Developer Forums
– More questions? Visit developer.salesforce.com/forums
Have Questions?

Agenda
1. Roadmap for the year:
– Four webinars, one per quarter
2. Plan for today:
– SDL, CRUD/FLS, Sharing, SOQL, Q&A
3. Introductions:
– Max
– Lehan
– Vinayendra

Security and the Force.com Platform
 Force.com was designed to be flexible and support
delevoper and business needs
 Force.com provides many built-in protections to protect
developers and their user base
 Salesforce protects end users by ensuring that all
applications listed in the AppExchange undergo a security
review

Background
 Principle of Least Privilege
– Users should only have access to the minimum amount of
information required to accomplish their duties
– Their ability to take advantage of excess privilege purposefully or
accidentally should be minimized
 Context
– User context: Enforces user permissions, field-level security, and
sharing rules of the current user
– System context: Ignores user permissions, field-level security, and
rules of the current user

Secure Development Lifecycle
 Design
– Plan your application with security in mind
– https://developer.salesforce.com/page/Security_Design_Resources
 Development
– Follow best practicies for secure development, implement securely
– https://developer.salesforce.com/page/Secure_Coding_Guideline
 Testing
– Test for security (as one would test functionality)
 Release
– Be prepared for the discovery of any security flaws
– Staying secure is an ongoing process

FourZip App
 Display zip codes in 12345-1234 format
– Read from Account object for the shipping address
– Take the 5 digit zip and make an external call to retrieve the 4 digit
extension
– Display associated Opportunities

Account Profiles
 System Administrator
– Default administrator profile
– Has access to everything
 ZipFour User
– Cloned profile from standard user
– Can access ZipFour app
– Cannot see Account’s Annual Revenue field
– Cannot see Opportunity

FourZip
 What will we develop today?
– One VF page
– One Apex controller
– Mock API call for the external call
• This will be covered in part 3 of the webinar series – External
application/system integration best practices
– Wrapper classes to hold the zip+4 information, plus opportunities
– Let’s take a look at the code!

Secure Development on the Salesforce Platform - Part I

What is CRUD?
Create, Read, Update, Delete
 Define user’s access for
each object
 Controlled on the profile
and permission set

CRUD
 Apex classes do not enforce CRUD
– Runs in system context
 Visualforce pages enforce CRUD
– Runs in user context

<sObject>.sObjectType.getDescribe()
• isCreateable()
• isAccessible()
• isUpdateable()
• isDeletable()
1 Public Class MyController {
2 Public String getmyAccount {
3 if (!Account.sObjectType.getDescribe().isAccessible()) {
4 return '';
5 }
6 }
Enforcing CRUD in Apex

Visualforce code patterns respect read in CRUD:
1. <apex:outputField value="{!sObject.Field__c}"/>
2. <apex:outputText value="{!sObject.Field__c}"/>
3. {!sObject.Field__c}
Visualforce code pattern does not respect read:
1. <apex:outputText value="{!wObject.String}"/>
2. <apex:outputText value="{!someVariable}"/>
Enforcing CRUD in Visualforce

CRUD Fix
Let’s fix the vulnerability and demo the fix

Best Practices for CRUD
 Always check CRUD permissions before performing the
operation in apex classes
 Not checking can give elevated access to users who should
not have it

What is FLS?
Field-Level Security
 Define user’s access to
fields on a given object
 Controlled on the profile
and permission sets

FLS for Developers
 Apex classes do not enforce FLS
 Visualforce pages enforce FLS
– Runs in user context
– Does not enforce FLS for dereferenced fields
• {!Contact.Email} = yes
• {!contact Email} = no

Schema.sObjectType.<sObject>.fields.<field>
• isAccessible()
• isUpdateable()
1 Public Class MyController {
2 Public String getmyAccount {
3 if (!Schema.sObjectType.Account.fields.Name.isAccessible()) {
4 return '';
5 }
6 ...
7 }
Enforcing FLS in Apex

When Sobject is assigned a primitive
Apex:
Random_Sensitive_Object_1__c r; // Salesforce sObject
wRandom_Sensitive_Object_1 wR; // Custom wrapper object
wR.Sensitive_Number = r.Sensitive_Number__c;
Visualforce:
<apex:OutputText value="{!r.Sensitive_Number__c}" /> 
<apex:OutputText value="{!wR.Sensitive_Number}" /> 
When does the Platform stop respecting FLS?

FLS Fix

Best Practices for FLS
 Use sObject references whenever possible
 Iterate through your list of fields and check FLS for each
field

What is Sharing?
Record-level access
 Dictates which records
of an object a user can
see
 Controlled outside the
profile via org-defaults,
roles, ownership, and
sharing rules

How is Sharing Enforced?
 Apex classes do not enforce sharing by default
– Exceptions: anonymous code blocks, developer console, and
standard controllers execute in user context
 Visualforce pages depend on controllers for record access

Sharing/CRUD/FLS
FLS
Sharing
CRUD

1 Public with sharing Class MyController {
2 // Code enforces current user’s sharing rules
3 Public without sharing Class MyInnerClass {
4 // Code doesn’t enforce current user’s sharing rules
5 }
6 }
Enforcing Sharing in Apex
 Default behavior is without sharing
– Use with sharing keyword to enforce sharing
 If a class isn’t declared as either with or without sharing, the current
sharing rules remain in effect
 The sharing setting of the class where the method is defined is applied,
not of the class where the method is called

Sharing Fix

Best Practices for Sharing
 Explicitly declare with sharing or without sharing for all
classes in your code
 If you must use without sharing, document the reasoning in
a comment block
 Sharing keywords don’t enforce CRUD and FLS

SOQL vs SQL
Salesforce Object Query Language vs Structured Query Language
 SOQL is the query language used in the Salesforce
platform
 SOQL only allows the SELECT command portion SQL
 SOQL does not allow command execution, or wild card (*)
for fields

SQL Injection
 SQL Injection is an attack where user input is allowed to
modify the structure of an SQL query and perform
unexpected actions
 Sample SQL query subject to SQL injection:
 If un_iput= admin’-- and user input is not modified before
passing it to the query we get:

SOQL Injection
 SOQL Injection only occurs when dynamic SOQL queries
are used without proper manipulation of user input
 Sample code block:
 User input:
 Final query:

SOQL Injection Mitigations
 Static query + bind variable:
 Wrap user input in string.escapeSingleQuotes()
– This will not prevent all the attacks.
– Sample query:
– User input that could bypass this defense mechanism

SOQL Injection Fix

Summary
Developer practices for respecting authorization model
 CRUD
– Object-level permission. Should the user have access to this object?
 FLS
– Field-level permission. Should the user have access to this field?
 Sharing
– Record-level permission. Should the user have access to this
record?
 SOQL
– Salesforce Object Query Language. Is there injection?

Additional Resources
Security Implementation Guide
https://developer.salesforce.com/././securityImplGuide/ (full link hidden)
CRUD & FLS Enforcement Guide
https://developer.salesforce.com/page/Enforcing_CRUD_and_FLS
Using with sharing or without sharing Keywords
https://developer.salesforce.com/./././apex_classes_keywords_sharing (full link hidden)
SOQL Injection
http://sfdc.co/SOQLInjection
Secure Coding Guidelines
https://developer.salesforce.com/page/Secure_Coding_Guideline
Salesforce Developer Security Forum
https://developer.salesforce.com/forums

Salesforce World Tour @ CeBIT
Hannover, 14.-18. März 2016

Q & A
Share Your Feedback: http://bit.ly/securedevelopment
Join the conversation:
@salesforcedevs
@SecureCloudDev

Survey
Your feedback is crucial to the success
of our webinar programs. Thank you!
http://bit.ly/securedevelopment

Secure Development on the Salesforce Platform - Part I

More Related Content

What's hot (20)

Similar to Secure Development on the Salesforce Platform - Part I (20)

More from Salesforce Developers (20)

Recently uploaded (20)

Secure Development on the Salesforce Platform - Part I