OP here. Thanks for responding promptly. To be clear, letting third party JS run in a trusted environment like a dashboard is an industry wide problem. If we assume CircleCI is the only bad actor we're kind of missing the point of the exercise.
CircleCI is a notable example, due to the fact it hosts source code and secrets for so many different companies and loads so many third party scripts in its dashboard context. But they're not unique in this regard. I hope everyone reading this is reconsidering the scripts that have access to their dashboard and pushing for changes at their company.
If CircleCI was immediately vulnerable to injection via the scripts above I would have used the private disclosure route and I encourage others to as well. But I don't know that there is a "vulnerability" here so much as a discussion that we need to have about what and how much third party code we let run in a trusted context. I wrote a little more in the thread below, https://news.ycombinator.com/item?id=15442988.
Thanks Kevin. We really do appreciate the discussion and, as you would imagine, are rethinking some of our approaches in line with the issues you've raised.
The real thanks should go to you Rob. As it's stated, it's an industry wide problem and the real guts come from the companies that take the issue seriously; the ones who come out, hold it close to their own, admit they were wrong, and work to improve. This says a lot about you and your company, and as a customer it makes me proud that you're part of our mobile pipeline.
As a customer, Rob, what would be a good avenue to notify you of issues like this in the future? Not every company wants to be front and center of what is essentially the news hub of tech people like HN for issues, so is there some way we can get with you guys directly to straighten security issues out, as well as some assurances as how you'll handle it along the way?
You can always email our security team at security@circleci.com Our gpp key is available on our site https://circleci.com/security/ if needed. You can also email me directly at rob@ if you have an immediate question.
In the interest of said discussion, I would appreciate a write-up of the rationale behind the approach chosen, when you are ready. It could help others that are in a similar situation. Perhaps inspire a better practice in the industry.
You mention vetting third party scripts, but did not explain how your app is not vulnerable to those scripts being hacked or modified in the future. This vulnerability seemed to be the main point of Kevin's piece.
IMHO you should have followed the standard practice of telling them first, then posting the story afterward. Blindsiding them wasn't nice, even if (hopefully) this makes them and others think more about what they risk with external JS, rather than just "oh shit circle...". Just my 5c.
p.s I'm curious why you thought this route was better?
I hear this attitude a lot and it always rubs me the wrong way.
It's a corporation... Why should he care about it's feelings? What does he owe CircleCI? Are they paying him? What claim do they have to his time to jump through their hoops / process?
I'm positive in this case that they weren't intentionally messing with people's security, but shouldn't we and their customers be able to judge that ourselves instead of getting it swept under the carpet via private channels?
I do believe it's good practice to "not be a douche", especially at a personal level, but I wouldn't even come close to categorizing this as douche behaviour.
* Note: this comment is not actually directed at CircleCI, just the attitude that we all somehow owe it to companies to tell them about their goofs privately.
This is, imho, douche behavior when it's the accepted norm to approach a company through their (listed and public!) security page. Why? So they can fix things before they get fucked. Yes of course you don't actually have to, but that makes you a douche imho.
Also, it's not swept under the carpet - it ends up usually getting $ for the reporter and a better story as they'd also know how the company fixed it. If they refuse to fix, then publish away.
That would have been appropriate if I had found e.g. an endpoint that did not accept CSRF tokens, or a vulnerability in Ring. It's not appropriate when the problem is they made a business decision to expose my source code to Quora.js.
How do you know it was a conscious decision, as opposed to ordinary human oversight? As the old saying goes, never ascribe to malice what can be adequately ascribed to incompetence. (Though I wouldn't go so far as to call CircleCI "incompetent" -- security issues are rampant in this industry, despite everyone's best efforts.)
I'd say it's more of a tossup. I mean they write software for people who write software.
I think we can rule out a malicious decision regardless though. I'd wager if it was flagged by the annoyingly pedantic but super smart developer, then it's still sitting in their Trello board buried under a few hundred features that were considered a higher priority by the product manager. In this case, the decision felt mostly harmless.
Or yeah, probably just as likely that no one noticed.
It's rarely about the company and much more about those affected by a potential issue. This issue's a little different as it's the potential for a vulnerability more than an actual vulnerability.
A typical case for responsible disclosure is something like a bug in Apache or Nginx that's serious and if a security issue is found that they're given time to address it. So when they make an announcement its:
1. Here is the issue
and
2. Here is the fix
Instead of just spreading and publicizing a vulnerability.
I'm mostly with you when there's potential damage to their customers, especially when those customers are individuals (like a database of social profiles being compromised), which was not the case here. However I think saying it's "rarely" about the company is a bit naive.
There's been some really high profile breaches where the extent of the impact to the customer has taken an unacceptably long time to be made public... which results in increased fallout damage.
A company's natural inclination is going to be to minimize losses (generalizing of course), and that often means dragging their feet, or dealing with it privately and never notifying their customers.
We should recognize these incentives and be a bit more aggressive about holding their feet to the fire, instead of criticizing the researcher who discovers the security flaw. Unless of course his / her behaviour is blatantly malicious.
It anecdotally feels a bit lopsided in favour of the corporations at the moment. Especially when someone like in this post, who clearly didn't endanger any customers, gets criticized...
I can't speak to what the OP was thinking, but given their above statement of this being an industry wide issue, it seems to me posting this privately to a single company would only address the issue within that specific company and very little to nothing would change in other companies due to the nature of competition. While this isn't nice, I guess, it does seem to be the nature of development and business. Just my 5 cents, though, I've been wrong before.
I disagree; report it to circle, if they fix then you can write the story on how it's a massive problem, how they fixed and people can learn. We learnt basically shit from this: nothing about how it's fixed or is avoided.
If I did that, no one today would be opening the Network tab on apps/credit card forms they care about and wondering whether third parties could steal the data.
I'm sure if CircleCI had a prompt to opt-in to enabling the tracking then they might have returned the courtesy. Why is it OK for a company/project to violate the privacy of so many with no warning but bad for users to report the privacy and security violations?
CircleCI is a notable example, due to the fact it hosts source code and secrets for so many different companies and loads so many third party scripts in its dashboard context. But they're not unique in this regard. I hope everyone reading this is reconsidering the scripts that have access to their dashboard and pushing for changes at their company.
If CircleCI was immediately vulnerable to injection via the scripts above I would have used the private disclosure route and I encourage others to as well. But I don't know that there is a "vulnerability" here so much as a discussion that we need to have about what and how much third party code we let run in a trusted context. I wrote a little more in the thread below, https://news.ycombinator.com/item?id=15442988.