Reputation: 1356
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.
Upvotes: 2
Views: 11473
Reputation: 6772
Check the Snyk example at https://learn.snyk.io/lesson/dom-based-xss/ where they provide an example in the form of:
var ESAPI = require('node-esapi');
document.body.style.color =
'url(<%=ESAPI.encoder().encodeForJS(ESAPI.encoder().encodeForURL(color))%>)';
Upvotes: 0
Reputation: 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
Upvotes: -2