Nothing really. There seem to be a lot of people posting about how it would be impossible for them to have been a target of a CSRF because they'd closed tabs and other confusion related to what the exploits actually are and how they work; Lots of people seem to mix up XSS and CSRF for example.

Just thought some people may find it useful.

There are a lot of confused posts in here that don't seem to know some of the basics about exploits and how they work. So I figured that while I'm still in newbie jail I'd help other newbies out and explain some of them:

SQLi SQL injection

An SQL injection attack is a server side attack that basically checks to see that input parameters are checked and tries to execute database commands from a browser. As an example if you went to a site and had the following url: http://example.com/trade?id=1 which executed the following sql: SELECT * FROM TRADES WHERE ID = 1 an attacker may change the URL to http://example.com/trade?id=1;SELECT * FROM USERS, which may throw a database error that leaks some information and may allow an attacker to work their way into a system.

They're bad and trivial to defend against, but unfortunately very common. Sites should be sanitising input and using parameters in queries. Any sites that are vulnerable to them should be avoided, if they can't get this right they've probably got a lot wrong besides. 

XSS (Cross site scripting)

A cross site scripting attack is when someone injects Javascript into the site you're working with that does something it shouldn't. Basically you craft a some javascript in a field you control and you can access it. Things like forum posts or even usernames could have javascript in them which downloads a file from another server and it will be executed by your browser as if it was part of the page.

I've seen these work in some pretty funny ways - some of the sms numbers you text will just blindly interpret javascript for example so if you send: to the number the admin will get a javascript alertbox when they view the message. I had a friend do this in a pub while he was taking a piss and got panicked calls from the company the next day. 

Obviously you can do other things with this, like execute trades or transfers because your session is open and the javascript is executing as if it was you.

They're bad and trivial to defend against, but unfortunately very common. Websites should sanitise input they're displaying to users to prevent attackers from doing this. Any sites that are vulnerable to them should be avoided, if they can't get this right they've probably got a lot wrong besides. 

CSRF (Cross site request forgery)

A cross site request forgery is similar to the XSS above except you don't inject the code into the current site, you inject it into another site. Let's say for example I'm trading on tradesiteA.com, tradesiteB.com and looking at a pretty graph on tradegraphs.com. Now let's say that tradegraphs.com isn't all it's billed to be, they quietly put some javascript on their page that in the background accesses tradesiteA or tradesiteB and does things on my behalf. It works just like Ajax calls, you'll never see the requests or the results until you realise your account has been emptied.

The CSRF doesn't have to come directly from tradegraphs.com either, it could be injected using a XSS above.

The biggest misconception I see about CSRF here and elsewhere is that you have to have the window/tab open on the target site for them to work. THIS IS WRONG! You just have to be logged in, even if you close the tab or window if your browser is still open you still have a session to that site until it expires. If you've set the site to remember you by setting a cookie it's also as good as open, so you may not have even opened the site in your current session and you're still vulnerable.

Defending against them isn't easy. As far as the target site knows, you're a valid using doing valid user things. There are a couple of strategies depending on the sites and the required security that work though. The first is to introduce nonces (number used once). For every action a user takes a number is randomly generated, they need to include this nonce when they make their next request or they get thrown out of the site and have to log in again.

This nonce is why you'll often see banking websites break when you click back buttons or try to navigate out of order.

Another way is to include a further form of authentication for actions that require higher security. So called two factor authentication, usually I know something (password) and I have something (bankcard). Many banks require transfers to be authenticated with a chip and pin reader, text message or secondary password. Don't let them fool you though, two passwords is NOT true two factor authentication.

I'm not sure avoiding regulators is such a great plan long term either for your exchange or bitcoins in general. First of all it's only so long it will fly under their radar. From that point on it will either be accepted and regulated or denied legitimacy and will likely fail as a result.

Being a regulated exchange in one of the financial centres of the world comes with prestige and legitimacy you won't get by operating from somewhere with a lax regulatory framework.

One of the most serious you probably need to be aware of is Money Laundering. In most places it's a crime to facilitate it you and any of your staff could go to jail if you're not following the guidelines. You can probably even be charged if your operations are offshore and you're seen to be within jurisdiction and facilitating it. I'm not a lawyer, please do get advice.

Now I don't think the bitcoin protocol makes it easier to launder money, I believe the protocol in fact makes it more difficult to obscure where money is going (assuming you know it's original source and eventual destination). The fact of the matter is for current purposes it has to come out somewhere and that somewhere is currently the exchanges.

Money launderers like the mafia have long based their operations on cash businesses for a reason, money generally comes to them as cash and they want to get it into the financial system so they can buy things like cars and houses. Spending vast sums of money in cash is difficult and going to your bank and depositing it raises too many suspicions. So what they do is operate a cash business as a front, say a bar or restaurant. It's very easy then to just add the dirty cash to you till receipts and now you've got the extra money.

Well it's very easy with small amounts of money, and it's a lot of work. Also when the profits from your evil empire start to rise and you've got henchmen to pay you need to build more and more complex systems to hide the money trail with more front companies and dodgy invoices for goods or work between them that's never actually delivered.

Bitcoin makes this easier for investigators if they know where they suspected it entered the bitcoin economy and where it left. Unlike banks and layered companies they just follow the trail in the block chain.

For an exchange though they need to make sure they're not helping make illegitimate money look legitimate and even if you're not a primary means of getting money into the system like a bank you still have requirements to meet.

One of the main cornerstones of money laundering regulations is know your customer. You should know who they are and you should know they have the income that can support the transactions they're attempting. You also have to watch out fo suspicious account activity, large amounts in then back out quickly at a loss are a red flag. Amounts in then out to a third party is another red flag.

As a financial business YOU are required to report suspicious activity, not just help investigators. Failure to do so means jail. You are also prevented from letting the suspected party know in anyway that they are suspect.

Exchanges as they exist right now probably manage to keep under the limits for the regs to apply but eventually they're all going to have to face up to them and they're all going to have to go legit or die off.

I work in the financial services industry as a programmer, I never see customer data but I am legally required to know how to spot suspect transactions and who I have to tell if I do. I'm also required to undertake yearly refresher training on money laundering regulations - it's not complicated the above pretty much sums it up, but I'm sure it's a different kettle of fish if you're the boss or the point of contact with the regulator.

There is also bitcoin-js-remote [http://tcatm.github.com/bitcoin-js-remote/] which defines a URL scheme, but I'm not sure how well that would work on a mobile device without the // - I'd guess you'd have to try it to see if you could just use the existing scheme.

I like it. A lot.

One suggestion would be to make the QRCode return a URL not an XML block. Most mobile devices will let an application register as a handler for a URL so for example if the standard was to return the following

bitcoin://<TARGET>/<AMOUNT>

Whatever application you used could register it's self and allow the transfer to take place. This could be a mobile wallet you use to hold walking around money in or even a more complicated mobile bitcoin banking setup.

There is also probably some fear based on this thread where someone allegedly had 25,000 bitcoins stolen.

http://forum.bitcoin.org/index.php?topic=16457.0

I think it would work much better as a 'Live CD' distro that makes securing wallets easy for everyone. Some thoughts:

At it's most basic level I think it would need to accomplish the following for users:

1) On startup it asks them to insert their secure media. In plain language of less than a couple of lines it should inform them that they should never use that media on any machine they haven't booted with the secure distro live cd or similar.

2) If the secure media has an wallet on there and it's encrypted ask them to unlock it. If it has more than one maybe they can choose which to use.

3) Let them back the wallet up to other media, telling them that if the lose the media they'll lose everything stored on there, including the coins.

4) Let them transfer money out and see the current balance of their wallet.

That's probably all I would let it do. The most basic things possible. I would have all incoming and outgoing networking restricted to the bitcoin protocol.

A linux distro that has everything you need probably can't come quick enough. It would be nice if it were tiny and was basically a wizard that walked users through all the steps required to secure their wallets. If I had the time I'd get right on it.

Would it still be 100% secure? What's the current state of malware residing in places like the BIOS? I know it was what all the cool kids did once upon a time. I think the fact that machines started booting OSs that had security as an afterthought running persistently from the same media killed some of it off. If BC take off in a big way would we see a return to those days?

Are there any articles about theoretical attacks on bitcoin? I've been mining for a while and have a minuscule amount of coins but before I invested any money in hardware, speculation or explored any BC related business ideas (of which I've got a couple) I want to read up more on the security of the protocol. I'm familiar with PPK encryption, the protocol and the idea of bitcoing but by no means an expert.

One thought that did occur to me is that while an attack on a single wallet is impractical, is it possible to attack all wallets? Similar in the way that passwords for any accounts on a system can be harvested even if they're hashed what's to prevent an attacker from generating PPK pairs night and day until they get a hit for a wallet somewhere in the block chain?

I said I was familiar with encryption and the concepts, by no means an expert.