Considering all the security issues with the Bitcoin ecosystem and the resulting mistrust, I think you need to be very explicit about your security.
- There's no Bitcoin wallet. Most incidents happen with stolen or lost wallets. Bitcoinica holds all the money and coins in traditional banks and other exchanges (currently only Mt. Gox).
- Bitcoinica runs on Heroku. Generally apps hosted in the cloud are more secure. Ruby on Rails itself is very secure too. (protect_from_forgery, html escape, force_ssl, etc)
- No account minimums. If you're unsure, you can deposit $1 first and try to do some trades.
- Margin trading. This reduces risks. You don't have to deposit 100 BTC worth of USD when you want to long/short a 100 BTC position. 20 BTC is enough. Only when you lose a lot, you can consider adding more margin.
I think trust is a common problem for all websites like Bitcoinica. That's why we designed the platform in the way that attempts to solve the fundamental problems.
There's instant deposit and withdrawal too. You can transfer money from Mt. Gox when you want to trade and transfer it back after you close your position. (Assume that you trust Mt. Gox.)
Uh-oh. Ruby on Rails has a lot of default settings that are decidedly not secure; our own Patio11 wrote an article on this topic for the CACM not too long ago.
You might want to sit down with a security professional before too long, and get an outside opinion on your code.
- SQL Injection
- Source being viewed
- Financial attacks
I believe that Rails has no problems with SQL injection? All my database queries are going through ActiveRecord.
Heroku protects everything nicely. Even the filesystem is read-only. There's virtually no way to control the server provided Heroku's 3-layer architecture (Varnish, Nginx and Thin).
We don't operate a Bitcoin wallet. Basically hackers have nothing to steal. Even if we are totally owned, the most that hackers can do is to get some free money and make some trades. After all, we can obviously identify and not to approve withdrawals (for unusual and large-amount ones).
(i) You don't know enough about appsec to be communicating things about the trustworthiness of your application.
(ii) Any feedback you're given about the threats your application faces is just going to get added to your list of "security challenges" you are aware of or have tried to address, which implies that anything anyone does to help you with your security is just going to be used to mislead others. No thanks!
I'm thrilled at the idea of a 17 year old building applications that need serious security countermeasures and would generally love to help. But not when the stakes are "other people's money".
You should pick a different project. For a variety of reasons. How about take your Bitcoin exchange and do (another) play-money exchange, like for a prediction market?
P.S. I used to participate on a prediction market. Was winning the Internet after going all in on three presidential elections. Got wiped out by JPY breaking a hundred two years too late for my contracts to pay. Did not jump out window.
That sounds pretty serious, and also a very laxidasial attitude to the security of money. You want me to give you some of my money?
People aren't worried with being hacked per se, we're not too concerned with if your server stays up, or if someone writes a temp file or if they make your heroku bill go really high. 'Security' in this case means my money and/or my bitcoins, which I'm entrusting to you. Can you make sure my money doesn't disappear? Statements like "well all that can happen is the money disappears" does not make me trust you.
All software has security vulnerbilities. Nothing in 100% secure. You need to know what your vulnerbilities are. You are entrusting your users to not reuse passwords, that's a vulnerbility. You should have a list written down (privately) of your vulnerbilities.
- Source being viewed
I assume you mean the Ruby on Rails source code of your application? That should not be a security mechanism. You should be able to put that online and let everyone look at it without that having any security implications.
From the web application & OS level everything is fine. No-one has compromised anything, the web application has performed exactly as required, since the admin user has just logged in normally.
There's also social engineering attacks, could I get you to open a certain webpage that I control? What will that tell me about your web browser? Does that give me control of your heroku server?
There is also account security (e.g. changing my default withdrawal account to something attacker-controlled), for instance. Password security (people re-use passwords...) And perhaps an attacker can withdraw money or BTC from your Mt Gox account?
This is BTC - security amateur hour - so you may well be better than, say, Mt. Gox. But if you get going, you should have someone competent looking at the code. (tptacek and co do that kind of stuff, but he's not exactly a BTC fan. Also, this kind of work is expensive.)
Used properly, it's safe, but you can still screw up with ActiveRecord. For example:
User.where("name = '#{params[:name]}')
User.find_by_name(params[:name])
User.where(:name => params[:name])I have never ever used #{} in my code. When I first learned Rails, I know this should be avoided at all cost.
I would prefer
"String 1: " + string1
rather than
"String 1: #{string1}"
With SQL, you must never, EVER mix untrusted data (ie, data from a user) with your trusted code (ie, SQL statements). The same applies to HTML - never, EVER mix untrusted data with trusted code (ie, HTML tags). If you want to mix the two, you must either:
a) first take steps to make your untrusted data trustworthy - for HTML, use an appropriate HTML scrubbing library to remove dangerous tags (or simply escape every & or <). For SQL, you'd have to escape all metacharacters - but I wouldn't recommend doing this for SQL, see below b) Find a way to transfer the data separately. All modern SQL libraries allow you to specify named variables in your SQL code, then fill in the variables separately. With this, the SQL library takes care of separating the untrusted data and trusted code.
The mechanism used to combine code and data is not the problem - + and #{} are equally harmful if used improperly, and equally harmless if properly escaped .
I should use
["created_at <= ?", @time]
rather than
"created_at <= #{@time}"
This is what I meant actually...
No, you don't...
For instance, right now what's to prevent someone brute-forcing login and password combinations?
Likewise, even if it is the user's fault for having lax password security, for something that involves direct money transfer, it'd be nice if you could send a warning or block an account if it's accessed from, say, Russia when it's always previously been accessed from the States.
Also, what if Heroku gets hacked, or has a undisclosed security hole, or someone bribes one of their employees? You can't protect against everything, but what can you do to minimize the risk?
Sounds like you've outsourced security to a website (Mt. Gox) that has a proven track record of being stupid with security. That does not reflect well on you.