On Apr 9, 2013, at 7:10 PM, Paul Theriault <[email protected]> wrote:
> Hmm. What about replay of payment messages? Could that be an issue? Or is it > up to an app to take care this risk? Ie, if I can intercept a payment message > (which would require significant network access admittedly), can I just > replay 1000 times to get 1000 magical unicorns? As Andy mentioned, you could replay the payment message but you can't tamper with it. So, yes, it would be up to the app to protect against replays. They would typically start it with their own transaction ID and when they receive a payment message they would reject it if that ID had already been processed. Replays may still be possible with HTTPS because server logs are usually leaky but I guess HTTPS would mitigate it. > > My other concern with this is that any app that does not have SSL has no > business having user accounts, let alone taking payments (I am assuming if > their postback URLs are not SSL, then their app is not SSL either - is this > valid?). Is this an unrealistic expectation? I'm mainly worried about > attackers injecting arbitrary scripts into insecure apps. I think it's valid that the app might not have HTTPS and still be secure enough for payments. For example, it might use client-side Persona for auth which I don't think requires HTTPS on the backend verifier to be secure. > > Thoughts? > > > > > > > > > > > > On Apr 10, 2013, at 9:15 AM, Kumar McMillan wrote: > >> >> On Apr 9, 2013, at 5:57 PM, Matt Basta <[email protected]> wrote: >> >>> Correct me if I'm wrong, but if a third party intercepted the JWT for the >>> purchase, they couldn't falsify information in that JWT or somehow create >>> their own fraudulent JWT. >> >> Correct. This was so obvious in my own head that I forgot to mention it :) >> An attacker can't intercept an HTTP request and *alter* the outcome of a >> payment. The JWT is signed with a secret (shared) key so both parties will >> know if it was tampered with. >> >>> And as you said, user privacy at a high level isn't impacted since there's >>> no personal information in the JWT. Since that's the case (AFAIK), I'd say >>> it's safe to not require HTTPS. >>> >>> >>> >>> ----- Original Message ----- >>> From: "Kumar McMillan" <[email protected]> >>> To: [email protected] >>> Cc: "Raymond Forbes" <[email protected]> >>> Sent: Tuesday, April 9, 2013 3:29:08 PM >>> Subject: should we support non-HTTPS urls for in-app payments? >>> >>> For a developer to build an app with in-app payments she currently has to >>> >>> 1. host a web server at some domain and >>> 2. that server must accept HTTPS connections with a valid cert. She cannot >>> use a self-signed cert. >>> >>> Is it important enough for the developer ecosystem to relax this >>> restriction and allow HTTP URLs? >>> >>> If a developer self-hosts their domain it is pretty costly to get an HTTPS >>> cert and this would be a barrier to entry. Many services like Heroku, App >>> Engine, OpenShift, etc, will provide HTTPS on a shared domain though. >>> >>> >>> Why HTTPS? The restriction applies to when the Firefox Marketplace does a >>> server to server post with a JWT containing the result of a purchase. This >>> JWT is a blob of JSON that contains info about the product. It does *not* >>> contain user data unless the developer put an email or something in the >>> productData field but that would be weird. In raw form, the JWT is a base64 >>> encoded string of JSON + a signature. >>> >>> Here's detailed info about how notifications work: >>> https://developer.mozilla.org/en-US/docs/Apps/Publishing/In-app_payments#Processing_postbacks_on_the_server >>> >>> Example JWT that would be sent over the wire in plain text (after decoding >>> it): >>> >>> { >>> "iss": "marketplace.firefox.com", >>> "aud": APPLICATION_KEY, >>> "typ": "mozilla/payments/pay/postback/v1", >>> "exp": 1337370900, >>> "iat": 1337360900, >>> "request": { >>> "id": "915c07fc-87df-46e5-9513-45cb6e504e39", >>> "pricePoint": 1, >>> "name": "Magical Unicorn", >>> "description": "Adventure Game item", >>> "productData": "user_id=1234&my_session_id=XYZ", >>> "postbackURL": "https://yourapp.com/payments/postback";, >>> "chargebackURL": "https://yourapp.com/payments/chargeback"; >>> }, >>> "response": { >>> "transactionID": "webpay:84294ec6-7352-4dc7-90fd-3d3dd36377e9" >>> } >>> } >>> _______________________________________________ >>> dev-webapps mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-webapps >> >> _______________________________________________ >> dev-webapps mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-webapps > _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
