信頼できないソースからのHTMLを高速かつ設定可能な方法で無害化するためのライブラリです。Java 8+をサポートします。
別の言い方をすれば、クライアントがプロフィールやコメントなどで提供したHTMLに悪意のあるコードが含まれていないことを確認し、サーバーに保存されるのを防ぐAPIです。Webアプリケーションにおける「悪意のあるコード」とは、通常「JavaScript」を意味します。多くの場合、Cascading StylesheetsはJavaScriptを呼び出す場合にのみ悪意があると見なされます。しかし、「通常の」HTMLやCSSが悪意のある方法で使用される状況も多数存在します。
1.6.xシリーズの開発を通じて、多くの機能とAPIを特定し非推奨としました。これらの非推奨項目はすべて1.7.0リリースで削除されました。これらの変更はすべてチケットで追跡されています: https://github.com/nahsra/antisamy/issues/195。各変更は以下に説明します。
CssHandlerには、LinkedList<URI> embeddedStyleSheetsパラメータを削除した2つのコンストラクタがありました。両方のコンストラクタは空の内部LinkedList<URI>を作成するようになり、必要に応じてメソッドgetImportedStylesheetsURIList()を使用してその参照を取得できます。この機能はほとんど使用されず、実際にこれらのコンストラクタが直接呼び出されることも稀であるため、この変更がAntiSamyのほとんどのユーザーに影響を与える可能性は低いです。使用される場合、通常は空のリストがこのパラメータ値として渡され、そのリストはその後二度と使用されません。
CssHandler(Policy, LinkedList<URI>, List<String>, ResourceBundle) シグネチャは削除されました
CssHandler(Policy, List<String>, ResourceBundle) が使用されますCssHandler(Policy, LinkedList<URI>, List<String>, String, ResourceBundle) シグネチャは削除されました
CssHandler(Policy, List<String>, ResourceBundle, String) が使用されます。注意: このメソッドの最後の2つのパラメータの順序が逆になりました。XHTMLのサポートは廃止されました。AntiSamyは現在HTMLのみをサポートします。これはほとんど使用されていない機能であると考えられるため、多くのAntiSamyユーザーに影響を与えることはないと予想されます。
AntiSamyポリシーファイルではXMLスキーマ検証が必須となり、無効にできなくなりました。AntiSamyで使用するには、ポリシーファイルをスキーマ準拠させる必要があります。
ポリシーディレクティブ noopenerAndNoreferrerAnchors はデフォルトで有効になりました。無効にすると、AntiSamyは有効化を促す警告を発します。
AntiSamyのアップグレードライフサイクルに伴い、HTMLパーサーの依存関係に変更があり、使用ケースによっては出力に差異が生じる可能性があります。特定のバージョンを使用していて、アップグレード後に異なる出力が得られる場合は、これを考慮してください。
これは、内部HTML表現をツールの最終テキスト出力に変換する出力シリアライザーにも当てはまります。
AntiSamyチームは、埋め込まれたリモートCSSを許可する機能をサポートすることは危険であると判断し、この機能を非推奨とし、将来のリリースで削除する予定です。この機能のユーザーはほとんどいないと予想されます。
この機能が呼び出された場合、ログWARNを追加しました。使用している場合は、この機能を有効にしないプライマリCssScannerコンストラクタに切り替えて、この機能を無効/削除してください。
まず、Mavenから依存関係を追加します:
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>LATEST_VERSION</version>
</dependency>
おそらく、あなたのサイトでのAntiSamyの使用ケースは、事前定義されたポリシーファイルのいずれかと少なくともおおよそ類似しているでしょう。それぞれが、ユーザーがHTML（および場合によってはCSS）の書式情報を提供するための「典型的な」シナリオを表しています。さまざまなポリシーファイルを見てみましょう:
Slashdotはテクノロジーニュースサイトで、ユーザーが非常に限定されたHTMLマークアップでニュース記事に匿名で返信できます。Slashdotは最もクールなサイトの一つであるだけでなく、多くの異なる攻撃を受けてきたサイトでもあります。Slashdotのルールはかなり厳格で、ユーザーは以下のHTMLタグのみを送信でき、CSSは許可されません: <b>, <u>, <i>, <a>, <blockquote>。
したがって、ほぼ同様の機能を許可するポリシーファイルを作成しました。フォント、色、強調に直接作用するすべてのテキスト書式タグが許可されています。
eBayは、私たちの知る限り、宇宙で最も人気のあるオンラインオークションサイトです。公開サイトであるため、誰でもリッチなHTMLコンテンツを含むリストを投稿できます。eBayがターゲットとして魅力的であることを考えると、いくつかの複雑なXSS攻撃の標的になってきたことは驚くことではありません。リストにはSlashdotなどよりもはるかにリッチなコンテンツを含めることができるため、攻撃対象領域はかなり大きくなります。
MySpaceは、このプロジェクトが生まれた時点で最も人気のあるソーシャルネットワーキングサイトでした。ユーザーは、JavaScriptを含まない限り、ほぼすべてのHTMLとCSSを投稿することが許可されていました。MySpaceは単語ブラックリストを使用してユーザーのHTMLを検証していたため、悪名高いSamyワームの標的になりました。Samyワームは、フラグメンテーション攻撃とブラックリストに登録されるべき単語（eval）を組み合わせたもので、このプロジェクトのきっかけとなりました。
このポリシーファイルの使用ケースはわかりません。すべての有効なHTMLおよびCSS要素（ただしJavaScriptや明白なCSS関連のフィッシング攻撃は除く）を許可したい場合、このポリシーファイルを使用できます。MySpaceでさえこれほどクレイジーではありませんでした。ただし、すべての要素の基本ルールが含まれているため、他のポリシーファイルを調整する際の知識ベースとして使用できるため、優れたリファレンスとして機能します。
AntiSamyにはログ記録用のslf4j-simpleライブラリが含まれるようになりましたが、AntiSamyユーザーは必要に応じて別のslf4j互換ログライブラリをインポートして使用することもできます。また、必要に応じてslf4j-simpleを除外することもできます。
警告: AntiSamyのslf4j-simpleの使用は、設定ファイルなしで、メッセージを標準出力にバッファリングして記録します。そのため、PolicyExceptionなどのExceptionがスローされると、これらのログメッセージの一部またはすべてが失われる可能性があります。これは、slf4j-simpleを標準エラーに出力するように設定するか、そうする別のslf4jロガーを使用することで修正できる可能性があります。
デフォルト設定でAntiSamyをデプロイしたい場合もありますが、サイトがユーザーに許可する内容に対して厳格なビジネス主導のルールを持ちたい場合も同様にあり得ます。調整を決定する議論では、攻撃対象領域も考慮する必要があります。これはポリシーファイルに比例して大きくなります。
各タグの要件に基づいてポリシーの例を適応およびテストできます。指定できるサポートされているタグアクションは次のとおりです:
filter: タグを削除しますが、コンテンツは保持します。validate: ルールに合格する限りコンテンツを保持します。remove: タグとコンテンツを削除します。truncate: タグ属性とすべての子タグを削除します（ただし、テキストコンテンツがある場合はそれを保持します）。encode: filterに似ていますが、タグをHTML用にエンコードして生のテキストとして保持し、子タグは階層の1つ上のレベルに移動します。AntiSamyの使用は簡単です。以下はポリシーファイルを使用してAntiSamyを呼び出す例です:
import org.owasp.validator.html.*;
Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);
MyUserDAO.storeUserProfile(cr.getCleanHTML()); // いくつかのカスタム関数
Policyオブジェクトを作成する方法はいくつかあります。getInstance()メソッドは以下のいずれかを取ることができます:
String ファイル名File オブジェクトInputStreamPolicy ファイルは、以下の例のようにAntiSamy#scan()メソッドの2番目の引数としてファイル名を渡すことでも参照できます:AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);
最後に、ポリシーファイルは2番目のパラメータでFileオブジェクトとして直接参照することもできます:
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));
CleanResultsオブジェクトは多くの有用な情報を提供します。
getCleanHTML() - クリーンで安全なHTML出力getCleanXMLDocumentFragment() - getCleanHTML()に反映されるクリーンで安全なXMLDocumentFragmentgetErrorMessages() - 文字列のエラーメッセージのリスト -- これが0を返しても、攻撃がなかったことを意味しません！getNumberOfErrors() - エラーメッセージの数 -- 繰り返しますが、0は入力が安全だったことを意味しません！getScanTime() - スキャン時間（秒）を返します重要な注意: getErrorMessages()メソッドについては多くの混乱がありました。getErrorMessages()メソッド（およびgetNumberOfErrors()）は、空のリストを返した場合に「これは安全な入力か？」という質問に肯定的に答えるものではありません。常にサニタイズされた入力を使用する必要があり、渡された入力に攻撃がなかったことを確実にする方法はありません。
サニタイザーの有効性に不可欠なシリアル化および逆シリアル化プロセスは、意図的に損失が生じるようになっており、多くの攻撃ベクトルを介した攻撃をフィルタリングします。残念ながら、この戦略のトレードオフの1つは、AntiSamyが攻撃が行われたことを事後的に常に認識できるわけではないことです。したがって、getErrorMessages()およびgetNumberOfErrors() APIは、ユーザーが自分の意図した入力がシステムの要件を満たしているかどうかを理解するのに役立つものであり、開発者が攻撃の存在を検出するのを助けるものではありません。
追加のドキュメントは、このGitHubプロジェクトのwikiページから入手できます: https://github.com/nahsra/antisamy/wiki およびOWASP AntiSamyプロジェクトページ: https://owasp.org/www-project-antisamy/
バグを発見した場合は、AntiSamyリポジトリでIssueを作成してください: https://github.com/nahsra/antisamy/issues
AntiSamyに脆弱性を発見した場合は、まずIssueリスト（上記参照）を検索して、すでに報告されていないか確認してください。報告されていない場合は、Dave Wichers（dave.wichers at owasp.org）まで直接ご連絡ください。パッチが実装されデプロイされる間、ユーザーのセキュリティを維持したいため、GitHub Issuesを介して脆弱性を報告しないでください。脆弱性を発見したことで謝辞を希望される場合は、このプロセスに従ってください。
詳細はファイルにあります: SECURITY.md
ソースから簡単にビルドおよびテストできます:
$ git clone https://github.com/nahsra/antisamy
$ cd antisamy
$ mvn package
BSD-3-Clauseライセンスの下でリリースされています。詳細はこちら: LICENSE