web-dev-qa-db-ja.com

HTTPエラーコードによる機密データの列挙

次のREST呼び出しをサポートするAPIを備えたWebサイトがあり、認証されたユーザーAliceが登録ユーザーBobに自分のサイトに登録した携帯電話にメッセージを送信できると仮定します（仮想的に言えば、この例のために）：

curl --header "Authorization: JWT $someTokenForAuthz" \
     --header "Content-Type: application/json" \
     --request POST \
     --data '{"phone":"+43 123 456","msg":"some text"}'
     http://example.com/text/send

電話番号を機密（PII）データとして分類し、サイトで登録されていない電話番号が送信された場合にAPIが次の応答を返すと仮定します。

{"error": {"code":404,"message":"Phone number not found"}}

イブが携帯電話番号+43 000 001から+43 999 999（実際の電話番号の制限を無視）を反復処理するスクリプトを作成していると想像してください。エラーコードがあり、スクリプトを1 000 000回繰り返した後、Eveはサイトに登録されているすべての番号を列挙しました。より具体的な方法でサイトユーザーをターゲティングします。

携帯電話番号などの機密データがシステムに見つからなかった場合に404​​ HTTPエラーコードを返すのはセキュリティ上の問題ですか？エラー処理の点で（バックアップ戦略として）より良い方法は何でしょうか？すでに実施されているリクエスト制限/検出メカニズムが失敗する可能性がある場合）、そのような機密データの発見を防ぐには？より一般的な401 - not authorizedエラーまたは何か完全に異なる？

restapisensitive-data-exposureerror-handling
2
SeeYouInDisneyland

したがって、脆弱性は、エラーコードを返すと、登録された電話番号の列挙が可能になることです。登録された番号の開示を許可することが悪い場合、これはセキュリティ上の問題です。

より一般的な401-許可されていないエラー

いいえ、テキストを変更しただけです。動作は変更していません。

ソリューションをより安全にするためにあなたが行うことはたくさんありますmight-しかし、架空のモデルに適切なものを知るための根拠はありません。

  • 常に成功を報告する
  • 電話番号を使用しない-サロゲート識別子（エントロピーがはるかに高い）を使用し、クライアントにルックアップテーブルの維持を要求する
  • 認証されたアクセスを要求し、失敗率に基づいてそのアクセスを取り消す
  • ハニーポットを使用してデータをシードし、ハニーポットを使用しようとしたときにクライアントアクセスを取り消す
  • クライアントがリクエストを行うことができるレートを制限する
  • pOSTごとにクライアントに請求する
  • 特定のクライアントからのメッセージの受信をオプトインするように受信者に要求する-権限が付与されていない番号と同じエラーが返されます。
  • ...

    リクエストの制限/検出メカニズムがすでに導入されていると仮定

それで、あなたはあなたが保護メカニズムを持っていると言っていますが、それらは列挙から保護しませんか？次に、あなたの質問はオキシモロンです。

2
symcbean

フロントエンドは、フロントエンドを参照するステータスメッセージのみをユーザーに伝えることができます。リクエストを受け取りましたか？もしそうなら、教えてください。検証に失敗した場合は、通知してください。他には何もありません。バックエンドがなんらかの理由でメッセージを配信できない場合、フロントエンドに通知しないでください。

{"status": "success", "message": "Received"}のようなものだけを返すだけで十分です。 Eveは、番号が存在するかどうかを知る必要はありません。イブが無効な番号（登録されていない無効な番号）を送信した場合、{"status": "error", "message": "Invalid number"}をスローしてタイプミスを修正し、再試行できます。

1
ThoriumBR