Apache Camel prior to 2.24.0 contains an XML external entity injection (XXE) vulnerability (CWE-611) due to using an outdated vulnerable JSON-lib library. This affects only the camel-xmljson component, which was removed.
This description specifically mentioned the camel-xmljson component. Our organization uses automated scanning tools to detect vulnerabilities in open source libraries -- it is currently flagging all application with Apache Camel dependencies < 2.24.0 including the applications that do not contain any version of camel-xmljson. I'm trying to determine if that is the correct exposure. Is there any exposure to the XXE attack if the application is not including camel-xmljson.
No exposure at all, its only if you use the camel-xmljson component, where that 3rd library JAR has the security vulnerability (eg its not really Camel but the 3rd party JAR itself).
Related
I have an application, which needs to be tested using in-house developed python automation. Originally, the application was developed using Swagger 2.x spec. Now it is migrated to use Open API 3.x
When it was on Swagger 2.x spec, I used to use swagger-codegen-cli-2.4.21.jar to generate the python client libraries, which we eventually consumed to write our automation. With the 2.4.21 jar we could disable the client side validation (configuration.py)
But after moving to OpenAPI 3.x, I am not able to use 2.4.21 jar because its not supported. So I used 3.0.36 jar to generate the python client libraries. But this doesn't have the option to disable the client side validation (in configuration.py). This is actually creating lot of problems because we are getting ValueErrors during GET calls.
I see that there are some discussions happened on the same, but none of them are conclusive enough that it is actually fixed in 3.x
https://github.com/OpenAPITools/openapi-generator/pull/4137
https://github.com/swagger-api/swagger-codegen/issues/5530
https://github.com/swagger-api/swagger-codegen/pull/9717
So I need help to understand whether this is still a open issue (or) it is fixed in some 3.x release..? If its not fixed yet, is there a workaround to overcome this issue..?
As of now, we are commenting all the ValueErrors to get around the issue, but this is not recommended because we lose the validation capability during POST calls.
On python-nextgen (latest Python generator) it is not implemented (you can indicate which type of validation can be skipped using disabled_client_side_validations when creating the configuration object, maybe works for you?).
The configuration object also includes a property client_side_validation which seems to be intended for this purpose but at the moment there is no implementation.
The only option at the moment is to keep it or remove it for all operations.
When running OWASP dependency check I am getting following issue reported (vulnerable dependency)
CWE: CVE-2010-1807
CWE-20 Improper Input Validation
Severity (CVSS): High (9.3)
Dependency: android-json-0.0.20131108.vaadin1.jar
I am using Spring Boot 1.5.3.
Doing gradlew dependencies I see that android-json is indeed dependency of Spring Boot
+--- org.springframework.boot:spring-boot-configuration-processor: -> 1.5.3.RELEASE
| \--- com.vaadin.external.google:android-json:0.0.20131108.vaadin1
How to check if this is false-positive or valid issue?
edit: this dependency is not used in runtime. it is used only in tests.
If the dependency is only used in tests, then it should be fine. Tests, almost by definition, don't use user input, and are not typically available to be run in a production environment. Therefore, a vulnerability in a test, or in a dependency of a test, isn't really a concern. I would reach out to the Spring Boot developers to ask why they have a potentially vulnerable library as a dependency, or look on their GitHub issues.
The issue is a false positive.
As described in the CVE, the vulnerability is in Apple's WebKit that was used in Android before 2.2:
WebKit in Apple Safari 4.x before 4.1.2 and 5.x before 5.0.2; Android before 2.2; and webkitgtk before 1.2.6; does not properly validate floating-point data, which allows remote attackers to execute arbitrary code or cause a denial of service (application crash) via a crafted HTML document, related to non-standard NaN representation.
It would appear that the OWASP dependency check as incorrectly identified android-json-0.0.20131108.vaadin1.jar as being part of Android. In reality the jar is a clean room implementation of org.json:json that has nothing to do with Android other than originally being developed by the Android team. It certainly doesn't contain WebKit.
I am looking for a solution to implement security-scanning of the application code-base at the time of a build. The idea is to capture a list of security vulnerabilities early in the software development life cycle.
I have a simple java project which uses a maven build. The java project specifies a number of .jar dependencies and comes up with a .war file as a build output.
I came across (and was able to configure) the dependency-check maven plugin (http://jeremylong.github.io/DependencyCheck/dependency-check-maven/index.html). However, though it scans the dependency jars and comes up with a vulnerability report, it doesn't seem to scan the final artifact - which in my case is the .war file.
How do I ensure that the .war is scanned as well? Is the dependency-check plugin the right tool for this?
dependency-check isn't the right tool for checking your own code. It uses a list of known vulnerability reports to determine if any of your dependancies have known flaws. It does not do an active scan of the code. see Plugin wiki
For checking your own code, HP's Fortify is a decent commercial solution, but if you are working in more of a DIY software setting, I would recommend Sonar. There are certainly many static code analysis tools out there. All have advantages and disadvantages.
I've got a large code base that currently runs on JSF 1.1 on embedded Jetty 5.1.14 server (Servlet 2.4). I've managed to get a JSF 2.0.9 app running on this version of Jetty even though I'd expected to require servlet 2.5, and I add EL 2.1.2 & the JSF jar to WEB-INF/lib. This works on a jetty config that excludes JSF 1.1.
The production environment consists of a large number of war and jar files on a single server instance.
JSF 1.1 is currently in the server ext/lib folder, and in a single war file I'd like to include the JSF 2 jar in the WEB-INF/lib. This is not possible as the server JSF version will load first and cause classpath pollution.
However would it be possible to eliminate the JSF 1.1 jar loading in just the one war file with a custom classloader? The documentation seems to cater for the case of adding paths to the classpath rather than excluding things. I wasn't clear whether it's loaded in the context of the server as a whole or just the war.
A little more information: Another potential solution is to simply upgrade to Jetty 8 and JSF 2.1+. Apart from convincing management that this is a good idea, we use an old WebMethods7 version, this has a graphical layout tool that produces some XML that is translated by a Component Application Framework, which uses the JSF APIs to generate content (so only a very few JSPs). This would simply be a case of seeing if it works, and if not having a total rethink because of the need to keep supporting this WebMethods "code".
The main goal here is to ultimately run up to date software although not necessarily in one step.
Jetty5 is incredibly old at this point and I would recommend working on the update to jetty8, or waiting a couple of months and making the jump to jetty9 which we are currently releasing milestones for. Changes in the newer jvm's since then alone are enough reason to update your jetty container.
I don't know if this approach was supported in jetty5 or not, but in jetty6 we have ability on the webapp context to modify the classes that are exposed to the context via system and server classes. If those hooks exists then you should be able to tweak that specific context to not expose the classes in the jar in ext/lib.
Related to Access restriction on class due to restriction on required library rt.jar? jaxb-impl has many classes that are provided by rt.jar, which is the reason behind the warning.
I generated my web service from a WSDL file.
If I'm meant to exclude jaxb-impl in order to get rid of the warning, what is it for then?
Which are the libraries I really need to keep for my web service to run, and which were only useful for generating the code related to it?
jaxb-impl is the JAXB implementation that CXF will use by default. In most cases, you can remove it at runtime (not at wsdl2java time though) and CXF will be ok. However, the jaxb-impl that CXF pulls in is generally newer than the versions found in the JDK and usually has several bugs fixed that would still be present in the in-JDK versions of JAXB. CXF and CXF users tend to stress JAXB pretty hard and find interesting issues that we log with them and eventually get fixed.