12

OWASP Html Sanitizer を使用して、Web アプリへの XSS 攻撃を防ぎます。プレーン テキストである必要がある多くのフィールドで、サニタイザーは予想以上のことを行っています。

例えば：

HtmlPolicyBuilder htmlPolicyBuilder = new HtmlPolicyBuilder();
stripAllTagsPolicy = htmlPolicyBuilder.toFactory();
stripAllTagsPolicy.sanitize('a+b'); // return a+b
stripAllTagsPolicy.sanitize('foo@example.com'); // return foo@example.com

データベースに間違ったデータが入ってしまう+など、メールアドレスなどのフィールドがある場合。foo+bar@gmail.com2つの質問：

  1. などの文字+ - @はそれ自体で危険ですか? 本当にエンコードする必要がありますか?
  2. + - @ などの特定の文字を許可するように OWASP html サニタイザーを構成するにはどうすればよいですか?

質問 2 は、私が回答を得るためのより重要な質問です。

4

4 に答える 4

3

ESAPI API を使用して特定の文字をフィルタリングすることができます。ただし、特定の HTML 要素または属性を許可する場合は、次の allowElements および allowAttributes を使用できます。

// ポリシーを定義します。

Function<HtmlStreamEventReceiver, HtmlSanitizer.Policy> policy
     = new HtmlPolicyBuilder()
         .allowElements("a", "p")
         .allowAttributes("href").onElements("a")
         .toFactory();

 // Sanitize your output.
 HtmlSanitizer.sanitize(myHtml, policy.apply(myHtmlStreamRenderer));
于 2014-11-17T03:02:26.433 に答える
1

XSS の危険性は、あるユーザーが自分の入力データに html コードを挿入し、それを別のユーザーに送信される Web ページに後で挿入する可能性があることです。

これを防ぐには、原則として 2 つの戦略があります。ユーザー入力がシステムに入ったときにすべての危険な文字を削除するか、後でブラウザーに書き戻すときに危険な文字を html エンコードすることができます。

最初の戦略の例:

ユーザー入力データ (html コード付き)

  1. サーバーはすべての危険な文字を削除します
  2. 変更されたデータはデータベースに保存されます
  3. しばらくして、サーバーは変更されたデータをデータベースから読み取ります
  4. サーバーは、Web ページ内の変更されたデータを別のユーザーに挿入します

2 番目の戦略の例:

  1. ユーザー入力データ (html コード付き)
  2. 危険な文字を含む変更されていないデータがデータベースに保存されます
  3. しばらくして、サーバーはデータベースから変更されていないデータを読み取ります
  4. サーバーは危険なデータを html エンコードし、別のユーザーの Web ページに挿入します

通常、データを読み取る頻度は使用するよりも少ないため、最初の戦略はより単純です。ただし、データを破壊する可能性があるため、より困難でもあります。後でブラウザに送り返す以外の目的でデータが必要な場合 (実際に電子メールを送信するために電子メール アドレスを使用するなど) は、特に困難です。これにより、データベースでの検索、pdf レポートへのデータの挿入、電子メールへのデータの挿入などを行うことが難しくなります。

もう 1 つの戦略には、入力データを破棄しないという利点があるため、後でデータをどのように使用するかについて自由度が高くなります。ただし、ブラウザに送信されるすべてのユーザー送信データが html エンコードされていることを実際に確認するのは、より難しい場合があります。特定の問題の解決策は、その電子メール アドレスを Web ページに配置した場合 (またはその場合)、その電子メール アドレスを html エンコードすることです。

XSS の問題は、ユーザーが送信したデータと制御コードを混在させたときに発生する、より一般的な問題の例です。SQL インジェクションも同じ問題の例です。問題は、ユーザーが送信したデータがデータではなく指示として解釈されることです。あまり知られていない 3 番目の例は、ユーザーが送信したデータをメールに混在させる場合です。ユーザーが送信したデータには、電子メール サーバーが指示として解釈する文字列が含まれている場合があります。このシナリオでの「危険な文字」は、改行とそれに続く「From:」です。

将来的に何らかのアプリケーションで命令として解釈される可能性のあるすべての制御文字または文字シーケンスに対して、すべての入力データを検証することは不可能です。これに対する唯一の恒久的な解決策は、実際にそのデータを使用するときに安全ではない可能性のあるすべてのデータを実際にサニタイズすることです。

于 2012-09-26T21:31:16.007 に答える