Highlighted

Cross Site Scripting Vulnerability

Explorer ,
Oct 26, 2015

Copy link to clipboard

Copied

I am using RoboHelp 11.0.4.291 to generate Responsive HTML5 help for web applications.

The web designers in my company have reported the following security vulnerabilities. Is there a fix?

1/ Cross Site Scripting Vulnerability via DOM Redirection
=========================================================

File: loadcsh.js
Function: redirectToTopic
Line Number: 117 (target.contentWindow.location.replace(gTopicURL);)

The mechanism RoboHelp is using to display the (context sensitive) help file is not secure because the passed in URL is

not being sanitised, therefore it's trivial for an attacker to trick the user into executing code by clicking on a link

e.g.

http://PATH_TO_ROBOHELP_DEFAULT_FILE.htm#t=javascript:alert(0)

The above URL will cause a pop-up in Internet Explorer, Chrome, Firefox and Opera (Safari is untested). This is a

definite issue that needs fixing by Adobe as illustrated by the following URL which prompts the user for their

credentials and sends the details to the attacker:

http://PATH_TO_ROBOHELP_DEFAULT_FILE.htm#t=data:text/html;charset=utf-

8;base64,PHNjcmlwdD5mdW5jdGlvbiBsb2dpbigpe3ZhciB1biA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCd1bicpLnZhbHVlO3ZhciBwdyA9IGRvY3V

tZW50LmdldEVsZW1lbnRCeUlkKCdwdycpLnZhbHVlO2FsZXJ0KCdZb3VcJ3ZlIGp1c3QgYmVlbiBoYWNrZWQhIFt1c2VybmFtZTonICt1bisgJywgcGFzc3d

vcmQ6JyArcHcrICddJyk7fWRvY3VtZW50LmRvY3VtZW50RWxlbWVudC5pbm5lckhUTUwrPSc8ZGl2IHN0eWxlPSJmb250OiAxNHB4IEFyaWFsOyI

+UGxlYXNlIExvZ2luPHA

+VXNlcm5hbWU6PGlucHV0IHR5cGU9InRleHQiIGlkPSJ1biIgbmFtZT0idXNlcm5hbWUiPjwvcD48cD5QYXNzd29yZDo8aW5wdXQgaWQ9InB3IiB0eXBlPSJ

wYXNzd29yZCIgbmFtZT0icGFzc3dvcmQiPjwvcD48YnV0dG9uIHR5cGU9ImJ1dHRvbiIgb25jbGljaz0ibG9naW4oKSI

+U3VibWl0PC9idXR0b24+PC9kaXY+Jztkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgndW4nKS5mb2N1cygpOzwvc2NyaXB0Pg==


2/ Potential Cross Site Scripting Vulnerability
===============================================

File: settings.js
Function: insertIFrame
Line Number: 188 (gIFrameElem.setAttribute("src", gHostPath+COOKIESPAGE);)

At first glance this doesn't appear to be an issue as the href property of the location object is being parsed and split

apart before being set as the src attribute for the iframe. However, it may be possible craft a URL that fools the

user-agent into passing a malicious payload through to this function. This is something that Adobe should investigate

and confirm that the necessary precautions have been taken.

3/ Potential DOM Data & Cookie Manipulation Vulnerability
=========================================================  

File: settings.js
Function: setThroughIFrame
Line Number: 202 (var objSave = new cookieSaveRequesObj(SAVE_REQ, name, value, bPersistent);)

I don't think this is an issue as the "value" property its referring to isn't a DOM Element it's a JavaScript object

(cookieSaveRequesObj). However, what might be an issue is whether that value is read back out and written to the DOM. It

may also be possible to craft a URL that exploits the setting/getting of the cookie. Again this is something that Adobe

should investigate and confirm that the necessary precautions have been taken.

4/ Preventing these exploits
============================

The above exploits could be mitigated by only allowing a white-list of URLs to be set (at build time RoboHelp knows all

of the URLS used so there is no need for it to allow any others) and sanitising the URL e.g. only allow schemes http: or

https: (not javascript:, data: etc).

Topics

HTML5 layout

Views

1.9K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Cross Site Scripting Vulnerability

Explorer ,
Oct 26, 2015

Copy link to clipboard

Copied

I am using RoboHelp 11.0.4.291 to generate Responsive HTML5 help for web applications.

The web designers in my company have reported the following security vulnerabilities. Is there a fix?

1/ Cross Site Scripting Vulnerability via DOM Redirection
=========================================================

File: loadcsh.js
Function: redirectToTopic
Line Number: 117 (target.contentWindow.location.replace(gTopicURL);)

The mechanism RoboHelp is using to display the (context sensitive) help file is not secure because the passed in URL is

not being sanitised, therefore it's trivial for an attacker to trick the user into executing code by clicking on a link

e.g.

http://PATH_TO_ROBOHELP_DEFAULT_FILE.htm#t=javascript:alert(0)

The above URL will cause a pop-up in Internet Explorer, Chrome, Firefox and Opera (Safari is untested). This is a

definite issue that needs fixing by Adobe as illustrated by the following URL which prompts the user for their

credentials and sends the details to the attacker:

http://PATH_TO_ROBOHELP_DEFAULT_FILE.htm#t=data:text/html;charset=utf-

8;base64,PHNjcmlwdD5mdW5jdGlvbiBsb2dpbigpe3ZhciB1biA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCd1bicpLnZhbHVlO3ZhciBwdyA9IGRvY3V

tZW50LmdldEVsZW1lbnRCeUlkKCdwdycpLnZhbHVlO2FsZXJ0KCdZb3VcJ3ZlIGp1c3QgYmVlbiBoYWNrZWQhIFt1c2VybmFtZTonICt1bisgJywgcGFzc3d

vcmQ6JyArcHcrICddJyk7fWRvY3VtZW50LmRvY3VtZW50RWxlbWVudC5pbm5lckhUTUwrPSc8ZGl2IHN0eWxlPSJmb250OiAxNHB4IEFyaWFsOyI

+UGxlYXNlIExvZ2luPHA

+VXNlcm5hbWU6PGlucHV0IHR5cGU9InRleHQiIGlkPSJ1biIgbmFtZT0idXNlcm5hbWUiPjwvcD48cD5QYXNzd29yZDo8aW5wdXQgaWQ9InB3IiB0eXBlPSJ

wYXNzd29yZCIgbmFtZT0icGFzc3dvcmQiPjwvcD48YnV0dG9uIHR5cGU9ImJ1dHRvbiIgb25jbGljaz0ibG9naW4oKSI

+U3VibWl0PC9idXR0b24+PC9kaXY+Jztkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgndW4nKS5mb2N1cygpOzwvc2NyaXB0Pg==


2/ Potential Cross Site Scripting Vulnerability
===============================================

File: settings.js
Function: insertIFrame
Line Number: 188 (gIFrameElem.setAttribute("src", gHostPath+COOKIESPAGE);)

At first glance this doesn't appear to be an issue as the href property of the location object is being parsed and split

apart before being set as the src attribute for the iframe. However, it may be possible craft a URL that fools the

user-agent into passing a malicious payload through to this function. This is something that Adobe should investigate

and confirm that the necessary precautions have been taken.

3/ Potential DOM Data & Cookie Manipulation Vulnerability
=========================================================  

File: settings.js
Function: setThroughIFrame
Line Number: 202 (var objSave = new cookieSaveRequesObj(SAVE_REQ, name, value, bPersistent);)

I don't think this is an issue as the "value" property its referring to isn't a DOM Element it's a JavaScript object

(cookieSaveRequesObj). However, what might be an issue is whether that value is read back out and written to the DOM. It

may also be possible to craft a URL that exploits the setting/getting of the cookie. Again this is something that Adobe

should investigate and confirm that the necessary precautions have been taken.

4/ Preventing these exploits
============================

The above exploits could be mitigated by only allowing a white-list of URLs to be set (at build time RoboHelp knows all

of the URLS used so there is no need for it to allow any others) and sanitising the URL e.g. only allow schemes http: or

https: (not javascript:, data: etc).

Topics

HTML5 layout

Views

1.9K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Community Beginner ,
Oct 27, 2015

Copy link to clipboard

Copied

Wow, #1 is a major issue, Adobe should fix this asap. I would not recommend anyone to upload RH HTML5 help content to a live server before this is fixed.

Thanks for sharing, Andrew.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
LEGEND ,
Oct 27, 2015

Copy link to clipboard

Copied

Hi all

While its certainly something for Adobe to look at, most often things like this just sound big scary mostly false alarms.

We often see similar things with antivirus software. Big scary alerts appear and whistles blow and progress grinds to a halt because of something known as a "false positive".

Cheers... Rick

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Community Beginner ,
Oct 27, 2015

Copy link to clipboard

Copied

It's definitely not a false alarm. Very easy to reproduce this on any RH 2015 project, online or offline. Check out the link they provided, it allows the attacker to execute any JS code using your corporate URL structure, e.g. they can easily create a link like http://www.yourtrustedcompany.com/help/Topic.htm#t=herecomesmaliciouscode. The user thinks "hey, this comes from my trusted company, it has to be secure", runs into e.g. a user/password prompt, enters his credentials, and everything is sent to the hacker. I could code that in 15 minutes, and I am a complete newbie hacker

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Explorer ,
Oct 28, 2015

Copy link to clipboard

Copied

I have had responses from two forum users (one of whom is an MVP) who agree that Adobe needs to look at the issue raised in this discussion but nothing from an Adobe staff member.

What is the procedure for escalating this?

Should I directly contact an Adobe staff member? The Top Participants list includes staff member SurbhiM.

The forum best practice guide has a reporting bugs section that links to http://www.adobe.com/products/wishform.html.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
LEGEND ,
Oct 28, 2015

Copy link to clipboard

Copied

Hi Andrew,

Please note that I don't work for Adobe and this is not a formal response. I would encourage you to also file a bug report with Adobe on: BugBase as that is the formal way of logging issues with them.

I forwarded the thread to Adobe (and perhaps Rick has also done this). They are aware of this issue. If you log a bug, Adobe can more easily contact you about this issue in the future.

Kind regards,

Willam

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Employee ,
Oct 28, 2015

Copy link to clipboard

Copied

Hi

Thanks for reporting this issue. We agree it is an issue. And Adobe will release the fix for this in next update coming soon.

Thanks again for reporting this.

Thanks

Amit Jha

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Explorer ,
Oct 28, 2015

Copy link to clipboard

Copied

Thanks for replying.

I tried to raise a bug report on BugBase but kept hitting the error "Sorry this operation could not be completed due to CAPTCHA mismatch, please try again.".

But from your message I assume that I no longer need to raise the bug report as Adobe are aware of the issue.

Can you give me an estimated date for the update that will fix this issue?

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Employee ,
Oct 28, 2015

Copy link to clipboard

Copied

Hi

You don't need to log a bug, we have logged the bug internally. We are working on this with very high priority and can share the private fix or tech note by next week or earlier.

Thanks again for reporting this issue.

Thanks

Amit Jha

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
LEGEND ,
Oct 28, 2015

Copy link to clipboard

Copied

Apologies then for misunderstanding. I'm not sure if it's a fortunate thing or unfortunate thing, but I have never understood the mindset of a hacker so I don't tend to think like one. There are so many more productive things one can do with computers that actually enhance folks lives other than cause grief and mischief. (shaking head)

Hopefully Adobe will be addressing it soon!

Cheers... Rick

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Community Professional ,
Oct 28, 2015

Copy link to clipboard

Copied

I reported the CAPTCHA mismatch error a while ago: Bug#4049246 - Captcha isn't recognised when using IE9

If you are using IE, try Chrome as I know that works.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Explorer ,
Nov 05, 2015

Copy link to clipboard

Copied

Can you give me an update on the progress of the private fix or tech note you said would be available this week for RoboHelp 11.0.4.291.

My company is approaching the release date for the products that use Responsive HTML5 help and this security vulnerability is becoming critical.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Employee ,
Nov 05, 2015

Copy link to clipboard

Copied

Hi

We have pushed the fix live here.

https://helpx.adobe.com/robohelp/kb/cross-site-scripting-vulnerability.html


Please try and let us know if you found any other issues.


Thanks for Reporting the issue.


Thanks

Amit Jha


Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Explorer ,
Nov 05, 2015

Copy link to clipboard

Copied

Thanks.

I have a question regarding section 2 on the Cross Site Scripting Vulnerability page(https://helpx.adobe.com/robohelp/kb/cross-site-scripting-vulnerability.html). Quote:

"If you are using layouts already created from Theme Standard or Theme Black, the layout.js file described in the following steps needs to be updated in those layouts"

I use my own layout based on the Theme1_Standard. Basically I changed the colours and dropped the glossary. Do I need to replace the layout.js file in my customised layout with the version provided in the fix?

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Employee ,
Nov 05, 2015

Copy link to clipboard

Copied

Hi

Yes, you need to update the layout.js. If you have changed layout.js for customization then you need merge the changes. Basically we have modified setTopic() function in layout.js.

Thanks

Amit Jha

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Explorer ,
Nov 06, 2015

Copy link to clipboard

Copied

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;

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Employee ,
Nov 07, 2015

Copy link to clipboard

Copied

Hi Andrew,

Thanks for reporting this issue. Adobe will soon release the fix for this in next update and we will update the kb article link too.

I agree that white-list url redirection is simple and best solution but Responsive HTML 5 help is not a application server based solution.

You can run Responsive HTML 5 on local files system or in any file server system or in any App.

Another way of solving these problems is to allow only valid relative file path. So that no other scheme (javascript: or data: etc) will be not allowed in URL components.

But their was some parsing bug which thankfully your web engineer have pointed out, We are re-looking at all the point and Adobe will release the fix soon..

Thanks again for reporting this.

Thanks

Gunjan Kumar

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Employee ,
Nov 10, 2015

Copy link to clipboard

Copied

Hi,


We have pushed the updated fix for url security issue live here.

https://helpx.adobe.com/robohelp/kb/cross-site-scripting-vulnerability.html


Please try and let us know if you found any other issues.


Thanks

Gunjan Kumar


Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Explorer ,
Nov 11, 2015

Copy link to clipboard

Copied

The web designers in my company have analysed the output generated by RoboHelp following your second fix and are still finding security vulnerabilities.

Their comments are listed below.

A vulnerability is still present e.g. http://PATH_TO_ROBOHELP_FILE#t=//www.attacker-controlled-site.com

This is an example of https://www.owasp.org/index.php/Open_redirect

"An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it."

As indicated previously there are probably (definitely) other ways to circumvent the current URL parsing in RoboHelp and trigger a web browsers default behaviour (e.g. to decode the url and/or perform navigation to the url) or trigger default behaviour of the users Operating System (e.g. exploiting windows UNC). For example this could be achieved by double URL encoding the payload and/or JavaScript escaping certain characters and/or hexadecimal encoding certain characters - this is not an exhaustive list and goes beyond the scope of our testing.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...