XSS対策などでエスケープ処理をするとき裏でどういう処理が行われているのでしょうか？

Question

私はこれまで何も意識せずに、ユーザに入力された文字列を出力するときにはサーバ側でエスケープ処理をしていました。漠然とこれによって文字列を変換して無害な形にしているのだろうと考えていました。
しかし、あるときエスケープ処理した後の文字列をテキストエリアに出力し、それをそのままサーバに送らせて、その元々の文字列と照合する機会があり、結果としてはエスケープされて出力されたものは元々の文字列と等値だと出ました。
（例えば元々『<a>』の文字列がhtml上では『<a>』と出力され（表示は<a>のまま）それをそのままサーバに送らせて照合したら一致するといった感じ）

単純な変換ならば文字列が変わるはずだし、変換されないなら特殊文字として機能するはずだしと、現在こんがらがった状態で調べています。
これは見えないところではどういう原理で動いてこうなっているのでしょうか？

Answer 1

HTML

しかし、あるときエスケープ処理した後の文字列をテキストエリアに出力し、それをそのままサーバに送らせて、その元々の文字列と照合する機会があり、結果としてはエスケープされて出力されたものは元々の文字列と等値だと出ました。

HTMLを解釈するのはWebブラウザです。
サーバサイドスクリプトでアンエスケープ可能なのは「パーセントエンコード(旧: URLエンコード)された文字列」になります。
従って、ブラウザがサーバにフォーム送信するタイミングでは、エスケープ処理後の生データを送ります。
https://momdo.github.io/html/syntax.html#character-references

クロスサイトスクリプティング

XSS対策の基本は出力時にエスケープです。
クライアントからサーバへ送る処理はサーバにとって入力処理にあたるので、XSS対策とは根本的に関係ありません。
https://www.ipa.go.jp/security/awareness/vendor/programmingv1/a01_02.html

Re: yamamotoyama さん

Answer 2

（例えば元々『<a>』の文字列がhtml上では『<a>』と出力され（表示は<a>のまま）それをそのままサーバに送らせて照合したら一致するといった感じ）

それは、ブラウザがエスケープから戻しています。属性値にもエスケープは必要なので、HTML上に<input value="&lt;a&gt;">とあった場合、入力ボックスには<a>と出て、送信すればやはり<a>という値になります。

Comments

[yamamotoyama]

回答ありがとうございます。
ってことは一回のサーバサイドのエスケープは一フロントエンドで一回の効力しか持たないと理解できそうですね。