5 ms·
Hacker News CSRF Vulnerability
- lucb1e 11y agoAlthough 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 11y agoThe 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 11y agoGood points indeed. I never thought of adding anti-CSRF measures to login forms, only while logged in, so I'll start doing that :)
- r1ch 11y agoAnother 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.
- ghayes 11y agoPlus 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.
- 0x0 11y agoAnother reason for customizing "topcolor" in your HN profile :)
- zer01 11y agoBoth 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-to-design.html https://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not... [2] http://scarybeastsecurity.blogspot.com/2010/01/logout-xsrf-significant-web-app-bug.html http://scarybeastsecurity.blogspot.com/2010/01/logout-xsrf-s...
- etjossem 11y agoGmail 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_list_hij.html http://archive.oreilly.com/pub/post/gmail_exploit_contact_li...
- zer01 11y agoAs 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-jsonp-properly.html http://homakov.blogspot.com/2013/02/are-you-sure-you-use-jso...
- ryanlol 11y agoCSRF 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).
- tptacek 11y agoThe 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. :)
- 11y ago
- stygiansonic 11y agoWhether or not the implications of this particular CSRF vulnerability were serious, the developers should be commended on implementing a fix quickly.
- vardump 11y agoWhen 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 11y agoThis should be required reading for anyone submitting vulnerabilities to bug bounties.
- david_shaw 11y ago> 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 11y ago> 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.
- Osiris 11y agoSo what was the fix? I don't see a CSRF token in the login page, so I'm curious what their patch was.
- philmander 11y agoThe logout link is rendered with the token in its query string
- VoidWhisperer 11y agoWouldn't this still allow logging in without consent if they aren't logged in?
- _asdf_asdf 11y agoAh, CSRF, the irritatingly low-hanging fruit that every would-be security researcher pre-emptively attacks for attention.
- ronnier 11y agoI don't understand the negative response towards CSRF exploits. They are real and they are dangerous.
- krapp 11y agoIf this had been reported in any other web application, everyone here would be calling the developers morons.
- ChristianBundy 11y agoIf it's such a low-hanging fruit why don't you prove it?
- ubernostrum 11y agoIt'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 11y agoTell 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.
- 11y ago
- cmdrfred 11y agoNice find it goes to show you that nearly everything has some sort of vulnerability. Adding anti-forgery tokens to my login page now...
- slavik81 11y agoInteresting. 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 11y agoyou could have an API that returns a CSRF token.
- bcg1 11y agoI 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.
- hatsunearu 11y agoI'm not too well versed on netsec; how do you fix something like this?
- etjossem 11y agoTo 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 11y agoThat'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 11y ago> the attacker just requests a valid one How?
- ymse 11y agoWould 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