Hacker News new | ask | show | jobs
by imaginenore 4248 days ago
> First, XSS. If Coinbase ever has an XSS vuln which allows JS to execute in the same context as their crypto key generation, then that attacker can silently siphon keys as they're being generated

So a very very very specific XSS vulnerability that affects the key generation process. I'm pretty sure that can be solved by not allowing any user input during the generation.

> Second attack vector: Third-party JS libraries. If Coinbase is loading JS from any external source

So don't load any external JS libraries on the key-generating pages.

> The third attack vector, which a sibling comment mentioned, is a rogue browser extension.

That's ridiculous. If you download malware on any OS, and allow it to run, it can do whatever within whatever permissions you allowed. Malware has been stealing money and identities long before Bitcoin was invented. Users need to learn not to install crap.

That can also be solved at the browser level - a website should be able to request a secure extension-less mode.

2 comments

> So don't load any external JS libraries on the key-generating pages.

And anywhere else. The local banks in my country are not doing this. And a wallet site shouldn't ether. Even the coinbase login screen pings olark.com all the time.

Oh, and if you look at their CSP report sending back home, the original-policy is quite scary.

"original-policy":"default-src https://www.coinbase.com https://*.olark.com; connect-src https://www.coinbase.com wss://ws.pusherapp.com https://api.mixpanel.com; font-src https://www.coinbase.com https://*.olark.com; frame-src https://www.coinbase.com https://*.wpstn.com https://h.online-metrix.net https://*.siftscience.com; img-src https://www.coinbase.com https://i2.wp.com https://secure.gravatar.com https://secure.etrust.org https://ssl.google-analytics.com data:; media-src https://www.coinbase.com https://*.olark.com; object-src https://www.coinbase.com https://*.olark.com; script-src https://www.coinbase.com 'unsafe-inline' 'unsafe-eval' https://stats.pusher.com https://cdn.siftscience.com https://*.newrelic.com https://*.google-analytics.com https://www.google.com https://www.youtube.com https://*.ytimg.com; style-src https://www.coinbase.com 'unsafe-inline'; report-uri https://www.coinbase.com/csp-report","referrer":"","violated... https://www.coinbase.com 'unsafe-inline' 'unsafe-eval' https://stats.pusher.com https://cdn.siftscience.com https://*.newrelic.com https://*.google-analytics.com https://www.google.com https://www.youtube.com https://*.ytimg.com"}}

A hypothetical extension-less mode isn't a bad idea. Unfortunately, it doesn't exist.

An XSS attack in an unrelated part of the webpage can escalate. If someone hijacks the session key of an admin, they get access to the admin panel. That access may or may not let them further escalate their privileges. If they manage to break into the box that serves the JS for the key generation page, then they can alter the JS however they want, including so subtly that no one will notice it's broken. Think this is unlikely? Privilege escalation attacks like this happen all the time. Again, the potential payout for a successful heist is in the range of millions, and due to bitcoin mixers, they're less likely to be caught.

Also, I bet at least one person reading this has the "Cloud To Butt" extension installed. It's not only untrained users who install that sort of thing.