On Aug 13, 2012, at 8:56 AM, Antonio Manuel Amaya Calvo wrote: > On 13/08/2012 7:59, Lucas Adamski wrote: >> Please reply to [email protected]. >> >> ==WebPayment API== >> >> References: >> *https://wiki.mozilla.org/WebAPI/WebPayment >> *https://bugzilla.mozilla.org/show_bug.cgi?id=767818 >> >> Brief purpose of API: Allow apps (including the Marketplace) to initiate >> in-app payments and refunds. >> >> General Use Cases: >> *Buy an app via the Marketplace >> *Get a refund for a purchase via the Marketplace >> *Buy an item from within a 3rd party app >> *Initiate a refund for an item bought in a 3rd party app >> >> Inherent threats: >> *Trick a user into paying for something they didn't want >> *Trick a user into paying something more than once (i.e. replay attacks) >> *Charge a user more than they expect for a purchase >> *Force a refund for a different app or user than expected, thereby disabling >> it > > All of those threats are a payment provider addressable threats (and in > fact I think only the payment provider can address them). It's assumed > than the payment provider will show the user information about what he's > *really* going to pay, and it is going to ask for authorization for each > and every payment. So even if a malicious developer shows an incorrect > price and/or tries to process a payment several times, the payment > provider will show the correct quantity on his payment letter (screen > that shows the user what he's buying and for how much) and will ask for > confirmation every time. The same goes for refunds actually.
I think you're probably right but then hopefully that can inform testing for each payment provider. My goal is to raise all significant threats due to the inclusion of a given API, regardless of who ends up on the hook. :) In this case it implies that user confirmation should be about the last operation that happens client-side before being sent off to the server (to reduce the chance that it may be altered/influenced by a 3rd party after confirmation). It may also have implications for how we show UI… what if part of the payment information scrolls off to the side or bottom of the dialog? > And if the payment provider doesn't fill his role correctly... Well, > then all bets are off. They don't even need to re-process payments, they > have all your payment information and can make new charges directly. Sure, but intentional malicious-ness is different from a vulnerability that a 3rd party can exploit. I'm more concerned about 3rd-party data that could influence the payment workflow or presentation. Thanks! Lucas. _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
