Force.com security

29
FORCE.COM SECURITY BUILDING SECURE APPS ON FORCE.COM PLATFORM

Transcript of Force.com security

Page 1: Force.com security

FORCE.COM SECURITYBUILDING SECURE APPS ON FORCE.COM PLATFORM

Page 2: Force.com security

OVERVIEW• What is Security?• Is force.com platform not Secure?!• What is Security Review?• Common Security Vulnerabilities• Why do these Vulnerabilities occur?• How to fix these Vulnerabilities?

Page 3: Force.com security

WHAT IS SECURITY?• Prevent unauthorized external access of data and logic• Prevent unauthorized internal access of data and logic• Principle of Least Privilege“Users should only have access to the minimum amount of information required

to accomplish their duties”

“Users’ ability to take advantage of excess privilege purposefully or accidentally should be minimized”

Page 4: Force.com security

IS FORCE.COM NOT SECURE?!• All standard apps built on force.com are secure & respect all data access and

security settings• Because force.com is a platform, it gives some power & flexibility to the

developers; some of the security controls are released to developers• So, when building custom apps its developers responsibility to take care of

some security aspects

Page 5: Force.com security

WHAT IS SECURITY REVIEW?!• Salesforce security experts look at application’s source code to ensure proper

security standards are followed• Is security only important for AppExchange apps?• Security is more significant for AppExchange apps, but the guidelines should

be followed all the time.

Page 6: Force.com security

COMMON SECURITY VULNERABILITIES• Not respecting CRUD• Not respecting FLS• Not respecting Sharing Settings• SOQL Injection• XSS (Cross-Site Scripting)• CSRF (Cross-Site Request Forgery)• Open Redirects• Insecure Remote Resource Interactions

Page 7: Force.com security

NOT RESPECTING CRUD!• Occurs when an application violates CRUD settings on Profiles/ Permission sets• Execution Context:

User Context: Enforces CRUDSystem Context: Ignores CRUD

• Apex runs in system context, which means it ignores CRUD settingsUsers can query the data even if there is no READ permissionUsers can Create records even if there is no CREATE permissionUsers can Update records even if there is no EDIT permissionUsers can Delete records even if there is no DELETE permission

• VF Pages respect CRUD, but not always true!

Page 8: Force.com security

CRUD IN VF PAGE• VF code respects CRUD:

• VF code does not respect CRUD:

• VF Pages with JS Remoting do not respect CRUD

Page 9: Force.com security

MAKING APEX RESPECT CRUD• Before query or DML use:

Page 10: Force.com security

NOT RESPECTING FLS!• Occurs when an application violates Field Level Security settings• Execution Context:

User Context: Enforces FLSSystem Context: Ignores FLS

• Apex runs in system context, which means it ignores FLS settingsUsers can see data of a field which is hiddenUsers can update/ create data of a field which is hidden/ read-only

• VF Pages respect FLS, but not always true!

Page 11: Force.com security

FLS IN VF PAGE• VF code respects FLS:

• VF code does not respect FLS:

• VF pages with JS Remoting do not respect FLS

Page 12: Force.com security

MAKING APEX RESPECT FLS• Before query or DML use:

Page 13: Force.com security

NOT RESPECTING SHARING SETTINGS!• Occurs when the application violates Sharing Settings• Execution Context:

User Context: Enforces Sharing SettingsSystem Context: Ignores Sharing Settings

• Apex runs in system context, which means it ignores Sharing settingsUsers can see the records which are not shared with them

Page 14: Force.com security

SHARING SETTINGS SCENARIOS!• Apex does not Respect Sharing Settings

• Apex Respects Sharing Settings

Page 15: Force.com security

FIXING SHARING ISSUE!• Use “with sharing” key word for every class• You should have a strong reason if you are not using “with sharing” key word

Page 16: Force.com security

SOQL INJECTION!• SOQL injection is the vulnerability which allows attackers to modify queries at

run time, thereby getting access to unauthorized data• Occurs when user input starts behaving like code instead of text!• This happens when user input is directly inserted into a dynamic query without

validating or escaping• Users can access fields or data that a developer did not intend to reveal!

Page 17: Force.com security

PREVENTING SOQL INJECTION!• Use static queries wherever possible• Escaping Single Quotes:

- This adds a “\” before every single quote- This prevents inputs from being treated as code and treat them as

strings

Page 18: Force.com security

XSS – (CROSS SITE SCRIPTING)!• XSS is the vulnerability which allows attackers to insert unauthorized

javascript, VBScript, HTML or other active content into a web page.• When the web page loads the malicious code executes, which may lead to a

wide range to security issues.• Occurs due to poor separation between code and data contexts.• Occurs when user input is treated as code!

- Data starts acting as code!

Page 19: Force.com security

TYPES OF XSS!• Reflected XSS

- Malicious script is injected as url parameter- Malicious script is injected into a text field

• Stored XSS- Malicious script is stored in data base- Malicious script executes when data is retrieved and displayed on a web

page

Page 20: Force.com security

SOME IMPACTS OF XSS!• Malicious script can be used to steal sensitive data• Malicious script can be used to deface a web page and impact a company’s

reputation• Attackers can steal a user’s session and make unauthorized requests• Attackers can show a pop up which looks legitimate, but could download a

virus• Malicious script can be used to log key strokes and steal user credentials• Many more………

Page 21: Force.com security

PREVENTING XSS!• Avoid use of “escape=false” with VF tags• Use “JSENCODE()” in javascript context

• Use “HTMLENCODE()” in HTML context

• Use “JSINHTMLENCODE()” when both javascript and html are involved

Page 22: Force.com security

CSRF (CROSS SITE REQUEST FORGERY)• CSRF is vulnerability where a malicious application causes user to perform an

unwanted action on a trusted site• User is tricked to click on a URL

- which looks legitimate- but performs unwanted action

• Can lead to unwanted data updates or deletes

Page 23: Force.com security

PREVENTING CSRF• Avoid any state changing operations in “apex:page” tag• Avoid DML actions which create, update or delete data in “apex:page” tag

Page 24: Force.com security

OPEN REDIRECTS• Open Redirects is a vulnerability where a users is redirected to an

unauthorized site• Also know as “Arbitrary Redirect”• Occurs when values that are controlled by the users determine where the app

redirects

Page 25: Force.com security

OPEN REDIRECTS

Page 26: Force.com security

OPEN REDIRECTS

Page 27: Force.com security

PREVENTING OPEN REDIRECTS• Allow only local redirects, i.e. allow only partial urls

• Whitelist all allowed external domains & validate before redirection

Page 28: Force.com security

REMOTE RESOURCE INTERACTION• Avoid using CDNs

- Risk is not that big, but we want to achieve 100% security- some malicious code could steal data, redirection to malicious sites etc

• Use static resource for storing all third-party libraries and scripts

Page 29: Force.com security

• Not respecting CRUD• Not respecting FLS• Not respecting Sharing Settings• SOQL Injection• XSS (Cross-Site Scripting)• CSRF (Cross-Site Request Forgery)• Open Redirects• Insecure Remote Resource Interactions