私はDjangoのtextarea filedsのTinyMCEエディタを使用しています。リッチテキストフィールド用のDjangoで安全なフィルタを使用する
リッチテキストをユーザーに表示するために、HTMLリッチテキストをブラウザに表示できるように、Djangoテンプレートで "安全"フィルタを使用するように強制されています。
ユーザーのブラウザでJavaScriptが無効になっていると、TinyMCEは読み込まれず、そのようなテキストエリアから<script>または他のXSSタグを渡すことができます。そのようなHTMLは、ユーザーに表示することは安全ではありません。
TinyMCEから来ていないような安全でないHTMLテキストの世話をするにはどうすればよいですか？
JavaScriptを無効にしたブラウザだけでなく、生のHTMLを心配するのは間違いありません。サーバーのセキュリティを考慮するときは、ブラウザーで行われた作業をすべて無視し、サーバーが何を受け入れ、何が起こるかだけを調べる必要があります。あなたのサーバはHTMLを受け取り、それをページに表示します。これは危険です。
TinyMceがHTMLを引用するという事実は、間違ったセキュリティだということです。サーバは受け入れたものを信頼します。
危険な構造物を取り除くために、到着時にHTMLを処理することです。これは解決すべき複雑な問題です。 XSS Cheat Sheetを見て、問題を引き起こす可能性があるさまざまな入力を確認してください。
lxmlには、HTML：http://lxml.de/lxmlhtml.html#cleaning-up-htmlを消去する機能がありますが、使用したことがないので、その品質を保証することはできません。
これには良い答えはありません。 TinyMCEはHTMLを生成し、djangoの自動エスケープは特にHTMLを削除します。
この問題の従来の解決策は、ユーザー入力側（bbcode、markdownなど）にHTML以外のマークアップ言語を使用するか、限られた数のHTMLタグをホワイトリストにすることでした。 TinyMCE/HTMLは一般的に、多かれ少なかれ信頼できるユーザーのための適切な入力ソリューションです。
ホワイトリストアプローチは、セキュリティホールなしで実装するのは難しいです。あなたがしたくないことの1つは、 "悪い"タグを検出しようとすることです - あなたはエッジケースを見逃してしまいます。
テンプレートフィルタ「removetags」を使用して、「スクリプト」を削除することができます。
'{{value | removetags：" "| safe}}'これは完全に機能します。 – Glycerine
しないでください。攻撃者が '
XSSのチートシートは、HTMLクリーンアップルーチンを実装することがかなり無駄なプロセスである理由の良い例です。 whitelisting htmlタグは本当にそれを完全に避ける唯一の方法です。 –
+1素晴らしいリンクです。私の将来のアプリは、このための穴が少ないだろうと思う。ありがとうございました。 –