REST APIを構築して、クライアントとサードパーティパートナーの両方のセキュリティ機密データを保存しています。
各リクエストは、ユーザーがログインした後、短時間割り当てられた一時キーをキーとする特定のデータのHMACを使用して検証されます。もちろん、すべてがTLSで実行されます。すべてのリクエストは、返されたデータのキーと、リクエストが何らかの理由でブロックされなかった場合に返されたデータのキーとともにログに記録されます。
データが存在しない場合、または特定の場所のデータが特定のユーザーによって読み取られても更新されない場合、または更新リクエストが不正な場合、サーバーは意味のあるエラーメッセージを返す必要がありますか?
ユーザーにアクションを実行する権限がない場合は、401または403の応答が返され、アクションを実行する権限がないためにリクエストが失敗したことが示されます。データが不正な形式である場合、または予期されるデータ型が一致しない場合(intフィールドに文字列を送信する場合など)には、他の応答コードが使用されることがあります。基本的に、REST/HTTPの適切なプラクティスに従い、すべてをログに記録しますが、何が問題だったかに関する基本的なヒント以外に、ユーザーに情報を提供しないでください。
何らかの方法でシステムに対して使用される可能性がある場合に備えて、誰にも情報を提供しないでください。 500エラーを返すだけで、何の説明もありません。 404を返すかどうか、または空の応答または500エラーを代わりに返す必要があるかどうかについては、ある程度の不一致があります。サードパーティの開発者がこれらの応答に遭遇し、その理由がわからない場合は、当社に連絡し、誰かにログを調べて、要求を正しく行う方法を説明してもらう必要があります。
誰がどの方法論が最も理にかなっているのかについて「溝から」の経験がありますか?特に懸念されるのは、セキュリティとユーザビリティおよびサポートリクエストのバランスをとる方法です。
短縮版:
アプリケーションの正当なユーザーをサポートできるだけの情報を提供してください。
ロングバージョン:
まず、これはアプリケーションのコンテキストに依存するため、これに対する単一の答えはありません。製品のオープンソースAPIをリリースしてクライアントが記述できるようにする場合は、有用なフィードバックを提供する方向に傾けて、彼らがコードをデバッグし、有用なエラーハンドラーを記述できるようにする必要があります。クローズドソースサーバーとやり取りするクローズドソースクライアントソフトウェアをリリースする場合は、自分自身にのみ影響を与えるので、もう少し制限が厳しい場合があります。
2つ目は、RESTfulモデルは、意味的な意味を持つHTTPコードを返すことを意味します(たとえば、「すべてが500だけではなく、「見つかりません」の404)。もちろん、RESTは、物事を行うための単なる方法であるため、REST監査人がナックルをラップしない場合とは異なりますが、モデルを使用している場合は、そのまま設計する理由があることを考慮する必要があります。
第三に、あなたが持つことができる最も重要なセキュリティの焦点は、シグニファイアではなく、エラーメッセージの内容です。 404、403、405、502、または503を返すことは、エンドポイントが-おおまかに-何が問題だったかを判断するのに役立つため、適切です。一方、Tomcatサーバーからスタックトレースを返すことは、やり直しの方法です。これがおそらくデフォルトであるため、注意してください。
最後に、私の「トレンチから」の経験は、私が説明したとおりでした。正しいHTTPエラーコードを返しますが、それについて詩的である必要はありません。「503」は「サービスが利用できません」と言っており、それで終わりです。 HTTPレベルの問題ではないものについては、短いアプリケーション層エラーコードを含む200を返します。コードは数値であり、APIで見つけることができるため、「攻撃者」にいくつかの情報を提供します-ここで彼らは間違ったパスワードを持っていました、ここで彼らは同時接続が多すぎました、ここで彼らは「不快なコンテンツ」を持っていました。はい、それは攻撃者にシステムをマッピングする方法を提供しています。正当なユーザーがデバッグできるシステムを持つことの価値は、一般的な戻り値でエラーを難読化することによって得られるセキュリティ上の利点を上回っています。たとえば、賢い攻撃者がラウンドトリップレイテンシに細心の注意を払うことで認証エラーとWAF違反を区別できるようにしたいと思っています。そのため、すべてを失うことはありませんエラーコードで彼。
エラー401
これにより、ブラウザがHTTP認証ログインボックスを表示するようになります。これは煩わしく、ユーザーを混乱させます。
それ以外の場合は、必要なエラーコードを返します。特定のクライアントが、応答コードに基づいて特定の処理を実行することを覚えておいてください。
たとえば、500
または403
は、検索エンジンによる応答のインデックス作成を妨げる可能性がありますが、200
ではないかもしれない。エラーコード自体は、実際にはセキュリティに関して何も開示していません。 4xx
範囲は、「クライアントが何か間違ったことをした」と言いますが、5xx
rangeは、「サーバーが何か間違ったことをした」と言います。
安らかなサービスの場合、私は両方のオプションを組み合わせます。しかし、私は401または403を返し(それらを区別しないでください)、単純に404と500の一般的なエラーを発生させます。代わりに、404または500ではなく、カスタムメッセージで200を使用します。