OWASP has successfully managed to tackle a susceptibility discovered in its enterprise security API, the ESAPI. The vulnerability, if left unfixed, could have been leveraged to carry out path control attacks. Unfortunately, it seems that coding errors made while developing the ESAPI are what paved the way for the development of the flow.
The OWASP ESAPI extends a library of security controls that can assist enterprise software developers in producing highly secure code.
Now that the vulnerability has been repaired, it may not be easy to exploit it. However, proactive measures are recommended as the potential impact will be huge. Therefore, the constant update is inevitable for the discovered susceptibility.
“most applications using ESAPI likely don’t even use the affected method,” so the vulnerability’s potential impact 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,” says Kevin Wall, project co-leader, OWASP.
Application developers can obtain valuable insights from the OWASP vulnerability incident. First, libraries’ developers need to utilize an SCA, a Software Composition Analysis tool, and understand its limits. However, not all SCAs are equipped to track vulnerabilities in transitive dependencies. Further, suppose patching doesn’t seem to be a feasible option. In that case, a deep-dive analysis should identify how the vulnerability would influence your application and the mitigating controls to be exercised to minimize the probable risks.
AlSO-READ: Solarwinds Fixed Its Web Help Desk Software Bug After Discovery by Assetnote
“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,” adds Wall.