徳丸本を読む 10月27日回

半年くらい前から、よちよち.rb の有志の参加者どうしで毎週木曜日の 21:00 から 22:00 まで、「体系的に学ぶ安全な Web アプリケーションの作り方」 a.k.a. 徳丸本 のオンライン読書会をしていた。

しかし、最近は他のメンバーがそれぞれ忙しくなって参加者がいなくなってしまったため、先週をもってこの読書会はやむなく中止することとなった。

個人的にはこのまま続けて読んで読了したいという気持ちがあったので、(ひとりで)読んでそのログを積むことにした。

過去の経験から思うに、ただ「読む」だけじゃなくてそれについて「話題にする」とか「文章にする」という二次的なアクションをとると、記憶の定着がより確実になるんだよね。あとは、未来のわたしが「あ〜あれなんだったっけ」となってしまったときにウェブから簡単に検索できるという恩恵も期待していたりして。

読んだところ

上記のような経緯があるので、読んだところは「前回」からの続き。

p.158〜p.183 4.6 節「セッション管理の不備」

TIL

セッションハイジャック

セッションハイジャックをするためにセッション ID を知るための方法:

  • セッション ID の推測
  • セッション ID の盗み出し
  • セッション ID の強制

推測可能なセッション ID とは

“ありがちなセッション ID 生成方法” を採用しているもの。具体的には

  • ユーザ ID やメールアドレス
  • リモート IP アドレス
  • 日時
  • 乱数

などの値をもとにしているもの。

攻撃者が標的アプリケーションのセッション ID を複数並べたときに規則性を推測されやすくなってしまう(そりゃそうだね)。

そこから導き出した新たなセッション ID を使って標的アプリケーションへログインを試み、ログインできてしまったときにその攻撃は「成功」となる。

URL 埋め込みによるセッション ID 盗み出しとは

リクエストヘッダの Referer を悪用することで、そのユーザがどんなセッション ID を持ってアクセスしているかがわかってしまうというもの。

NTT ドコモの携帯電話は 2009 年夏モデルまで Cookie をサポートしていなかったので、携帯電話向けのウェブサービスでは URL にセッション ID を埋め込む仕様になっているところが多かったらしい。(いまだに Cookie 非対応の携帯電話も多いので、URL 埋め込みをすべて禁止にするというわけにもいかないらしい)

携帯電話向けウェブサービスだけでなく、PC 向けウェブサービスでもそのような設定になっているところもないわけではないとのこと。

セッション ID の固定化とは

Session Fixation Attack。外部からセッション ID を強制する。

ウェブサービスから付与された正しい値のセッション ID を先に入手しておき、被攻撃者に、そのセッション ID を埋め込まれた URL で標的アプリケーションにログインさせる。

ログインしてしまうと、攻撃者が「既に知っている」セッション ID を使う設定となるので、攻撃者にも自在にログインができてしまうというしくみ。

セッションアダプション

対象アプリケーション外で勝手に作成された、未知のセッション ID を受け入れるというミドルウェアの特性。

セッションアダプションがあるミドルウェアではより少ない手順でセッション ID 固定化攻撃が可能になる。が、上記のとおり、セッションアダプション問題がないものでも攻撃が「行えない」というわけではない。

Rails での対応と実装の概要

以上。

徳丸本を読むときは毎回背筋がこおりそうになってドキドキするけど、自分の作るアプリケーションのセキュリティについて振り返るいい機会にもなっている。