5 ms·

Looking at how many sites use vulnerable JavaScript libraries

108 points by heitortsergent 9y ago

nawitus 9y ago
Even if we have better tooling to make updating dependencies easy, there's still the fact that there's a lot of applications in production that are not maintained. If there are no maintainers there will be no updates..
irrelative 9y ago
One might even say that 100% of 333,410 sites use vulnerable javascript libraries
- jjnoakes 9y ago
  Those means different things. Their wording means "we checked X sites and 77% of them met some criteria", which can be extrapolated to higher values of X (assuming the proper statistical care is taken, etc). Your wording implies the same, but that's not good because you can't extrapolate to a larger X. You chose the sites after knowing they already met the criteria, and that changes the meaning.
  - spurcell93 9y ago
    I get the sense OP was being a bit snide
    - bigiain 9y ago
      The snide version would be "100% of 433,000". (Which is what I initially parsed it as, and nodded in agreement...)
- jazoom 9y ago
  I thought exactly the same thing but wasn't dedicated enough to do the calculation.
- Fnoord 9y ago
  The information "77% of 433,000" contains the sample size number (433k). "100% of 333,410" does not contain a sample size number. The lack of the sample size number makes the data (and title) less meaningful. I'd go as far saying it makes the data (and title) meaningless.
wesleytodd 9y ago
We run nsp on our production services in CI before merge. The number of false positives I have tracked down is infinitely higher than the number of vouln's found. I literally mean this, we have never seen one disclosure which resulted in a viable attack on our production services. For example, recently a bunch of ReDOS voulns were reported in popular libraries. None of which were in code paths hit by our configurations. So needless to say, I think this is a sensationalist headline.
- wesleytodd 9y ago
  NOTE: I am NOT saying we have had no security voulns. Just that the snyk and nsp disclosures on packages do not mean that those applications are vulnerable.
- guypod 9y ago
  I think it's an absolute statement about the lack of awareness to this risk. Of course some of these site would not actually be vulnerable, but I would bet the vast majority of them don't even know they're using a library with a known vulnerability.
  - wesleytodd 9y ago
    Agreed, but the tools (nsp) are there to make it simple to know. Devs who are not going to update/patch are not the target here, so making big claims like this does not strongly add to the conversation IMO. Also, this is nothing new on the web, the amount of wordpress sites with known voulns is probably MUCH higher.
- qaq 9y ago
  "viable" is a function of how interesting your production services are to a capable adversary.
merb 9y ago
> One of the discoveries the report mentions is that an analysis of around 433,000 sites found that 77% of them use at least one front-end JavaScript library with a known security vulnerability. Does that even matter? No Front-End JS Library should actually make your backend vulnerable.
- bastawhiz 9y ago
  An XSS issue could make your users' data vulnerable.
  - merb 9y ago
    is still only an issue if you pass untrusted data to your js code.
    - Klathmon 9y ago
      And there is a pretty good chance of that happening in most JS projects. Anywhere you take or show input from the user (an input box, a URL query, displaying data stored by some other system on the DB, etc...) could be a vector for an XSS attack. And it's not just data passed to JS, but data passed to HTML or any data that could make it's way into CSS in many cases!
    - sakshyamshah 9y ago
      turns out that most of times, untrusted user supplied data slips through JS codes https://www.owasp.org/index.php/Top_10_2017-Top_10 https://www.owasp.org/index.php/Top_10_2017-Top_10
  - oneweekwonder 9y ago
    But cors[0] headers can mitigate some of the risk? [0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
    - thefreeman 9y ago
megaman22 9y ago
If it's an automated scan, I'd be skeptical. Currently dealing with some overzealous security folks who put adherence to their scan tool over common sense, and insist that we lock down Oracle PL/SQL vulnerabilities in an application that doesn't use any flavor of SQL...
- Klathmon 9y ago
  I absolutely hate these kinds of "security" scans. I once worked with a company that started using one of these. They said our "vulnerability scores" were significantly too high. I looked at the report, turns out they were just looking at HTTP headers and throwing up every CVE that matched any version numbers they found. (One of the "worst offenders" on the system was a CVE about a vulnerability in PHP when using "magic quotes", a part of PHP that hadn't been used in many years, and our application never used) We were officially instructed that the fix would be to hide the PHP and apache version numbers from the headers. If I were the one running that scan, and someone "fixed" the problem by just hiding the version numbers, I'd be calling for that person to be fired for trying to hide the problem. But here they were instructing us to do just that. And once we did, the system was marked "secure"...
  - styfle 9y ago
    There was a fund raising website written 15 years ago that a team I was on was responsible for (I never actually worked on it). There were fraudulent credit card donations for $1 which became really obvious when the zip code was garbage. The “solution” was to disabled the credit card page until the month of the fund raising event when it was enabled again in hopes of the scammers would not try during that month.
    - CapacitorSet 9y ago
      I don't understand, what were the scammers trying to achieve?
      - megaman22 9y ago
peternicky 9y ago
I’d like to hear how Snyk compares to GitHub’s recently release vulnerability notification feature.
fenwick67 9y ago
Just because the library has a vulnerable code path doesn't mean the site itself is vulnerable. Especially with libs like jQuery, where there are many many functions.
binarymax 9y ago
Needs some significant clarification on what it means to be 'vulnerable'. As an example, many static sites (such as blogs) can use jQuery, that doesn't necessarily mean there is an attack vector for those blogs or their visitors.
jbob2000 9y ago
This means nothing unless they mention what the vulnerabilities are. We do security scans on our front-end javascript code as well; most of the hits we get are for "log injection". Meaning, we have a console.log somewhere and someone could fake our logs by overriding the output. Wow, such vulnerability!
JasonFruit 9y ago
Is it better for a website to roll its own insecurity? I'd a lot rather people use libraries with significant adoption — hopefully being aware of and avoiding any security problems they may include — than write their own version where the security problems will never be exposed, at least for good.
- arca_vorago 9y ago
  I'd rather devs stop using JavaScript in so many places where its not even needed. Pure html5 and CSS is where its at.
- colejohnson66 9y ago
  Isn’t that just security through obscurity?
coin 9y ago
I still question why I need to execute remote code just to read web content
- ben_w 9y ago
  You don’t. The majority of websites behave acceptably if you disable JavaScript entirely.
tyingq 9y ago
This boils down mostly to a lot of sites running jQuery at a version less than 3.0.0. Which technically means "vulnerabilities", but depends on how it's used.
styfle 9y ago
Snyke posted “The State of Open Source Security” not long ago https://news.ycombinator.com/item?id=15729811 https://news.ycombinator.com/item?id=15729811
dbg31415 9y ago
Of course this is click bait. But of course most companies don't invest what they should in website maintenance, code reviews, security audits, and upgrades. I'm OK with some clickbait if it helps raise awareness of the need for more recurring investment in technology.
mnm1 9y ago
I looked at what it would take to upgrade our Angular 1.5 to 1.6: weeks worth of trying to untangle dependency hell and testing. For a minor version number upgrade. Let's not pretend it's only the consumers of these libraries that are lagging. A lot of these libraries are maintained by teams who have no business maintaining software, open source or not. They can release all the security patches they want, it won't make a difference if their new version isn't backwards compatible (obviously Angular is egregious and by far the worst I know of where even their minor version numbers have huge incompatibilities, not to mention 3 major version releases in 11 months).

Even if we have better tooling to make updating dependencies easy, there's still the fact that there's a lot of applications in production that are not maintained. If there are no maintainers there will be no updates..

irrelative 9y ago

One might even say that 100% of 333,410 sites use vulnerable javascript libraries

jjnoakes 9y ago
Those means different things. Their wording means "we checked X sites and 77% of them met some criteria", which can be extrapolated to higher values of X (assuming the proper statistical care is taken, etc). Your wording implies the same, but that's not good because you can't extrapolate to a larger X. You chose the sites after knowing they already met the criteria, and that changes the meaning.
- spurcell93 9y ago
  I get the sense OP was being a bit snide
  - bigiain 9y ago
    The snide version would be "100% of 433,000". (Which is what I initially parsed it as, and nodded in agreement...)
jazoom 9y ago
I thought exactly the same thing but wasn't dedicated enough to do the calculation.
Fnoord 9y ago
The information "77% of 433,000" contains the sample size number (433k). "100% of 333,410" does not contain a sample size number. The lack of the sample size number makes the data (and title) less meaningful. I'd go as far saying it makes the data (and title) meaningless.

wesleytodd 9y ago

We run nsp on our production services in CI before merge. The number of false positives I have tracked down is infinitely higher than the number of vouln's found. I literally mean this, we have never seen one disclosure which resulted in a viable attack on our production services. For example, recently a bunch of ReDOS voulns were reported in popular libraries. None of which were in code paths hit by our configurations. So needless to say, I think this is a sensationalist headline.

wesleytodd 9y ago
NOTE: I am NOT saying we have had no security voulns. Just that the snyk and nsp disclosures on packages do not mean that those applications are vulnerable.
guypod 9y ago
I think it's an absolute statement about the lack of awareness to this risk. Of course some of these site would not actually be vulnerable, but I would bet the vast majority of them don't even know they're using a library with a known vulnerability.
- wesleytodd 9y ago
  Agreed, but the tools (nsp) are there to make it simple to know. Devs who are not going to update/patch are not the target here, so making big claims like this does not strongly add to the conversation IMO. Also, this is nothing new on the web, the amount of wordpress sites with known voulns is probably MUCH higher.
qaq 9y ago
"viable" is a function of how interesting your production services are to a capable adversary.

merb 9y ago

> One of the discoveries the report mentions is that an analysis of around 433,000 sites found that 77% of them use at least one front-end JavaScript library with a known security vulnerability. Does that even matter? No Front-End JS Library should actually make your backend vulnerable.

bastawhiz 9y ago
An XSS issue could make your users' data vulnerable.
- merb 9y ago
  is still only an issue if you pass untrusted data to your js code.
  - Klathmon 9y ago
    And there is a pretty good chance of that happening in most JS projects. Anywhere you take or show input from the user (an input box, a URL query, displaying data stored by some other system on the DB, etc...) could be a vector for an XSS attack. And it's not just data passed to JS, but data passed to HTML or any data that could make it's way into CSS in many cases!
  - sakshyamshah 9y ago
    turns out that most of times, untrusted user supplied data slips through JS codes https://www.owasp.org/index.php/Top_10_2017-Top_10 https://www.owasp.org/index.php/Top_10_2017-Top_10
- oneweekwonder 9y ago
  But cors[0] headers can mitigate some of the risk? [0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
  - thefreeman 9y ago

megaman22 9y ago

If it's an automated scan, I'd be skeptical. Currently dealing with some overzealous security folks who put adherence to their scan tool over common sense, and insist that we lock down Oracle PL/SQL vulnerabilities in an application that doesn't use any flavor of SQL...

Klathmon 9y ago
I absolutely hate these kinds of "security" scans. I once worked with a company that started using one of these. They said our "vulnerability scores" were significantly too high. I looked at the report, turns out they were just looking at HTTP headers and throwing up every CVE that matched any version numbers they found. (One of the "worst offenders" on the system was a CVE about a vulnerability in PHP when using "magic quotes", a part of PHP that hadn't been used in many years, and our application never used) We were officially instructed that the fix would be to hide the PHP and apache version numbers from the headers. If I were the one running that scan, and someone "fixed" the problem by just hiding the version numbers, I'd be calling for that person to be fired for trying to hide the problem. But here they were instructing us to do just that. And once we did, the system was marked "secure"...
- styfle 9y ago
  There was a fund raising website written 15 years ago that a team I was on was responsible for (I never actually worked on it). There were fraudulent credit card donations for $1 which became really obvious when the zip code was garbage. The “solution” was to disabled the credit card page until the month of the fund raising event when it was enabled again in hopes of the scammers would not try during that month.
  - CapacitorSet 9y ago
    I don't understand, what were the scammers trying to achieve?
    - megaman22 9y ago

peternicky 9y ago

I’d like to hear how Snyk compares to GitHub’s recently release vulnerability notification feature.

fenwick67 9y ago

Just because the library has a vulnerable code path doesn't mean the site itself is vulnerable. Especially with libs like jQuery, where there are many many functions.

binarymax 9y ago

Needs some significant clarification on what it means to be 'vulnerable'. As an example, many static sites (such as blogs) can use jQuery, that doesn't necessarily mean there is an attack vector for those blogs or their visitors.

jbob2000 9y ago

This means nothing unless they mention what the vulnerabilities are. We do security scans on our front-end javascript code as well; most of the hits we get are for "log injection". Meaning, we have a console.log somewhere and someone could fake our logs by overriding the output. Wow, such vulnerability!

JasonFruit 9y ago

Is it better for a website to roll its own insecurity? I'd a lot rather people use libraries with significant adoption — hopefully being aware of and avoiding any security problems they may include — than write their own version where the security problems will never be exposed, at least for good.

arca_vorago 9y ago
I'd rather devs stop using JavaScript in so many places where its not even needed. Pure html5 and CSS is where its at.
colejohnson66 9y ago
Isn’t that just security through obscurity?

coin 9y ago

I still question why I need to execute remote code just to read web content

ben_w 9y ago
You don’t. The majority of websites behave acceptably if you disable JavaScript entirely.

tyingq 9y ago

This boils down mostly to a lot of sites running jQuery at a version less than 3.0.0. Which technically means "vulnerabilities", but depends on how it's used.

styfle 9y ago

Snyke posted “The State of Open Source Security” not long ago https://news.ycombinator.com/item?id=15729811 https://news.ycombinator.com/item?id=15729811

dbg31415 9y ago

Of course this is click bait. But of course most companies don't invest what they should in website maintenance, code reviews, security audits, and upgrades. I'm OK with some clickbait if it helps raise awareness of the need for more recurring investment in technology.

mnm1 9y ago

I looked at what it would take to upgrade our Angular 1.5 to 1.6: weeks worth of trying to untangle dependency hell and testing. For a minor version number upgrade. Let's not pretend it's only the consumers of these libraries that are lagging. A lot of these libraries are maintained by teams who have no business maintaining software, open source or not. They can release all the security patches they want, it won't make a difference if their new version isn't backwards compatible (obviously Angular is egregious and by far the worst I know of where even their minor version numbers have huge incompatibilities, not to mention 3 major version releases in 11 months).