Identifying your packaged app from a receipt

RESOLVED FIXED in 2013-07-18

Status

defect
P2
normal
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: andy+bugzilla, Assigned: andy+bugzilla)

Tracking

2013-07-18
x86
macOS
Dependency tree / graph

Details

A receipt for an app contains your product domain. That way when you verify the receipt, you can check that the product url matches your hosted app. This will stop people copying valid receipts around for your app.

However a packaged app has no domain. To get packaged apps working we just set it to the marketplace for want of a better idea in bug 784447. That's not such a great idea, since I can take a receipt for packaged app X and copy it over to packaged app Y and it will work great there.

Best idea so far, make a fake domain app-slug.packagedapp.marketplace.firefox.com thats obvious to the end developer. We'd need to surface this in the dev tools so its clear.
Of course, problem is that slugs can change.
Priority: -- → P1
Rob suggested using the app guid, so the domain could be:

app-guid.packaged-app.marketplace.firefox.com

Those can't change.
app://app-guid is what nick suggested and makes sense, we'll just need to change specs and trunion to allow that.
Depends on: 852720
Whiteboard: [blocked]
I don't quite understand the attack here.

Is the problem that the user purchases an application and receives a valid receipt for that app. He then copies the application files as well as the receipt to another device, thereby being able to use the application on that app as well?

If so, how does giving an application a domain help here? Wouldn't the application running on the other device also have the same domain?
I think that is correct: an attacker buys one app legitimately then copies the receipt to use for another app illegitimately.

Andy, is the problem that the developer needs some unique value in the receipt to whitelist? If so, could we use an ID in product.storedata?
The could use product.storedata, but they wouldn't know the data before hand and its specific to the store. So we'd have to expose that information.

Plus the assumption has been that information is something store specific and something a developer should never worry about.

If an origin is given in the manifest as is suggested in the bug 852720, I would much, much rather use that than any made up value.
This means that packaged apps will require an origin if they would like to be paid.
Depends on: 878103
Let's use the origin from the manifest to populate the receipt. This means the developer will know the value before it goes to the marketplace and testing should be possible.
This is blocked on bug 878105 - figuring out if app origins are unique or not.
Assignee: nobody → amckay
Depends on: 878105
Whiteboard: [blocked]
No longer depends on: 878105
Target Milestone: --- → 2013-06-20
Depends on: 878105
Depends on: 878101
Blocks: 883388
Target Milestone: 2013-06-20 → 2013-06-27
Priority: P1 → P2
https://github.com/mozilla/zamboni/commit/e0e01d
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Depends on: 888415
Target Milestone: 2013-06-27 → ---
Target Milestone: --- → 2013-07-18
For the record, I reverted in: https://github.com/mozilla/zamboni/commit/10187d85
https://github.com/mozilla/zamboni/commit/da0d06
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Can you please add some STRs to this bug in order to test it?
1) create a paid packaged app. ensure that the app manifest has an origin.
2) buy the paid packaged app, examine the receipt contents, ensure that the receipt product url field, matches the origin.
You need to log in before you can comment on or make changes to this bug.