21–30 of 65 posts
Nice write-up and good on them for fixing that quickly, but it's a serious bummer they unnecessarily bring in the RubyGems incident as some sort of awkward "Well at least we didn't screw up that badly!" swipe. It's not relevant to anything else they said.
Why do they have to apologize for that? Almost every piece of software has security vulnerabilities. Do 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…
It's just the sad state of the 'industry'. As soon as some armchair warrior finds something remotely wrong with whatever, they'll go nuts on you and you need this sort of touchy-feely PR nonsense to placate the comic book shop types. Hats off to these guys for being level-headed enough to be able to play the game this way - I couldn't do it any more, I'd go bonkers over overhead like this.
can 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.
I'd turn away any client who asked me to do appsec work, because I don't think I'd produce work of a sufficient quality to justify the sort of rates I charge, but I do think I'm probably good enough to roughly scope appsec projects on technologies I understand well. Example: Appointment Reminder is an architecturally simple Rails application. I think an audit of the marketing site, application, and architecture would reasonably require probably 1 to 2 billable weeks depending on how much I asked you to plumb e.g. line-by-line HIPAA requirements, and that would probably run in the $4k to $12k region based on my understanding of prevailing rates for appsec work. (I'm sure that if I had $25k budgeted for that audit many firms could find a way to get me my money's worth for every penny of that budget, by the way.)
Earlier quoted context omitted.
> 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.
As a point of honor, I feel obligated to mention that @rockbot and I are very aware of these hazards, but our website was put together in somebody's spare time when Node had like 100 users in total :-)
Why do they have to apologize for that? Almost every piece of software has security vulnerabilities. Do 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…
Don't worry. Some of us agree with you. Sadly I'm one so I can't explain as to why you got buried.
Why do they have to apologize for that? Almost every piece of software has security vulnerabilities. Do 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…
While this is true, there are certain classes of software for which vulnerabilities are a bigger deal and thus should be treated much more seriously, which includes much better up-front analysis of potential attacks and decent disclosure systems for when an attack (yes, almost inevitably) occurs.
Software distribution systems are pretty high up on the list for which exploits are A Big Deal because of how an exploit within them can very quickly spiral out of control (eg. attacker injects malicious code into very widely used module that is distributed from your repository -- now you're responsible for a lot more security problems than just the original problem on your site).
IMO this response is a good one; not over the top at all but gets the point across that they take this situation very seriously, which they should.
(FWIW, I upvoted you, so just because I partly disagree don't lump me in with those 'burying' you; I think the question you raise is entirely valid, but I do think this was a serious situation and the response was warranted).
Has there been any talk within the node community about auditing node modules themselves? Maybe start with the most popular? I could see this being popular with enterprise development, etc.
I want to say that Strong Loop made noise about doing something like this, but I haven't seen much on it of late.
It'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…
[1] https://github.com/chjj/marked/commit/904c71b7713979b01d5bc5...
[2] https://github.com/npm/npm-www/commit/a1ed923870609b578fcde4...
edit: On closer inspection it looks like it may have been a problem with the html sanitizer[3] it used as opposed to the marked `sanitize` option (which is not used at all). I guess my conscience is clear here at least.
[3] https://github.com/npm/npm-www/blob/master/models/package.js...