アプリ画面の外のリクエストまで確認する: モバイルアプリ・サーバーのセキュリティ検証事例

アプリ画面に見えないリクエストまで。端末・通信・認証とサーバーの権限を併せて点検し、修正結果をあらためて確認しました。

アプリの機能が正常に動作していても、データと権限が安全に処理されているかは別に確認しなければなりません。モバイルアプリR社のリリース前検証では、端末・通信・認証とサーバーAPIを併せて確認し、修正された欠陥をあらためて検証しました。

アプリの画面にボタンがなければ、その機能は実行できないように見えるかもしれません。しかし、サーバーが受け取るリクエストは、画面の制約とは別に確認する必要があります。

利用者に見える動作だけをテストすると、アプリが呼び出すサーバーの権限処理と入力検証を見落としかねません。アプリがどんな情報を残すのか、通信と認証はどう動くのかも、別の確認対象です。

二つのモバイルOSでのリリースを準備していたR社のプロジェクトで、IXCはアプリとサーバーを同じ検証範囲に入れました。機能の成功経路だけでなく、許可してはならないアクセスがどう処理されるかを確認する作業でした。

まず点検対象と許可範囲を定めました

セキュリティ検証は、どこでも自由に試す作業ではありません。どのアプリとサーバー、どの機能とリクエストを対象にするのか、合意した範囲が必要です。

R社では、着手前に点検範囲を書面で確定し、アプリとサーバーの項目を分けて実行しました。リリース前に確認する対象を明確にしたのです。

範囲を先に定めてこそ、結果も正確に説明できます。一部のAPIを点検した結果をサービス全体のセキュリティに広げたり、特定バージョンの結果をその後のすべてのバージョンにそのまま当てはめたりしてはなりません。

この事例でも、点検した項目と範囲外に置いた項目を区別して記録しました。

アプリでは、端末に残るデータ、通信区間、認証フローを確認しました。サーバーでは、API権限と入力検証を確認しました。

一つのテストでこれらの問いにすべて答えることはできません。アプリがログインに成功したからといって、すべてのサーバーリクエストの権限が正しく処理されていると結論づけられない理由です。

機能を使えるかどうかと、その機能を使う資格を確認しているかどうかは、別の検証対象です。

サーバー検証では、アプリ画面を経由せずサーバーを直接呼び出すリクエストも実行しました。画面の制限だけに頼らず、サーバーがリクエストを処理する基準を確認したのです。

この検証の目的は、特定の攻撃手法を数多く実行することにはありません。通常の利用の流れでは隠れてしまいかねない、権限と入力処理の境界を確かめることにあります。

たとえば、ある操作が画面で制限されていても、その制限がサーバー側でも適用されているかは別に確認しなければなりません。これは当該サービスで特定の侵害が起きたという意味ではなく、検証で問うべき問いです。

R社では、このようにアプリとサーバーを併せて見て確認した問題を、重要度と再現条件のある記録に整理しました。

欠陥を報告した後は、修正結果を再検証しました。同じ項目を再度実行して、対応の有無を確認する過程です。

修正したコードがあることと、もともと確認した問題が解決されたことは、別の状態です。変更が実際に反映された環境で同じ条件を確認してこそ、対応の結果を説明できます。

この点検では、報告と修正確認を切り離しませんでした。何を発見し、その項目をどう再確認したかがつながるようにしました。

ただし、確認した欠陥への対応は、サービスに他の問題がまったくないという意味ではありません。セキュリティ検証の結果は、対象バージョンと範囲、使用した条件の中で解釈しなければなりません。

プロジェクトには、アプリ・サーバーの点検結果、欠陥と対応確認の記録、検証範囲と除外項目が残りました。以後のリリースであらためて参照できる点検リストも整理しました。

この成果物の価値は、安全だという一文でサービス全体を評価することにはありません。どこまで確認し、どの対応を再検証したのかを説明できる点にあります。

アプリの品質を画面の動作だけで判断すると、見落とす領域があります。端末に残る情報と通信、サーバーがリクエストを受け入れる条件も、サービスの一部です。

R社の事例は、リリース前検証の範囲をアプリの中に閉じ込めず、データを処理するサーバーまでつなげて確かめたプロジェクトです。

他の事例

次のステップ

アプリとサーバーの点検対象、許可されたテスト範囲、修正後の再検証条件を先に整理します。