Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

The CheckMarx security scanner says that this line is a Reflected XSS vulnerability.

<apex:outputText value="0,number,#,##0.00}" style="color:!nost.balColor};">

However this page

http://www.salesforce.com/us/developer/docs/pages/Content/pages_security_tips_xss.htm

says that <apex:outputText/> is filtered to prevent XSS vulnerabilities. Is that a false positive?

Thanks!

share|improve this question

2 Answers 2

up vote 3 down vote accepted

The 'Reflected' part of reflected XSS vulnerabilities usually means that a parameter going into the page is being echoed back in the response exactly as is, the issue being that if an attacker were to put JavaScript into the parameter it'd end up on the page and being executed by the user's browser.

Given that in this particular case you're outputting a number on to the page, and that JavaScript in the parameter would most likely throw an exception, I believe you're safe to call this a false positive.

share|improve this answer

The issue is with the merge-field in the style tag. It appears your code is missing opening brackets in question, but assuming the code is:

<apex:outputText value="{!foo}" style="color:{!bar}">

Then this will render on the page as, roughly,

<span style="color:{!bar}">{!foo}</span>

Now the platform will encode {!bar}, replacing "<", "&", ">", and double quotes with their HTML entity character references, and it will encode {!foo} by replacing "<", "&", and ">". However if the value of bar was expression($javascript_payload', then this will execute javascript payload in older versions of IE (or newer versions running in quirks mode). So if bar is pulled from a URL parameter, then this is a reflected XSS and if bar is pulled from the db it is a stored XSS.

Whether or not this is a false positive depends on the range of characters that can flow into the merge-field, but auto encoding is not going to protect you here.

In general avoid placing merge-fields within script and style tags as the platform does not have a CSSENCODE function as it does for JSENCODE and CSS is very difficult to sanitize (a string encoding function is not sufficient as many CSS properties do not take quoted values).

One alternative is to use CSSOM or manipulate styles with javascript based on the values of merge-fields passed to javascript within a script context.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.