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