カスタムcmsを構築するときにコンテンツをエスケープすることについて尋ねた質問に続いて、データベースからコンテンツをエスケープしないことがどれほど危険であるかを知りたいと思いました-データベースに挿入する前にデータがフィルタリング/検証されていると仮定します。
出力をエスケープすることがベストプラクティスであることは知っていますが、表示されるページコンテンツに誰かが値を「注入」することがどれほど簡単であるか、あるいは可能であるかさえわかりません。
たとえば、HTMLマークアップを含むこのコンテンツが、単純なechoステートメントを使用して表示されると仮定します。
<p>hello</p>
確かに、コンテンツの作成に関しては、賞を獲得することはできません;）
私の質問は、db挿入の前にフィルタリング/検証されたと仮定して、誰かがそれを悪意のある目的で変更できるかどうかです。
常に適切なコンテキストのために脱出してください。JSON、XML / HTML、CSV、SQLのいずれであるかは関係ありません（ただし、SQLにはプレースホルダーを使用し、JSONにはライブラリを使用する必要があります）。
なんで？一貫しているからです。また、一貫性を保つことは怠惰な形でもあります。データが「HTMLに対して安全」であるかどうかを考える必要はありません。それは、問題ではないからです。そして、（良い意味で）怠惰であることは、貴重なプログラミング特性です。（この場合、将来の変更による「バグ」の修正を回避することにも怠惰です。）
「エスケープする必要のあるデータが含まれることは決してないため」、エスケープを省略しないでください。ある日、さまざまな状況で、その仮定が間違ってしまうためです。
たとえば、SQLインジェクションなどの他の脆弱性に関連する問題である可能性もあります。そうすれば、誰かがdbに追加する前にフィルタリング/検証を省略して、できることは何でも表示できるようになります。
HTML出力をエスケープしない場合は、ページのHTMLコードにスクリプトを挿入するだけで済みます。ページにアクセスするすべてのクライアントのブラウザで実行されます。これは、クロスサイトスクリプティング（XSS）と呼ばれます。
例えば：
<p>hello</p><script>alert('I could run any other Javascript code here!');</script>
の代わりに、alert()基本的に何でも使用できます。Cookieへのアクセス、DOMの操作、他のサーバーとの通信などです。
これはスクリプトを挿入する非常に簡単な方法であり、これからstrip_tags保護することができます。しかし、何百ものより洗練されたトリックがあり、それはstrip_tags単に防御することはできません。
本当にHTMLを保存して出力したい場合は、HTMLPurifierが解決策になる可能性があります。
ハッカーは、HTML仕様の奥深くに隠されたXSSベクトルの膨大な武器を持っています。HTML Purifierは、ドキュメント全体をトークンに分解し、ホワイトリストに登録されていない要素を削除し、タグの整形式とネストをチェックし、RFCに従ってすべての属性を検証するため効果的です。HTML Purifierの包括的なアルゴリズムは、幅広い知識によって補完され、豊富な形式のドキュメントがストリップされずに通過することを保証します。
データベースからhelloという単語を取得して表示している場合、何も起こりません。ただし、コンテンツに<script>タグが含まれている場合、ユーザーのCookieが盗まれ、セッションの乗っ取りに使用される可能性があるため、危険です。