cross site script

  • 1
  • Question
  • Updated 2 years ago
  • Answered
We have a community portal developed in Skuid, and we have identified a security risk around reflected cross site scripting. We are passing the Account ID between skuid pages, and it is possible for a user to substitute the ID for a piece of javascript.  

Unfortunately from a community (unlike internal pages), the javascript does not get blocked when it is sent to the server, and the server response includes the javascript and is executed in the client.  The example we have used is a simple javascript alert.

Does anyone know how to prevent users injecting a piece of javascript manually into the url?
Photo of Digby Bartosh

Digby Bartosh

  • 100 Points 100 badge 2x thumb

Posted 2 years ago

  • 1
Photo of Rob Hatch

Rob Hatch, Official Rep

  • 44,006 Points 20k badge 2x thumb
Digby.  Thanks for brining this issue to our attention.  We take security issues very seriously and want to get to the bottom of what is going on.

We have some follow up questions that we are going to send you directly.  When we have fully understood the situation and determined that any corrective action needs to be taken we will post that resultion back here so that everyone can see the closure. 

Thanks. 
Photo of Karen Waldschmitt

Karen Waldschmitt, Official Rep

  • 8,240 Points 5k badge 2x thumb
Hi Digby~

Here is a technical summary of the issue. 

In Skuid's Apex code, we construct strings of JavaScript which are added to the page and interpreted by the browser. Skuid does proactively look for XSS vulnerabilities and escape them out within our Apex. Modern browsers have built in protection against XSS vulnerabilities which also help, but there are ways to disable these protections in some browsers. One of these ways is by setting a particular header in the response: X-XSS-Protection: 0

It appears that Salesforce sets this header when pages are served up from a Community or Portal. Skuid was relying on the browser's built in XSS protection so disabling it allowed for the vulnerability you noticed. The latest release of Rockaway includes a fix that will escape tags in the part of the code that processed URL parameters. Thus, even if the browser feature is disabled, XSS attempts via URL parameters will fail. 

Thanks again for alerting us of this issue as security issues are a very serious concern.
Karen