Copy link to clipboard
Copied
We use robohelp for online help.
A security scan of the product is reporting "HTML5: Overly Permissive Message Posting Policy" against Funtion:Window:postMessage in robohelp.
They do not like that a "*" is being used when sending messages via postMessage:
Is this a real problem?
Thanks
===
HTML5: Overly Permissive Message Posting Policy ( 11347 )
Summary
A broadcast of information to windows on the client-side using postMessage was observed. The postMessage function is one of the features of HTML5 that allows a window to send messages to another open window. The typical syntax of postMessage is window.postMessage(message, targetOrigin, [transfer]).
The message parameter contains the information to be shared and targetOrigin indicates the origin of the destination window. It is recommended to explicitly specify the targetOrigin intended for a particular message. While the function permits the use of a wildcard character (*) for the targetOrigin, allowing the message to be shared to any window, we strongly recommend avoiding this practice. If a malicious user injects a new window into the javascript’s execution context, then the new window will now be able to receive any information that is shared using the vulnerable postMessage construct.It is also important to validate any message that is received from another window to confirm that the sender was authorized to do so. This will avoid receiving unintended input from a malicious window.
Execution
Inspect all messages that are transferred between windows to check the targetOrigin of the function calls. In this particular case, the given stack trace represents the execution of javascript that led to the discovery of the vulnerability.
If the postMessage() is used to transmit sensitive information between windows, then an unauthorized window would be able to retrieve this information as well.
Implication
Fix
All data that is shared between windows must have explicit origins to avoid eavesdropping. It is recommended to avoid using “*” for the targetOrigin in order to prevent a broadcast of the information.
===
Copy link to clipboard
Copied
I have not seen anyone else report this but it is not something that RoboHelp users (those who support the forums) could really answer.
I think this is something for your IT people to take up as they will understand whether or not it is a real risk. Perhaps also approach whoever produced the scanning software.
See www.grainge.org for free RoboHelp and Authoring information.
Copy link to clipboard
Copied
Thanks for responding Peter.
I was hoping that RoboHelp developers may be monitoring this forum and may respond.
Or a user might have run into this issue.
I did see a 5 year old message here related to this issue but no real answer.
Copy link to clipboard
Copied
Hi takhlia,
Do you have detailed report for the security scan for this issue or related issues? Please share that report with us (you can send me private message).
Regards,
Vikas Singla
Copy link to clipboard
Copied
Hi Vikas:
I have sent an email to you with an attachment that details the finding from the security scan.
Copy link to clipboard
Copied
Vikas:
I made some manual changes to our version of ehlpdhtm.js. And deployed it and did not see any issue with online help. Since there is really no cross domain stuff in our online help, I added source to postMessage and on event listener I added a check for origin:
from
targetWnd.postMessage("getContentSize" + gMsgSeparator + " ", "*");
to
targetWnd.postMessage("getContentSize" + gMsgSeparator + " ", window.location.origin);
and
function onPopupClicked(e)
{
var target = null;
var popupIFrame = rhPopupEx.getPopupIFrame();
if(!e)
e = popupIFrame.contentWindow.event;
etc
to
function onPopupClicked(e)
{
var target = null;
var popupIFrame = rhPopupEx.getPopupIFrame();
if (e) {
if(e.origin !== window.location.origin) return;
}
==
Is this something worthwhile to change in RoboHelp?
Thanks
Copy link to clipboard
Copied
We are using this version of RoboHelp:
RoboHelp 2017 version 13.0.2.334
Copy link to clipboard
Copied
Hi takhlia,
Yes, changing "*" to "window.location.origin" is a valid change for security reasons. Though we would still need to validate this change from product side, but the change is completely fine if you are not using the online help inside your own specific iframe or across different domains. Thanks for trying and sharing the workaround. We will also be working on validating and incorporating messaging security as per the shared report. We will share the update with you.
Regards,
Vikas Singla
Copy link to clipboard
Copied
Thanks you Vikas for looking into this quickly.