4

XSLTを使用してXMLデータをフォーマットしてXHTMLとして表示するアプリケーションがあります。

システムは任意のXMLスキーマに対応できるため、システムのユーザーはスキーマとXSLTをアップロードする必要があります。明らかに、これは管理者レベルのユーザーにのみ許可されているタスクですが、狙うのもかなり大きな目玉なので、より安全にしようとしています。

Saxon9.0Bを使用していることに言及する必要があります

ユーザー提供のXSLTをサニタイズする標準的な方法はありますか？これまでのところ、考えられる3つの問題を特定しましたが、私が単に考えていなかった問題がさらにある可能性があることを認識しています。

  1. xsl：importおよびdocument（）関数は、サーバーファイルシステムで取得できます。これは、カスタムURIリゾルバーを使用してロックダウンするのは非常に簡単なので、これをカバーしていると確信しています。

  2. 出力にはjavascriptを含めることができます。OWASP Anti-Samyのようなものを使用して、許可された出力タグをホワイトリストに登録することを考えています。

  3. XSLTはJava関数を呼び出すことができます。これは現在私に頭痛を引き起こしているものです。私たちはそれを使用しているので、機能を完全にオフにしたくありません（現時点ではそれを行う方法さえわかりませんが）。私の好ましい解決策は、既知の安全な関数のみを実行できるように、受け入れ可能なJava名前空間をロックダウンできるようにすることです。しかし、私は他の提案を受け入れています。

ゴールドスタンダードは、すべての既知のXSLTベースの脆弱性を処理するだけの標準ライブラリですが、上記の問題（特に3つ）に取り組むための提案がない場合は、非常に評価されます。

前もって感謝します

4

2 に答える 2

2

Saxon には、「再帰的」(動的にロードされる) 拡張関数の使用を無効にする構成オプションがあります。これは、API を介して構成に明示的に登録された「統合された」拡張機能の使用を妨げるものではありません。これは、サービス プロバイダーに拡張機能の登録を許可するが、スタイルシートの作成者には許可しないという要件を満たしているようです。

必要に応じて、独自の JavaExtensionFunctionFactory を定義して拡張機能呼び出しのバインド方法を制御することにより、さらに選択的にすることができます。これはかなり低レベルのシステム プログラミングであり、ニーズを満たすためにどのメソッドをオーバーライドする必要があるかを確認するには、おそらくソース コードを調べる必要があります。

document() と同様に、collection()、unparsed-text()、xsl:result-document を考慮する必要があります。いずれの場合も、動作を制御できる Saxon フックがあります。

于 2012-12-19T08:44:16.507 に答える
0

サーバー上で誰かの XSLT をアップロードして実行することは賢明なことではないと思います。

次のようなサービス拒否攻撃など、防止または検出できないものがあります。

  1. 利用可能なすべてのメモリを使い果たし、スタック オーバーフローでサーバーをクラッシュさせる無限の再帰。

  2. 何分または何時間もかかる変換 -- 停止する問題は決定できないため、これが意図的な永久ループなのか、偶発的なプログラマ エラーなのか、収束する可能性がある計算なのか、収束しない可能性があるのか​​はわかりません。

確かに、再帰的に定義されたエンティティを参照するなど、他にも多くのエクスプロイトがあります...

于 2012-12-18T20:56:16.093 に答える