0

Webページにユーザー入力を追加するときは、XSS攻撃などを防ぐために(もちろんHTMLでない限り:)エンコードする必要があります。次のようになります。

litForename.Text = HttpUtility.HtmlEncode(MyUser.Forename);

テンプレートを作成してビジネスロジックレイヤーを生成し、データがデータベースから出てすぐにUIコードに到達する前に、それを使用してすべてのエンコードを実行することを考えています。これにより、すべてがエンコードされている必要があります(Xhtml / Xml文字列を含む列は明らかに除外します)。データアクセスメソッドのオーバーロードにより、エンコードなしでデータを取得できるようになります(したがって、データを編集できます)。

// Get a 'User' entity with all the string fields HTML encoded
BLL.Users.GetById(int userId)

// Get a 'User' entity with optional HTML encoding
BLL.Users.GetById(int userId, bool useHtmlEncoding)

これは他の誰かが使用するアプローチですか、それともばかげた考えですか?長所と短所は何ですか?

ありがとう。

4

5 に答える 5

3

これが理にかなっているエッジケースがあるかもしれませんが、一般的に私はこれに反対することをお勧めします。ビジネスロジック層は、ビジネスロジックとビジネスロジックのみを処理する必要があります。

同様に、コントローラー(ASP.NET MVCを想定)は、特定のタイプのUIを見越して既に変更された値ではなく、ビジネスドメインのコンテキストで意味のある値を処理する必要があります。

UIレイヤーは、それがどのタイプのUIであるかを認識し、気にする必要がある唯一のレイヤーです。現時点では、唯一のタイプのUIがHTMLベースになるように思われるかもしれませんが、それは変わる可能性があります。

于 2009-06-07T18:31:31.510 に答える
1

HtmlEncodeデータベースに保存されたデータを使用する際の問題は、データのようなもの&"データ内で処理する必要があることです。たとえば、「TomO'Brien」は"「TomOBrien」としてデータベースに保存されます。その上でSELECTまたはUPDATEを実行するのは、注意が必要です。

HtmlEncodeUIにテキストを表示するためだけに使用する方がうまくいくと思います。

于 2009-06-07T18:33:03.083 に答える
1

あなたのビジネスロジックは本当にあなたのプレゼンテーションについて知っているべきではありません。Web、ウィンドウ、またはその他のタイプのUIにフィードするかどうかにかかわらず、ビジネスロジックにこれらの詳細を含めるべきではありません。

あなたのビジネスレイヤーを使用している人々があなたのエンコーディングの上にデ​​ータを再びエンコードしようとするかもしれないとあなたは考えましたか?それは物事が本当に乱雑に見える原因になる可能性があります。

于 2009-06-07T20:00:31.923 に答える
0

ビューレベルのデータ変換がビュー生成に属するという他のポスターに同意します。XMLベースのビュー(XHTML、音声ブラウジング用のVoiceXML、Webサービス用のXMLなど)のみから始めることもできますが、AJAXインタラクションをサポートするためにJSONビューも必要であると判断した場合はどうなりますか?JSON Javascriptリテラルは、XMLとは異なるエスケープメカニズムを使用します。

また、ビューの生成とは関係のない目的で、あるロジック層メソッドが別のロジック層メソッドを呼び出す必要がある場合もあります。おそらく、呼び出し元のメソッドは、別のデータベーステーブルにデータを入力するバルクデータ変換を適用する必要があります。その場合、呼び出し元のメソッドはXMLエスケープを元に戻す必要があります。

于 2009-06-07T19:23:46.803 に答える
0

PHPのmagic_quotes_gpc機能の教訓を学びましょう。このようなエンコーディングは、間違いなく物事を混乱させるだけであり、すべきでないときに脱出することを引き起こし、必要なときに脱出することを忘れ、一般的に苦痛になります。データベース、Web、その他の場所など、必要な場所にデータが送信されるまで、データをエンコードしないでください。

于 2009-06-07T20:10:47.973 に答える