Hello @Robert (Community Member)​ ,

Can you please let me know how old the scan that you are referring to? Thank you.

Jason

Community Support Engineer

It can be a scan that was just finished, or any existing scan for that matter.

I have just double-checked it on a Sandbox scan that completed at 05:12 EDT on July 14, 2020 and I get a standard prompt to "Load File" for a file in (customer specific file names masked for privacy reasons) "jsp\WEB_002dINF\jsp\xxxx\xxxxxxxx_jsp.java" (that was for an "older" issue). A newer issue from the same scan has the following path in the prompt (customer specific names masked for privacy): "com\veracode\compiledjsp\xxxxxxxxxx\WEB_002dINF\jsp\xxxxxxxxxx_jsp.java"

Of course, I don't have access to where the analyzer precompiled the JSP files so I cannot provide the source, and when I use locally built ones, the line numbers do not make sense (I'm expecting because the static analyzer doesn't use the same precompiler version or settings as we do locally).

Robert

Hello Robert,

First, I would check the Compilation Guide in our Help Center: https://help.veracode.com/reader/4EKhlLSMHm5jC8P8j3XccQ/UXI5sR0ayWfLm6ifmd4zWw

Veracode wants the source JSP file as we do the compilation on our side when it is upload to the platform. For Java class files, we based the line numbers on the debug information provided to us. Files uploaded are point of time representation of your binary/source that you want to scan. For languages where you provide us the source, we can show that source file in Triage Flaws if it is within 30 days or so from when the scan is completed. For binaries, you would have to load that point in time reference of your source code to view to correlate the findings source/line number provided by the scanner.

I would also suggest that you try using our Pipeline Scan: https://help.veracode.com/reader/tS9CaFwL4_lbIEWWomsJoA/ovfZGgu96UINQxIuTqRDwg

Jason

Community Support Engineer

Jason,

Maybe the details of how JSP compilation work are not clear. I'll try to explain in hopes that it becomes more clear.

The WAR file contains the source JSP files. When a Servlet container (web server supporting Java Servlet Pages, such as Apache Tomcat) uses a JSP file, it first "compiles" the JSP file into a Java source file (*_jsp.java). This is done based on settings in the web.xml file and based on the configurations of the web server. This Java source file is then compiled using the Java compiler to a Java class file (*_jsp.class). Both the .class and .java files are stored in a temporary location by the web server. In the case of Apache Tomcat, this is in work/Catalina/localhost/<application_context>/org/apache/jsp.

Here's a listing from a local Tomcat instance for our application:

$ ls -l server_data/tomcat/work/Catalina/localhost/xxxxxxx/org/apache/jsp/

total 448

-rw-r----- 1 rturner staff  45955 27 Jun 22:01 Login_jsp.class

-rw-r----- 1 rturner staff 110832 27 Jun 22:01 Login_jsp.java

-rw-r----- 1 rturner staff  21593 26 Mar 09:08 Logout_jsp.class

-rw-r----- 1 rturner staff  37781 26 Mar 09:08 Logout_jsp.java

drwxr-x--- 3 rturner staff   96 9 Jul 00:17 WEB_002dINF/

drwxr-x--- 3 rturner staff   96 9 Jul 00:17 tag/

In order for the Veracode static analyzer to look for flaws in the JSP "code", what it does is precompile these files using a local JSP and Java compiler (as the source files are not put in the WAR file -- although sometimes one can include the _jsp.class files, but the _jsp.java files are usually not). Then, from there, the static analyzer performs its usual analysis of the Java .class file, then "reverse tracks" the line numbers from the debug information in the .class file back to the _jsp.java file, and then when possible (as it seems it isn't always, or it's not working properly), uses the JSP lines numbers that are emitted as comments into the generated _jsp.java file to try to generate line numbers for the JSP file.

The problem is that different JSP compilers generate different _jsp.java files, and Veracode does not publish the precise details of how those _jsp.java files are created, and thus as a user, one cannot recreate them in the same way. Moreover, the Veracode static analyzer (as documented) uses a fixed version of Java (1.7) instead of the once specified in the web.xml file as part of the Servlet standard, and thus fails to compile 1.8 (or later) syntax, requiring any scriptlets to be forced back to 1.7 even though the application is using (and specifies) a later version of Java.

However, since the static analyzer has those files as part of the analysis process, the "triage flaws" UI could pull those files from the Veracode server (as it does for the JSP files) to make things easier for people.

The Compilation Guide does not properly address this aspect of the problem. The section entitled "JSP Files" discussed how it's compiled (and that it explicitly does not use anything precompiled from the WAR file), and what it doesn't do, but doesn't address the issue of the source generated during the compilation process, or how to recreate that source (in a precise way).

I believe this is an issue that needs to be taken to the development team as it's not something that as far as I can tell is currently documented or supported.

Hope that helps,

Thanks,

Robert

FYI, the outcome of the Consultation call was that there is no current way to get the source from the system, so one needs to schedule a consultation call so the Consultant can look up the "data model" and help you locate the offending code.

In our case, all 3 occurrences look like false positives being triggered by something else we are seeing in JSP files elsewhere as well (ones we can reference).

I suspect since this doesn't seem to be a general problem, this will be the only outcome of this limitation as JSP files aren't as common in new development, and in most cases the analyzer can backtrack the line numbers to the JSP file.