3

I am getting Cross-site Scripting (XSS) while scanning in force.com scanner.if i remove javascript there is no error..what to change in javascript code..please help its quite urgent...may be encode something...

Class

 accid=ApexPages.currentPage().getParameters().get('accid');
    public meetingCtlr1(ApexPages.StandardController controller) 
    {
      conRecList=[Select id,name,email from contact where Accountid=:accid];
    }

conRecList on VF page

I have used this in javascript on VF page
<script>
    for(var i=0;i<{!conRecList.size};i++)
    var id='thePage:theform:thePB:conTable:'+i+':'+checkboxid;
    document.getElementById(id).checked=bool; 
</script>  
2
  • Where is your '{' for the conRecList in the script? – Phil B May 24 '13 at 17:40
  • I have updated the '{' thats not an issue actually..can you help me... – miku May 24 '13 at 17:54
3

This may be a false positive, since conRecList.size will always be an Integer (since it's probably declared as List<Contact>).

In our projects that trigger false positives, we've just documented in the code why it's not an actual XSS issue.

If you wanted to satisfy the scanner, you could wrap it as {!JSINHTMLENCODE(conRecList.size)} but I see that as unnecessary overhead.

5
  • Per the SFDC docs: Unescaped Output and Formulas in Visualforce you should wrap that expression with either JSENCODE or JSINHTMLENCODE to provide the safest code possible. – Mark Pond May 24 '13 at 19:15
  • 3
    @MarkPond, I can see how that would make sense for a String, and especially something derived from user input, but in @miku's case it's the Integer result of a method call on a List. The last sentence of my answer stands -- wrapping in JSINHTMLENCODE() is unnecessary but will satisfy the scanner. – tomlogic May 24 '13 at 22:23
  • I could not agree more. This is definitely a preventative measure which is just to satisfy the scanner's threat pattern matcher. It is good practice to escape absolutely anything which could be deemed dangerous and though it is a minimal threat (if even that) in this case, it is good practice to do so any time you are retrieving and outputting data in this fashion. I wouldn't call this a false positive as much as an extremely low-risk threat. – Mark Pond May 24 '13 at 23:24
  • {!JSINHTMLENCODE(conRecList.size)} gives me error...how to satisfy this condition that will satisfy the scanner : Incorrect argument type for function 'JSINHTMLENCODE()'. – miku May 25 '13 at 13:20
  • 1
    @miku, that's interesting -- since conRecList.size isn't a String, you can't run it through JSINHTMLENCODE(). Perhaps this is an issue where you just have to document that it's safe to leave it in bare, since it's an Integer that can't trigger XSS (there's nothing you'd need to escape). It may work to do {!JSINHTMLENCODE(TEXT(conRecList.size))} if you really want to keep the wrapper. – tomlogic May 28 '13 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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