過剰なデータ露出

過剰なデータ露出とは

APIはフロントエンドのクライアントに必要なデータのみを返すべきですが、時としてチームがミスをしたり楽な方法を選んだ結果、全てのデータを返すAPIが実装されることがあります。このようにAPIが過剰なデータを返す場合、過剰なデータ露出と呼ばれます。

攻撃シナリオの例

例えば、クレジットカード情報を取得するアプリがあるとします。利用者にはフロントエンド側でフィルタされるためCCVは表示されませんが、API自体は過剰なデータを返してしまいます。

例:

GET /api/v1/cards?id=0
[
    {
        "CVV": "677",
        "creditCard": "1234567901234",
        "id": 0,
        "user": "API",
        "validUntil": "1992"
    }
]

ご覧の通り、クレジットカード情報を取得する呼び出しが行われ、利用者にはCCVが見えなくても、APIが返すことで過剰なデータ露出となっています。

さらに別の例を挙げます。あるモバイルアプリがGETリクエストを /api/articles/{articleId}/comments/{commentId} に送信し、著者を含むコメントのメタデータを取得します。しかし、通信が傍受されると著者のPII情報も見えてしまう可能性があります。

GET /api/v1/comments?id=0
[
    {
        "comment": "1234567901234",
        "id": 0,
        "user": "testUser",
        "user adress": "testlane, testing - 340043 testing in testland",
        "user email": "test@bla.com"
    }
]

‍

過剰なデータ露出への対策

• フロントエンドクライアントによるデータのフィルタリングに依存すべきではありません
• バックエンドからの全レスポンスに機密データが含まれていないか確認すべきです
• 新しい APIエンドポイント を作成する際、データの利用者と必要なデータを十分に考慮する必要があります
• to_json() や to_string() のようなメソッドは、渡されたオブジェクト全体を無差別に出力してしまい、望ましくない結果を招く恐れがあります。特定のプロパティだけを返すようにし、オブジェクト全体を渡さないよう注意すべきです
• Wallarmのアプリで扱う全ての PII情報 は、定期的に分類・再インデックスする必要があります。新規・既存の API呼び出し のレスポンスも、不要なPII情報が含まれていないか確認すべきです
• あらかじめ定義したスキームに基づいてリクエストやレスポンスを検証するスキームベースのバリデーションは、セキュリティ対策として有用です。APIからの全レスポンスをチェックするために活用できますが、スキームの作成には手間がかかります

‍

‍

結論

この問題は一見シンプルなため見落としやすく、Wallarmの自動検出でも拾いにくい性質があります。データの選別を適切に行うために、APIセキュリティソリューションの活用が推奨されます。統計データに基づいたOWASP Top 10 2021のランキングも取りまとめています。APIから送られる各データがどの程度機微なもので、何がフロントエンドに必要かを判断することが重要です。可能な限りフロントエンドでのフィルタリングは避けるべきです。