- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 26 Jan 2013 00:10:53 -0500
- To: Web Payments <public-webpayments@w3.org>
On 01/25/2013 09:02 PM, Manu Sporny wrote: > #4 is dangerous. JSON-LD does have a feature where it allows you to > load any other context from the Web. Those contexts can override > 'source' and 'destination'. Dave Longley and I just talked this attack vector through and it doesn't seem like it's a valid attack. Here's the attack in a nutshell: 1. A buyer is attempting to swap the source/destination fields on who gets paid for a particular asset. There are two places that they could corrupt the source/destination: the listing, the contract before payment is made. 2. The buyer finds a seller that is overlaying their own JSON-LD context and poisons the DNS that the seller is using to load their own context. The buyer's poisoned context swaps source/destination in the PaySwarm listing. 3. The buyer poisons the PA's DNS with their poisoned context that swaps source/destination in the listing and the PaySwarm contract. #2 fails because swapping source/destination in the listing creates an invalid payee for the digital good. The PaySwarm Authority will reject the listing because it doesn't contain a destination field. #3 fails because the PaySwarm Authority (and this part is implementation dependent) uses the listing to figure out who should be paid what, and the listing is invalid at this point. Even if the listing were valid, the poisoned JSON-LD context isn't applied until /after/ payment is made, so the money would still go to the right place. The poisoned JSON-LD context could still be written to the database with source/destination swapped, which would cause a transaction audit to fail, at which point the attack would be detected. So, a successful attack results in no monetary damage, but a corruption of the transaction record (that is easily detected and fixed). However, that this attack didn't work out is just a result of the way PaySwarm is designed. There could be other fields that the seller could sign in the future that would affect the flow of payment. So, it's probably best that we implement some sort of more heavy-weight requirement that all JSON-LD Contexts used in PaySwarm transactions MUST be loaded over HTTPS. This makes it so that implementers don't have to worry about this sort of attack vector at all, which will simplify implementations and lead to a tighter security model in general. I've raised an issue in the JSON-LD group to discuss the issue in more depth: https://github.com/json-ld/json-ld.org/issues/213 -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) President/CEO - Digital Bazaar, Inc. blog: Aaron Swartz, PaySwarm, and Academic Journals http://manu.sporny.org/2013/payswarm-journals/
Received on Saturday, 26 January 2013 05:11:24 UTC