Hacker News CSRF Vulnerability | Hacker News Reader

Hacker News CSRF Vulnerability

tjosse.me

173 pointsetjossem55 comments

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.

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

> 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 :)

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

The high value statement that got my attention was this: "Arrogance and vulnerabilities are a bad mix."

This applies to all parties- the ones who are vulnerable and the ones who are discovering.

I totally agree with your statement about reporters inflating the impact of minor bugs. In fact, it is the spirit of arrogance which they exhibit that attracted me to OP's comment!

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.

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.

Plus if you made the account name "new" or "top posts" or something, it could take weeks for me to notice that it didn't say my username at the top right.

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

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.

Another reason for customizing "topcolor" in your HN profile :)

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... [2] http://scarybeastsecurity.blogspot.com/2010/01/logout-xsrf-s...

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. :)

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?

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

Gotcha.

I agree that depending on the context session fixation and login CSRFs can have actual security impact, but those cases are far and few between, so calling them a "serious flaw" feels a bit hyperbolic to me.

Gmail account contacts were stolen in a CSRF attack (combined with another vulnerability). This type of attack is often overlooked, but it's very real.

http://archive.oreilly.com/pub/post/gmail_exploit_contact_li...

As far as I can tell that particular vulnerability isn't a CSRF at all, it's an insecure JSONP endpoint[1]. The original author is mistaken.

[1] http://homakov.blogspot.com/2013/02/are-you-sure-you-use-jso...

CSRF attacks are very real, but the impact is generally taken into account before calling things a "vulnerability".

e.g you can have a SQL injection that's not a vulnerability because the input passes through a substr($_GET["id"],1,1).

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.

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.

you could have an API that returns a CSRF token.

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

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

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

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

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.

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.

Correct. By "a valid token" I mean one that corresponds to the user session it was dispensed to.

> the attacker just requests a valid one

How?

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.

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

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.

That works if you have sessions. HN doesn't.

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

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

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

It does. We haven't rolled out the fix that Nick described (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.

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

I have implemented CSRF for the public API I work on and all PUT/POST requests require the CSRF token, not GET requests. In this case, the login form uses a POST request and thus must require a CSRF token to avoid an attack on users that aren't logged in.

What stops an attacker from requesting the CSRF token?

Same-origin policy.

That only applies to browsers. I can request it from my server just fine. See https://news.ycombinator.com/item?id=11178922

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

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

The negative response tends to be against the super low impact ones, such as this.

I have to agree with the GP, blogging about an issue like this just seems tacky.

The reactions would undoubtedly be different if it was a practically exploitable CSRF, like something that allows you to change users email addresses.

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

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

How would you go about proving that?

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

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.

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.

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.

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.

Reply on news.ycombinator.com