パブリックXSLT＆XMLプレイグラウンド（PHP DOMDocumentなど）を使用）セキュリティリスク？
ユーザーがPHPにサンドボックスまたはプレイグラウンドを設定して、XMLとXSLTを作成（または貼り付け）できるようにして、XSLTを介してXMLを変換したいとします（PHP 5のDOMDocumentおよび関連オブジェクト）。
したがって、簡単な例では、2つのtextareas（XML用とXSLT用）を持つフォームがあります。ユーザーは自分のXMLとXSLTを入力し、ボタンを押します。 XSLTとXMLは私のサーバーに投稿され、そこでXSLTを使用してXMLを変換し、結果をユーザーに返します。
ある意味では、これはeval()に似ていますが、このシナリオのリスクは最小限であるか、PHPとそのコードをeval() edしました。
私の直感は正しいですか、またはここに隠れたセキュリティ問題がありますか？もしそうなら、それらは何であり、私の理論的なアプリケーションを確保するためにどのような予防策を検討する必要がありますか？.
私はPHP 'newbie'と呼んでもかまいません。しかし、過去にXMLとXSLTライブラリのセキュリティの脆弱性を分析し、最近、かなりの少しXML、これは私が考えることができるものです：
- 特権コードの実行を引き起こすXSL変換を渡すことが可能である場合、そのような実行を無効にするいくつかの手段を見つける必要があるかもしれません。 Javaの世界（私がどこから来たか）では、この「機能」は標準ではありませんが、 Xalan-Jトランスフォーマーに実装されていることがわかります。構築済み 。攻撃者がXSLファイルを渡した場合、SQLクエリの実行（SQL拡張機能を使用）、またはサーバーですでに利用可能なコードの実行（Java =拡張）、条件が正しければXalan-Jはそうします。これがPHPで使用されるトランスフォーマーに適用されるかどうかはわかりませんが、トランスフォーマーがXMLをXMLに変換し、何も実行しないことを確認する価値があります。 else（これはあなたの要件のようです）私はこれをより簡単な言葉で言い直します-XMLドキュメントの変換に必要な機能のみを提供するために、可能な限りロックダウンできるXMLトランスフォーマーを選択します。
- ファイルやその他のURI（攻撃者には見えない）はXSLで指定できます。これはトランスフォーマーによってフェッチされ、結果のXMLに含めることができます。これは 外部エンティティ展開 （XXE）攻撃です。基礎となるプロセスがファイルにアクセスできる場合、
/etc/passwd、/etc/shadowなどをこの方法で取得することが可能です。可能であれば、エンティティ参照の展開を無効にします。 - XXEに関連するのは XDoS です。これにより、サービス拒否攻撃が開始され、CPUサイクルが消費されます。対応策は次のとおりです。
- パーサーが実行できるエンティティ展開の数を制限する（これは 安全な処理サポート）に似ています Java API for XML Processing 1.4で必要）。この領域での対策は、ドキュメントの任意の要素に表示できる属性の数を制限することです。
- dTDの使用を無効にします。 DOCTYPE要素が含まれるドキュメントを拒否するようにパーサーを構成する必要があります。これは、SOAP実装で採用されているアプローチです。
- XSL変換は有効なXMLまたはHTMLを生成する必要がないため、反映されたXSSの可能性もあります（JavaScriptを使用してtextareaにデータを入力していない場合）。結果は、文字のランダムなシーケンスになります。したがって、XSS攻撃を防ぐために、出力を適切にエスケープする必要があります。
- XMLパーサー自体の脆弱性により、他の形式の攻撃が可能になります。 このCERTアドバイザリ は、XML解析ライブラリの潜在的な問題を示しているため、投稿者です。パーサーは、さまざまな仕様によってさまざまな要件が課されるため、複雑です。これにより、パーサーが特定の文字シーケンスを安全な方法で処理できないEdgeケースが発生することがあります。安全なパーサーの作成にはかなりの作業が費やされていますが、作業が完了していないとは言えません。この場合の適切な推奨事項は、適切に実装および理解されたXML解析ライブラリを選択し、セキュリティ修正のために解析ライブラリに定期的にパッチを適用することです。
上記は必ずしも包括的ではありませんが、それは良い出発点であると思います。