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]<p>Even Bitcoin.org has stopped recommending web-based wallets, like they were doing just a couple of years ago.<p>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]<p>[0] <a href="https://selfkey.org/list-of-cryptocurrency-exchange-hacks/" rel="nofollow">https://selfkey.org/list-of-cryptocurrency-exchange-hacks/</a><p>[1] <a href="https://www.buybitcoinworldwide.com/wallets/online/" rel="nofollow">https://www.buybitcoinworldwide.com/wallets/online/</a><p>[2] <a href="https://bitcointalk.org/index.php?topic=1741339.0" rel="nofollow">https://bitcointalk.org/index.php?topic=1741339.0</a>
#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.<p>This post is not about security vulnerabilities in blockchain, smart contract or crypto protocols.
The last part on session management is a critical and very common vulnerability.<p>Session time-out due to inactivity is critical.<p>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.
They say these are common issues - but don't actually link to any websites which have these issues.<p>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.<p>Nothing here seems specific to "crypto" websites.
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.
> 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.<p>Seriously, at the end of 2020 this kind of advice is necessary?
I don’t understand point 2. Can anyone please explain how a disabled input with .value == "<script>...</script>" is a security issue?