モバイルにおける中間者（MitM）攻撃から保護するには、端末上の脅威を排除し、迅速かつ容易な証明書のローテーションを可能にする、証明書ピンニングを含む堅牢なエンドツーエンドのセキュリティが必要です。モバイルにおけるMitM問題の概要については、本ブログをご覧ください。
しかし、MitMへの最適な対策に関しては、いくつかの誤解が存在します。このブログでは、それらの誤解に直接対応し、アプリに対して「最適な」保護を実現するためのステップを解説しています。
開発者はよく「すべてのAPI通信にHTTPSを使っているので、MitM攻撃の心配はありません」と言います。
しかし、これは誤解です。TLSは回避される可能性があります：
TLSを使用しているかどうかに関係なく、モバイルにおけるMitM攻撃は依然として主要な攻撃ベクトルのひとつです——セキュリティテスターに聞けばすぐにわかります。
多くの開発者は、「GoogleやAppleが推奨していないから」という理由でピンニングは避けるべきだと考えています。しかし、これは誤解です。彼らが警告しているのは、適切に実装されていない静的証明書ピンニングに対してです。
実際、GoogleのAndroidドキュメントでは、ハードコードされたピンに関するリスクが強調されています：
“Pinning can cause apps to break when certificates are rotated or reissued.”
(Source: Android Network Security Config) and Apple also notes: “Pinning can interfere with your ability to update server certificates.” (Source: Apple Security Best Practices)
しかし、これらの警告はピンニングそのものに対するものではなく、以下のような実装ミスに対するものです：
したがって、混乱しないことが重要です。ピンニングは、正しく実施されれば非常に効果的です。
OWASPの「Mobile Security Testing Guide (MSTG)」では、ディフェンス・イン・デプス（多層防御）の一環として証明書ピンニングを明確に推奨しています：「証明書ピンニングは、攻撃者がルート認証局を侵害した場合や、自らのCA証明書をデバイスにインストールした場合のMitM攻撃からモバイルアプリを保護します。」
また、OWASPのピンニングに関するチートシートも参照してください。
問題なのはピンニングそのものではなく、静的ピンニングと、それに伴う証明書・ピンのローテーション時の運用負荷です。
Burp Suiteやmitmproxyのようなツールをインストールするには、その個別のデバイスにアクセスする必要があるため、影響は限定的だろう……そう考えていませんか？それは間違いです！
これは明確な誤解です。オンデバイスMitMは、大規模なAPI悪用を可能にします。
攻撃者はオンデバイスMitMを使って、単に自分のデータを覗き見るのではなく、APIトラフィックをリバースエンジニアリングします。 mitmproxy、Burp Suite、Charles Proxyのようなツールを使って、すべてのリクエストとレスポンスを解析し、APIエンドポイント、リクエスト形式、認証トークン、パラメータ構造を明らかにします。こうして得た情報を元に、アプリ外からのAPI操作をスクリプト化できます。
攻撃者はボットやエミュレータファームを構築します。 APIの構造が分かれば、攻撃者は自動化されたリクエストでAPIを攻撃します。例えば、ログインAPIを悪用したクレデンシャル・スタッフィング、価格・在庫・ユーザー情報のスクレイピング、チケット購入やクーポンの不正使用といった大量処理の攻撃が可能になります。
攻撃者はMitMを通じてAPIキーやシークレットを収集します。 これには、オンデバイスMitM中に傍受されたAPIキー／トークンが含まれます。攻撃者はそれらを再利用したり、偽のクライアントに埋め込んだりします。結果として、あなたのAPIは正規のモバイルアプリではなく、悪意のあるスクリプトや偽アプリに対してサービスを提供することになります。
このように、被害は単一のデバイスにとどまりません。攻撃者の本当のターゲットは、個々のユーザーやデバイスではなく、常にあなたのAPIそのものです。
ここで、MitM対策における「Good・Better・Best（良・優・最良）」のアプローチをご紹介します。……と言いたいところですが、その前に「最悪（Terrible）」も加えておきましたので、最初に簡単に触れておきましょう！
|
MitM保護レベル |
アプリにピンを含むか？ |
証明書ローテーション対応？ |
ルート化デバイスでのMitMを防止？ |
APIボットをブロック？ |
|
最悪（Terrible） |
None |
✅ Yes |
❌ No |
❌ No |
|
良（Good） |
❌ Yes |
❌ No |
❌ No |
❌ No |
|
優（Better） |
✅ No |
✅ Yes |
✅ Yes |
⚠️ Partial |
|
最良（Best） |
✅ No |
✅ Yes |
✅ Yes |
✅ Yes |
すでに「HTTPSだけで十分」という神話について説明しました。TLSはOSのトラストストアを使用します。もし悪意のある、あるいはユーザーによってインストールされた認証局（CA）が存在すれば、偽造された証明書でも正当と認識されてしまいます。
さらに、攻撃者は侵害されたデバイス上でトラフィックを傍受でき、Burp Suiteのような一般的なツールを使えばそれは非常に簡単に行えます。
「TLSだけの対策は、ドアに鍵をかけても玄関マットの下に鍵を置いておくようなものです。」
この方法では、APIサーバーの公開鍵や証明書のフィンガープリントをアプリにハードコードして証明書ピンニングを実施します。Approovの無料ピン生成ツールを使えば、ドメインのピンを即座に作成することも可能です。
偽造証明書でもMitM攻撃をブロックできる
小規模アプリや証明書のローテーション頻度が低い場合にはシンプル
証明書が一致しないとAPIリクエストが失敗する
証明書のローテーション時にはアプリを再配布しないと動作しなくなる
ピンがバイナリに含まれる → 攻撃者に抽出・改ざんされる可能性がある
メンテナンス負荷が高い
静的ピンニングでは、サーバーの証明書や公開鍵を開発時にアプリへハードコードしますが、動的ピンニングではアプリが実行時にこれらの信頼情報（ピン）を取得・更新できます。
ピンはハードコードされません
アプリが整合性の証明（インテグリティ・アテステーション）に合格した後、実行時に動的に配信されます
メリット
証明書のローテーション？ピンを更新するだけで、アプリに自動で反映されます —— アプリの再配布は不要
ピンはアプリのバイナリに含まれない → リバースエンジニアリングの対象にならない
注意点
この方法には、デバイス上でピンを受け取るためのライブラリやSDK（例：Approov SDK）、および最新の証明書を安全な形式で提供するセキュアな（クラウド）APIが必要です。
このアプローチでは、動的証明書ピンニングに加えて、アプリおよびデバイスの実行時整合性チェックを組み合わせます。これにより、デバイス上で動作しているMitMツールを特定してブロックできます。
さらに、証明書ピンやAPIシークレット（キー、トークン）は、改ざんされていないアプリおよび侵害されていないデバイスに対してのみ配信されるため、オンデバイスMitM攻撃のリスクを完全に排除します。
Approovは、次の2つの方法でこれを実現しています：
管理されたトラストルート：Approov SDKは、Approovに登録されたAPIへのすべての接続について、証明書チェーンを検証します。この検証では、チェーンのルート証明書の公開鍵ピンが、Approovに登録されたルートセットのいずれかと一致することを確認します。このルートセットは、攻撃者が操作可能なデバイストラストストアに依存せず、Approovによって管理され、更新時には新しいセットが配信されます。
動的ピンニング：Approov SDKは、接続先のAPIごとに登録された証明書ピンを含む証明書チェーンであることを確認します。ピンはアプリパッケージ内に含まれておらず、Approovクラウドに保存されており、いつでも更新可能です。SDKは、アプリがアクティブな間、5分ごとのアテステーション実行時に常に最新のピンセットを取得します。これにより、ゼロダウンタイムでのピンローテーションが可能になります。
詳細な仕組みについては、Approovのナレッジベース記事をご覧ください。
メリット
すべてのMitM攻撃手法をブロック：
プロキシツール
偽アプリ
ルート化／エミュレータ環境
MitMに加えて、APIスクレイピングやボットによる悪用も防止
完全なAPIトラストを実現
これは、モバイルAPIに対する多層防御（ディフェンス・イン・デプス）型のMitM対策です。
モバイルアプリ開発者は、アテステーションとトラスト強制を統合した動的ピンニングを実装するソリューションを目指すべきです。これにより、あらゆる種類のMitM（中間者）攻撃の脅威を排除できます。
このソリューションは以下の点で優れています：
ピンをアプリのバイナリにハードコードせずに済む
アプリの再配布なしで、バックエンド側からピンを更新可能
インテグリティ・アテステーションを通過した検証済みのアプリにのみピンを配信
オンデバイス攻撃を完全に排除
このようなソリューションは：
あらゆる種類のMitM攻撃を防ぐうえで非常に効果的
証明書のローテーションが頻繁にある環境でも容易に管理可能
最後に一言：モバイルAPIセキュリティにおいて、ピンニングは依然として不可欠です。ただし、静的な実装は避けてください。現代的な動的ピンニングソリューションを使用すれば、ピンニングの利点をすべて享受しながら、運用上のリスクを回避できます。
ApproovはモバイルアプリおよびAPIセキュリティの専門家です。ご興味があれば、ぜひお打ち合わせの機会をいただければと思います。