Common security issues with crypto websites and APIs | Hacker News Reader

Common security issues with crypto websites and APIs

introvertmac.wordpress.com

90 pointsintrovertmac34 comments

A bit of a side-note, but this needs to be said: articles like these should be a good wake-up call for crypto users that are still using web-based wallets (and their accompanying apps for mobile platforms) especially for storing LARGE amounts of cryptocurrency -- you're essentially trusting a third-party exchange (with many of them using opaque ToS and PP) with your private keys and as a result your funds (especially those platforms that don't use multi-sig architecture). And crypto exchanges' data breaches/hacks is getting more common by the day. [0]

Even Bitcoin.org has stopped recommending web-based wallets, like they were doing just a couple of years ago.

The best alternative is hardware wallets, but a good middle-ground is using self-managed, 'semi-cold' software wallets like Electrum, Armory, etc. [1][2]

[0] https://selfkey.org/list-of-cryptocurrency-exchange-hacks/

[1] https://www.buybitcoinworldwide.com/wallets/online/

[2] https://bitcointalk.org/index.php?topic=1741339.0

Be careful with your personal data even with hardware wallets. Literal physical attacks are possible with things like the Ledger data dump. [0]

[0] https://www.bleepingcomputer.com/news/security/physical-addr...

#1 is actually another issue in itself. You should never blindly accept X-Forwarded-For. Why would you let the client modify its own IP address? X-Forwarded-For is used to allow proxies (such as nginx) to forward the client’s IP so that the application server uses the client IP and not the intermediate proxy IP. For example, with NodeJS Express, by default it only accepts X-Forwarded-For from local requests. You can add additional IPs or ranges so you can “trust” the header from your load balancer as well, or make it trust X number of hops. I’m sure other web servers have something similar.

P.S. I've just complied few of recent findings from crypto websites. These issues are applicable to any website or REST APIs.

This post is not about security vulnerabilities in blockchain, smart contract or crypto protocols.

Nice compilation, thanks

The last part on session management is a critical and very common vulnerability.

Session time-out due to inactivity is critical.

In fact, “hacking” companies like NSO steal authentication tokens of services like gmail that DELIBERATELY do not log you out for inactivity for periods like 30 days.

How do you steal session cookies without having access to an end user device (in which case you could steal passwords and short lived cookies just as easily)?

Mostly through XSS and combining other security issues

I personally consider automatic logouts to be in the same category as periodic password rotations: a defense in depth idea that so badly impedes accessibility that it isn't worth it. It is common to type 1-2 passwors into a computer to before getting to the browser, so why isn't a trusted device a reasonable threat model?

I think it is a personally reasonable threat model to consider anyone capable of stealing a token off of my device as capable of stealing my password because if a website has other vulnerabilities allowing credentials to be stolen or misused without my device being compromised then it is a defense in depth technique and it is to cover the ass of the website operator and not me. I shouldn't be liable for a website owner's screw up there.

Now, a genuine two factor authentication changes the picture there and actually adds some security for ultra risky scenarios (like transferring money). But instead of invalidating my session, just ask for a token on every risky transaction. There I can understand a bank wanting to cover their liability a bit more.

Great point!

They say these are common issues - but don't actually link to any websites which have these issues.

Disabled input fields are fine - so long as they are ignored on the backend - and there's nothing in this article saying they aren't.

Nothing here seems specific to "crypto" websites.

Indeed, but the crypto keyword made us click on the article. Otherwise it would have been quite a common article with some commonsense advices on basic web security...

I genuinely tried to complied the issues and yes, most of them are crypto websites.

Sorry for any confusion created by the title!

The fact that makers of those websites are supposedly 'crypto' experts (and should as such probably not be completely ignorant of information security) makes the presence of such vulnerabilities in their websites more appalling than the same vulnerabilities in your average Joe's webapp.

Security disclosure and private work have some responsible disclosure policies.

I've added added the public bug bounty website for the last one!

Couldn’t you also avoid rate-limits and such with setting your own X-Forwarded-For header? I guess the site operator should have been a bit more vigilant and used the Cf-Connecting-IP header in that specific case.

There could be n numbers of ways to prevent this but saving user inputs without validation is always a bad idea.

The server should only accept the header from trusted proxies (like nginx, your load balancer, etc). If #1 is possible, you have a bigger problem of letting the client send any arbitrary IP.

You need to block traffic at the origin from anyone except your CDN or proxy, and the CDN or proxy must not accept such headers, they must set them themselves.

Depending on your set-up you may need to use one or both of those headers. For example, you might use CloudFlare for some requests and CloudFront for others, as you may find one or the other to be cheaper or faster for specific content. So you may need to allow both headers at your origin's reverse proxies, but distinguish between which to accept and where to redirect the traffic based on the Virtual Host and request URI.

> No matter what variation of auth token you are using, make sure you are not just encoding BASE64 of user data like user ID and some timestamp.

Seriously, at the end of 2020 this kind of advice is necessary?

Yes. Software engineers about double in numbers every 5 or so years.

Most of the field has never heard this advice before.

For any given bit of common wisdom, to many people it’s completely new advice: https://xkcd.com/1053/

Good point! Hmm, the xkcd, "mentos", what's that, apparently I don't need to know in my life

Yes, it is :P Saying sorry on behalf of whole 2020 :)

Is (was) necessary also for one or more crypto currency websites?

Seriously what kind of world do you live in where this kind of advice is not necessary?

I don’t understand point 2. Can anyone please explain how a disabled input with .value == "<script>...</script>" is a security issue?

That is basically injecting JS to trigger XSS (running user's code on the application)

Your description about the issue is sketchy, there is nothing wrong with disabled input fields but it it sounds like you are making that an issue while the actual issue would be parsing those fields in the backend.

Maybe I was not able to make it clear - what I meant was "if you can inject arbitrary code in disabled fields and the system is using those JSON data elsewhere, it can lead to injection attacks"

The whole idea is validate the user inputs - be it disabled fields or normal inputs

It is more “sanitize” than “validate” then. Saying that you need to sanitize disabled or normal fields in “crypto websites” is like saying that you need to put handrails on 7th floor of a red building to prevent falling down. But in reality you may fall from any height that has no handrails, and 7th floor and a red decoration aren’t specific requirements for falling.

I’m not trying to nitpick here, my confusion was genuine. These sorts of statements are hugely misleading even for seasoned folks (“what if I missed something in disabled inputs? why crypto suffers from that?”), and in novice developers it creates magic recipe thinking instead of generic awareness that you never want to execute(user_input).

You made a good point but accepting JS in a currency field requires validation + sanitization.

Validate for functional errors then sanitize for injection issues.

Hope it makes more sense now! Sorry for any confusion from previous comments or post

I still don’t get it. Some code may use .value, store it, parse it, send as a part of a form, etc. How is that a security issue? If you meant that evaluating strings (as in eval(s) or el.innerHTML = s) is dangerous, then okay, but why this exact location - disabled inputs? One can eval(from_any_source) if they are unaware.

Didn't knew this before even when I was working in a fintech company,very informative.

What about your coworkers? If there were senior people too, who thought about such things

Reply on news.ycombinator.com