Is this why npm made the changes with self signed certificates http://blog.npmjs.org/post/78085451721/npms-self-signed-cert... or is that unrelated?
Npm security post-mortem
41–50 of 65 posts
Re: Npm security post-mortem
#42The 'we fixed it' link points to four new lines including these:
.replace(/>/g, '<')
.replace(/Re: Npm security post-mortem
#43So the audit was mostly about nom the website and the service for maintaining npm packages? That's a good first step. 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…
One of the Node Security Project ( https://nodesecurity.io/ ) main efforts is to audit all the npm modules in a community driven way. We are accepting contributions from the community to build the tools that get the job done efficiently and to audit modules, disclosing vulnerabilities in a responsible manner.
I'll take a look, thanks. Some reviews will, of course, be manual in nature -- implementation correctness of digest auth, for instance, is one that comes to mind (I need to contribute that back to a particular module).
Re: Npm security post-mortem
#44can 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.
Thomas could give you better numbers here, but in general, appsec reviews cost as much as getting software development done. (i.e. For a security review worth the paper you print the report on, you're looking at $5k at the lower end if your application is simple or if someone wants to really do you a favor, and they get substantially more expensive than that. You can get someone to run an automated scan for $500 and…
A $4k billable week is incredibly cheap, so much so that I'd worry about the team delivering it. Our rates are high because big firms bid them up. Why are the cheap teams turning down free money?
If someone offers you a $4k week, make sure they know they're cutting you a deal.
Re: Npm security post-mortem
#45can 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.
Full Disclosure: I work at ^Lift (liftsecurity.io) 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…
Just to be clear: any firm charging appsec rates should not be an automated-tool shop. I know there are some firms like that, but we banned scanners altogether the first year we were in business. I used to think we were cool for doing that, but really among the high-end firms that's table stakes.
Re: Npm security post-mortem
#46Security postmortems are a great idea. Until time machines happen.
Re: Npm security post-mortem
#47Earlier quoted context omitted.
I'm sorry you took it that way. The scope of our security hole was exactly as big as the Rubygems vulnerability. If I'd omitted that comparison, I was sure somebody would say "these guys were just as bad as ruby but they're covering that up!" At the same time, I wanted to make it clear that the only reason this wasn't a game-over disaster for us is because we were lucky. We weren't any smarter, or better designed. Ju…
I think the problem I had with it had to do with the way the sentences were constructed. For example: "... this could have been a disaster, very much like the rubygems.org security breach in early 2013" This implies that the issue you had wasn't as serious as the RubyGems issue. Similarly, the following sentence likewise implies that the breach was not as severe: "Unlike that incident, there’s no evidence that, other…
It turns out we were incorrect about the scope of the Rubygems incident, and have issued a correction:
http://blog.npmjs.org/post/80307645782/correction-to-previou...
Re: Npm security post-mortem
#48Is this why npm made the changes with self signed certificates http://blog.npmjs.org/post/78085451721/npms-self-signed-cert... or is that unrelated?
The original abandoning of the self-signed cert was because self-signed certs were a bad idea.
The issue that post refers to (it is a little unclear, because we ourselves were a little unclear what had gone wrong at that point) is when we broke older clients by moving to a non-GlobalSign cert. We cleared that up here: http://blog.npmjs.org/post/78165272245/more-help-with-self-s...
We had already planned to move to a new cert before the security disclosure, and hadn't anticipated the size of the problem with a non-GlobalSign cert, so although the two happened pretty much simultaneously, they weren't really related.
Re: Npm security post-mortem
#49Nice 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.
Update: I was in fact incorrect about the severity of the rubygems.org incident; their issue was a disclosure without a breach, exactly like ours. I've updated the original post and also issued a correction:
http://blog.npmjs.org/post/78165272245/more-help-with-self-s...
Re: Npm security post-mortem
#50Earlier quoted context omitted.
I think the problem I had with it had to do with the way the sentences were constructed. For example: "... this could have been a disaster, very much like the rubygems.org security breach in early 2013" This implies that the issue you had wasn't as serious as the RubyGems issue. Similarly, the following sentence likewise implies that the breach was not as severe: "Unlike that incident, there’s no evidence that, other…
It turns out we were incorrect about the scope of the Rubygems incident, and have issued a correction: http://blog.npmjs.org/post/80307645782/correction-to-previou...
Glad to see the correction, it solves the one problem with an otherwise very well written incident report. Kudos for setting the record straight and taking the criticism so well.