Download - Secure Salesforce: Lightning Components Best Practices

Transcript

Secure Salesforce: Lightning Component Best Practices Secure best practices

 Sergey Gorbaty  SMTS Product Security  [email protected]  @ser_gor  

 Robert Sussland  SMTS Product Security  [email protected]

 Safe harbor 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.

Safe Harbor

Sergey Gorbaty SMTS Product Security, Salesforce

Robert Sussland SMTS Product Security, Salesforce

•  Client Side Security

•  Security Model and Dangers

•  Lightning Domain Separation

•  Playing Safe Within Your Locker

•  Content Security Policy

•  Escaping, Rendering, External Scripts

•  Server Side Security

•  Apex Controllers, Aura Methods

•  CRUD, FLS

•  Summary

Agenda

Client Side Security

•  Lightning applications built using components

•  Components come from your org, from Salesforce and from AppExchange

•  All non-Salesforce authored Lightning components run from the Lightning Domain*

•  Same Origin Policy Browser Security Model

•  Many components will be rendered from the same Lightning Domain

•  Security risks come from JavaScript and not from Lightning design

•  JavaScript from different code bases runs on the same domain

•  Can access everything

Security Model and Dangers

•  Lightning domains are used for all things Lightning

•  Including partner applications, components

•  Data and metadata fetching

•  Domain separation will improve over time

•  Each component needs to play safe within its locker to avoid breakage

Lightning Domain Separation

Do not:

•  Send user data to 3rd party external domains

•  Clobber Aura built-in methods

•  Implement component RPC yourself

•  Trigger DML operations from init()

•  Modify DOM in the controller

•  Fire events from renderer

•  Use 3rd party MVC

Playing Safe Within Your Locker

Do:

•  Call your own controller’s @AuraEnabled methods

•  Modify only your own component’s DOM

•  Use <aura:method> to define component actions

•  Use events for communication

•  COMPONENT type events for internal events

•  APPLICATION type events should be treated as ‘navigation’

•  Practice JavaScript secure coding best practices

Playing Safe Within Your Locker (Cont’d.)

•  Common ground rules for safe-by-default communication

•  XHR, websockets can only connect to the application origin

•  Script sources can only be loaded from the application origin, e.g. from static resources

•  All components are subject to CSP

•  Additional rules are enforced at the security review

•  No eval(), inline JavaScript, dynamic <script> creation, innerHTML based rendering…

•  Latest details posted at

•  https://developer.salesforce.com/page/Lightning_Security

Content Security Policy

•  Avoid href assignment via document.location.href

•  Use relative URL with ‘/’ and encodeURI

•  String attributes need to be escaped if rendered outside of Lightning rendering

•  Avoid rendering using <unescapedHTML>, v.body, innerHTML

•  Instead of element.innerHTML = ‘<div class=‘ + class + ‘”>’ + name + ‘</div>’;

•  Use element.className = class; element.innerText = name;

•  Public attribute of String data must be escaped before assignment to v.body

•  For additional escaping functions check Aura.Utils.SecureFilters

Component Data Rendering Tips

Demo

Server Side Security

•  Use unambiguous class sharing definition

•  with sharing

•  without sharing

•  Assume any @AuraEnabled method is global == web service

•  Components may call it out of order

•  Additional checks are needed due to various user levels

Apex Controllers, Aura Methods

•  Apex runs in a system mode, will return all data for every user

•  Lighting Components do not have automatic CRUD enforcement

•  Each @AuraEnabled method that returns data must perform checks

•  Do not assume user has access to all fields

•  Checks must be performed on all objects

•  Checks allow best user experience when access is limited

•  Documentation

•  https://developer.salesforce.com/page/Testing_CRUD_and_FLS_Enforcement

CRUD, FLS

Demo

Summary

•  User input and 3rd party data needs to be rendered safely, use escaping

•  Never assume user has access to anything, perform proper checks in Apex

•  Use JavaScript defensively and do not access other components’ DOM directly

Summary

Thank you Thank you

Secure Salesforce at Dreamforce 2015

  10 DevZone Talks and 2 Lighting Zone Talks covering all aspects of Security on the Salesforce Platform

  Visit our booth in the DevZone with any security questions

  Check out the schedule and details at http://bit.ly/DF15Sec

  Admin-related security questions?

  Join us for coffee in the Admin Zone Security Cafe

Secure Salesforce Sesssions

  Common Secure Coding Mistakes   Rachel Black and Alejandro Raigon Munoz   THURSDAY   5:00pm in Moscone West 2006

  Chimera: External Integration Security   Tim Bach and Travis Safford   FRIDAY   10:00am in Moscone West 2009