ZIPのクロールで、展開を拒否したはずのファイルがバイナリーのごみとして検索本文へ入る問題に対し、fess-crawlerのPR #228が提案されています。
原因の例外にあるZIP爆弾の検出結果を拾う
Tikaが過大な展開を検出すると、外側の例外はTIKA-237: Illegal SAXExceptionとなり、Suspected zip bombという情報が原因の例外にだけ入ることがあります。従来の抽出処理は外側のメッセージしか確認せず、このケースを見逃していました。
標準の抽出設定ではxmlExtractorが登録されています。そのため、通常のXML抽出への代替処理へ進み、ZIPの生のバイト列が本文として返ることがありました。PRには、約0.3MBのファイルから展開後300MB相当となるZIPで、約305KBのごみが登録された例が記載されています。Tika 3.3.2でも同じ挙動と報告されており、Tika 4だけに起因する問題ではありません。
修正案の適用条件と初期値
修正案は原因の例外を順にたどり、メッセージにzip bombがあれば、既存のreason=zipBombDetectedを含む抽出エラーとして拒否します。他のSAXExceptionでは従来どおりXML抽出への代替処理を残します。
新しい有効化スイッチや初期値の変更はありません。確認した標準extractor.xmlではmaxCompressionRatio=1、maxUncompressionSize=10000000が設定されていますが、今回のPRはこれらの閾値を変更しません。実際の判定はTikaと環境の抽出設定にも依存するので、この値をすべてのアーカイブの安全性を保証する上限として扱わないでください。
利用には修正を含むcrawlerを組み込んだ対応Fessビルドが必要です。PR番号だけを根拠に、本番環境のjarを単独で差し替える手順にはしません。
運用で確認すること
取り込み後の本文に読めないバイト列が並ぶ場合は、元のファイル、抽出ログ、原因の例外を併せて確認します。修正を含む検証環境では、疑わしいファイルが本文として返らず、reason=zipBombDetectedの抽出エラーになることを確認します。実運用のファイルを検証する際も、隔離した環境で扱います。
既に登録されたごみを自動削除する処理は含みません。対象文書を特定し、運用上の削除・再クロール方針を決める必要があります。失敗した再クロールだけで古い文書が必ず消えるとは判断しません。また、例外メッセージを調べる修正であり、すべての圧縮爆弾を検出する新しい仕組みではありません。
PRではxmlExtractorを登録したコンテナーと生成ZIPを使う回帰テストが追加されています。テスト成功はPR作者の報告で、こちらでFessの実クロールを再実行したものではありません。