2

As a security engineer, I wonder about the common approach for web app 3rd party JS dependency vulnerability management. We have a lot of apps depend on Jquery etc. In a regular vulnerability scan, old versions of JS libraries (which alot of them has XSS CVEs) reported as vulnerability. Without really reading and understanding the code, you can't say your app is affected by those XSS's or not and it is not an easy job for a security engineer. However, upgrading with newer version (which hopefully no assigned XSS CVE s) is not easy too because it requires effort for new developments and QA-UX tests on the app by other teams. I believe it is common problem. So what is the industry standart (applied by big players like Google, Apple, microsoft etc.).

We have cases that we classify the issue as vulnerability, without providing an actual XSS exploit. However development teams are not happy to upgrade it because of the effort. They suggest fixes by editing the library.

So what to do when you encounter an old JS library that has known vulnerabilities?

To Force the upgrade despite to development and test effort?

To fix the old version on your side by looking at the changes over source code? (guess it is the worst idea)

Totally ignoring it until an XSS exploit has been found for that specific app? (finding the real exploit is not easy because the need of really examine where the vulnerable part is and find out if you are using it or not. pretty time consuming for dynamic testers and it is completely manuel)

Classifying them as a risk instead of vulnerability

other ideas?

Improve this question
1
  • 1
    i update and unit test. if it works keep it. if units fail, go back to the "vuln" version and make a plan. Typically, first find out "are we even affected"; if not, ignore. If so, determine "how bad is it"? Is it worth custom dev time to remedy? If so, is it cheaper to fork the busted or integrate the vendor patched version and all it's new quirks? You might also be able to drop a less-used feature to close the hole if only a small part of your app needs the problematic lib method. I once replaced JQ with zepto because JQ upgrades were incompat, but zepto wasn't, so it pays to "shop around".
    – dandavis
    Commented Mar 1, 2021 at 17:55

1 Answer 1

Reset to default
0

This is a common issue for legacy systems and not only about JS Library.

Mainly it is a risk and needs to be analyzed, managed, accepted, and documented.

Analyzed That depends on your risk management process. But mainly, identify the current vulnerabilities with real exploitations so you highlight the real risks for risk owners (the one who is going to accept it). Good to have a PoC.

Managed Propose the workaround till the risk is remediated... for your case, CSP and other browser-based protection might be a good suggestion.

Accepted Get acceptance from management (risk owner).

Documented Document for tracking and follow-up purpose.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .