徳丸本の読書メモ

徳丸本を読んだので、メモを残しておく。ほんとに自分用のメモでしかないが、そのうち清書するかもしれない。

xssについて

本質は、

• 外部から来た文字列を
• エスケープせずに
• 自ドメインのレスポンスとして

返してしまうこと。

• 内部で作った文字列なら、単なるミスで攻撃ではない
• エスケープしてれば攻撃を防げる
• ブラウザは、サンドボックスの仕組みで、安易に表示中のドメイン以外に由来する文字列をレンダリングしたりJSとして実行したりはしないが、まさに表示しているドメインから送られてきた文字列であれば実行するしかない

つまり、xssは、外部からの入力を元に動的にページを作る部分の脆弱性をついて、不正なコードを正当なレスポンスとして返させられる攻撃。レスポンスを作るために利用し得る外部からの入力てあれば、何でも脆弱性の源になり得る。

攻撃を成立させるためには、被害ユーザー自身に、攻撃を成立させる入力値を、被害サイトのサーバーに送らせる必要がある。このために、URLパラメタやフォームの値などに有害入力を仕込んだリンクなどを外部サイトに置いて、それを被害ユーザーに踏ませるのが典型例。

CSRFについて

ブラウザは、サーバーにリクエストを送る際に、そのドメインのクッキーがあれば、それをリクエストに付加する。

普通、クッキーのセッション情報を見てログイン状態が判定される。これは、たとえ悪意あるリンクを踏んだり、悪意あるフォームによってPOSTする場合も同じ。

したがって、何らかの方法でログイン状態にあるユーザーのブラウザでリンクを踏ませたりフォームからポストさせたりできれば、サーバーに認証済みのリクエストを送ることができる。

xssとは異なり、この不正リクエストは、被害サイトと異なるドメインからも送ることができる。しかし、外部ドメインからのリクエストの場合は、レスポンスの内容を悪意あるサイトのjsなどから盗み見ることはできない。つまり、攻撃の範囲はサーバー側での副作用に限定される。

対策として、当該のリクエスト（リンクによる遷移やフォームからのポスト）に検証用のトークンを含むことを要求する（含まれてなかったらリクエストを捨てるなりエラーを返すなりする）。サーバー側で、誰に・どのトークンを送ったかを管理しておけば、攻撃者が用意したニセのトークンを含むリクエストを送らされても拒否することができる。