I wonder if the npm, Inc. team told ^Lift about the disclosed vulns before ^Lift's own audit completed. I can imagine being tempted to see whether they'd discover it themselves, to gain more evidence on how comprehensive the audit was.
Npm security post-mortem
11–20 of 65 posts
Re: Npm security post-mortem
#12Nice disclosure, and can't fault the npmjs team given that they commissioned a security audit as soon as they possibly could. I wonder if the npm, Inc. team told ^Lift about the disclosed vulns before ^Lift's own audit completed. I can imagine being tempted to see whether they'd discover it themselves, to gain more evidence on how comprehensive the audit was.
As part of the audit, ^Lift audited a lot of the third-party modules we use, and notified the authors of those packages separately (I'm not aware of the details, but I don't think there was anything major).
Re: Npm security post-mortem
#13Re: Npm security post-mortem
#14Re: Npm security post-mortem
#15It's worth noting that the XSS vulnerability ("A user could inject scripts into the npm website via the README and license fields") assuredly exposed a whole slew of easy-to-exploit vulnerabilities, and the community should feel very lucky that such an obvious vulnerability was in the wild for so long without being exploited. TL;DR always use a templating engine that makes you think about XSS and don't allow unsaniti…
It's sad that you even need to say this, both for the fact that Javascript sandboxing is so terrible and the fact that developers aren't aware of the hazards of just blindly taking user-provided HTML.
Re: Npm security post-mortem
#16It's worth noting that the XSS vulnerability ("A user could inject scripts into the npm website via the README and license fields") assuredly exposed a whole slew of easy-to-exploit vulnerabilities, and the community should feel very lucky that such an obvious vulnerability was in the wild for so long without being exploited. TL;DR always use a templating engine that makes you think about XSS and don't allow unsaniti…
> don't allow unsanitized user-provided HTML through raw. It's sad that you even need to say this, both for the fact that Javascript sandboxing is so terrible and the fact that developers aren't aware of the hazards of just blindly taking user-provided HTML.
Re: Npm security post-mortem
#17[deleted]
Re: Npm security post-mortem
#18Do people now really believe that there are definitely no security vulnerabilities related to the npm registry? Or any other type of registry, or website or application for that matter?
People have completely unrealistic expectations about security. Every time you had a significant amount of new functionality, or even a very insignificant amount, you could have introduced a new security vulnerability.
Basically this other company Lift or whatever could have two full time engineers doing security audits for npm from here until npm is done, and you could still have some other hacker who was thinking differently come up with a vulnerability in some new feature that they missed.
Its great to have the attitude that you are going to make a serious effort, but totally unrealistic to think that you are going to do one security audit and then there will be no more vulnerabilities. And also really makes no sense to make a big deal about it or give them grief or for them to even feel bad. If you think that way then you don't understand security.
You see all of these large projects having security issues not because they are full of negligent or sloppy engineers, but because security takes a lot of resources and is very difficult. The security firms will certainly suggest that engineers are negligent, of course. That ensures that they will continue to get new clients. But the reality is even with a lot of resources dedicated to just security, projects can easily have new vulnerabilities.
So that's great that they are getting regular security audits now. They are ahead of the curve.
EDIT: I notice I have been buried without anyone bothering to even respond. If you disagree, say why you disagree.
Re: Npm security post-mortem
#19[deleted]
Re: Npm security post-mortem
#20can anybody disclose some figures on how much ^lift (or competitors) costs, e.g.: for a 100K-line Python codebase? A rough ballpark would help a lot.
To be honest, we usually bill out by time rather than code base size.
To determine costs, we: * look at the application size * estimate how long it will take us to get good coverage * take in all the other factors (source provided vs blackbox) * then we give an estimate based on how long we think it will take
I must say that I honestly believe that what we provide is totally worth the money. We work really hard to provide a clear assessment of the problems with recommendations on how to fix them.
We aren't an "automated tool" shop, we actually look at the app and understand how it works and then see how to break it.
But to actually answer your question, having NO IDEA what your application actually is: (Keep in mind I am not the actual guy who does the bids, I do assessments and training. No promises, please don't fire me, etc.)
Prices vary drastically by project, and it would really depend on what we were looking at.