Secure Salesforce: Lightning Components Best Practices

download Secure Salesforce: Lightning Components Best Practices

of 22

  • date post

    16-Apr-2017
  • Category

    Technology

  • view

    1.999
  • download

    2

Embed Size (px)

Transcript of Secure Salesforce: Lightning Components Best Practices

  • Secure Salesforce: Lightning Component Best Practices Secure best practices

    Sergey Gorbaty SMTS Product Security sergey.gorbaty@salesforce.com @ser_gor

    Robert Sussland SMTS Product Security rsussland@salesforce.com

  • 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 controllers @AuraEnabled methods

    Modify only your own components DOM

    Use 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 (Contd.)

  • 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 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 , v.body, innerHTML Instead of element.innerHTML = + name + ;

    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