
Hacker News CSRF Vulnerability - etjossem
http://www.tjosse.me/articles/csrf-on-hn/
======
vardump
When it comes to security vulnerabilities, please remember when reasoning
about their impact there's a good chance you'll miss something critical.
Arrogance and vulnerabilities are a bad mix.

Even innocent looking "low impact" issues can be used as stepping stones to
something much worse.

Creative exploitation can make two or more low impact vulnerabilities into a
very serious compromise. Some of those vulnerabilities might be in a
completely different system.

~~~
droopybuns
This should be required reading for anyone submitting vulnerabilities to bug
bounties.

~~~
david_shaw
_> This should be required reading for anyone submitting vulnerabilities to
bug bounties._

In my experience, people submitting vulnerabilities to bug bounties tend to
incorrectly estimate in the _other_ direction, since they have financial
incentive to do so.

You replied to a comment indicating that even minor bugs can be serious --
which they can -- but many researchers will find _actually_ minor bugs (nginx
version disclosure, existing account enumeration on signup page, etc) and
claim they're critical.

There's a balance there, and it can be tough to find. In any event, my stance
is that if there's a security bug, you should damn well fix it :)

~~~
vardump
> In my experience, people submitting vulnerabilities to bug bounties tend to
> incorrectly estimate in the other direction, since they have financial
> incentive to do so.

A good point. There's definitely motivation to exaggerate the impact.

However, could there be a flip side to this as well?

People _not_ reporting vulnerabilities _they_ consider minor, thinking they'll
get no financial gain. No money or fame, so why bother?

Some of those unreported issues could be very critical when connected with
something else minor or perhaps even something that's not a bug at all.

Perhaps some of bug bounty funds should be retained for awarding any reported
issues that turned out to be a (part of) critical vulnerability in the future?

Retroactively awarding issues that became more critical later on should
encourage reporting of _maximum_ number of bugs. Even those the discoverer
considered insignificant.

As a result, everyone involved would be better of. More bugs would get
reported and their discoverers properly compensated.

> ... minor bugs (nginx version disclosure, existing account enumeration on
> signup page, etc) and claim they're critical.

Wouldn't you agree it's preferable they're reported regardless, no matter how
minor they may be? For example unintended version disclosure could very well
make targeted attack a successful one. Account enumeration disclosure could
conceivably be used to attack the account holder in some other way, including
social engineering attacks.

------
lucb1e
Although I can totally see how this is a vulnerability, the implications are
quite limited. Basically you can log people out for fun, and you can log them
in to an account of yours, which I think would be noticed quite soon.

~~~
etjossem
The implications depend on your app. If the user doesn't notice being logged
into a new account, they may go on to create data in the attacker's account
that they expect to be private (e.g. YouTube watch history).

On e-commerce sites, they might add a credit card - thereby allowing the
attacker to use it.

Fortunately, HN doesn't have these risks, but it's a good illustration of how
CSRF works in the real world.

~~~
lucb1e
Good points indeed. I never thought of adding anti-CSRF measures to login
forms, only while logged in, so I'll start doing that :)

~~~
r1ch
Another good reason for login CSRF tokens is to prevent a malicious page from
submitting lots of invalid logins and getting an account / IP locked or rate
limited.

------
zer01
Both Michal Zalewski[1] and Chris Evans[2] have commented on this, and I tend
to agree with them. The actual implications for a CSRF like this are very
minimal.

[1] [https://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-
not...](https://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-
design.html) [2] [http://scarybeastsecurity.blogspot.com/2010/01/logout-
xsrf-s...](http://scarybeastsecurity.blogspot.com/2010/01/logout-xsrf-
significant-web-app-bug.html)

~~~
tptacek
The implications for HN are minimal, but this is a login CSRF, not a logout
CSRF. Like session fixation, login fixation is a serious flaw.

Believe it or not, there have been apps with serious flaws stemming from
logout fixation --- but those flaws were notable because they weaponized
logout CSRF. :)

~~~
rudolf0
What exactly is "logout fixation"? Session/login fixation makes sense, but I
can't really imagine what logout fixation would look like. Google was of no
help, either. Do you mean a logout function which doesn't properly log you
out, or logout CSRF?

~~~
tptacek
Sorry, that's a typo. I meant "logout CSRF".

~~~
rudolf0
Gotcha.

------
bcg1
I disagree with those saying that the impact of this type of attack is
minimal.

Depending on the application it could significant implications. Imagine for
instance if this was possible in an application, and after switching to the
attacker's account the victim was tricked into doing an OAuth to some third
party service.

------
slavik81
Interesting. Is this why login is usually on its own page, rather than right
on the main page? CSRF seems to limit your ability to cache any pages that
contain forms.

~~~
malka
you could have an API that returns a CSRF token.

------
stygiansonic
Whether or not the implications of this particular CSRF vulnerability were
serious, the developers should be commended on implementing a fix quickly.

------
cmdrfred
Nice find it goes to show you that nearly everything has some sort of
vulnerability. Adding anti-forgery tokens to my login page now...

------
ymse
Would this still work with 3rd party cookies disabled?

In the years I've used uMatrix[0] I can't remember a single case where sending
a cookie with a 3rd party request was needed. Why do browsers do this still?

0: [https://github.com/gorhill/uMatrix](https://github.com/gorhill/uMatrix)

------
hatsunearu
I'm not too well versed on netsec; how do you fix something like this?

~~~
etjossem
To mitigate CSRF on a form, send the user a randomly generated, long, unique
token every time the form is rendered. Put it in a hidden input.

Your server must expect the POST to answer back with a valid csrf token.
Otherwise, the request results in an error and doesn't go through. Attacker
pages won't know anything about the csrf token, so they can't forge the form.

~~~
kogir
That's actually not always enough. For example, to fix this login CSRF on HN,
you need a per-visitor secret an attacker can't read (like a cookie) plus a
form value _based on that secret_. Note it can't be tied to the user account,
because the visitor hasn't logged in yet.

A random CSRF token on a login form is easily defeated - the attacker just
requests a valid one and uses it when submitting the CSRF form.

~~~
jonny_eh
> the attacker just requests a valid one

How?

~~~
kogir
wget, curl, whatever. If I'm the attacker, I ask for a new one from my server
each time and put the result in the form I serve your browser.

~~~
r1ch
The CSRF token should be tied to the user session, so you'd need to perform
session fixation for that to work.

~~~
ubernostrum
Tying to the session is a common practice but not necessary. You can do non-
session-tied CSRF tokens so long as you don't expose your cookie.

------
Osiris
So what was the fix? I don't see a CSRF token in the login page, so I'm
curious what their patch was.

~~~
philmander
The logout link is rendered with the token in its query string

~~~
VoidWhisperer
Wouldn't this still allow logging in without consent if they aren't logged in?

~~~
dang
It does. We haven't rolled out the fix that Nick described
([https://news.ycombinator.com/item?id=11178922](https://news.ycombinator.com/item?id=11178922))
because it will probably break a bunch of the third party apps and scrapers
that give people alternative interfaces to HN. Those have value and I'd rather
not make their lives more difficult unless/until it's necessary.

~~~
qjighap
Finally, some clarification on which hacker news it is. I care less about the
hacker news with the "the"

------
_asdf_asdf
Ah, CSRF, the irritatingly low-hanging fruit that every would-be security
researcher pre-emptively attacks for attention.

~~~
ronnier
I don't understand the negative response towards CSRF exploits. They are real
and they are dangerous.

~~~
krapp
If this had been reported in any other web application, everyone here would be
calling the developers morons.

~~~
ChristianBundy
If it's such a low-hanging fruit why don't you prove it?

~~~
ubernostrum
It's more that if literally any other site on the internet were found to have
any type of CSRF vulnerability, people here would be going on and on and on
about how this is web dev 101, only a complete idiot wouldn't know
about/secure against CSRF attacks, etc.

Whereas here, when it's HN with a CSRF issue, "eh, it would break some third-
party clients if we patched this".

~~~
dang
Tell me more about this world in which HN's users shield its developers from
criticism.

We fixed the reported vulnerability and have a fix for the remaining issue
ready if it's needed. There's no "eh" here; it's a question of what the right
tradeoff is.

~~~
ubernostrum
Well, I don't see people insulting you the way they would if it were another
site...

And I don't see people calling out the "breaks third-party clients"
justification for not rolling out the full fix.

~~~
dang
Since you're a "people here", your comments disprove themselves.

A phrase like "calling out" assumes that it's obvious what we should do. It's
not obvious; the parts that were obvious are done. Our goal is to do what's
best for the community, not to avoid getting criticized on the internet.

~~~
ubernostrum
_Since you 're a "people here", your comments disprove themselves._

If I were going to respond to you the way I feel HN would generally respond to
a CSRF hole in a major non-HN site/service, I'd say something like "Well, that
line shows you're as good at formal logic as you are at preventing/patching
CSRF holes".

You know the same as I do that HN's getting light treatment from its users in
this thread, compared to how security issues in other things typically get
received. It's OK to admit that.

