How a jar can propagate a vulnerability in a web application where it is used?

Question

I have a Spring MVC web application protected with Spring Security. Life seems so calm until I was forced to do a Static Application Security Testing (SAST) and the tool threw a bunch of security issues. Have a look at here:

I have gone through all CVEs and got a rough picture about the vulnerabilities. I have a few queries:

1. How a web application is vulnerable to such exploitation, when a security framework like (Spring Security) is integrated with it?

2. Can I ignore all those vulnerabilities since Spring Security might have some sort of workaround for all those vulnerabilities?

Answer 1

From the Spring Security manual:

Spring Security is a powerful and highly customizable authentication and access-control framework. It is the de-facto standard for securing Spring-based applications.

Think of spring security as an authentication framework, it covers one piece of the security puzzle.

As an example, let's have a look at the #1 of the OWASP Top 10 Application Security Risks: A1 - Injection
Assume you use a jar for accessing an SQL database (e.g. hibernate) and it has an injection vulnerability, then your application could be vulnerable as well. However even if hibernate doesn't have any security bugs, if a programmer concatenates an SQL query together without correctly escaping the user input the application is vulnerable to an injection attack.
Spring security doesn't protect your application from either of these injection attacks.

If a jar has a vulnerability and you are calling the vulnerable methods/features then your app may also have that vulnerability, it depends a lot on what the vulnerability is and how its executed and how your application is configured to use the jar.

For a quick look over the other OWASP Top 10 Application Security Risks:
A1-Injection - No protection from Spring Security
A2-Broken Authentication and Session Management - Spring Security can help manage some of these, however a miss configured spring security will expose these.
A3-Cross-Site Scripting (XSS) - No protection from Spring Security
A4-Insecure Direct Object References - No added protection from Spring Security (Spring Security gives you the tool to manage this)
A5-Security Misconfiguration - No protection from Spring Security
A6-Sensitive Data Exposure - Spring Security can assist with this however it also depends a lot on how you store and manage your data (E.g. log files)
A7-Missing Function Level Access Control - If the access control has been missed, Spring Security can't help you, however spring security makes it easy to add these
A8-Cross-Site Request Forgery (CSRF) - Spring Security (depending on how your application is configured) will assist you or even manage this risk for you.
A9-Using Components with Known Vulnerabilities - This is the CVE's you have listed in your question - No protection from Spring Security
A10-Unvalidated Redirects and Forwards - Spring Security could be used to manage this however it doesn't protect your application from this out of the box

The list of CVEs found during the STAT of your application is an example of A9-Using Components with Known Vulnerabilities have a look at the OWASP wiki for more information.

Example Attack Scenarios

Component vulnerabilities can cause almost any type of risk imaginable, ranging from the trivial to sophisticated malware designed to target a specific organization. Components almost always run with the full privilege of the application, so flaws in any component can be serious, The following two vulnerable components were downloaded 22m times in 2011.

• Apache CXF Authentication Bypass – By failing to provide an identity token, attackers could invoke any web service with full permission. (Apache CXF is a services framework, not to be confused with the Apache Application Server.)
• Spring Remote Code Execution – Abuse of the Expression Language implementation in Spring allowed attackers to execute arbitrary code, effectively taking over the server.

Every application using either of these vulnerable libraries is vulnerable to attack as both of these components are directly accessible by application users. Other vulnerable libraries, used deeper in an application, may be harder to exploit.

Note from the last paragraph above, the deeper the component (jar) is the harder it is to exploit, however, that doesn't mean a determined entity can't exploit them.

In summary, Spring Security is a great tool for managing authentication and access-controls in your application but it isn't a magic bullet to fix all security problems.