[deckar01]

1. "I reported this issue to Coursera last Thursday; to the company’s credit, in less than a day ..."

2. "I reported the issue to Coursera on Sunday, and I have not yet received a response."

3. "I notified Coursera of this issue last Thursday."

Kind of, but not very responsibly.

[aioprisan]

How would you define responsibly in this case? Isn't a week enough time?

[seanieb]

There are norms for this type of thing. Normally a few weeks is the minimum that people are expected to give.

At worst they don't fix it in a timely manner. And at that point giving them a heads up that you're about to publish. Then you can publish the bug, the timeline and communications, which should serve as a ref flag to their users, government regulators and the community.

However, you need to bear in mind publishing before they fix the issue puts existing users at risk by publicizing a flaw that can be leveraged by bad guys. You need to weigh this against any slowness to fix the issue (99.99% of companies will fix the issue). Protecting users can be a tricky line to walk in this scenario.

Also, Security fixes might seem simple from the outside, but there might be hidden complexity or dependancies that you don't see. Or worse your report is only the tip of the ice berg and there is a much larger issue that they will have to tackle all at once (and the company won't share these related issues in order to protect their users and reputation).

Giving them the extra time will achieve the goal of getting the bug fixed and protecting users. If you suspect the bug is actively being exploited you can always email them and share your concern/frustration with the timeline.

My core advice is try your best to communicate with the company and inform them of your thoughts and concerns.

[jacalata]

I think it's reasonable to expect a response or acknowledgement in a week, not necessarily a fix.

[seanieb]

Totally agree. However, I feel the correct response in that situation is to criticize them when you publish, rather that publishing before the fix.

[deckar01]

I think waiting for Coursera to resolve the issue isn't too much to ask. They seem cooperative, and it was a holiday weekend.

[nknighthb]

If there was irresponsibility in the disclosure, it was in waiting so long, presumably allowing many more people to sign up and become exposed to Coursera's negligence.

The cargo cult of "responsible disclosure" needs to die. Responsibility lies with us, the developers.

[shortstuffsushi]

Well, yes and no. Ultimately yes -- Coursera should have been more diligent about considering the implications of their API endpoints.

On the other hand, telling the whole internet before they've addressed the items he told them about, and potentially opening them up to more scrutiny (likely less white-hat like) is not an especially helpful thing to do.

[nknighthb]

Coursera is a large, high-profile site. I am quite certain it did not take a law professor's blog post to bring black-hat scrutiny to it or any other site, server, or technology deployed on the public Internet.

[shortstuffsushi]

It may or may not have. These holes have been present presumably since the launch of these APIs. However, the author has now made public specific vectors of attack. You may be right that hackers have already been aware of them. In either case, does making these publicly known benefit Coursera, or its users in any way? I can't think of how it could possibly help, but I can certainly see how it might hurt -- anyone who comes across that page now might feel the urge to further 'explore' these findings.

[nknighthb]

It's telling that your first concern is for Coursera (which deserves no concern at all) and only then its users.

There are definite benefits for Coursera's existing users -- at the very least, they now know it is vulnerable to cross-site attack and can be sure to log out before visiting other sites.

Another set of people clearly benefiting are those I've already alluded to, who now know not to sign up for Coursera.

[shortstuffsushi]

I'm not really sure how you infer the first line there. I'm in no way defending Coursera -- clearly they need to run their services through some better security checks.

I still generally disagree with your second point -- informing users of a security breach/flaw could (and should, even now after this article was published) be done by Coursera. In this situation, they should be the ones who come forward to their users and A. describe what the issues at hand are and B. describe how to avoid falling victim to them. The author of this article doesn't provide any suggestions for the non-tech-savvy.

Regarding users not signing up, perhaps you're right. It does prevent them from potentially losing their private information. In all likelihood, though, users who don't sign up after reading this article will never sign up. Yes, I realize this primarily hurts Coursera, so in this case, my concern is for them. It also means that potential users miss out on whatever they might gain from the site. A better option that Coursera itself might offer is a temporary "hey, we aren't accepting new users right now -- check back in a week" or something.

And again, I do not believe Coursera should just forgiven for something like this. As I mentioned, I've never been on the site, probably never would, and now am even less likely to do so, as I have no faith in them. I still don't believe that publishing open security holes is the right solution, unless they specifically said something along the lines of "yeah, we're not gonna fix that."

[Afforess]

I love how the security researcher, and not the website with the sloppy code, is at fault according to you. You live in a strange world, my friend.

Responsible disclosure doesn't really exist, bugs may be used anywhere, any time, and it's perilous to assume that there is a window of "safety" for fixing security bugs.

[pyre]

I love how all blame can be assigned to a single entity, and it's not possible for multiple entities to act irresponsibly. You live in a strange world, my friend.

Edit (since you added more):

> Responsible disclosure doesn't really exist, bugs may be used anywhere, any time, and it's perilous to assume that there is a window of "safety" for fixing security bugs.

It is true that you can't assume that there is a window of "safety" for fixing security bugs, but on the other hand, once an exploit is published widely, you know for certain that it's in the hands of everyone. Prior to that you can only speculate.

Now, I know that there is a dance between "give them time to patch it before you guarantee that everyone has their hands on the exploit" and "giving users full disclosure so that they can take their own steps to protect themselves." I don't really see how that works here though. Thinking about it:

1. Current users are just screwed. They can't protect themselves in any meaningful way. Their information is already in the system. [Note: they are a little less screwed without disclosure because there is at least a possibility that no one else has found the exploit yet]

2. New users know to wait to get on the site until after fixes are announced.

That's about it. This isn't some exploit in (e.g.) GnuPG where notifying users potentially prevents them from sending encrypted messages that (e.g.) the NSA could be reading.

Edit 2:

I missed the CSRF attack. In this case, it makes sense to notify users so that they can protect themselves. But users don't need to know the details of the attack to protect themselves. They just need to know that they shouldn't visit other sites while logged into Coursera. A blog post saying "details to follow..." could post the write-up after waiting a reasonable amount of time for a fix.

[Afforess]

I never assigned blame.

[pyre]

> is at fault

According to Wikipedia:

  Blame is the act of censuring, holding responsible,
  making negative statements about an individual or
  group that their action or actions are socially 
  or morally irresponsible, the opposite of praise.

I would say that claiming (via sarcasm) that the company that did the "sloppy coding" is "at fault" qualifies as blaming them. You're defacto blaming them by deflecting "fault" away from the security researcher to them.

[manicdee]

You assigned blame to the website.