最近、Webベースのアプリケーションにhtmlpurifierを実装しました。以前は、一般的に知られているXSSインジェクション（スクリプト、imgなど）に一致する正規表現がありました。これでは不十分であることがわかったため、htmlpurifierに移行しました。htmlpurifierの動作が遅い（以前の正規表現メソッドと比較して非常に遅い）ことを考えると、htmlpurifierを使用する価値は本当にありますか？または、満足のいくレベルに達するまで正規表現フィルタリングを増やし続けることは意味がありますか（その時点で速度の利点が無効になると主張される可能性があります）。Webアプリケーションのセキュリティに関して同様の問題に直面した他の人はいますか？最終的には何をしましたか？
何か曖昧に思われる場合はお知らせください。詳細をお知らせします。
正規表現の問題は、HTMLのフィルタリングが複雑すぎて、大きな混乱を引き起こすことなく正規表現を使用して簡単に、またはエレガントに実行できないことです。
HTMLを実際に理解し、HTMLとして操作できるものを作成し、ブラウザーが何かをどのように解釈するかを知る必要があります。正規表現は、1つの大きな長い文字列であるかのように動作します。たとえば、現在の一致がコメント内、属性内、または要素内にあることを認識するなど、ステートフルな方法でHTMLを解析するのは得意ではなく、エレガントでもありません。正規表現でそれをエミュレートするのは非常に複雑です。
もう1つの問題は、「一般的に知られているXSSインジェクションのマッチング」が思ったよりもはるかに複雑であるということです。そうでない場合、あなたはそれを正しく行っていません。フィルタはHTMLを知っている必要があり、有効なURLスキームとは何か、HTMLのさまざまな部分でnullバイトがどのように機能するかなどを知っている必要があります。正規表現ベースのフィルターによって行われます。
そしてもう1つ、HTML清浄機は、自分が何をしているのかを知っている誰かによって維持されているということです。あなたはそれを信頼することができます、そしてあなたはそれに新しい欠陥があるならばそれがパッチを当てられるであろうと信じることができます。これにより、同じことを自分でやろうとする多くの作業を節約でき、さまざまなパッチをすべて最新の状態に保つことができます。
html / javascriptに正規表現を使用していますか？おそらく、ボビス氏によるこの壮大な答えを見たことがないでしょう。つまり、正規表現を使用する場合、2つの問題があります。実際、HTML Purifierが非常に遅い理由は、メッセージをクリーンアップするために何百もの呼び出しpreg_match()を使用するためです。preg_repalce()安全性が低下することは間違いありませんが、whealを再発明してはなりません。
本当の問題はhtmlspeicalchars($var,ENT_QUOTES);vsHTMLPurifierです。HTML Puriferは遅いだけでなく、何度もハッキングされています。他に選択肢がない場合を除いて、HTML Purifierを使用しないでください。htmlspeicalcharsはほとんどの問題を解決し、バイパスできない方法で解決します。
後悔するより安全である方が良いです。正規表現では見つけられない可能性のある攻撃がたくさんあります。たとえば、ここにいくつかあります。HTML Purifierが遅すぎる場合は、精製されたHTMLをキャッシュすることが役立つかどうかを確認してください。