質問編集履歴
1
文章が乱雑なので水平線を入れて区切り。
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -5,6 +5,7 @@
|
|
|
5
5
|
|
|
6
6
|
この質問での「課金のレシート」はMII～ から始まるASN.1のbase64です。jwt ではありません。
|
|
7
7
|
|
|
8
|
+
---
|
|
8
9
|
|
|
9
10
|
今まではアプリで課金操作をした後にStoreKitから受け取ったレシートをそのままアプリサーバーに投げて、そのアプリサーバーからverifyReceipt APIにそのまま投げてレシートのjsonを取得していました。
|
|
10
11
|
悪意あるユーザーがデタラメなレシートを送ったとしても、そのレシートはAppleの署名がされていないので verifyreceipt APIでエラーになって気づく事が出来ました。
|
|
@@ -12,12 +13,14 @@
|
|
|
12
13
|
しかしverifyreceipt APIは非推奨になり、いつ消えるか分からない状態です。
|
|
13
14
|
https://developer.apple.com/documentation/appstorereceipts/verifyreceipt
|
|
14
15
|
|
|
16
|
+
---
|
|
17
|
+
|
|
15
18
|
色々な記事を見ると「サーバーにトランザクションIDを送り、サーバー側ではAppStoreServerAPIを使ってトランザクションの詳細情報を取得する」という方法が代替案として提示されていて
|
|
16
19
|
https://speakerdeck.com/yuheiito/storekit2woshi-tutake-jin-sisutemunohururiniyuaru?slide=29
|
|
17
20
|
|
|
18
21
|
Apple公式の Apple App Store Server Node.js Library でも
|
|
19
22
|
https://github.com/apple/app-store-server-library-node
|
|
20
|
-
レシート検証の処理は以下の
|
|
23
|
+
レシート検証の処理は以下の用に記述されています。
|
|
21
24
|
```
|
|
22
25
|
const appReceipt = "MI..."
|
|
23
26
|
const receiptUtil = new ReceiptUtility()
|
|
@@ -25,11 +28,16 @@
|
|
|
25
28
|
```
|
|
26
29
|
|
|
27
30
|
このどちらの方法も「デタラメのトランザクションIDをアプリサーバーにPOSTされたら無課金でサブスクに加入されてしまうのでは？」という不安があります。
|
|
31
|
+
MII～ から始まる文字列のレシートはASN.1という形式で、特定のプロパティのみデタラメな値に差し替える事は可能なはずです。
|
|
28
32
|
|
|
29
33
|
Apple公式のnodejsのライブラリの該当処理のロジックを追いかけたのですが、レシートのbase64からトランザクションIDのプロパティを読み込んでいるだけでAppleの証明書の検証はしていません。
|
|
34
|
+
また、前者のspeakerdeckの例においては「サーバーにトランザクションIDを送る」と書いているのでトランザクションIDの数字を信じるしかない状態だと思います。
|
|
35
|
+
|
|
36
|
+
---
|
|
30
37
|
|
|
31
38
|
これ、アプリから渡されたトランザクションIDの数字をそのまま信用してよいのでしょうか？
|
|
32
|
-
|
|
39
|
+
アプリを解析とかiOSに中間者攻撃を仕掛ければアプリサーバーへの通信内容は丸裸ですし、
|
|
40
|
+
そこで不正に入手されたトランザクションIDを投げ込まれたらアプリサーバーはそれを受け入れてしまうはずです。
|
|
33
41
|
|
|
34
42
|
※
|
|
35
43
|
StoreKit2の jwsRepresentation というプロパティを使えばjwsが取れて、
|