URL に GET 変数を含むサーバー要求を送信するモバイル アプリ (iOS) があります。
現在、すべてのリクエストは SSL で保護されています。つまり、すべてのリクエストに HTTPS のみを使用しています。
現在はブラウザではないため、履歴がなく、誰も実際に URL を見ることはありません。サーバー上のサーバー ログへのすべてのアクセスを無効にします (これら 2 つの事実が、この質問を他のすべての同様の質問とは異なります)。
そうは言っても、渡された GET 変数は保護されており、「中間者」攻撃によってハッキングできないと推測しても安全でしょうか?
厳密に言えば、「man in the middle」攻撃は依然として実行される可能性があります。大きな問題は、それがエンドユーザーに透過的かどうかです。
中間者が最初の SSL ハンドシェイクをハイジャックし、独自の SSL 証明書を返す可能性があります。証明書は正しいドメイン名などに対するものである可能性がありますが、際立った特徴は、(できれば) 信頼できるソース、つまり認証局 (CA) によって署名されていないことです。アプリケーションがこれを認識して通信を停止する場合は、問題ありません。一方、アプリケーションが信頼できる CA によって信頼性をチェックしない場合は、ハッカーとセッションをネゴシエートし、ハッカーはトラフィックを確認して検査し、その後、処理のために実サーバーに送信します。実サーバーからのすべての応答も、ハッカーに表示されます。
ハッカーが、信頼できる CA のキーを使用して不正な証明書に署名できた場合、ハッカーを止めることはできません。これはまれですが、CA が危険にさらされる可能性があります。
Web ブラウザーの場合、このような攻撃により、ユーザーに「停止してください。何か怪しいことが起こっています」というメッセージが表示されます。このメッセージは、後のバージョンのブラウザーではより明白になりました。それでも、エンド ユーザーは先に進み、信頼されていない証明書を受け入れることができ、事実上、ハッカーが傍受できるようになります。アプリケーション (または iOS 自体) でこれが許可されている場合、できる限りユーザーを教育する以外にできることはほとんどありません。
要約すると、アプリケーションがターゲット サーバーと SSL チャネルをネゴシエートし、返された証明書が信頼できる機関によって署名されていることを確認する (そしてユーザーに質問しない) 場合は、問題ありません。GET/POST 動詞とその後のヘッダーを含むすべての HTTP トラフィックが暗号化されます。さらに 2 つの警告が必要です。
SSL は、リクエストが移動するための暗号化されたチャネルを提供しますが、リクエストが宛先に到達するとプレーン テキスト変数がアクセス ログに記録されることを認識しているように。
送信する情報が機密情報である場合は、POST を使用する必要があります。これにより、変数が Web サーバーによってログに記録されなくなります。また、それがあなたに関係する場合、保護されたリクエストが他のドメインから呼び出されるのを防ぎます（同じオリジンポリシー）。
リクエストがプロキシを通過する可能性があり、それらもメッセージをログに記録することを忘れないでください。