As a certified Salesforce partner, a common subject that we’ve noticed popping up is the act of a Visualforce Remote Objects HTML Encode; an XSS analysis. XSS stands for Cross Site Scripting and is in the OWASP Top 10 Vulnerability list. An unprotected system is vulnerable to attacks with malicious scripts being passed to an end user’s web browser where the script may be executed to perform a mini-program created by an attacker. With the expectation of Visualforce Remote Objects being introduced shortly, I wanted my team to know how to use this new technology without introducing XSS vulnerabilities into our code.
Here’s how I went about the Visualforce Remote Objects HTML Encode…
My goal was to answer 3 key questions regarding visualforce Remote Objects and XSS.
1. Does user input with HTML tags cause a system exception to be thrown? Some web frameworks take the approach that it is safer never to allow HTML to be saved to the back end, so they watch for inputs that contain certain tags and stop the operation immediately by throwing a system exception.
2. Does user input get encoded before being saved to the back end? One approach to ensuring only encoded output gets displayed is to save to the persistence layer with the encoded value. I was hoping not to find this behavior because it throws off maxlength validation and doesn’t make sense when sending values to anything other than a web browser.
3. Is HtmlEncode required when writing output to the browser? If the JS object gets populated with unencoded values, the responsibility would lie with the programmer to always encode before outputting.
Because Visualforce Remote Objects have only been released in the developer edition to date, I performed all testing on my dev account. First, I created a custom object named “XSS Test Object” with a name field (Name, Text 80) and a single char field (Single_Char__c, Text 1).
The page has a single textbox used to test out script tag input and an associated button to save the input. There is also an output section to pull the newly created data down and display the results in the browser.
Well done, Salesforce Security team. There were no system exceptions thrown when I entered script tags. From what I can tell, user input does not get encoded when being saved, so there has been no maxlength or system-to-system integration issues introduced. The biggest win though is that the Visualforce Remote Object already takes care of the encoding, so programmers don’t have to remember to encode every time they write to the browser.
With most of the hard work being done already, the most important thing for developers to consider is that there is encoding happening by default. To show why this is important, I created a single character field and saved a “<” character to the field. When I retrieved the data and wrote out the length of the field, I didn’t get a length of 1. I got a length of 4. The “<” got converted to “<”, and it was reporting on the encoded length. This could also affect equivolence checks. It’s a small price to pay for the benefit of auto-encoding.
Bottom Line | Visualforce Remote Objects HTML Encode
Visualforce Remote Objects gracefully handles potentially dangerous inputs and keeps end users secure by automatically encoding outputs. This is just one more reason the Salesforce developer community is anxious to hear of the release of Visualforce Remote Objects in production environments.
Need help with Salesforce? Datix specializes in helping businesses, implement, customize, and integrate their Salesforce system so that it better fits within their organization. We help businesses map CRM to their sales process, customize the software to fit business needs, and help mold business processes inside of the CRM to produce more dynamic outcomes. Learn more about what we can do with Salesforce.
Salesforce Reference Doc: