最近、 サーバーでの購入の検証でアプリケーションを保護する方法について話しました 。 投稿の公開から数日後、この種の保護は回避することがわかった。 しかし、良いニュースがあります。私たちは今、弱点が何であるかを知っており、これらの点を強化することができます。
何が悪かった？
-
SKTransaction
チェックとデータのコンプライアンスのための十分なチェックがありませんSKTransaction
。 - サーバーの応答チェックが不十分でした。
Apple VerificationController
私が最初の投稿を書いたとき、私はAppleが提案した保護方法について冷静に語ったことを認めます。 同様に、彼らはまだ彼らのサーバーでチェックを行っているので、彼らの保護は脆弱です。 したがって、このサーバーを欺くことができる場合、それを使用したすべてのアプリケーションの保護が破られます。 妥当に聞こえますが、よく見ると、このようなシナリオの可能性はそれほど高くありません。VerificationControllerはサーバーにリクエストを送信して結果を確認するだけではないからです。
VerificationControllerに含まれるチェックは次のとおりです。
- アプリケーションで行われたすべての購入を保存し、一意性をチェックするため、同じ吸収された購入でアプリケーションを欺くことはより困難です。
- サーバーから受け取った領収書が正しく署名されるように、証明書と購入データの署名を確認します。
-
SKPayment
オブジェクトと購入領収書で一致するフィールドをチェックします。 - Appleサーバーの購入領収書を確認し、確認中にSSL証明書からの拡張情報を確認します。 そうでない場合、接続は確立されません。
- 検証要求は、アプリケーションに固有の秘密鍵を使用します。 おそらくすぐに、Appleはキーレス検証または他のアプリケーションの購入による領収書の検証を禁止するでしょう。
- 応答では、サーバーはフィールドの一致をチェックで確認するため、他の人のデータとステータスを単に返すことは不可能です：0
GithubにはすでにValidationController-aのわずかに吹き替えられたバージョンがあります： github.com/evands/iap_validation 標準のものとは異なり、base64エンコード/デコードが既に実装されており、有料機能を有効にできる便利なデリゲートが作成されています。
他にできること
上記が十分ではないようで、独自の何かを追加してアプリケーションを保護したい場合は、このトピックに関する良い本をお勧めします：iOSアプリケーションのハッキングとセキュリティ保護：データの盗用、ソフトウェアのハイジャック、およびそれを防ぐ方法 ただし、夢中にならないでください。既存の保護に弱いリンクを追加して、それを悪化させることができます。
バトルチェック
数日前、ストアはアプリケーションのバージョン2.2.1をリリースしましたが、いくつかの統計があります。 ジェイルブレイクされていないデバイスをハッキングする現在の方法は、チェックフィールドがSKPaymentフィールドに対応し、焦げるというチェックに達します。 手のひらをオフにするチェックは、まったく別の購入によるものです。 私にとって嬉しい驚きは、ジェイルブレイクされたデバイスのジェイルブレイカーも購入できないことでした。代わりに、検証時にアプリケーションがクラッシュします。 そしてこれは、保護が機能し、うまく機能している間、それを破るのにどれくらい時間がかかるかを見てみましょう。 :)