XSSとCSRFの違い早わかり
http://d.hatena.ne.jp/ockeghem/20071203
あー・・・・・ええと。うん。それ違うから。
私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 |
その表現は非常にまずい。まず「攻撃スクリプト」が混同されている。
少なくともサーバ上で「攻撃スクリプト」が動作するのはもう CSRF ではない。CSRF の場合，脆弱ではあっても悪意はない本来のスクリプトが記述された通りの「正常な」動作をしているにすぎないからだ。
第二に，CSRF でも悪意のスクリプトがブラウザ上で動作するパターンがある。というより記事内で例示されている CSRF ではブラウザ上で罠サイトに設置された攻撃スクリプトであるところの JavaScript が動作しているものだ。アプリケーションにポストする内容の話だ，とした場合，それならブラウザ上で動作するスクリプトの話を混ぜてしまうと単にややこしくなるだけだ。いずれの場合も「攻撃コード」（XSS の場合はスクリプトを含んだポストをさせるもの，CSRF の場合は正規のリクエストに見えるポストをさせるもの）はブラウザ上で動いているし，アプリケーションにポストするデータの内容はブラウザ上に攻撃コードがあるかどうかに依存しない。
説明を明快にしたいのはわかるけど，明らかにおかしな説明をしてはいかん。
CSRF と XSS の大きな違いは，サーバ上のアプリケーションの脆弱性の種類だ。XSS は単純に「ブラウザへの出力時に出力が汚染されたままになっている」ことが原因。CSRF はそれとは別に「セッション管理の不備」が加わる。いずれもブラウザにはあまり関係がない。XSS でスクリプトを挿入した結果，セッションハイジャックのために Cookie を盗まずに再度「ボク，真珠はキライなんだ」とポストさせることもありえる。この場合，結果は成立するが，攻撃の手段そのものは XSS の利用になる。また，CSRF を用いて登録メールアドレスの変更に引き続いて「パスワードを忘れた場合」機能あたりを呼び出して新規パスワードを送付させるような攻撃手段の場合，やはりセッションハイジャックよろしく乗っ取りが成立する。
両方のできることはとても近く，問題の原因を「どんなデータがやって来たかに対する問題」あたりに認識していたら余計に混同しやすい。片方は出力の問題で，片方はデータの出自確認の問題だ。
違いはサーバ上のアプリケーションの脆弱性であって，スクリプトがどこで動作するかとかそんなところでは明確に別けられない。
ユーザから見ればいずれも自分のアカウントが勝手に操作されたわけだから，どっちも気に入らない問題でしかないし，どっちも罠サイトへのリンクなりを踏まされたら同様の結果が現れる。
サーバ管理者やWEBアプリの作成者から見れば，XSS も CSRF もサーバ上のスクリプトの脆弱性に起因するものである以上，「XSS はブラウザ上で攻撃スクリプトが動作して CSRF はサーバ上で動作」ってのもおかしい。少なくとも攻撃スクリプトはいずれの場合でもブラウザ上で動作している。違いはサーバに対して「正規の（ように見える）リクエスト」を投げるかどうかでしかないし，セッション管理が不充分な場合はそれをサーバ側が本来のポストなのか CSRF なのか判別できない。だから，セッション管理・・・というより，ページ遷移状態を確認することになる。異常な遷移で投げられたリクエストかどうかを判別すればよいのであって，それができれば CSRF は防げる。ただし，XSS の問題が同時にあった場合は別だけど。
どっちにしろ，利用者向けの説明にしては不適切だし，管理者向けにしてもなんか微妙。どちらを向いているのかもわかりづらければ正確でもないという結果になってしまっている。
追記
2007年12月04日 Kanatoko "あー・・・・・ええと。うん。それ違うから。" (;´Д`)
|ω･`;)
