The web designers in my company have analysed the output generated by RoboHelp following your fix and are still finding security vulnerabilities.
Their comments and the output generated by their tests are listed below.
The vulnerability still appears to be there e.g. http://PATH_TO_ROBOHELP_FILE#t= javascript:alert(1) - notice the white-space we put between the equals and the 'j' (and there may be many other ways to trick the validation code).
In our opinion the best way to fix this is to match the value of 't' to a white-list and use the matched value instead of the one passed in on the url.
We are running Burp Suite (https://portswigger.net/burp/) and it's finding the following things:
1. Cross-site scripting (DOM-based)
Issue background
DOM-based cross-site scripting vulnerabilities arise when a client-side script within an application's response reads data from a controllable part of the DOM (for example, the URL), and writes this data into the HTML document in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to visit the attacker's crafted URL in various ways, similar to the usual attack delivery vectors for reflected cross-site scripting vulnerabilities.
Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.
Issue remediation
The most effective way to avoid DOM-based cross-site scripting vulnerabilities is not to dynamically write data from any untrusted source into the HTML document. If the desired functionality of the application means that this behaviour is unavoidable, then defences must be implemented within the client-side code to prevent malicious data from introducing script code into the document. In many cases, the relevant data can be validated on a white-list basis, to allow only content that is known to be safe. In other cases, it will be necessary to sanitise or encode the data. This can be a complex task, and depending on the context that the data is to be inserted may need to involve a combination of JavaScript escaping, HTML encoding, and URL encoding, in the appropriate sequence.
Issue detail
The application may be vulnerable to DOM-based cross-site scripting. Data is read from document.location.href and written to the 'setAttribute()' function of a DOM element via the following statements:
template/scripts/mhutils.js
template/scripts/settings.js
var folderAbsPath = _getFullPath(_getPath(document.location.href), commonRootRelPath + "/");
strURL=strURL.substring(0, n);
return strURL.substring(0,pathpos+1);
var folderAbsPath = _getFullPath(_getPath(document.location.href), commonRootRelPath + "/");
return _getHost(sPath)+sRelPath;
return sPath.substring(0,nPosx);
return _getHost(sPath)+sRelPath;
var folderAbsPath = _getFullPath(_getPath(document.location.href), commonRootRelPath + "/");
gHostPath = _getPathFromURL(folderAbsPath);
return sURL.substring(nPosx, sURL.length);
gHostPath = _getPathFromURL(folderAbsPath);
gIFrameElem.setAttribute("src", gHostPath+COOKIESPAGE);
2. Open redirection (DOM-based)
Issue background
DOM-based open redirection vulnerabilities arise when a client-side script within an application's response reads data from a controllable part of the DOM (for example, the URL), and writes this data into the target of a redirection in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause a redirection to an arbitrary external domain. This behaviour can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain and with a valid SSL certificate (if SSL is used), lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.
Note: If an attacker is able to control the start of the string that is passed to the redirection API, then it may be possible to escalate this vulnerability into a JavaScript injection attack, by using a URL with the JavaScript: pseudo-protocol to execute arbitrary script code when the URL is processed by the browser.
Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.
Issue remediation
The most effective way to avoid DOM-based open redirection vulnerabilities is not to dynamically set redirection targets using data that originated from any untrusted source. If the desired functionality of the application means that this behaviour is unavoidable, then defences must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a redirection target. In general, this is best achieved by using a white-list of URLs that are permitted redirection targets, and strictly validating the target against this list before performing the redirection.
Issue detail
The application may be vulnerable to DOM-based open redirection. Data is read from document.location.href and written to window.location via the following statements:
template/scripts/mhtopic.js
var strMainPage = document.location.href;
window.location = strMainPage.substring(0, indx+1) + "whcsh_home.htm#topicurl=" + strMainPage.substring(indx+1);
3. Cookie manipulation (DOM-based)
Issue background
DOM-based cookie manipulation vulnerabilities arise when a client-side script within an application's response reads data from a controllable part of the DOM (for example, the URL), and writes this data into the value of a cookie in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will set an arbitrary value in the user's cookie.
The potential impact of the vulnerability depends on the role that the cookie plays within the application. If the cookie is used to control the behaviour that results from certain user actions (for example, a 'production' versus 'demo' mode setting), then the attacker may be able to cause the user to perform unintended actions by manipulating the cookie's value. If the cookie is used to track the user's session, then the attacker may be able to perform a session fixation attack, in which they set the cookie's value to a valid token that they have obtained from the application, and then hijack the session during the victim user's subsequent interaction with the application.
Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.
Issue remediation
The most effective way to avoid DOM-based cookie manipulation vulnerabilities is not to dynamically write to cookies using data that originated from any untrusted source. This behaviour should never be implemented for cookies that have any role in controlling privileged actions or user sessions within the application.
The application may be vulnerable to DOM-based cookie manipulation. Data is read from document.location.href and written to document.cookie via the following statements:
template/scripts/mhutils.js
template/scripts/settings.js
var folderAbsPath = _getFullPath(_getPath(document.location.href), commonRootRelPath + "/");
strURL=strURL.substring(0, n);
return strURL.substring(0,pathpos+1);
var folderAbsPath = _getFullPath(_getPath(document.location.href), commonRootRelPath + "/");
return _getHost(sPath)+sRelPath;
return sPath.substring(0,nPosx);
return _getHost(sPath)+sRelPath;
var folderAbsPath = _getFullPath(_getPath(document.location.href), commonRootRelPath + "/");
gHost = _getHostNameFromURL(folderAbsPath);
return sURL.substring(nPos+2,nPosx);
gHost = _getHostNameFromURL(folderAbsPath);
document.cookie = "testcookieone;domain=" + gHost + ";path="+gHostPath;
4. DOM data manipulation (DOM-based)
Issue background
DOM-based DOM data manipulation vulnerabilities arise when a client-side script within an application's response reads data from a controllable part of the DOM (for example, the URL), and writes this to a data field within the DOM that is used within the visible UI or client-side application logic. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will modify the appearance or behaviour of the client-side UI. An attacker may be able to leverage this to perform virtual defacement of the application, or possibly to induce the user to perform unintended actions.
Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.
Issue remediation
The most effective way to avoid DOM-based DOM data manipulation vulnerabilities is not to dynamically write to DOM data fields any data that originated from any untrusted source. If the desired functionality of the application means that this behaviour is unavoidable, then defences must be implemented within the client-side code to prevent malicious data from being stored. In general, this is best achieved by using a white-list of permitted values.
Issue detail
The application may be vulnerable to DOM-based DOM data manipulation. Data is read from document.location and written to the 'value' property of a DOM element via the following statements:
template/scripts/settings.js
template/NOGLOSSARY1/layout.js
var url = document.location.toString(), hashString = rh._.extractHashString(url);
saveSetting(lastVisitedTopic, url, false);
setThroughIFrame(name, value, bPersistent);
var objSave = new cookieSaveRequesObj(SAVE_REQ, name, value, bPersistent);
this.value = value;
18
Replies
AdChoices