3

Web アプリ アーキテクチャをマイクロサービス ベースに移行しています。コンテンツを提供する REST API (JSON など) がコンテンツを安全にするためにエンコードする必要があるのか​​、それともコンシューマーがコンテンツを取得して表示するのか (HTML など) について社内で議論しています。またはそれを使用する) は、そのエンコーディングを担当する必要があります。ユースケースは、XSS 攻撃などを防ぐことです。

プロバイダーのスタンスは、「すべての人のためにエンコードする方法や、コンテンツをどのように使用するかを知ることはできないので、もちろん消費者はコンテンツをエンコードする必要があります.」

コンシューマーのスタンスは、「プロバイダーは 1 つ、コンシューマーは複数あるので、すべてのコンシューマーにそれを期待するよりも、提供 API で 1 回実行する方が安全です」です。

これに関して一般的に受け入れられているベストプラクティスはありますか?またその理由は?

4

3 に答える 3

4

原則として、「内部」プロセスを通過するときのデータ (使用する意味が何であれ) は、意味のある「内部」形式で格納またはエンコードする必要があります。選択される形式は、通常、エンコード/デコードの手順を最小限に抑え、データの損失を防ぐように設計されています。

次に、出力時に、意味のある出力形式を使用してデータがエンコードされます。データの損失を防ぐことは重要ですが、ここでは適切なエスケープとフォーマットも重要です。

たとえば、内部 API では、バイナリ形式のデータで十分な場合があります。ただし、JSON、HTML、XML、または PDF を出力する場合は、出力形式に合わせてデータを適切にエンコードおよびエスケープする必要があります。

ここで重要な点は、出力形式が異なれば「安全」の概念も異なるということです。HTML に対して「安全」であるものは JSON に対して安全ではない可能性があり、JSON に対して安全であるものは SQL に対して安全ではない可能性があります。タスクに適切なエンコーディングを使用できるように、データは特に出力時にエンコードされます。このステップが事前に行われていると想定することはできません。また、出力関数を、エンコードを行う必要があるかどうかを判断する立場に置いてはなりません。「出力関数は常に安全のためにエンコードする」というルールを守れば、データ インジェクション攻撃について心配する必要はありません。

于 2013-07-20T05:10:31.080 に答える
3

重要な点は次の 2 点だと思います。

  • プロバイダーが使用するエンコーディングは、すべての消費者の実装者が何を期待できるかを知ることができるように、参照ドキュメントで非常に明確かつ正確に指定する必要があります。
  • プロバイダーが使用するデフォルトのエンコーディングが何であれ、必要なすべての情報を保持する必要があります。

これら 2 つのルールに従えば、信頼性とセキュリティの 95% を達成したことになります。

あなたの特定の質問に関しては、良い習慣は中間です.プロバイダーはデフォルトで「ジェネリック」エンコーディングに従いますが、消費者は(オプションで)プロバイダーが適用できる特定のエンコーディングを要求できます-これにより、プロバイダーはおそらくさまざまな種類のいくつかのダムで軽量なクライアントをサポートし、後で API を壊すことなく追加のエンコーディングで拡張できます。

于 2013-07-19T21:24:07.640 に答える
3

セキュリティ分野で善良な市民としての役割を果たさなければならないのは、消費者とプロバイダーの両方であると固く信じています。

プロバイダーとして、安全な製品を確実に提供したいと考えています。クライアントが製品を使用する状況を知る必要はありません。知る必要があるのは、製品をどのように提供するかだけです。配信が JSON である場合、XML やプレーン テキストなどと同様に、そのコンテキストを使用してデータを送信する前にエスケープできます。さらに、セキュリティを支援するトランスポート メソッドが既に存在します。JSONP はそのような配信方法の 1 つです。これにより、ペイロードが適切に消費されるようになります。

ちなみに、私たちの環境では誰も最終的な消費者ではありませんが、消費者として、私たちはすべて最終的なエンド クライアント (主に Web ブラウザーを介したエンド ユーザー) へのプロバイダーです。このため、この最後にデータを保護する必要もあります。私は、ブラック ボックス API がこの仕事をしてくれるとは決して信じません。安全なペイロードを確保するよう常に主張します。そこには多くのツールがあり、データのコンテキストによるサニタイズを支援する OWASP の ESAPI プロジェクトが思い浮かびます。最終的にはこのデータをエンドユーザー (ブラウザ) に送信することになるため、問題が発生した場合は責任を転嫁することはできません。欠陥がどこにあるかに関係なく、サービスは脆弱なサービスと見なされます。さらに、消費者として、ブラック ボックス プロバイダーに信頼して欠陥をタイムリーに修正できるとは限りません。彼らのサポートが不足している場合、または優先順位が高い場合はどうなりますか。それは、エンドユーザーに既知の欠陥を提供し続けるということですか?

セキュリティは層に関するものであり、ソースとエンドポイントに保護手段を設けることは常に望ましいことです。

于 2013-07-19T22:39:36.280 に答える