Security issues in Fortify On Demand static code analysis

This forum is for all Flare issues related to the HTML5, WebHelp, WebHelp Plus, and Adobe Air Targets
Post Reply
bobmoon
Sr. Propeller Head
Posts: 259
Joined: Thu Mar 27, 2008 10:22 am
Location: Atlanta

Security issues in Fortify On Demand static code analysis

Post by bobmoon »

We run all of our products through the Fortify on Demand (FOD) static code analysis tool to look for security vulnerabilities. Many of our clients are now doing the same thing with our software solutions.

Flare's HTML5 help has been flagged for several vulnerabilities. I'd be curious if anyone else is experiencing this, and how you are addressing them with FOD or other analysis tools.
  • Version of jQuery - The current 2018 version of Flare includes a version of jQuery in the web output (v 1.12.4) that has known vulnerabilities. This one was found by a client. MadCap Support acknowledged that there is a feature request to upgrade jQuery, and said it was a high priority. In standard practice, they could not provide a date when it would be included in a patch or release. My guess is it will be fixed in the next full release if not sooner.
  • "Sends unvalidated data to a web browser" - Flare targets have an option "Prevent external URLs from frames." This wonderfully-named option is UNSELECTED by default, and it introduces a vulnerability. A malicious Flare author could add a TOC entry to webhelp that appears to open a safe URL (the company website, say), but in reality has a malicious website URL appended (ourhelp.com/index.htm#myhackersite.com). Clicking the TOC entry would take you to the malicious site. SELECTING this option on the target will prevent TOCs or browse sequences from ever opening external web sites. It's explained here.
  • "Interprets unvalidated user input as source code". - This one is more problematic. The flagged vulnerability appears to be the fundamental behavior that enables context sensitive web help. It is considered vulnerable to allow a user to append a value to a URL that will be executed without validation. Flare CSH works through this behavior. You append a topic ID to the help URL (myhelp.com/index_CSH.htm#specifictopic). When you follow that link in the browser, the help site "executes" the URL and the help looks for that topic ID. I can't imagine a way that a hacker could use this. If you put in a value that Flare doesn't recognize, it just ignores it.
ajturnersurrey
Sr. Propeller Head
Posts: 346
Joined: Fri Nov 05, 2010 3:30 am

Re: Security issues in Fortify On Demand static code analysi

Post by ajturnersurrey »

Very interesting - thanks for posting.
Vernholio
Propeller Head
Posts: 12
Joined: Thu Jul 11, 2013 12:01 pm

Re: Security issues in Fortify On Demand static code analysi

Post by Vernholio »

Does anyone know if any headway has been made with this with MadCap? I currently have issues flagged against some of my documentation for these potential security vulnerabilities.

Thanks!
bobmoon
Sr. Propeller Head
Posts: 259
Joined: Thu Mar 27, 2008 10:22 am
Location: Atlanta

Re: Security issues in Fortify On Demand static code analysi

Post by bobmoon »

If you're chasing the same issues as me, I don't have any more information. I don't have any open tickets with them, so I don't expect any more official word from MadCap.

On the issue of the jQuery version, I think we just have to wait and see what's in the next 2018 update.

MadCap's policy is not to comment publicly on what's going to be in the next release, and they don't publish a release schedule. You get an email if they have fixed an issue associated with your support ticket, but otherwise you just have to read the release notes to see what's in there.

For the "Interprets unvalidated user input as source code" issue, it appears to be fundamental to the way webhelp works. I suspect that it would be a significant fix, so might be more than they would tackle in an update.

Bob
Chicago_HPT
Sr. Propeller Head
Posts: 133
Joined: Sun Feb 03, 2013 6:01 pm

Re: Security issues in Fortify On Demand static code analysi

Post by Chicago_HPT »

FOD flagged the jQuery vulnerability for the HTML5 help I'm developing for my client. We're saving page-level context-sensitive help (CSH) for a post-release update but, as indicated above, we'll probably get flagged for that too.

Frak.

I don't have any open tickets with MadCap yet either but, if I do, I'll post any updates here along with everyone else.

Interesting that the current 2018 version of Flare includes jQuery v 1.12.4. The current stable build for jQuery, as I write this, is 3.3.1. I wonder if newer libraries break Flare functions.

Thanks for posting about this, Bob!

-jeff
cfraser
Jr. Propeller Head
Posts: 1
Joined: Mon Oct 22, 2018 3:01 am

Re: Security issues in Fortify On Demand static code analysi

Post by cfraser »

Useful to see others having the same problem - we're also using Fortify and see this issue reported. The dev team had a look at replacing the old file with the latest JQuery but it didn't work cleanly, there must be some incompatibility somewhere in the Flare output.

Will follow this trail to see if anyone finds another workaround.
bobmoon
Sr. Propeller Head
Posts: 259
Joined: Thu Mar 27, 2008 10:22 am
Location: Atlanta

Re: Security issues in Fortify On Demand static code analysi

Post by bobmoon »

One of our Dev groups has provided a solution to the cross-site scripting vulnerability with jQuery 1.12.4 with Ajax. We are implementing it and testing it, but I thought I'd share since several people have reported the same issue.

They provided some jQuery code that should prevent cross-site scripting. I have added that as a custom script to the project, and I added a script reference to the help Master Page to load that script on every page.

I have a script file called jqueryfix.js which I've added to the project in a folder Content\Resources\Scripts. (If you look in your help output, Flare creates its own Scripts folder, but I couldn't find any way to get my custom script to be added there. Thus I added it under the Content\Resources folder since that gets copied directly into the output.)

The content of that file is:

Code: Select all

/*
 * JQuery script to prevent cross-site scripting under JQuery 1.12.4
 */
 	jQuery.ajaxPrefilter( function( s ) {
	if ( s.crossDomain ) {
	s.contents.script = false;
	}
	} );
On the master page (in Content\Resources\MasterPages), I've added the following in the <head> area.

Code: Select all

    <head>	
		<script src="../Scripts/jqueryfix.js">
		</script>	
    </head>
The result is that the script reference is added to every page. Hope that may help, and i'm certainly open to suggestions for improvement.

Bob
Post Reply