3 ms·

> Ok, weird. That means that the client has to send a correctly calculated price in the purchase order, because the server validates the order by performing its

> Ok, weird. That means that the client has to send a correctly calculated price in the purchase order, because the server validates the order by performing its own price calculation. While this left me stumped as to why the client-side calculation even exists This is exceedingly sensible. By including the expected price, the client is saying "the user has agreed to purchase a, b, and c for tootal cost X." That price was the one being displayed to the user, and it was being calculated live on the client as the user fiddled with quantities and whatnot. The actual cost might be totally different if a card's price changes or a sale ends or who knows what, and charging a user a different value than what was displayed is totally unacceptable. It's a sanity check, or alternately a form of optimistic locking. It prevents a whole class of nasty billing bugs.

dmurray 3y ago
Yes, I wouldn't do it any other way, and it's not the cause of the bug here (except in so far as it didn't contribute to protecting the implementation details by security through obscurity).
- dontlaugh 3y ago
  There are other ways to do this, but not necessarily simpler: - explicitly version every change to the store catalogue and require the version to be passed with a purchase, disallowing purchases from old catalogues - make an expiring signed piece of data (like JWT) for each offer in the store catalogue and require it to be passed back with a purchase, accepting old prices briefly - make the purchase API two-phase, locking in the price on the first phase and letting the client notice that it changed and potentially neglect to go through with the second phase
h1fra 3y ago
There is a good chance they don't even know what the price should be on the backend. The worst kind of apps are constantly running sales, special offer, limited discount, etc... Im pretty sure it's only calculated frontend side since it's very tied to if you just lost or if you are stuck in a game. And tbh, I think they are okay with 10 hackers are ruining the game, as long as 1 thousand mothers are putting their credit card to pay for gems.
- chinaman425 3y ago
  [dead]
- viciousvoxel 3y ago
  in the article it's explained that they do in fact check the price on the back end
jchw 3y ago
Yep! I've noticed older games tend to utilize this trick; I spotted it in a certain Korean golf MMO from ~2004. It did have me scratching my head initially, but if I were the one designing the game, it definitely would've occurred to me that I don't want the value to mismatch. Of course, I think this is a bit old-timey now. If I were developing a game today, I'd probably make the store emulate how a typical store with a shopping cart works; do everything on the server side, and just display it to the client. I can, however, imagine coming up with this scheme if I were faced with the same problem, and I can appreciate that it is an elegant way to reduce the load/statefulness of the server without adding the risk that someone might get shafted.
- jrgv 3y ago
  > [...] how a typical store with a shopping cart works; do everything on the server side, and just display it to the client. The same concerns apply for a typical shopping cart design. The price can change in between the time when you sent the price to the client, and the time when the user actually decides to buy.
  - dmacedo 3y ago
    Majority of times I've seen this being solved with shopping cart items being copied from the main product table by SKU with the current price. There is a TTL on the shopping cart itself. However, that meant for a period of time you had a frozen cost per-line-item in a shopping cart.
  - jchw 3y ago
    Well, in case of the server-side shopping cart, the server would have enough state to know if the price has changed since an item was added to the shopping cart, so the client wouldn't necessarily need to participate in preventing this scenario. I'm sure in practice, the checkout confirmation process for modern e-commerce sites also takes extra precautions to ensure that it can only happen exactly once and that it fails if any details change during the process of checking out.

dmurray 3y ago

Yes, I wouldn't do it any other way, and it's not the cause of the bug here (except in so far as it didn't contribute to protecting the implementation details by security through obscurity).

dontlaugh 3y ago
There are other ways to do this, but not necessarily simpler: - explicitly version every change to the store catalogue and require the version to be passed with a purchase, disallowing purchases from old catalogues - make an expiring signed piece of data (like JWT) for each offer in the store catalogue and require it to be passed back with a purchase, accepting old prices briefly - make the purchase API two-phase, locking in the price on the first phase and letting the client notice that it changed and potentially neglect to go through with the second phase

h1fra 3y ago

There is a good chance they don't even know what the price should be on the backend. The worst kind of apps are constantly running sales, special offer, limited discount, etc... Im pretty sure it's only calculated frontend side since it's very tied to if you just lost or if you are stuck in a game. And tbh, I think they are okay with 10 hackers are ruining the game, as long as 1 thousand mothers are putting their credit card to pay for gems.

chinaman425 3y ago
[dead]
viciousvoxel 3y ago
in the article it's explained that they do in fact check the price on the back end

jchw 3y ago

Yep! I've noticed older games tend to utilize this trick; I spotted it in a certain Korean golf MMO from ~2004. It did have me scratching my head initially, but if I were the one designing the game, it definitely would've occurred to me that I don't want the value to mismatch. Of course, I think this is a bit old-timey now. If I were developing a game today, I'd probably make the store emulate how a typical store with a shopping cart works; do everything on the server side, and just display it to the client. I can, however, imagine coming up with this scheme if I were faced with the same problem, and I can appreciate that it is an elegant way to reduce the load/statefulness of the server without adding the risk that someone might get shafted.

jrgv 3y ago
> [...] how a typical store with a shopping cart works; do everything on the server side, and just display it to the client. The same concerns apply for a typical shopping cart design. The price can change in between the time when you sent the price to the client, and the time when the user actually decides to buy.
- dmacedo 3y ago
  Majority of times I've seen this being solved with shopping cart items being copied from the main product table by SKU with the current price. There is a TTL on the shopping cart itself. However, that meant for a period of time you had a frozen cost per-line-item in a shopping cart.
- jchw 3y ago
  Well, in case of the server-side shopping cart, the server would have enough state to know if the price has changed since an item was added to the shopping cart, so the client wouldn't necessarily need to participate in preventing this scenario. I'm sure in practice, the checkout confirmation process for modern e-commerce sites also takes extra precautions to ensure that it can only happen exactly once and that it fails if any details change during the process of checking out.