Cross Site Scripting (XSS)

Today Salesforce rejected our app due to several security issues. One of these was Cross Site Scripting (XSS). This is a common issue in security domain, and we need employ the changes to prevent XSS. The problem, and possible fix solution from Salesforce is very clear, so I copied and pasted here for future reference.

Description:

The attack involves reflecting user provided data into the browser, without any modification at the server's end. Cross Site Scripting attacks can be scripted in any browser scripting technology. There are 3 different types of Cross Site Scripting attacks. The first, being the most simple, in which the data entered is reflected back. The attack is temporary and is least risky. The second, called Persistent Cross Site Scripting is very common on bulletin boards and various social networking sites. The malicious input is stored on the server and each time a user accesses the data, the code is interpreted. And finally, the third form, called DOM based Cross Site Scripting, is perpetrated by exploiting the accessibility of the DOM of HTML page the user is viewing, and then running scripts with the user's privileges on his/her machine.

The developers of the application need to have strong input validation in place. This can be done using either blacklists or whitelists of characters. Similarly, the developers need to ensure that output is well sanitized. This can be implemented by escaping all the content being directed to the browser. Methods to boost cookie security should be employed.

Recommendation:

Consider performing a combination of input filtering and context-appropriate output encoding, such as HTML entity encoding for all the data that could be provided by external data sources like databases, users or web services if that data is included in the application’s output. Sanitize all user input. Enforce input validation checks on the server side. Include data type checks, data size and range checks. Check user input against whitelist values, check against other data values for logical accuracy and data integrity based on business rules.

An example of a blacklist would be where any input that contains characters that are considered “invalid” for web applications, such as “ < > & ‘ `;. Despite efforts to authoritatively identify all such characters, some characters are likely to be left out. A better way of validating input would be to define a list of allowed characters, also referred to as a whitelist.