How to find security vulnerabilities in JAVA application libraries using Dependency Check

A web-application is never finished. Even when no new features are being developed new vulnerabilities may be found in the frameworks used in the application requiring a patch or an upgrade.Java is a very popular programming language. Two key reasons for its popularity are security and the availability of a huge ecosystem of libraries and components. Since most Java applications make use of a wide range of libraries, which in turn have dependencies on other libraries, it is difficult to ensure the integrity of these applications from a security perspective.

The OWASP Top 10 represents a broad consensus on the most critical web application security flaws.They are dangerous because they will frequently allow attackers to completely take over your software, steal data, or prevent your software from working at all

those are :

1. Injection : Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. Injection flaws are easy to discover when examining code, but frequently hard to discover via testing. Scanners and fuzzers can help attackers find injection flaws.

2. Broken Authentication and Session Management (XSS) : Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.

3. Cross Site Scripting (XSS) : XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are two different types of XSS flaws: 1) Stored and 2)Reflected, and each of these can occur on the a) Serveror b) on the Client.

Detection of most Server XSS flaws is fairly easy via testing or code analysis. Client XSS is very difficult to identify.

4. Insecure Direct Object References : Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified.

5. Security Misconfiguration : Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.

6. Sensitive Data Exposure : The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm usage is common, particularly weak password hashing techniques. Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale. External attackers have difficulty detecting server side flaws due to limited access and they are also usually hard to exploit.

7. Missing Function Level Access Control : Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget.

Detecting such flaws is easy. The hardest part is identifying which pages (URLs) or functions exist to attack

8. Cross Site Request Forgery (CSRF) : CSRF takes advantage the fact that most web apps allow attackers to predict all the details of a particular action.

Because browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones.

Detection of CSRF flaws is fairly easy via penetration testing or code analysis. 

9. Using Components with Known Vulnerabilities : Virtually every application has these issues because most development teams don’t focus on ensuring their components/libraries are up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse.

10. Unvalidated Redirects and Forwards : Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page.

Detecting unchecked redirects is easy. Look for redirects where you can set the full URL. Unchecked forwards are harder, because they target internal pages.

Now we will see how to find out security vulnerabilities in JAVA application libraries using Dependency Check,

dependency-check-ant is an Ant Task that uses dependency-check-core to detect publicly disclosed vulnerabilities associated with the project's dependencies. The task will generate a report listing the dependency, any identified Common Platform Enumeration (CPE) identifiers, and the associated Common Vulnerability and Exposure (CVE) entries.

Currently Java and .NET dependencies are supported. support for Node.JS, client side JavaScript libraries, etc. is planned.

Steps to follow :

Step 1 : Download dependency-check-ant from bintray here

Step 2 : To install dependency-check-ant place the dependency-check-ant-1.2.6.jar into the lib directory of your Ant instalation directory. Once installed you can add the taskdef to you build.xml and add the task to a new or existing target:

<'taskdef name="dependency-check" classname="org.owasp.dependencycheck.taskdefs.DependencyCheckTask"/'>
<'taskdef name="dependency-check" classname="org.owasp.dependencycheck.taskdefs.DependencyCheckTask"'>
<'classpath path="[path]/[to]/dependency-check-ant-x.x.x.jar"/'>
<'/taskdef'>

Step 3 : If you do not want to install dependency-check-ant into your ant’s lib directory when you define the task def you must add the classpath to the taskdef:

Step 4 : If you are behind proxy set proxy settings in you ant script as :

<'setproxy proxyhost="proxyIP/IURL" proxyport="proxyPort" /'>

That's it run you script to get the report

It is important to understand that the first time this task is executed it may take 20 minutes or more as it downloads and processes the data from the National Vulnerability Database (NVD) hosted by NIST: https://nvd.nist.gov

Source : www.owasp.org