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.
Related
Creating a docker image with gradle 7.4.1 triggers the security scan which shows vulnerability CVE-2020-36518. How can this particular jar file within the gradle package be updated?
I would just reject the security issue, explaining that it is not possible to exploit the vulnerability as the Gradle build runs isolated on controlled input, and is not accessible by any potential attackers.
(Assuming this is the case, of cause, and you don't have a custom Gradle plugin that reads untrusted JSON documents using Jackson from the Gradle classpath. But even then, all you are risking is a denial-of-service on the build.)
Fiddling around with jar files in external tools could easily lead to problems hard to debug later. But if you like, you could create an issue for them, asking if they could bump the Jackson version to avoid unnecessary noise from security scans like this. There is an example of that here.
i recently built an electron app using node js , html ,css , js
and have been wanting to compile it ive npm installed all options ifound (packager,build,forge) but npm says all have security issues is there asecure way to compile? (compile for windows)
most of the security vulnerabilities are mostly in "build" packages, things that are run during compile time only, and not when the electron/nodejs app is in use, only when it's built/minified/etc, but they are not included in the final product.
Then also are most of those security vulnerabilities usually highly hypothetical, with a high threshold of prerequisites for the weakness to occur.
If you wish to be certain, read the security risk descriptions, what is required, and evaluate if it applies to your system, if it's in a build time package, or a runtime package, and what kind of vulnerability it represents.
if there is a vulnerability in a package that gets included in the app, and it is one that you need to fix because it would pose a serious threat to your end users, check the repository for the package, to see if someone already submitted a pull request for a fix that hasn't made it to the main branch, and merge that into your version that you use.
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).
I want to know the differences between npm and maven respository
Same tool, different language?
Maven is the most popular build and dependency resolution tool for Java, just like NPM is for JS. But it's not just the same tool for a different language. There are obviously huge differences between Java and JS builds, and these differences are directly visible in the way Maven operates. For example, while many JS tools rely on Git to do some heavy-lifting, Maven works with custom filesystem-based Maven repositories, as Maven predates Git and needs to handle binary artifacts, which Git historically didn't handle well. In Maven there's a clear separation between sources and binaries, while they are often the same thing in JS world.
Maven basics
Maven in its purest form follows a declarative model, where pom.xml (similar to package.json) defines different properties of the build, but contains no scripts. The disadvantage is it can be a challenge to fine-tune some aspects of the build without using scripts as you have to rely on plugins. The advantage is it can be easier to understand other builds just by looking at pom.xml, as they usually follow the same approach without too much customization. Gradle is a popular Groovy-based tool built on top of Maven standards and conventions, and is specifically designed to simplify pom.xml and break this "no script" barrier.
Referencing your dependencies
Similarly to package.json, you don't work with pom.xml of your dependency directly, but rather define dependency coordinates and let your build tool handle the rest. In Maven the basic form of these coordinates is GAV (groupId, artifactId, version).
Flat dependency tree?
Based on comments in the other answer, Maven provides "flat dependency tree", not "nested dependency tree" that NPM provides by default. Maven does not allow multiple versions of the same dependency. If it happens that different versions are requested, Maven uses dependency resolution to pick a single version. This means that sometimes your transitive dependencies will get a different version than they require, but there are ways to manage this. However, this limitation comes from Java, not Maven, as (normally) in Java a class loader will only provide access to a single class definition even if multiple definitions are found on the classpath. Since Java is not particularly good at handling this, Maven tries to avoid this scenario in the first place.
Note: since npm v3 the dependencies are flatten. The alternative package manager yarn also does the same.
Maturity
Furthermore, Maven is considerably older than NPM, has a larger user base, huge number of custom plugins, and so far could probably be considered more mature overall. Sometimes Maven is used for non-Java or even polyglot projects, as there are plugins for handling other languages or specific environments, such as Android. There are plugins that bridge Maven and other build tools, such as frontend-maven-plugin that actually handles multiple JS build tools.
NPM is focused on JavaScript while Maven is focused on Java and JVM derived (that is Scala, Kotlin, Groovy).
So comparing them doesn't make sense at all as these are not concurrent.
While comparing Maven to Gradle (Java world concurrent) or NPM to Yarn (JavaScript world concurrent) makes more sense.
Now Maven and NPM have closed features. Which is not surprising : good recipes spread beyond a language.
Here are some common points/features:
- these are package(JavaScript term)/ dependency (Maven term) managers that works with local/remote repositories.
- these are also a way to manage dependencies in your projects and to execute build tasks for them.
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.