Path traversal flaw found in OWASP enterprise library of security controls

Difficult-to-exploit ESAPI vulnerability offers best practice lessons

The Open Web Application Security Project (OWASP) has fixed a vulnerability in its Enterprise Security API (ESAPI) that, if left unresolved, might have been abused to run path traversal attacks.

The issue, which involved the ESAPI validator interface and had a security severity rating of 7.5 out of 10, can be resolved by applying the patched 2.3.0.0 release.

OWASP ESAPI offers a library of security controls that can help enterprise software developers to write more secure code. The technology is designed to be embedded in (mostly web) applications as a proactive set of security measures.

Although the vulnerable component would be hard to exploit, an update is nonetheless recommended since the potential impact is high, as an advisory by OWASP explains:

The default implementation of Validator.getValidDirectoryPath (String, String, File, boolean) may incorrectly treat the tested input string as a child of the specified parent directory. This could potentially allow control-flow bypass checks to be defeated if an attack can specify the entire string representing the ‘input’ path.

Limited impact

OWASP ESAPI project co-leader Kevin Wall told The Daily Swig that “most applications using ESAPI likely don’t even use the affected method” so the potential impact of the vulnerability is application specific.

“With all library vulnerabilities, it is hard to gauge how exposed a generic application is to exploit a vulnerability in a library.”

Wall added: “Even when that Validator.getValidDirectoryPath() is used within an application, that still does not mean that it is exploitable within your application itself. You really have to analyze it on a case-by-case basis.”

According to Wall, in most use cases the vulnerable ESAPI would be used in conjunction with a web application firewall (WAF) or intrusion Detection software – factors further limiting the scope for harm.

On the question of severity, the software developer concluded: “I don’t think this is really a ‘high’ vulnerability, but that’s what we go have with because that’s what CVSSv3.1 spits out.”

Lessons to learn

While the vulnerability in play is unlikely to be exploited, and even less likely to cause much harm, the bug offers lessons for software developers, according to Wall.

For one thing, application developers using libraries should use a software composition analysis (SCA) tool and know its limits.

“Some SCA tools only find vulnerabilities reported in direct dependencies, but not in transitive dependencies,” Wall explained.

“And if you decide not to patch, then you need to do a deep-dive analysis to see exactly how the vulnerability in some library impacts your application and what types of mitigating controls you can put up (e.g., maybe ‘virtual patching’ via a WAF) to reduce the risk.”

DON’T FORGET TO READ NPM developer reputations could be leveraged to legitimize malicious software

The flaw may also be instructive for library developers because it illustrates the utility of static application security testing (SAST) tools.

“For library developers, run SAST tools of some sort and review the results, but also try to have adequate test coverage and at least do manual code reviews of the ‘git diffs’ when PRs are submitted but before they are merged,” Wall advised.

Although coding mistakes made in developing ESAPI led to the flaw, these were understandable mistakes, according to Wall.

He concluded: “I think the place where ESAPI dropped the ball is that there was no specific test that would have brought this to our attention and that’s on us, although I think in our defense, it was mostly the unawareness of everyone who previously touched that code that File.getCanonicalPath() acts differently when a value for a directory is not ‘/’ terminated. I think that’s a bit unintuitive.”