XSS文字コードネタの思想

私のイデオロギーなので正しい真理とは限りませんけれど、以下、XSSにまつわる文字コードネタに対する感触といいますか、世間様から石を投げられるかもしれない異端思想の一端を、きわめて曖昧模糊とした私のヘタレ脳からの垂れ流しを少しばかり。

XSSというのはブラウザへの攻撃です。なんかサーバ側の瑕疵がクローズアップされることが多いですけれど、サーバへの攻撃ではないですよね、XSSというのは。被害にあうのはあくまでブラウザ。へんなたとえですけれど、サーバを踏み台にしてブラウザに攻撃をしかけるイメージが、私にはとても強いんです。だから、ブラウザ側の瑕疵のせいでXSSが成立するという悪性のものも当然考えられますし、今までも現にそうした事例はあったわけです。XSSについてはここまで。

次。文字コードネタによるXSS。私の頭の中にあるブラウザのモデルでは、エンコーディングに関して3種類を意識しなくてはいけません。順に、外部エンコーディング、入力エンコーディング、内部エンコーディングです。

このうち、外部エンコーディングと入力エンコーディングとのあいだで齟齬をきたす攻撃を考えますと、もっとも簡単なものは次のようなものでしょう。　なにかしら攻撃者による符号がまじってしまっているページをユーザに提供しておき、ユーザの手作業によって（メニューからcharsetを指定しなおさせるなど）、外部エンコーディングの変更をさせます。
攻撃を自動的にやりたいのであるならば、UTF-7による悪意ある記述をまぜておいて、IEに勘違いさせる攻撃も有名ですよね。これなどは、外部エンコーディングと入力エンコーディングとのあいだの曖昧さをIEというブラウザにまかせて自動的に解釈させてしまう攻撃だと言えます。
ここまで書いた2種類は外部エンコーディングと入力エンコーディングとの間への揺さぶりをかけてみるという発想になっているわけです。
input要素のvalue属性に変なものを突っ込んで属性を追加してしまうというよく知られている攻撃も、この範疇ですね。外部エンコーディングや入力エンコーディングからみて、あってはいけない悪意ある符号が突っ込まれているという。

ところで、以上とは異なる他の種類の方法も検討しておくべきかとは思います。外部エンコーディングと入力エンコーディングが一致している条件下で、内部エンコーディングのほうに揺さぶりをかけるという方向性。これなどは、ブラウザ側（OS含む）の瑕疵？に目をつけているのであって。

…いずれにせよ、XSS攻撃を避けるためにサーバ側としては、エンコーディング上、あってはいけない不正な符号を避けてページを生成しておいてやれば大丈夫なのですが、技術者が通常意識しているのは、外部・入力エンコーディングまでなのでしょうかね？　あってはいけない不正な符号を考えるときには、OSやブラウザまで意識しなくてはいけないのかというとそうでもないはずで、標準に従えばものすごく安心、ということになるんですけれど。機種依存文字を使わない！といったレベルと同じなんですけれどね。

ま、私の意識の上では、エンコーディングネタというのは3層のあいだの軋轢をどういうふうにコントロールしていくのか、ということになります。　たぶん異端思想なのだろうなぁと数年前から感じています。