0

I have been assured by 2 Archtects that there is no security issue here but I want to ask the wider community because i sense a security vulnerability looming.

Below is the standard markup for Lightning Out(LO). I am interested in what a malicious actor could do with an Auth token. Once the user has obtained a token to pass into this markup, if the token could be captured by a third party at the point where it is used here, could that party abuse it in someway to gain access salesforce data?

    <script>
    $Lightning.use("c:locatorApp",    // name of the Lightning app
        function() {                  // Callback once framework and app loaded
            $Lightning.createComponent(
                  // Code
            );
        },
        'https://universalcontainers.force.com/ourstores/',  // Site endpoint
        **<AUTH TOKEN>**
    );
</script>

We have a design wherein the LO application would be made available on a website behind a log in. The authenticated user for whom the Auth token was created would be the website's server but the end user actually using the token would be the person how has logged in. This user then has access to the token as it is being passed into the markup. How could a user abuse this token? If there is a way to do so, how can this be mitigated? *no data such as an id would be passed into the component that could be used in an attack

Thanks for any help.

1 Answer 1

1

There's no inherent undue risk in a properly hardened app. Basically, follow OWASP's Top 10, and you should be fine. However, many orgs are set up with various vulnerabilities, so that's where most of your attention should be focused.

First, we have the Sharing Model. Make sure that your sharing model allows only as much access as necessary for the users involved. If you can set the model to Private, that would be the ideal solution. Use Sharing Rules and Restriction Rules to fine-tune which records a user has access to.

Second, we have Profile Permissions and Permission Sets. Make sure users have only the Object and Field Permissions needed to use the app. Also, make sure that they only have access to the Visualforce Pages and Apex Code classes that the app needs to function properly.

Third, we can consider session security settings. If possible, consider locking sessions to their origin IP address. Set session timeouts to reasonable values. Require modern TLS protocols. Basically, you want to make your sessions as locked down as possible.

Fourth, make sure you set the CORS and CSP settings appropriately in Salesforce. This will mitigate many kinds of XSS and XSRF attacks, including DOM injection and script injection. Further, you should also be appropriate testing apps like Chimera, BURP, CheckMarx, etc to scan for vulnerabilities in your web app. Your own site should also have a CSP to minimize attacks inside your own app.

Fifth, make sure you're using a secure SSL configuration. Use the latest TLS configurations, make sure you have a strong certificate, and that the private key for that certificate is secure. Consider HSTS configuration so it is impossible to accidentally or purposefully downgrade a TLS connection in your app.

Sixth, consider using a Connected App to establish the session, and set the scope for that app to only the features the user needs access to. This provides even greater security, as there's no way to trade a limited Connected App token for a more powerful full-session token.

Basically, as long as you follow security best practices, mainly the six sections I just outlined, you can feel confident that these exposed tokens won't present any undue risk. As with all security-related matters, make sure you test and attempt to break your system until you're satisfied that every area has been covered.

If you're still not satisfied after everything above, consider hiring a professional pen-tester to test your app. It is their daily job to attempt to thwart a system's security measures, and they'll have other specific tips and tricks that will help them find vulnerabilities that may be specific to your web app.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .