How to use ESAPI to resolve JavaScript DOM XSS?

Question

We are using HP fortify Audit Workbench 3.80 to assess vulnerabilities in our applications. Fortify marks the the following ExtJs JavaScript code as a Critical (the "worst") DOM XSS vulnerability:

function doAjaxCall(param1, param2, div) {
    var options = {
            url : url,
            params : {
                param1 : param1,
                param2 : param2
            },
            method: 'GET',
            success: function(response, options) {
                processResponse(response, div);
            },
            failure: function(response, options) {
                doSomethingElse();
            }
    };
    Ext.Ajax.request(options);
}


function processResponse(response, div) {
     // SECURITY ISSUE HERE
     document.getElementById(div).innerHTML = '<br>' +
            'An error occurred with status code ' 
             + response.status + 
             '<br><br>';  
}

response is the response returned from an AJAX request.

Fortify says :

method "processResponse" sends unvalidated data to a web browser on line 100, which can result in the browser executing malicious code.

I understand the issue and why it is an issue. What I do not know is how to sanitize the input with ESAPI . We are using ESAPI successfully for issues in our Java code, but I am not sure to resolve this specific issue in JavaScript.

I did find this JavaScript ESAPI library, ESAPI4JS , but I work in an extremely high security environment, and I do not have access to this library whatsoever.

How can I use ESAPI to sanitize the response?

EDIT

Added full ajax request code per user request.

Answer 1

Vulnerable:

document.write("Site is at: " + document.location + ".");

Not vulnerable: org.owasp.esapi.ESAPI.initialize(); document.write($ESAPI.encoder().encodeForHTML("Site is at: "+document.location));

You will need to initialize it before use. There is documentation on owasp's site.

@GeorgeStocker is wrong. A dom based xss typically is most dangerous because it cannot be handled server side. A perfect example would be the above which could easily be exploited by using a # before some code.

Also most client side xss filters can be bypassed by using onerror.

ey3