検索
連載

Cookie Monster襲来! 戦え、星野君星野君のWebアプリほのぼの改造計画(6)(3/3 ページ)

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

困ったときのまこと先輩……なんだけど

 結局、町田さんがWeb管理ツールにログインできなかった原因は、Web管理ツールが有効なCookieを判断できないという問題に起因し、以下のような流れで被害が発生していたということになる。

  1. 外部サイト(.co.jp)でCGISESSIDが発行される
  2. Web管理ツールにログインを行うと、通常のCGISESSIDが発行される
  3. 同名の2つのCookieが共存し、Webブラウザから.co.jpドメインのCGISESSIDが1番目に、通常のCGISESSIDが2番目に送信される
  4. Webアプリケーション側では、1番目のCGISESSIDの値を取得するため【注2】、セッションが無効であると判断される

【注2】
Webアプリケーション側のセッション管理の方法によって、どのCookieの値を採用するかは異なる。例えば、PHP標準のセッション管理の方法だと最後の値を取得する作りになっている。また、Webブラウザや各属性の値によってどの順番でCookieを送信するかが異なる。


 従って、対策をするには.co.jpドメインにひも付いたCGISESSIDを使わないようにすればよい。しかし、HTTPリクエスト内には、そういった情報は含まれない。malicious_cookieのように明らかに無効なものであれば判断できるかもしれないが、攻撃者が正規に取得したCGISESSIDを指定している場合(セッション固定攻撃を行う場合に使われる手法)にはWebアプリケーション側で判断するのは難しい。

 あまり頼りすぎるのはよくないとは思いつつも、困ったときのまこと先輩……。星野君は、「いいかげん怒られるかな」と思いながらも、聞いてみることにした。

 まこと先輩は意外にもすんなりと返事をくれた。

星野君へ

まことです。
なかなか難しい問題だね。.co.jpドメインにCookieを指定できる(これ、Cookie Monsterっていうらしいよ、知ってた?)ってのは聞いたことあるけど、特に深く考えたことはなかったな……。

確かに星野君のいうような問題は起こるし、簡単に被害にもつながっちゃう可能性があるね。うーん、悩ましい。

けど、やっぱり、WebブラウザやCookieの仕様から発生してる話だから、それをWebアプリ側で対応させるのを強要することはあまりしたくないよね。

う〜ん。「これでスッキリ!」っていうような対策は思いつかないなぁ。


 まこと先輩からは、解決につながるようなアドバイスをもらうことができなかった。

星野君 「(まこと先輩でもよく分からないことがあるのか……。困ったなぁ)」

困ったときの高橋さんによる取りあえずの対策

 今回のケースは社内向けのWebアプリケーションなので、その都度対応すればよいのだが、町田さんは結構怖いのでできることなら直してしまいたい。しかも、今後対外的にWebアプリケーションを公開する場合を考えたら、Webブラウザの仕様といえども対策しないといけない事態が出てくるかもしれない。

星野君 「むぅー……。どうしよう……」

高橋さん 「まだ悩んでるの?Webブラウザの仕様なんだからほっとくしかないんじゃない?」

星野君 「そういうわけにいかないんですよぉ。町田さん怖いんですから……。Webアプリ側でも手を打たないと……」

高橋さん 「う〜ん。そういってもねぇ。難しそうだな……」

町田さんが怖くて対策を放置できないとぼやく星野君

 しばらく高橋さんは考え込んでいたが、対策を考えるのも面白そうだということで、一緒に知恵を絞ってくれることとなった。

 結局思いついた対策は以下の3つの方法である。

  1. .co.jpドメインに対して有効期限切れのCookieをSet-Cookieし無効化する
  2. CGISESSIDとIPアドレスをひも付けしたうえで、複数のCGISESSIDがある場合は、正しいIPアドレスとひも付いているものを利用する
  3. Cookieを使うのをやめる

 1は「目には目を」という感じだ。しかし、2と3の方法だとWebアプリケーションに大幅な変更を加えなければならない。

 Web管理ツールで利用しているセッション管理のモジュールでは、Cookieを1つしか見ない作りになっている。従って、2の方法を実現するには、複数のCGISESSIDを解析できるようモジュール自体を変更しなくてはならない。また、3の方法では、セッション管理の方法を根本から変えなくてはならず、非常に手間がかかってしまう。

 今回は仕方なく1つ目の「.co.jpドメインに対して有効期限切れのCookieを発行する」という方法で取りあえずの対応とすることにした。

 Webアプリケーションとしてはひとまずの対策を行うことができた。今回、星野君は、高橋さんが想像以上にWebアプリケーションに詳しかったことにちょっと驚いた。まこと先輩、赤坂さん以外にも身近に詳しい人がいたとは……。

Webアプリに詳しい3人を思い浮かべる星野君

次回予告:

 Cookie Monsterは何とか撃退(?)した星野君。今度は、会社のWebサーバが大変なことに……。

高橋先輩のWebアプリ・チェックポイント!

高橋先輩

Check!
Cookieは信用できない

「クロスドメインクッキーインジェクション」により簡単に不正なCookieを送り込むことができてしまう。WebブラウザやCookieの仕様といえども、Webアプリケーション側でも不正なCookieが使われた場合を想定した作りにしよう

Check!
同名のCookieが複数存在する場合がある

ドメイン属性が違うCookieの場合、同名であってもWebブラウザからはすべて送信される。同名のCookieがある場合、どちらが正しいCookieかを判断する仕組みが必要だ


Profile

杉山 俊春(すぎやま としはる)

三井物産セキュアディレクション株式会社
テクニカルサービス事業部検査グループ
コンサルタント

セキュリティコンサルタントとして、主にWebアプリケーションのセキュリティ検査などに従事している。大手就職活動支援サイト、ショッピングサイトなどの検査実績を持つ。



前のページへ |       

Copyright © ITmedia, Inc. All Rights Reserved.

Security & Trust 記事ランキング

ページトップに戻る