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 Force.com 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:
<script>
If you inspect the source code of the page, you'd see the following:
<a><script></a>
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}
</apex:outputText>
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:
<script>
var a = '{!$CurrentPage.parameters.userName}';
</script>
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:
<script>
var a = '{!JSENCODE($CurrentPage.parameters.userName)}';
</script>
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}"
onclick="displayPopup('{!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}"
onclick="displayPopup('{!JSINHTMLENCODE(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: http://bit.ly/2hBk6Os
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
threat!
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:
ESAPI.encoder().SFDC_HTMLENCODE(name)
page revision: 1, last edited: 02 Jan 2017 00:34