1

I have this .bat file which scans one of mine applications at work.

I'm comparing two ways I've generated the .fpr file:

  • Using Scan Wizard
  • Using the HP Fortify Plugin for Visual Studio.

What is happening is that when the .fpr file is generated by Scan Wizard's .bat file it seems to ignore completely all my .aspx, aspx.cs and .cs files inside the application .

My app is an old Web Forms, which in order to publish it, we need to select that precompiled option in Visual Studio.

I've already tried Eric's solution in the post. HP Fortify scans get ASP Pre-Compilation error

But still nothing.

I've already tryed to generate the bat file before and after the publish, but both returned the same number of vulnerabilities. Something around 15. After the publish it generates dll's to all pages though, which means that theorically it should detect all the application code.

In the other hand, when I've generated the .fpr file through the Visual Studio plugin, it returns me about 600 vulnerabilities.

My real problem is that we need to run over the .bat file, not the Visual Studio, because we have a continuous integration process, in which we build the app, run code analyze and then the HP Fortify to complete the process, so I need that the number of vulnerabilities returned running the plugin to be the same one when I run with the .bat file.

Any help would be very appreciated.

Thank you for your time !

Community
  • 1
  • 1
Elek Guidolin
  • 487
  • 1
  • 8
  • 21

1 Answers1

2

There are several different options you can do.

1) Have Visual Studio installed on the CI machine with the Fortify Plugin installed. Here is a sample batch file that I used to scan WebGoat.Net using Visual Studio

sourceanalyzer -b test -clean

sourceanalyzer -b test -Xmx6G -verbose -debug -logfile vs_translate.txt "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe" NewWebForms.sln /REBUILD Debug

sourceanalyzer -b test -show-files > vs_files.txt

sourceanalyzer -b test -show-build-warnings > vs_warnings.txt

sourceanalyzer -b test -verbose -debug -logfile vs_scanlog.txt -scan -f vs_scan.fpr

fprutility -information -categoryIssueCounts -project vs_scan.fpr

2) With the latest version of Fortify (16.20) you can scan .Net code directly. Here is the batch file I created to scan WebGoat.Net

sourceanalyzer -b test -clean

sourceanalyzer -b test -dotnet-version 4.5.2 -cs-extern-alias "global=C:\Samples\NewWebForms\packages\Microsoft.AspNet.Identity.EntityFramework.2.2.1\lib\net45\Microsoft.AspNet.Identity.EntityFramework.dll;global=C:\Samples\NewWebForms\packages\Microsoft.AspNet.Identity.Core.2.2.1\lib\net45\Microsoft.AspNet.Identity.Core.dll;global=C:\Samples\NewWebForms\packages\Microsoft.AspNet.Identity.Owin.2.2.1\lib\net45\Microsoft.AspNet.Identity.Owin.dll;global=C:\Samples\NewWebForms\packages\Microsoft.Owin.3.0.1\lib\net45\Microsoft.Owin.dll" -dotnetwebroot NewWebForms\ -libdirs packages\**/*.dll;NewWebForms\bin\*.dll NewWebForms\**/*

sourceanalyzer -b test -show-files > cmd_files.txt

sourceanalyzer -b test -show-build-warnings > cmd_warnings.txt

sourceanalyzer -b test -Xmx6G -verbose -debug -logfile cmd_scanlog.txt -scan -f cmd_scan.fpr

fprutility -information -categoryIssueCounts -project cmd_scan.fpr

3) If you want, you can also scan the compile .dll's of your project. Here is what I did to scan WebGoat.Net

sourceanalyzer -b test -Xmx8G -vsversion 14.0 
               @excludelist.txt 
               -Dcom.fortify.sca.SourceFiles=WebGoat.NET\WebGoat 
               -libdirs WebGoat.NET\WebGoat\bin WebGoat.NET\**/*.dll
               WebGoat.NET/**/*

For a more detailed look at this, take a look at my answer over at Fortify to scan 3rd party dll's

Community
  • 1
  • 1
SBurris
  • 7,378
  • 5
  • 28
  • 36
  • When I try scanning WebGoat.Net using option No.2 in your answer, the third party .dlls are not picked up using the wildcard. Any ideas why this might be? I notice in your answer you use a forward slash `-libdirs packages\**/*.dll;`, is this necessary? – hamo Feb 18 '17 at 21:49
  • The forward slash is on old habit, it use to matter, just tested and looks like forward or backwards works now. Why do you think it hasn't picked up your third party dll? Can your question with the command you ran? – SBurris Feb 18 '17 at 22:18
  • When I check fpr in AWB after scanning using wildcard, the third party libs are not listed, if I specify them individually, they are. – hamo Feb 18 '17 at 22:39
  • Sorry, I don't have command atm, I was running it in work. Command was same as yours except I didn't use the `-cs-extern-alias` flag. – hamo Feb 18 '17 at 22:44
  • Following is the command I use `sourceanalyzer -b test -dotnet-version 4.5.2 -dotnetwebroot C:\projects\WebGoat\ -libdirs C:\projects\WebGoat\packages\**\*.dll;C:\projects\WebGoat\bin\*.dll C:\projects\WebGoat\**\*` If I add paths to the directory the dll's are in or the path to each individual dll, it works but the wildcards in the above command do not work. Any idea why? Any help much appreciated. – hamo Feb 20 '17 at 19:32
  • Thank You for your answer @SBurris, but even creating the script as you said in item 2, it still ignoring the dlls generated by the publish. Do you know any other way I can include those dlls? – Elek Guidolin Mar 20 '17 at 21:30