パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

iOSのアプリ内課金における課金回避ハック、Mac向けアプリでも同種の穴が見つかる」記事へのコメント

  • つまり、それ以前のバージョンには、まだ穴があるってこと?

    • Re: (スコア:5, 参考になる)

      よくわからない流れになってるみたいですけど、iOSとは縁がないものの
      興味があったのでちょこっと調べた感じだと
      攻撃の方法はDNSのレコードを変更してAppStoreのサーバーに対する
      リクエストを偽装サーバーにリダイレクトし、偽装サーバーがAppStoreのサーバーの
      エミュレーションを行うことで支払ったかのように見せることができる、というものの
      ようですね。

      その後の報道によると、Appleはこの攻撃を防ぐことはできなかった、ようで
      現時点では
      http://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_Rece... [apple.com]

      My app performs validation by connecting to the A

      • AppとAppStoreがどんなプロトコルで通信しているのか知りませんが
        httpsのようにリクエスト先が正しいか確認する仕組みは無いのでしょうか。

        • 一応HTTP系っぽいです。
          HTTPS使ってたけどライブラリ/APIではロクに検証してなかったか、この件を受けてHTTPからHTTPSに切り替えたのかは知りませんが、今回はそのチェックをアプリ側でやってくれれば対策になるって話のようです。
          (#2199150) [srad.jp]が紹介している公式の対策を見ると

          If your app connects to the App Store server directly from the device, your app may be affected by this vulnerability. You can address this vulnerability as follows:
          ・Check that the SSL certificate used to connect to the App Store server is an EV certificate.
          ・Check that the information returned from validation matches the information in the SKPayment object.
          ・Check that the receipt has a valid signature.
          ・Check that new transactions have a unique transaction ID.

          ・SSLのEV証明書でつながってることを検証しろ。(後述されているが非公開APIをこの用途限定で使えとの突貫対応)
          ・得られた購買情報が要求と矛盾していないか確認しろ。(SDKでは確認していない?)
          ・署名が有効か確認しろ。(SDKでは確認していない?)
          ・トランザクションIDがユニークか確認しろ。(複数回検証しろということか?)
          ということで、これらの対策を行った課金チェックAPIのラッパーが提供されています。

          この対策と攻撃の大雑把な解説記事を読む限り
          ・HTTPで購入情報の取得をしてしまうケースがあったか、ライブラリ/APIではHTTPSの証明書を検証していなかった(または回避可能だった)。
          ・多くのアプリ開発者の実装では、購買情報のBool値しか読んでおらず、ライブラリ/APIもそれを検証していなかった(または回避可能だった)。
          ・購買情報自体にも署名がついているらしいが、ライブラリ/APIはそれも検証していなかった(または回避可能だった)。
          ・今回の攻撃では何らかの理由でトランザクションIDが固定だった。
          という状況のようです。

          検証項目から察するに、今回の攻撃では「素のHTTP」または「異常なHTTPS」で検証接続を行わせて、「購買情報の署名が間違っている偽造購入情報」または「別のアプリ・利用者の購買情報」を食わせることで、それらの検証をおこなっていないアプリの課金情報を突破していた、ということになりそうです。
          これらのチェックをライブラリ/APIではやっていなかったのか、それを突破可能なバグがあったのか…

          検証していなかった、の方だとするとお粗末すぎますね。

          親コメント

犯人はmoriwaka -- Anonymous Coward

処理中...