8

In latest development Salesforce Security Review team identified an issue with Javascript code in WebLinks.

The exact statement that was provided in Security Report was:

JavaScript of any type is not allowed to run within the Salesforce.com application context. This includes JavaScript blocks within HomePageComponents, WebLinks, and all other components that are run under the Salesforce.com DOM.

Now, a very Standard custom WebLink we have is on a List view, where we use GETRECORDIDS() of selected records and prepare a redirect URL and open a VF page.

So does that mean, Salesforce is completely closing the platform for JS based Buttons? I thought this was always an optional thing, I know JS based WebLinks/Buttons are not supported for Lightning, but what if an App is not built for Lightning, but is for Classic Aloha interface?

Does anyone know of any workarounds to counter the JavaScript Buttons/WebLinks failing an App's security review? Do I need to get rid of these buttons from the application for good if I need to have the app certified for Security Review?

I'm all puzzled, because this piece of information that Buttons with JS will be causing Security Review problems in any documentation ...

Improve this question

2 Answers 2

Reset to default
1

I think SF review team/ automated review scanner see this as Cross-Site Scripting vulnerability. You are taking ID by using GETRECORDIDS but what if some vulnerability consider its text field or user input. Then hacker can enter some java-script code in your text field.

XSS is described in detail with example at https://developer.salesforce.com/page/Secure_Coding_Cross_Site_Scripting

The simple solution to avoid this problem is to use proper encoding function around GETRECORDIDS function.

For ex:

<script>
  var x = '{!$CurrentPage.parameters.userInput}'; //vulnerable to XSS
</script>

To fix this you can do something like. 

<script>
  var x = '{!URLENCODE($CurrentPage.parameters.userInput)}'; //NOT vulnerable to XSS
</script>

I don't think weblinks and JS is blocked completely on platform. Your case looks like false possible because ID can not contain JS code.

So you have 2 options

1) Convince review team that its false positive as no one can manipulate ID field data

2) Fix the (false positive)vulnerability by using Encoding function and submit the the package for review again.

Improve this answer
7
  • In the example you posted, it seems like you should use JSENCODE rather than URLENCODE?
    – Adrian Larson ♦
    Commented Mar 9, 2016 at 5:35
  • either should work right?
    – AtulRajguru9
    Commented Mar 9, 2016 at 5:52
  • Not sure. They certainly have different purposes, but I guess single quote gets escaped either way.
    – Adrian Larson ♦
    Commented Mar 9, 2016 at 5:54
  • I agree, but my thoughts are: These vulnarabilities you mentioned and the formulas that exist are applicable for VF pages, and not the JS button/weblinks. JSENCODE() / JSINHTMNLENCODE() / URLENCODE() - these cannot be used in Weblink editor. And I've used these formulas in my VF pages. The main purpose of using JS buttons is to be able to alert users if he hasn't selected any record and thus GETRECORDIDS() function of JS in wbelink worked to suit it, plus, using JS weblinks made possible of reusing the same VF page for multiple list view buttons.
    – VarunC
    Commented Mar 9, 2016 at 7:22
  • I underhand your point and that is why I said it looks like false positive. You can execute JS on web links and that is why review team scan them.
    – AtulRajguru9
    Commented Mar 9, 2016 at 7:36
1

I recently had a meeting with the review team for one of the Appexchange apps my company is trying to publish and we too ended up facing the same thing for Weblinks.I don't think the review team can ever be convinced regarding this.Infact, they asked me to refer them those links where I read abt convinving them.

Anyways, the only solution was to convert all the JS buttons(list view and record detial level) that we had ,to VF pages and in that page, wecan surely execute javascript but as far as weblinks are concerned, i don't think the info given here is accurate.

Improve this answer
3
  • I may have been lucky then. After our review meeting we agreed on a common consensus that we can have weblinks with javascript as source but we should limit url parameters to only id values.
    – VarunC
    Commented Aug 4, 2016 at 7:12
  • Hi Varun- for the managed package in my case, we have multiple JS buttons on the record detail page and we are performing some logic by fetching id from URL like '{!Custom object__c.Id}'"); Currently, i have not encoded it.Just want to you will this also fall under vulnerability category and if yes, jusy by encoding it we can get rid of it right? Please let me know ur understanding if we can actually solve this
    – Abhijeet
    Commented Aug 8, 2016 at 8:20
  • Abhijeet, we had scheduled a meeting with Security Review's Office Hours team member. We reviewed and discussed various steps we could take to get our app security reviewed. The JS button/weblinks were also part of that. Our app was passing lot of parameters in those buttons. But the concern raised by the team was xss injection occurring by text fields or doing some location.url or redirect as retUrl parameter, so ultimately, it was confirmed to us that if we make sure that we only pass record ID field in weblink content then we are good to go. You should also hold same discussion with them
    – VarunC
    Commented Aug 8, 2016 at 11:48

You must log in to answer this question.

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