Security vulnerability over allowing StartTopic to load exte

[spackiaraj]

We can load external URL using StartTopic parameter in the URL. To explain more let us consider basic URL which displays some content
'http://[MyWebServer]/wwhelp_Left.htm#CSHID=helplibrary%2Administer.htm|StartTopic=Content%2Fhelplibrary%2Administer.htm|SkinName=TechPubsSkin'

With the above URI help topic will be loaded from "Content/helplibrary/Administer.htm" with in the server.
But URI can be external also.

'http://[MyWebServer]/wwhelp_Left.htm#CSHID=helplibrary%2Administer.htm|StartTopic=http://www.malicious_software.com/stealsession.html|SkinName=TechPubsSkin'

The above URL will load the content from 'http://www.malicious_software.com/stealsession.html'
Attacker can easily craft such URL and trick the user to steal users credentials as the end user might pay attention to the actual server not entire content of the URL.

This behavior is because of the following code at 'MadcapDefault.js' file
--------------------------------------- @ funciton "CheckCSH()"
else if (pair[0] == "StartTopic")
{
gStartTopic = decodeURIComponent(pair[1]);
}
----------------------------------- @ function "NavigateToStartupTopic()"

var path = null;
if (!startupTopicUrl.IsAbsolute)
path = MCGlobals.RootFolder + gStartTopic;
else
path = gStartTopic;
======================

The StartTopic value is not validated for external URIs.

This behavior is considered to be high vulnerability as attacker can easily get the users credentials by just having login page that mimics the actual server login page.

Since its considered as high vulnerability we would like to fix this script. Do any one see license (EULA) violation. [large enterprises do not like to have these kind of vulnerabilities]

[NorthEast]

This is a peer-to-peer forum; so if you want MadCap's advice on the script or its licence, then I would contact MadCap support directly.

[RamonS]

Also, if you detect such vulnerabilities it is common courtesy to first contact the vendor and not post this in a public forum. Others may have picked up on this vulnerability already, but by posting it here you made it a piece of cake for just any village idiot to launch attacks against Flare generated help. So rather than improving the situation you made it quite worse.

[spackiaraj]

My intention is NOT to disclose this vulnerability to everyone, rather figuring out right direction to fix.
That is,
Will madcap fix this, by going through the support? {My urgency is not your emergency}
We have to fix this by ourselves. By doing so, do we breach EULA?

I was more concerned towards the direction of fix rather than possible abuse of the information on this forum.

If my posting was not in-line with your interest, I apologies

[rob hollinger]

Hello spackiaraj and welcome to the forums.
You can alter the output files without any fear of EULA violations if needed.

It is true you can load external content into the topic pane by altering the URL.
We do not prevent this because users link to outside content in their TOC, links in content, etc and want those outside pages to load in the topic pane.

Here is an example of loading external content via the TOC.
Open one of the two links below (HTML5 and WebHelp)
Click on the TOC item "MadCap Software Website"
Notice it loads the MadCap site in the topic pane.

http://ts.madcapsoftware.com/Downloads/ ... efault.htm
http://ts.madcapsoftware.com/Downloads/ ... efault.htm

[spackiaraj]

Thanks Rob. Appreciate your time
We might change the 'js' files to have a quick fix, but expect Madcap to fix this ASAP.
Just to illustrate how this functional requirement can turn into vulnerability/exploit, try the following URL
http://ts.madcapsoftware.com/Downloads/ ... %6fg%69%6e

End/Enterprise user might not anticipate the trap and might click the URL as the hostname looks trusted.

Since its considered as security vulnerability & easy to trick the enterprise user, it might be desirable to have a on/off switch to load the external content.

Thanks a lot again.

PS: Without support contract it looks to me I will not be able to contact support team.
Also, no public disclosure is intended. The above sample intended for illustration/education purpose only.

[RamonS]

Also, no public disclosure is intended.

Already happened because this is a public forum that gets indexed by any search engine in the universe....just sayin'.

[spackiaraj]

Thanks RamonS.

Perhaps we can focus on the solution so the both of us win. Moreover definitely I am not the one who find this. Its easy for anyone to guess. People already aware that Flare allows external URL to be loaded.

So I am not really worried whether public aware of this info or not.
All web apps do have vulnerability some known and many unknown.

IMHO, instead of nitpicking on public disclosure argument we can look at the details.

Appreciate your time & input.

[whunter]

Without support contract it looks to me I will not be able to contact support team.

Anyone can report an issue using the "Report a bug" link at the bottom of this page:
http://www.madcapsoftware.com/support/

They will respond to you with or without a support contract, there's just no guarantee of a speedy response.

[RamonS]

IMHO, instead of nitpicking on public disclosure argument we can look at the details.

The detail is that you do not have a maintenance contract, yet demand that MadCap fixes your problem asap. Also, there are plenty of contact email addresses and phone numbers on the MadCap web site for anyone to see and use. Did you try it that way first? The procedure for disclosures of any kind is not something I cooked up or unique to MadCap, it is just common practice...and yes, courtesy.
As far as the code being the way it is, Rob explained it quite well that this is by design to intentionally load external content. That further means that MadCap is probably not providing a fix unless there are other means of seamlessly loading external content. The solution is as you suggest and your concern for license violation is put to rest as well.
And now go a buy a maintenance contract....

[spackiaraj]

Thanks Mr Cool. FYI we have platinum support. I do not wish to disclose the details of the support info we got it.
Just because I seek some info on developer forums does not mean that we do not have support contract.
{personally i am unhappy about info on the support web-page}

As you have pointed that "Its a behavior by design" so I have not found anything new, {then no worry about disclosing}

All I am saying/asking that, this Flare behavior vulnerable and can end customer modify this behavior by changing some of Flares JS file.
And hoping to get some developers {peer - peer) opinion on that.

If you do not want to listen to that, that is your choice.

Thanks for the helpful replay
Anyway I got the info I wanted to make our customer happy. {do not wish to waste any more time on this}

PS: I expect you to fix this ASAP so that (we) customer do not need to carry out a patch for you

[RamonS]

PS: I expect you to fix this ASAP so that (we) customer do not need to carry out a patch for you

Just an FYI...I do not work for MadCap. And you mentioned earlier this: "PS: Without support contract it looks to me I will not be able to contact support team." With Platinum support in place why even bother with a peer to peer forum that is not actively monitored at all times by MadCap? In fact, I dropped Rob a line pointing him to this post and that got you the prompt response. You are right that your problem is not my emergency, but I made the effort to get you the info you needed. Yet all we get is a 'fix my stuff now or else' response.

[spackiaraj]

With Platinum support in place why even bother with a peer to peer forum that is not actively monitored at all times by MadCap?

my personal opinion is peer-peer developer forum is more helpful then support for non-conventional issues. Easy to point to piece of code where I think the problem originates.

In fact, I dropped Rob a line pointing him to this post and that got you the prompt response. You are right that your problem is not my emergency, but I made the effort to get you the info you needed.

Thanks for the support and help. I really appreciate your time and effort.

[Msquared]

Anyone know if this has been fixed in Flare 10? One of our customers has raised the same concern.

[doc_guy]

I would probably check with MadCap Support to see if they have fixed the vulnerability. I tried to duplicate the problem with the link provided earlier in the thread, and I wasn't able to easily reproduce it, but that doesn't mean the vulnerability is gone or not. It would be nice to get an official statement on the matter.

I am concerned about the vulnerability as well. It seems like it would be trivial to add a pop-up that says, "You're being redirected to a site outside the help system. The site is: <name>. We do not control the security policies or terms of service of the external website. Click OK to continue, or click Cancel to return to the help system."

Not verbatem, but you get the idea.

If the vulnerability is still there, I will agree that I would really like to see a fix for it as the reputation of all of us who use Flare output is at stake. Not to sound all "doom and gloom" but I strongly believe in patching known vulnerabilities, even if they were put there for a good reason. As software developers in general, it is our job to provide the features we want in a way that doesn't compromise other people's security. I'm certain that there is a way to do both.

[Msquared]

I don't think our customer would buy a warning message - I think they would want the action prohibited completely.

I think the issue is that some people need it to work as it is, but others need it to be locked down. Ideally, this could be set on the target, perhaps open by default, but with an option to generate a locked-down version, a bit like you can do with "mark of the web". Another enhancement request coming I think . . .

[Msquared]

I've raised this as a bug - our security experts tell me that the recognised (and safe) behaviour if you need to link externally is to specify a whitelist of allowed addresses/partial addresses. Otherwise, you could still be vulnerable to an injection attack where malicious code takes over part of your site and plants malicious external links that you didn't intend to link to. MadCap's desire to allow external links appears to be a security vulnerability if not controlled.

MadCap think it's a feature request, in fact two feature requests. One feature is to add the ability to say that external links are never required for a target, hence the locked down version of the code is generated. The second is to be able to specify that external links are required, and to specify a list of valid external links, hence a locked down version that allows just those whitelisted links is generated.

So until this is implemented, if at all, we will be joining the list of folks that need to do some post-processing on our output to patch the vulnerability.

[rob hollinger]

Here are the ways to prevent the use of external websites within WebHelp and HTML5 outputs in Flare 10.x
This requires hand patching MadCapDefault.js in both cases. Both Targets MUST have "Condense JavaScript files" disabled. This option is found on the Performance tab of each target type.

In WebHelp:
In the Target/Advanced Tab un-check "Condense JavaScript Files" and build the output.
In the Output folder, browse to the following directory: "MyWebHelp\Content\SkinSupport"
Open the MadCapDefault.js file to around line 140.

Locate and Replace/Comment the following code:

Code: Select all

   if (!startupTopicUrl.IsAbsolute)
       path = MCGlobals.RootFolder  gStartTopic;
   else
       path = gStartTopic;

REPLACE WITH THIS:

Code: Select all

      if (!startupTopicUrl.IsAbsolute)
          path = MCGlobals.RootFolder  gStartTopic;
      else 
          path = MCGlobals.RootFolder;
    

This will prevent any external sites from loading via the CSH call. Nothing will load, but the user can click on the TOC/Index/Ect to gain access to panes. This was sent to MadCap by a user as a possible fix.

In HTML 5
In the Target/Advanced Tab un-check "Condense JavaScript Files" and build the output.
Browse to the following location and file: Resoucres\Scritps\MadCapDefault.js
Locate the following code around Line 995
Locate and Replace/Comment the following code:

Code: Select all

 if (pathUrl.IsAbsolute) {
            //external url support - in case such a url has a query, this will strip off just our query.
            var iq1 = pathUrl.Query.indexOf('?');
            var iq2 = pathUrl.Query.lastIndexOf('?');
            var query = '';
            if (iq1 != iq2) {
                query = pathUrl.Query.substr(iq1, iq2);
            }
            if (pathUrl.FullPath.indexOf("http://") != 0) {
                path = _HelpSystem.ContentFolder + pathUrl.ToNoQuery().FullPath + (MadCap.String.IsNullOrEmpty(query) ? "" : query);
            } else {
                path = pathUrl.ToNoQuery().FullPath + (MadCap.String.IsNullOrEmpty(query) ? "" : query);
            }
        } else
            path = _HelpSystem.ContentFolder + pathUrl.ToNoQuery().FullPath; 

REPLACE WITH THIS:

Code: Select all

  if (pathUrl.IsAbsolute) {
            path = _HelpSystem.DefaultStartTopic;
        } else
            path = _HelpSystem.ContentFolder + pathUrl.ToNoQuery().FullPath;

[RamonS]

Thanks for sharing...but now make it an option in the Flare settings so that folks do not have to tweak the files. Should be easy enough to have two sets of files and pull the necessary one based on option setting.

[Msquared]

I've already got a pending feature request.

[SusanL]

What was the number of your feature request? Did it get fixed in Flare 11? The only vulnerability issue I saw was 56251 in the release notes, but couldn't tell from the cryptic write-up whether that was the same issue as this.

[doc_guy]

Looking at Flare 11 right now. In the HTML5 target, there is a new setting on the Advanced tab that is called "Prevent external URLs from Frames."

That setting is new, and it seems to be directly related to this thread.

Here is the help topic that discusses this feature: http://webhelp.madcapsoftware.com/flare ... rnal%20url

[SusanL]

Thanks for that -- I was able to send the link to the powers that be to expedite getting the new version.