2007/03/21(水)水曜日ー。（崖の上のポニョ？）
[セキュリティ] * SessionSafe: Implementing XSS Immune Session Handling
**[pdf]**
経由。 （仮に XSS があっても）セッションハイジャック攻撃をされないという、3種類のサーバサイドのテクニックについての論文。**1. Session ID Protection Through Deferred Loading**例えば、既に Cookie を持っている場合のページ取得の手順は… １．ブラウザが http://www.example.org/ index.ext をリクエスト。(RQ1) ／ ２．PageLoader と呼ぶ、コンテンツ取得用の JavaScript のみを含む HTML を返す。(RP1) ／ ３．PageLoader が、1x1ピクセルの画像を http://secure.example.org/ getCookie.ext?rid=99 に取得しに行く。 secure.example.org には Cookie "SID" が送られる。(RQ2) ／ ４．PageLoader は同時に、XMLHttpRequest を使ってコンテンツを取得しに行く。(RQ3) ／ ５．Webサーバは、RQ2 の Cookie を確認してから、同じ rid を持つ RQ3 への返答としてコンテンツを返答する。(RP2) ／ ６．PageLoader は受け取ったコンテンツを document.write() を用いて表示する。 ・・・という感じらしいです。 www. をコンテンツの送受信用に、secure. を セッションID 確認用に、と分離したところがミソでしょうか。 これにより、仮に www. に XSS が存在したとしても、Cookie "SID" を奪取することは出来ないと。 まぁ、www. に XSS があったら、rid を盗られて情報を盗まれたり、そもそもコンテンツ自体を別のサーバに送られたり、あるいはそっくり同じような偽コンテンツを表示させられて騙されて情報を盗られたり、情報の送信先を攻撃者のサイトに変更されて盗まれたり、今回は影響無さそうですが .example.orgドメインで何らかの Cookie を勝手に発行されたりしそうな気もしますが。 それに、個人的には document.write() って何だか少し怖いｗ**2. One-Time URLs**URL を予測不可能でワンタイムなものにしてしまおうという試み。 URL に付加する値を生成するコンポーネントは、HTMLや JavaScript にハードコーディングされたものではなく、サーバ側に動的に取りに行く仕組みになっており、ワンタイムで かつ 予測不可能な値を生成すると。 元記事でも指摘されていますが、[戻る]/[更新] は出来なくなりますね。**3. Subdomain Switching**JavaScript には、同じホスト・ポート・プロトコル由来のページしか操作できない same-originpolicy があるので、隠れたポップアップウィンドウなどから表ウィンドウを監視する background XSS propagation 攻撃に対処するために、ページごとにホスト名を変えてやれば良いんじゃない？という発想。 s0001.example.org, s0002.example.org, s0003.example.org, ... を同じホストに紐付けると。 この場合、セッション管理は 1. の方法で行うのでしょうね。これらの方法を組み合わせることで、セッションハイジャックに強いサイトを作ることが出来るのではないかとのことです。 また、元記事では同時に、これは、今までの 入力値の妥当性の確認や 出力時のエスケープ処理を実装しなくて良くなるわけではないことを警告しています。 あくまでも、XSS が万が一存在していた場合の影響を低減する目的だとのこと。 ・・・私の感想も、面白い発想ではあるけど、何だか無理矢理感がただよっているなぁという感じですｗ
**[pdf]**
- T.Teradaさんの日記
経由。 （仮に XSS があっても）セッションハイジャック攻撃をされないという、3種類のサーバサイドのテクニックについての論文。**1. Session ID Protection Through Deferred Loading**例えば、既に Cookie を持っている場合のページ取得の手順は… １．ブラウザが http://www.example.org/ index.ext をリクエスト。(RQ1) ／ ２．PageLoader と呼ぶ、コンテンツ取得用の JavaScript のみを含む HTML を返す。(RP1) ／ ３．PageLoader が、1x1ピクセルの画像を http://secure.example.org/ getCookie.ext?rid=99 に取得しに行く。 secure.example.org には Cookie "SID" が送られる。(RQ2) ／ ４．PageLoader は同時に、XMLHttpRequest を使ってコンテンツを取得しに行く。(RQ3) ／ ５．Webサーバは、RQ2 の Cookie を確認してから、同じ rid を持つ RQ3 への返答としてコンテンツを返答する。(RP2) ／ ６．PageLoader は受け取ったコンテンツを document.write() を用いて表示する。 ・・・という感じらしいです。 www. をコンテンツの送受信用に、secure. を セッションID 確認用に、と分離したところがミソでしょうか。 これにより、仮に www. に XSS が存在したとしても、Cookie "SID" を奪取することは出来ないと。 まぁ、www. に XSS があったら、rid を盗られて情報を盗まれたり、そもそもコンテンツ自体を別のサーバに送られたり、あるいはそっくり同じような偽コンテンツを表示させられて騙されて情報を盗られたり、情報の送信先を攻撃者のサイトに変更されて盗まれたり、今回は影響無さそうですが .example.orgドメインで何らかの Cookie を勝手に発行されたりしそうな気もしますが。 それに、個人的には document.write() って何だか少し怖いｗ**2. One-Time URLs**URL を予測不可能でワンタイムなものにしてしまおうという試み。 URL に付加する値を生成するコンポーネントは、HTMLや JavaScript にハードコーディングされたものではなく、サーバ側に動的に取りに行く仕組みになっており、ワンタイムで かつ 予測不可能な値を生成すると。 元記事でも指摘されていますが、[戻る]/[更新] は出来なくなりますね。**3. Subdomain Switching**JavaScript には、同じホスト・ポート・プロトコル由来のページしか操作できない same-originpolicy があるので、隠れたポップアップウィンドウなどから表ウィンドウを監視する background XSS propagation 攻撃に対処するために、ページごとにホスト名を変えてやれば良いんじゃない？という発想。 s0001.example.org, s0002.example.org, s0003.example.org, ... を同じホストに紐付けると。 この場合、セッション管理は 1. の方法で行うのでしょうね。これらの方法を組み合わせることで、セッションハイジャックに強いサイトを作ることが出来るのではないかとのことです。 また、元記事では同時に、これは、今までの 入力値の妥当性の確認や 出力時のエスケープ処理を実装しなくて良くなるわけではないことを警告しています。 あくまでも、XSS が万が一存在していた場合の影響を低減する目的だとのこと。 ・・・私の感想も、面白い発想ではあるけど、何だか無理矢理感がただよっているなぁという感じですｗ