Salesforce Developer Security Xss Automatic Encoding


// Salesforce - Developer - Security - XSS - Automatic HTML Encoding:

By default, Salesforce provides HTML encoding for any values / merge fields 
placed in HTML context. This includes all standard functionality, as well as 
Visualforce pages and components.  For example:

<apex:outputText value="{!$CurrentPage.parameters.userName}" />

Theoretically, this piece of code would be vulnerable to XSS because user 
supplied input is reflected back on the page . Thanks to the platform 
this code is not actually vulnerable to XSS however, because the platform will 
encode this value for HTML context. If the URL were /page?userName=<script>, 
you'd see the following displayed on the page:


If you inspect the source code of the page, you'd see the following:


It is possible to disable this behavior by setting the optional attribute 
escape="false" on several Visualforce tags. For example:

<apex:outputText escape="false">
Hello {!$CurrentPage.parameters.userName}

This ability exists because there are use cases where this behavior may be 
desired by a developer.  In such circumstances, it is up to the developer to 
make sure that their code is not vulnerable to XSS.

As mentioned previously, there are places where standard platform encoding does 
not apply , and user input is vulnerable to cross-site scripting. Those 
locations are:

1. Within javaScript context (commonly between <script> tags)
   a. One exception is javaScript remoting, where escape:true is a default 
      property of a remoting call.

2. Within style context (commonly between <style> tags)

3. Where encoding has been disabled due to escape=false or escape:false in 
   javaScript Remoting.

To prevent XSS in these locations, several native encoding functions are 
offered in Visualforce:

1. HTMLENCODE: Encodes text and merge field values for use in HTML by replacing 
   characters that are reserved in HTML. This is used where user input is 
   reflected in HTML context without encoding. 

2. JSENCODE: Encodes text and merge field values for use in JavaScript by 
   inserting escape characters, such as a backslash (\), before unsafe 
   JavaScript characters, such as the apostrophe ('). This will be used in 
   cases where a merge field is directly used as a JavaScript variable.

3. JSINHTMLENCODE: Encodes text and merge field values for use in JavaScript 
   within HTML tags by inserting escape characters before unsafe JavaScript 
   characters and replacing characters that are reserved in HTML with HTML 
   entity equivalents. This is used for cases like merge fields in javascript 
   event handlers since the merge field is reflected both in HTML and 
   JavaScript context. 

Consider the following code:

var a = '{!$CurrentPage.parameters.userName}';

The user input (from the URL parameter) needs to be encoded for javaScript 
context before displaying on the page, or there will be an XSS vulnerability. 
The correct native encoding function for this code is JSENCODE:

var a = '{!JSENCODE($CurrentPage.parameters.userName)}';

JavaScript context does not always mean between <script> tags however. 
Javascript event handlers like onClick and onHover are considered javaScript 
context as well: 

<apex:column id="message" value="{!message}" 

In this case, the user input is reflected back in the HTML context when the page 
is rendered and in JS context onclick. So the correct encoding would be:

<apex:column id="message" value="{!message}" 

All of the above examples are in Visualforce. What if you need to encode in 
Apex? The ESAPI package can be used to provide encoding functions and other 
security tools in Apex.

The primary use cases for the Apex encoding functions of the ESAPI are 
scenarios where you need to encode a smaller portion of the value represented 
by a merge field. This often happens when outputting HTML code into a function 
with escape="false".

ESAPI documentation:

You might notice that certain characters in the JSENCODE() column have \uXXXX 
listed. This is the unicode equivalent for this character. Do not be fooled! 
JavaScript automatically converts unicode, so they still represent an XSS 

Hhow do you find any XSS vulnerabilities in your code? 

In this section, we'll go through the common methods of locating XSS 
vulnerabilities, and give you a sample broken page that has many different 
kinds of XSS for you to locate. Then, we'll help you fix those different 
vulnerabilities. This will give you lots of practice in dealing with XSS.

Fixing XSS:

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License