大丈夫か日経

　
　えーと。
　http://itpro.nikkeibp.co.jp/article/COLUMN/20070208/261279/
　時間の許す限りツッコむとしてみよう。戦闘力たったの５でたかぎせんせいからみれば「ふ。ゴミめ」みたいな俺だけどな。
　
　さて。１ページ目。

アクセス時にユーザーIDとパスワードを入力して認証するWebサイトをイメージしてみてください。一度ユーザーIDとパスワードを入力して認証に成功すれば，2回目以降はページにアクセスしただけでユーザーIDが表示されていることがあります。これは，初回のアクセス時に，WebサーバーがユーザーPCにCookieを送り，ブラウザが保持していたからです。2回目以降に同じサイトにアクセスしたときは，ユーザーPCのブラウザがCookieの情報を読み出して表示しています。

　
　マテコラ
　
　Cookie に ID とか入れるような構成をシレっと書いてんじゃねえよ。むしろあれだ。スーパー銭湯とかのカギに例えたほうが妥当。手首に巻いたロッカーキーの番号で管理とか。
　っつうか「2回目以降に同じサイトにアクセスしたときは，ユーザーPCのブラウザがCookieの情報を読み出して表示しています。」とかありえねえ。何年前の入門書だよ。ふつうセッションID。
　

Cookieには認証情報や個人的な情報が入っている場合があり，攻撃の的になることがあります。

　
　マテコラ
　
　Cookie にいきなりそんなモン入れてる段階でアウトです。そんなページは XSS 関係なしに脆弱です。Cookie に入れられるのはせいぜいページの機能のオン/オフなフラグとか、セッションIDとかそんなもんです。
　それ以上の余計なものを入れようとするサイトがあたかも普通みたいな書き方してはいけません。
　
　つうか挿絵もえらいことになってるな。
　

Cookieに情報を追記したり，削除できるのは基本的に発行したWebサーバーだけです。

　
　JavaScript でブラウザ側でも普通にできますが何か。入門書程度でも Cookie のサンプルに「JavaScript で値をセット/読み出し」くらい提示されてるのが普通でしょ？
　「Cookie は書き込むときに表示したサイトにしか送られません」とでも言うほうがいいのかな。
　
　
　２ページ目。

この買い物サイトのWebアプリケーションは，注文者の氏名，メール・アドレス，パスワードをユーザーのCookieに記録して保存しておき，再びアクセスがあったときには自動的に表示するように作ってあります。

　
　HTTP:// なんだけど。XSS しなくても盗聴されたら終わりじゃん。
　
　
　３ページ目

具体的にはWebアプリケーションは，ユーザーに情報を返信する際に，＜や＞のままではなく「＆lt;」や「＆gt;」に置き換えます（エスケープ処理，あるいはサニタイズと呼びます）。これを受け取ったユーザーのブラウザは，ページを表示する時に<を＜に，>を＞に置き換えて表示します。すると，ユーザーがWebブラウザで見るときには，元の文字列のまま表示されます。脆弱性がないWebアプリケーションでは，この処理がきちんと実施されています。

　
　・・・・・('A`) & の使い方知らないでよく言えるなぁ。
　・・・・「IT教育事業部」かあ。
　
　
　もうこうなったらさ。全部パーセントエンコーディングで返すようにしちゃえよ。
　そうしとけば何も考えることねえよ。何もかも全部16進数で返しちゃいなよ。
　
　
　
　４ページ目。

ここまでなら，自分のブラウザに自分のCookieの内容が表示されるだけですので，さほど大きな問題はないでしょう。しかし，この情報がほかのWebサイトに送信されてしまったら，個人の情報が漏洩してしまいます。それがクロスサイト・スクリプティングです。詳しくは後編で解説します。

　
　違う。根本的に違う。個人情報が別サイトに送られるのが XSS なんじゃない。それは結果のひとつにすぎない。
　
　XSS は文字通り「サイト横断スクリプト」だ。攻撃用サイトに置かれていたスクリプトが被害者のブラウザをまたいで別サイトの表示にもぐりこむのが問題。個人情報が漏洩するとかじゃないの。「それがクロスサイト〜〜」じゃねえの。「挿入するスクリプトの動作によっては、この情報をほかのサイトに送信するようなことすらできてしまうのです」程度しか書けないはずのところでしょ。
　
　こりゃだめだ。最初からたかぎせんせいにお願いすればよかったのに。
　
　
　っつうかこのヒト、WEB アプリの中身を見たこともないんじゃないかって気がする。
　
　後編に続く？