Comment by zhoutong | Hacker News Reader

Comment by zhoutong | Hacker News Reader

Parent Full thread

Yeah, I understand your concern. Bitcoinica has several features/characteristics that make itself like no other:

- 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.)

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)

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.

Currently our only non-trivial security challenges are as follows:

- 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 believe that Rails has no problems with SQL injection? All my database queries are going through ActiveRecord.

Used properly, it's safe, but you can still screw up with ActiveRecord. For example:

    User.where("name = '#{params[:name]}')

That's vulnerable to an SQL injection. You can make it safe, by using something like:

    User.find_by_name(params[:name])

Or if you want to stick with the where clause, one out of many ways of doing it, is:

    User.where(:name => params[:name])

Yeah, I understand your point.

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}"

> Yeah, I understand your point.

No, you don't...

Those two examples are _exactly_ the same; it's clear you don't understand the actual problem.

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 .

Sorry for the confusion. I realized that I gave the wrong example.

I should use

["created_at <= ?", @time]

rather than

"created_at <= #{@time}"

This is what I meant actually...

Well, being hacked allows such financial attacks, obviously (one direction: dump zillions of BTC into the market, pick them up really cheap; other direction: ask for zillions of BTC, sell them really expensively).

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.)

the most that hackers can do is to get some free money

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.

I'm another voice recommending that you sit down with someone who works in security :)

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?

To add to mootothemax's post, non-repudiation is often important in financial systems. This is the ability, if a user comes to you and says "It wasn't me that made these transactions, so they're invalid," that you have the ability to argue whether they did or did not make those transactions. At a minimum, this probably means logging IPs like mootothemax suggests.

You should know that when you write comments like this, you communicate two (bad) things:

(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?

Seconding Thomas' advice. You could even write against the API of one of the existing prediction markets (thus inheriting their user base) and try to add, e.g., options to it. That will give you plenty of holes to shoot in your foot without ever causing more damage than wiping out the geek cred of someone who tried to prop trade using the knowledge that there are unlikely to be two next US presidents.

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.

There is more to security than hardening your code. For example, I assume you have some sort of master/root/admin level account on your own website. Are you using the same password as your email account? Do you use a third party email account? Do you have a 'forgot my password' feature? Here's an attack vector: I get read access to your gmail account, then I use the 'forgot my password' feature to change your password and I have then rooted your site.

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?

My semi-amateurish opinion is that as a non-registered securities dealer with all accounts having margin capabilities the (near 100%) likelihood of your Rails app exploitably broken is not the key source of risk to your business.

Bitcoinica holds all the money and coins in traditional banks and other exchanges (currently only Mt. Gox).

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.

I think he's outsourced security to a site that has experience in dealing with security and has (hopefully) learned something from their mistakes. For bootstrapping, I'd say it's acceptable.

Reply on news.ycombinator.com