私は次のことをどちらの方法で行うべきか疑問に思いました。私は、ユーザーデータを適切なhtmlタグでフォーマットする小さなMCEwysiwygエディターを使用しています。次に、エディターに入力されたこのデータをデータベーステーブルに保存する必要があります。
DBに挿入するときにhtmlタグを対応するエンティティにエンコードする必要があります。その後、テーブルからデータを取得するときに、XSSの目的でエンコードする必要はありませんが、フォーマットするにはhtmlタグにevalを使用する必要があります。テキスト。
また
htmlタグをデータベースに保存し、データベースからデータを取得するときにhtmlタグをエンティティにエンコードしますが、タグがユーザーに表示されるため、実際にeval関数を使用する必要があります。入力されたとおりにデータをフォーマットします。
私の考えは最初の選択肢にあります、私はあなたたちが何を考えているのか疑問に思いました。
データベースにデータをできるだけ「自然な」形式で保存することをお勧めします。通常、データベースレイヤーは、フィールドにHTML、Base64エンコードされたバイナリテキスト、またはプレーンテキストが含まれているかどうかを気にする必要はありません。これらは、コンテンツのレンダリング方法を決定する際のビューレイヤーの懸念事項です。
したがって、データベースに挿入する前にXSS攻撃の予備的なスクリーニングを行うこともできますが、「信頼できない」情報をブラウザに送信する前に、常にXSSをスクリーニングする必要があります。
これには、XSS防止アルゴリズムが将来改善された場合に、HTMLを含む可能性のあるフィールドをデータベースでスキャンして更新する代わりに、表示するルーチンを変更するだけで、アプリケーション全体に実装できるという利点もあります。彼ら。
ない。HTMLを「現状のまま」保存するので、HTMLを引き出したときにレンダリングの準備が整います。あなたは前後に変換することはできません。あなたが入れるものはあなたが表示するものでなければなりません。あなたがしたいのは、DBに入れる前に入力をフィルタリングすることです。tinyMCEとck/fckEditorの両方に、エディターで使用できるタグを制限する機能があり、それらのタグを削除します。次に、他の必要な検証またはフォーマットを実行する必要があります。
私が最初にブログを始めたとき、私はBBCodeからHTMLに変換し（そして健全性チェックを行い）、それをデータベースに入れることに決めました。さて、1か月が経ち、レイアウトの問題が発生したことがわかりました。古いHTMLがデータベースに「修正」されたので、ユーザーが使用する最初のテキストを常にデータベースに保存し、後でリクエストで変換する必要があることをすぐに学びました。
これにより、HTMLとXSSのバグを修正でき、遡及的に使用できるようになります。
データベースに挿入するときにSQLインジェクションをチェックし、HTMLを「生の」形式のままにします。
drupalがこれを行い、フィルター（たとえば、すべてのhtmlタグ（フィルターなし）、特定のタグのみ、xssフィルター、phpコード形式、トークンなど）をその場で適用することを知っています。このアプローチの利点は、後で使用するフィルターを変更する場合に、入力データを破壊的に変更しないことです。
1つの可能性は、サニタイズされたバージョンと元のバージョンの両方を保存することです。これをHTMLPurifierで使用して、ライブサニタイズによって作成されるパフォーマンスの問題を回避しながら、ユーザーがコンテンツを元の形式で編集できるようにします。
言うまでもなく、ストレージスペースは2倍になりますが、通常、スペースは速度や制御ほど問題にはなりません。