
A Funny Thing Happened on the Way to Coursera - boynamedsue
http://webpolicy.org/2014/09/04/a-funny-thing-happened-on-the-way-to-coursera/
======
frankchn
Here is Coursera's official response:
[http://blog.coursera.org/post/96686805237/response-to-
report...](http://blog.coursera.org/post/96686805237/response-to-reported-
vulnerability-in-instructor-access).

We have already implemented fixes and mitigation strategies for all of the
vulnerabilities - including completely disabling type-ahead hinting for email
address on our instructor interfaces (instructors must now enter the complete
email address of a learner in order to manually enroll him or her in the
instructor's course) and rate limiting and referrer header checking on APIs to
slow down and stop enumeration attacks by third parties to discover learner
enrollment status for courses.

Finally, we would like to thank Dr. Mayer for reporting these security
problems and helping us make Coursera a more secure and privacy conscious
platform for our learners.

------
empressplay
Tech debt is like monetary debt -- you still have to pay it back, and quick.
When it's security / API related debt, you have to pay it back even quicker,
because if you don't, someone inevitably forecloses on your metaphorical house
and repossesses your metaphorical car.

~~~
mathattack
The analogy I like is, "If you have too much technical security debt, someone
will eventually report you to the credit agency"

------
yeukhon
> I reported the issue to Coursera on Sunday, and I have not yet received a
> response. Possible remediation steps include rate limiting (again), referrer
> checking, and configuring APIs to always return the same HTTP status.

Wouldn't the 2nd issue (the cross-origin data leak) be better off solved by
having a CSRF token instead?

~~~
shortstuffsushi
That would presumably solve this issue. Perhaps that is what they will end up
doing -- hard to say since they haven't addressed this issue yet. The author
was guessing at solutions that might help (though, as you've noted, he was
mostly off base).

~~~
yeukhon
I don't mean to say his suggestion is bad. For what it is worth, I just want
to clarify this :) I too, am not too good with security stuff either (still
learning!) and thanks!

Seriously though, he's the kind of privacy person you wouldn't think you'd be
listening to a law textbook because he obviously is pretty good with web
technology.

~~~
shortstuffsushi
Hey, you've got other interests aside from coding, don't you? Some people like
to bike, some like to play games, some like to study law. Some like to do all
three ;)

------
javert
Accepting a role in an organization, only to turn around and immediately
publicly humiliate and embarass them (for no good reason[1]), is just about
the biggest dick move one can make.

I hope this guy finds his 5 seconds in the limelight to be worth sacrificing
his common decency to.

[1] Because they appear to be in the process of addressing the issues in a
timely manner.

~~~
joshschreuder
Well I don't think it's really a role in an organisation, so much as a user of
that organisation's product from what I can see. The author appears to be
teaching some course on Coursera later this year, not working directly for
Coursera.

It's probably more like a Facebook user finding a security exploit, disclosing
(responsibly or not as has been discussed in this thread), then posting a blog
on their findings, rather than one of Facebook's team posting a blog talking
about how bad Facebook's security is.

------
ivanhoe
Hiding the IDs doesn't have to be a security feature at all. Maybe they just
didn't want to publicly show how many students they've got, simply for
marketing reasons?

~~~
allochthon
There is a benefit in having an id used in APIs that is difficult to iterate
through sequentially or otherwise anticipate. I'm guessing the "internal" id
is a surrogate key in a database, which normally wouldn't be used in other
contexts.

------
magicarp
Was Coursera contacted before this was published?

~~~
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.

