3

外部の HTML データ (HTML エンコードされた電子メール テキストなど) を安全に表示する必要があるアプリケーションがあります。つまり、XSS 試行やその他の厄介なものを削除します。ただし、HTML を表示できるようにする必要があります。これまでに検討されたソリューションは理想的ではありません。

  1. HTMLPurifier などで HTML をきれいにします。正常に動作しますが、電子メールのサイズが 100K を超えると非常に遅くなり、電子メールあたり数十秒になります。十分に安全なパーサーはどれも、PHP では遅くなると思います。一部の電子メールは非常に質の悪い HTML であり、1 ページのテキストに対して 150K の HTML を生成するものを見たことがあります。
  2. HTML を iframe に表示する - ここでの問題は、iframe が XSS AFAIK から安全であるために別のオリジンにある必要があることです。これには、同じアプリに対して別のドメインが必要になります。2 つのドメインでアプリケーションをセットアップするのは、はるかに手間がかかり、一部のセットアップ (1 つのドメイン名しか与えないホスティングなど) では非常に難しい場合があります。

この結果を達成できる他のソリューションはありますか?

4

2 に答える 2

2

私の理解では、そうは思いません。

問題は、その構造を理解している場合にのみHTML タグを安全に削除できることであり、「その構造を理解する」ことはまさに解析です。HTML の構造を解析する別の方法を見つけて、それを解析と呼ばなくても、それはあなたが行っていることであり、何らかの形で低速 (または安全でない) になることは間違いありません。

あなたができることは、いくつかの予備的なフィルター（たとえばstrip_tags、これは一般的に良い予備的なものです（他に何もない場合））を試して、パーサーの作業を減らすことですが、それが実行可能かどうかは、タグのホワイトリストのサイズに依存します-strip_tagsパーサーがそれに到達する前に HTML の大部分が除外されるため、小さいホワイトリストの方がベンチマーク結果が向上する可能性があります。

さらに、さまざまなパーサーはさまざまな方法で動作し、頻繁に扱う HTML の種類は、ある種類のパーサーに最も適している場合があります。あなたにとってより良いベンチマークです（違いはごくわずかだと思いますが）。

ただし、そのようなジャグリングがユースケースで機能するかどうかは、おそらく自分でベンチマークする必要があるでしょう.

注意点: それを追求することに決めた場合、私は iframe アプローチを使用しないことを知っておいてください。HTML をフィルタリングしないと、フォームも許可され、(IMO) スクリプトや CSS と組み合わせて非常に説得力のあるフィッシングを設定するのは簡単になります。たとえば、「このメールはパスワードで保護されています。続行するには、パスワードを入力してください」。

于 2012-11-01T13:20:59.790 に答える
0

考えられる解決策の1つ（およびSOが使用する解決策！）は、特定のタイプのタグのみを許可することです。 <p>と<br />大丈夫ですが、<script>すぐにです。

于 2012-11-01T01:10:48.557 に答える