W3C home > Mailing lists > Public > public-web-security@w3.org > April 2014

Bitcoin payment protocol

From: Ross Nicoll <jrn@jrn.me.uk>
Date: Sat, 26 Apr 2014 19:08:32 +0100
Message-ID: <535BF620.1070100@jrn.me.uk>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:21 UTC