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?
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. 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
