Hi. Veracode is a platform that performs dynamic and static security scans of code for various platforms. I’m trying to adapt the ColdFusion instructions (see link below) to my Lucee code and have a few questions.
Basically, they need a WAR file of the compiled code uploaded. I know I can use jar -cvf myfilename.war * to package up the .class files , located in WEBROOT/WEB-INF/lucee/cfclasses
My question is, where should I look to get the Lucee application server classes as I’d like to include those in the scan.
V.Likely
80
Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
3/22/2019 1:20 PM EDT myapp.war/bundle.jar
TemporaryStream.java: 80 5 Paths New None
Attack Vector: java.io.DataOutput.write
Number of Modules Affected: 1
Description: This call to java.io.DataOutput.write() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to write() contains tainted data from the variable os.toByteArray(). The tainted data originated from earlier calls to java.net.URL.openStream, javax.servlet.ServletRequest.getInputStream, java.net.URLConnection.getContent, and java.lang.ClassLoader.getResourceAsStream.
Remediation: Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible.
References: CWE OWASP WASC Supported Cleansers
690
Likely
117 Improper Output Neutralization for Logs
3/22/2019 1:20 PM EDT myapp.war/bundle.jar
LogAdapter.java: 45 1 Path New None
Attack Vector: org.apache.log4j.Category.log
Number of Modules Affected: 1
Description: This call to org.apache.log4j.Category.log() could result in a log forging attack. Writing untrusted data into a log file allows an attacker to forge log entries or inject malicious content into log files. Corrupted log files can be used to cover an attacker's tracks or as a delivery mechanism for an attack on a log viewing or processing utility. For example, if a web administrator uses a browser-based utility to review logs, a cross-site scripting attack might be possible. The third argument to log() contains tainted data from the variable t. The tainted data originated from earlier calls to javax.servlet.http.HttpServletRequest.getHeaders, and javax.servlet.ServletRequest.getParameterValues.
Remediation: Avoid directly embedding user input in log files when possible. Sanitize untrusted data used to construct log entries by using a safe logging mechanism such as the OWASP ESAPI Logger, which will automatically remove unexpected carriage returns and line feeds and can be configured to use HTML entity encoding for non-alphanumeric data. Alternatively, some of the XSS escaping functions from the OWASP Java Encoder project will also sanitize CRLF sequences. Only write custom blacklisting code when absolutely necessary. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible.
References: CWE OWASP WASC Supported Cleansers
Recommended eLearning Courses: AppSec Tutorials - CRLF Injection
whatever you analyze it is not the lucee code itself, most likely you analyze 3 party libs bundled with lucee.
nowhere in the Lucee code “java.io.DataOutput” is used.
to analyze the lucee code, analyze the lucee.jar itself.
the .lco file(s) you find at “/lucee-server/patches” (it is a jar file) that is the lucee core
and the jars at “/lucee-server/bundles”, this are the 3 party libs used by lucee.
have in mind that Lucee loads it’s core and all 3 party bundles via OSGi, that means the loaded classes are NOT visible to any other classloader, only a single classloader loaded inside the CFMLEngineFactory. So even a 3 party lib has a security flaw, it is not that big of an issue because that lib is invisible to the rest of the JVM.
Thanks for the info.
So I uploaded lucee.jar instead (had to rename it to .war) and this time it gave me the following high risk issue…
746
Likely
80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
3/22/2019 9:02 PM EDT lucee-5.3.1.95.war BundleCache.java: 554 1 Path New None
Attack Vector: java.io.OutputStream.write
Number of Modules Affected: 1
Description: This call to java.io.OutputStream.write() contains a cross-site scripting (XSS) flaw. The application populates the HTTP response with untrusted input, allowing an attacker to embed malicious content, such as Javascript code, which will be executed in the context of the victim's browser. XSS vulnerabilities are commonly exploited to steal or manipulate cookies, modify presentation of content, and compromise confidential information, with new attack vectors being discovered on a regular basis. The first argument to write() contains tainted data from the variable bytes. The tainted data originated from earlier calls to java.net.URLConnection.getContent, and java.net.URLConnection.getInputStream.
Remediation: Use contextual escaping on all untrusted data before using it to construct any portion of an HTTP response. The escaping method should be chosen based on the specific use case of the untrusted data, otherwise it may not protect fully against the attack. For example, if the data is being written to the body of an HTML page, use HTML entity escaping; if the data is being written to an attribute, use attribute escaping; etc. Both the OWASP Java Encoder library and the Microsoft AntiXSS library provide contextual escaping methods. For more details on contextual escaping, see https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet. In addition, as a best practice, always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible.
If veracode requires a war, you can’t just rename a jar to a war and have it be the same thing. Download the actual war download from the Lucee download page. A war is a zip with a web-inf containing classes or libs (jars).
Lucee does have a class named BundleCache.java but it sounds like it’s part of Felix, a 3rd party library. In fact, here’s the line
I had tried performing the analysis with the .war but when I do that, it says it can’t find the lucee runtime for my app. Basically, I’m uploading the lucee.war file downloaded from download page, and a second .war for my app (created by zipping up the directories in the /cfclasses folder).
I guess the best way to rephrase the question…how would I create a standalone .war file for my app that would be self running when deployed as a Tomcat servlet?
Download the war from the Lucee download page, unzip it and replace the index.cfm with your app’s code in the root and rezip it and rename it back to .war. That’s all a war is.
Unless the Veracode scanner actually sends HTTP requests to your app, it’s not actually going to run any of your CF code most likely so I don’t know know how any of that would work. Veracode’s Java war scanning probably doesn’t really take a dynamic JIT compiled language running as an app inside a servlet (like CFML) into account.
It is a static scan of the code, but needs compiled classes to work. It can’t work on the source code. The CF instructions are at https://help.veracode.com/reader/4EKhlLSMHm5jC8P8j3XccQ/MoL6VpMG2Mqs6~PDdN5gnQ . It says to use cfcompile to compile the code and then package using Packaging and Deployment > J2EE Archives.
Where would I place the cfclasses/*.class files relative to index.cfm? Same directory structure as original source files?
Ahh yes, I remember that. So, cfcompile is specific to Adobe ColdFusion. Lucee has never had a compile command. You can hit all the pages in your site to seed the cfclasses folder but unless Veracode has told you they support Lucee, I’d bet there’s a really good chance their CF support is specific to Adobe ColdFusion, where it puts the files, and the name of its bootstrap classes. The cfclasses folder goes inside the web context folder, which in a war would most likely be /web-inf/lucee/cfclasses
Like @bdw429s writes it is hard to say without more input.
The classes in the cfclasses folder contain bytecode we generate that in most cases NOT can be “decompiled” to java source code. This is not by accident, we actually spend a lot of time to write our bytecode in a form that cannot simply be decompiled.
I’m not sure if that will influences this tool, but if it works by “decompile” the compiled classes, it will most likely fail.
In addition we use OSGi, as i pointed out, so the Lucee core and all 3 party libs are NOT part the the classpath or any visible classloader, we actually had to change the structure if Lucee 5 to avoid that accidentally this jars are loaded publicly. So when you simply embed this jars (bundles) in this tool, it would also be incorrect, it would suggest that they are visible to the “outside world”.
what is “visible” is the lucee.jar, nothing else.
Hmm this is going to be a problem on my side. I’ll keep looking around , but seems there’s no solution as of yet on how to package it up into a war to have it scan.
I’ll see if i can get any information from Veracode as well… I’m sure they’ve had this question from someone at some point.
You could try following the packaging instructions for Cold Fusion in the Help Centre (https://help.veracode.com/reader/4EKhlLSMHm5jC8P8j3XccQ/MoL6VpMG2Mqs6~PDdN5gnQ) and package the application as a WAR file as you suggested, however please note that we do not support Lucee and so your mileage may vary. Please be mindful that since we do not support Lucee there could be flaws we will not find, however if the scan is successful and actionable some flaws are found, then that would be better than not scanning at all.
If you feel others would benefit from Veracode supporting Lucee you may wish to submit an idea here: https://community.veracode.com/s/ideas. By submitting an idea you can track it’s progress as we consider it for inclusion in the platform and other community members can vote for the idea to give it greater priority.
