web-dev-qa-db-ja.com

Webサービスで例外情報を公開することはセキュリティリスクですか？

例外情報をエンドユーザーに公開するとセキュリティリスクが発生することは既知の事実です。攻撃者は、内部でどのように機能するかを把握して攻撃することができるためです。しかし、その情報がAPIを使用する開発者に関連する可能性があるWebサービスについてはどうでしょうか。

一方では完全なスタックトレースを公開し、さらにはメッセージにデータベース情報が含まれている可能性があるため、メッセージでさえ危険です。一方、何かがうまくいかず、サーバーが「申し訳ありません」と言っただけの場合、開発者は不満を感じるでしょう。本当に適切な方法は、知っているすべての例外を安全な方法で処理することです。つまり、ビジネス/検証の例外をキャッチし、特別なエラーコードとメッセージ（スタックトレースなし）でそれを返します。

しかし、私はここでそれを行う一般的な方法は何であり、どのアプローチがセキュリティの観点から取られるべきかをここに述べたいと思います。

web-serviceerror-handlingexposure
18
Ilya Chernomordik

APIは、スタックトレースなどの内部情報を公開しないでください。あなたが本当に気づいたように、彼らは実装を攻撃するために使われるかもしれない情報を漏らすかもしれません。

さらに、それらは通常、APIの開発者にのみ関連し、APIのユーザーには関連しません。これらのユーザーはとにかく適切なエラーメッセージを期待し、API開発者にこれが何を意味するかを最初に尋ねる必要があり、開発者がソースコードを調べる必要があるような奇妙なメッセージを期待しません。したがって、ユーザーにとって意味のあるものではなく、スタックトレースをユーザーに投げるだけの場合、これはセキュリティの問題ではなく、APIのユーザビリティの問題になる可能性があります。

23
Steffen Ullrich

通常、2種類の例外があります。

  • 無効な入力値などの予期される例外。または認証の失敗。または存在しないオブジェクトを要求します。したがって、説明と文書化されたエラーコードとメッセージを使用して、この種の問題に適切に対処する準備をすることができます（すべきです）。この場合、スタックトレースのポイントはありません。

Youtube invalid video code

  • 内部（または予期しない）例外：データベースを利用できません。メモリ不足; [〜＃〜] npe [〜＃〜] につながるコードのバグ。スタックトレースにも意味がありませんAPIユーザーの場合。ただし、（開発者として）あなたはそのようなスタックトレースに関心があります。ほとんどの場合、ユーザー自身はそのような問題を解決できないため、開発者に連絡する必要があります。 encryptedスタックトレースを一般的な「申し訳ありません」メッセージに添付できるため、開発者はユーザーの問題をより簡単に解決できます。

Youtube internal error

7
deniss

これは使いやすさとセキュリティの問題です。

  • API、特にa REST one、友好的でなければなりません、自己文書化。これには、正確なエラー、考えられる原因、スタックなどを示すわかりやすいエラーが含まれます。

  • 一方、フレンドリーは危険だと思います...

だから答えは：はい、それはセキュリティの問題です。この情報は、潜在的な攻撃者があなたのAPIについてもっと知るのに役立ちます。

それを行う一般的な方法は？

ASP.NETでは、web.configで設定を行い、詳細はエラーです（CustomErrors）。

デフォルトの設定では一般的な安全なエラーが表示されますが、同じコンピューターから閲覧している場合は例外です、完全なエラーが表示されます。このようにして、ローカルコンピューターの開発者はエラーを確認できますが、いったん環境にデプロイすると、詳細なエラー情報を確認できません。

<?xml version="1.0"?>
<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>
4
Oscar Foley