簡潔な答え:
データベースからの情報を本当に信頼できる場合は、正規化を実行する必要はありません。データがブラウザーで使用されないことがわかっている場合は、HTML 用にエンコードしないでください。ただし、データがブラウザによって使用されると思われる場合は、エンコードし、呼び出し元に結果を処理させてください。それが容認できないと判断された場合は、Web サービスの「安全でない」バージョンを公開します。このバージョンの URL では、警告ワードを明示的に使用して「悪意のある可能性がある」というフラグが付けられ、安全でないアクティビティに関与していることを発信者に認識させます。
長い答え:
まず、ユースケースによると、基本的に呼び出し元のクライアントにデータを提供しています。あなたの質問を読んだときの私の最初の本能は、あなたが自分のデータ コンテキストに慣れていないと思うということです。
そのため、通常、canonicalize()
検証を実行するための安全なデータが必要なときに への呼び出しが表示されます。したがって、最初に尋ねる質問は次のとおりです。
q1: データベースからのデータを信頼できますか?
q1 のガイドライン: データが適切に検証および無効化されている場合、たとえば、ESAPI.validator().getValidInput( args );
データを保存するプロセスによる呼び出しを使用して、アプリケーションは安全な電子メール文字列をデータベースに保存します。この時点で入力データを信頼できることが証明できる場合は、ここで行っているように出力を正規化しないことは完全に安全です。
ただし、この時点でデータを信頼できない場合は、データを下流のシステムに渡す前に検証する必要があるというシナリオになります。を呼び出すとESAPI.validator().getValidInput( args );
、入力が正規化され、有効な電子メール アドレスであることを確認できます。ただし、これには、発信者がニュートラル化された入力を適切に変換する必要があるという手荷物が伴います。これは、質問によると、回避したいことです。
安全なデータをダウンストリームに送信したいが、データ ソースを防御できるほど信頼できない場合は、安全なデータを呼び出し元に送信し、最後にそれを操作させる以外に選択肢はありません。私はすぐに議論します。
q2: ブラウザーは私のデータを消費するために使用されますか?
q2 のガイドライン: このencoder.encodeForHTML()
方法は、ブラウザの解釈を無力化するように設計されています。あなたはRESTful Webサービスについて話しているので、なぜそれを使用する必要があると思うのかわかりません。ブラウザはblabla@gmail.com
正しい正規形式に正しく解釈する必要があるためです-おそらく、次のようなデータ要素として正しくトラップされていない限りドロップダウンボックスで。しかし、これはあなたがコントロールできないと私が推測しているものですか?
おわかりのように、このような質問に対する迅速な答えはありません。呼び出し元がデータをどのように使用するかについて、ある程度理解しておく必要があります。ブラウザによってデータがデータとして正しく処理される可能性と、データがコードとして処理される可能性があるため、データを取得するために「安全」および「安全でない」呼び出しを提供する必要がある場合があります。クライアントがサービスをどのように使用するかを制御することはできません。怠惰な呼び出し元は安全でないバージョンしか使用しない可能性があるため、これはあなたを悪い場所に置きます. 私の業界でこれが起こった場合、私は通常、安全でない関数を呼び出す URL が次のようになるようにします。mywebservice.com/unSafeNonPCICompliantMethod
または同様のものを使用して、呼び出し元にリスクを明示的に受け入れるように強制します。ブラウザの正しいコンテキストで使用されている場合...安全でないメソッドは実際には安全かもしれません。あなたは知らないでしょう。