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

Security issues in Fortify On Demand static code analysis

Postby bobmoon on Thu Jul 05, 2018 11:09 am

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.
bobmoon
Sr. Propeller Head
 
Posts: 256
Joined: Thu Mar 27, 2008 10:22 am
Location: Atlanta

Re: Security issues in Fortify On Demand static code analysi

Postby ajturnersurrey on Fri Jul 06, 2018 6:20 am

Very interesting - thanks for posting.
ajturnersurrey
Sr. Propeller Head
 
Posts: 314
Joined: Fri Nov 05, 2010 3:30 am

Re: Security issues in Fortify On Demand static code analysi

Postby Vernholio on Mon Jul 16, 2018 8:54 am

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!
Vernholio
Propeller Head
 
Posts: 12
Joined: Thu Jul 11, 2013 12:01 pm

Re: Security issues in Fortify On Demand static code analysi

Postby bobmoon on Mon Jul 16, 2018 9:43 am

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
bobmoon
Sr. Propeller Head
 
Posts: 256
Joined: Thu Mar 27, 2008 10:22 am
Location: Atlanta

Re: Security issues in Fortify On Demand static code analysi

Postby Chicago_HPT on Tue Sep 25, 2018 11:43 am

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
Chicago_HPT
Propeller Head
 
Posts: 42
Joined: Sun Feb 03, 2013 6:01 pm

Re: Security issues in Fortify On Demand static code analysi

Postby cfraser on Mon Oct 22, 2018 9:38 am

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.
cfraser
Jr. Propeller Head
 
Posts: 1
Joined: Mon Oct 22, 2018 3:01 am

Re: Security issues in Fortify On Demand static code analysi

Postby bobmoon on Fri Oct 26, 2018 10:52 am

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
bobmoon
Sr. Propeller Head
 
Posts: 256
Joined: Thu Mar 27, 2008 10:22 am
Location: Atlanta


Return to Web-based Outputs

Who is online

Users browsing this forum: No registered users and 1 guest