Common security issues with crypto websites and APIs | what I'm breaking...

There are many crypto startups coming up with the increasing popularity of cryptocurrencies.

As a FinTech enthusiast, I explore as many crypto websites, wallets, DeFi systems as possible and as a bug bounty hunter – I get to test some of them. 

This week I tested a couple of crypto applications and there seems to be a pattern in security vulnerabilities among these applications. 

Most of these security issues were related to injection, bypassing disabled forms, and access control. 

Let’s see each one of them with example:

1. Injection via X-forwarded-for header:
   As a general practice most crypto websites save log-in IPs and have some functionality around IP whitelisting.
   
   an example of login notification – also present in the dashboard
   
   Without a proper validation on the server side, this field can be injected using XFF header.
   These Injection can range from a harmless XSS to server side code injection, here’s an example:
   
   
   an example of XFF injection
   
   Most of these application uses REST architecture, hence these API injections can lead to severe damage depending on where you are using these JSON fields.
2. Bypassing disabled input fields:
   Some of the input fields are disabled in the dashboard (of crypto/FinTech websites).
   In most cases, these fields are name, username and email – disabling them make sense because these fields shouldn’t be updated regularly for KYC and compliance issues.
   
   Just disabling them from HTML forms on the client side is a bad idea, it can be easily bypassed through a browser proxy like Burp and Zap.
   
   Sometimes even fields which aren’t supposed to be updated like currency, language and timezone can get injected.
   
   here’s an example:
   
   
   Again, because of REST architecture if you are using these user data elsewhere – it can create injection issues ranging from XSS to server side code execution
3. Access control: This one is complex and deep topic but I’ll share two examples: weak auth token and improper session managements.
   
   There are many ways to authenticate a user in REST from HTTP basic auth, JWT to a complex implementation of cryptography. 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.
   
   In case of JWT, use a longer secret with HMAC enabled, RS256(asymmetric algorithm) is recommended over HS256(symmetric) is the alg header.
   
   Also, there are some known issues with JWT, you can read more about it at https://www.cvedetails.com/product/35664/Jwt-Project-JWT.html?vendor_id=16053 and https://auth0.com/blog/brute-forcing-hs256-is-possible-the-importance-of-using-strong-keys-to-sign-jwts/
   
   Coming to session management – the most common issue here is session fixation.
   It is recommended to end the session when a user log-out. All the cookies and session ids shouldn’t work in a new session but that’s not the case most of the time.
   
   In some cases, even where new session IDs are generated old session IDs are not disabled.
   This was the case with Remitano, where I submitted the issue in their bug bounty program on Hackerone:
   Here is the video POC for the same:
   https://youtu.be/543g_6UbIS0
   
   Again make sure, session IDs are not predictable.

That’s all for now, hope you found this short post useful.
And if you are a crypto or FinTech startup and looking for security audit or hiring security engineers – we should talk

If you have any questions, suggestion regarding this post – feel free to reach out on my Twitter.

P.S. Can’t name websites as per their security and responsible disclosure policies but Remitano(the one with session fixation issue) has a public bug bounty on Hackerone.