- From: Ross Nicoll <jrn@jrn.me.uk>
- Date: Sat, 26 Apr 2014 19:08:32 +0100
- To: public-web-security@w3.org
- CC: gaurav@chaturvedi.me
I'm looking over the new Bitcoin payment protocol suggestions. These are not web specific, however it is likely the most common use-case will be based around a web environment, and I'd appreciate input on security issues I may have missed. Please note these are not specifications I have written, however I am working on software which may use them, and providing feedback to the original author(s) as part of that. The current draft specifications are at: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki It is intended that the files can be sent over HTTP and the files themselves signed, to provide verification of source and integrity of the file's contents. I note however that in such a scenario the contents of the file (including potentially details of items ordered) are sent in plain text. Counter-point, this does enable easier adoption by small/sole merchants. Any feedback on pros/cons? Would you advise the standard should require a secure transport layer? I'm trying to consider whether there are any other attack scenarios that need to be planned for. I was wondering whether redirect statuses (especially to non-HTTPS URLs or URLs on other domains) should be rejected, however my inclination is that if someone can trigger a redirect, it's likely they could simply inject their own payment request into the process instead. Would it be a sensible precaution to state that bitcoin: URIs should not be dereferenced automatically, but only as a result of user interaction? I'm wondering about potential issues, for example, with hostile Javascript opening one of these URIs. Uncertain whether it's feasible to reliably determine how a URI was requested. I am aware that the MIME types proposed are not registered and should be (and arguably may not be accepted in their current form). Any comments would be greatly welcomed. Ross
Received on Saturday, 26 April 2014 18:08:56 UTC