Force.com security

Post on 06-Apr-2017

98 views 0 download

Transcript of Force.com security

FORCE.COM SECURITYBUILDING SECURE APPS ON FORCE.COM PLATFORM

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?

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”

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

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.

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

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!

CRUD IN VF PAGE• VF code respects CRUD:

• VF code does not respect CRUD:

• VF Pages with JS Remoting do not respect CRUD

MAKING APEX RESPECT CRUD• Before query or DML use:

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!

FLS IN VF PAGE• VF code respects FLS:

• VF code does not respect FLS:

• VF pages with JS Remoting do not respect FLS

MAKING APEX RESPECT FLS• Before query or DML use:

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

SHARING SETTINGS SCENARIOS!• Apex does not Respect Sharing Settings

• Apex Respects Sharing Settings

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

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!

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

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!

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

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………

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

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

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

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

OPEN REDIRECTS

OPEN REDIRECTS

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

• Whitelist all allowed external domains & validate before redirection

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

• 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