log

安全なwebアプリケーションの作り方 158-183

例えば、下記のURLのように、明示的にPHPSESSIDパラメータを付けてリクエストを送ってみる。
http://foo/bar.php?PHPSESSID=3333
すると、このリクエストに対する応答のヘッダには下記の内容が含まれる。
Set-Cookie: PHPSESSID=3333; …
つまり、ブラウザから与えた値がセッションIDとして採用されてしまう。
攻撃者は上記のセッションIDを仕込んだハイパーリンクをクリックさせることによって、被害者を罠にかけることができる。このセッションIDが使われたままユーザがログイン手続きを行うと、攻撃者もそのユーザのプライベートなページを見て回る機会を得る。

  • なるほどなぁ、これはすごい納得出来たかも
    • セッションハイジャックの原因は多様で個別対応する👼
    • 推測可能なセッションID
      • 自分で作らない！！！実績ある言語などが提供しているものを使うべき！！！暗号アルゴリズムと一緒
      • (1) 攻撃対象からセッションIDを集める　(2) 規則性の仮説をたてる　(3) 推測したものを試す
      • ユーザID/メアド/リモートIPアドレス/日時/乱数を生成に使う場合が多い。組み合わせとかエンコードとかハッシュ値されることもある。
      • ユーザIDと日時は外部から推測可能なので🙅
      • セッション取れるからなりすましは出来るけど、パスワードとかはわからないので、再認証要求とかである程度被害軽減出来る（前やった！）
      • 現実的で効果的な対策：あらかじめ提供されているセッション管理機構使え！！！
    • URL埋め込みのセッションID
      • 🍪に保存せずそのまま渡すものがあって、携帯電話向けとかの過去の遺産はそんな感じらしい？
      • セッションIDを持った状態で外部へのリンクとかをクリックしたとき、その情報がRefererに乗ってるので、やばやばのやば　やっとこの問題納得した
      • webメールサービスとかで、メール内に書いてあるリンク踏んで飛ぶとやばいことになるんだけど、あんまり認知されたとは言えない←明らかにやばやばい
      • 一時期🍪は🙅とかやばいって風潮になったり、携帯電話ブラウザが対応してなかったりしたのでこういう脆弱性が生まれた→URL埋め込みを完全になくすのはむずい
      • 対策：CookieにセッションIDを保存しろ！！！
    • セッションIDの固定化
      • さっきの記事の通り
      • ログイン後にセッションIDを変更するとかで攻撃者にわからなくさせる
      • いま気付いたけど、ログインIDというか認証情報とセッションID誤認してたかも。全然違うわ
      • 認証とか関係なしに、たとえばユーザ登録とかの場面でもこの攻撃出来て、ユーザが入力した時点でサーバの🍪に残るから、別のところでガン待ちしてれば情報が盗める。
      • ただなりすましして権限使ってるわけじゃないから、情報漏えいだけで防げる………とも言える
      • 知らないセッションIDを受け入れる設定でも受け入れない設定でも、結局適当なの作ってそれつかって攻撃すればいいから、攻撃し放題😢
      • URLじゃなくて🍪に情報保存してても、ブラウザとかwebappに脆弱性があれば攻撃出来る。前やった！
      • 脆弱性が生まれる原因っていっぱいあるんだけど、全部対策するのは不可能？？だし修正予定もなかったりするから（!!!IE!!!）、これはもう許容して、ハイジャックされないように気をつけるのがよい。認証の後セッションID変更するとか！
      • ものによっては明示的に変更できないので、トークンを🍪とセッション変数両方に記憶→比較→同じならおｋ、みたいな感じ
      • これが外部に出るタイミングはログイン時の🍪生成のときだけなので、攻撃者はわからないので防げる。
      • トークンは予測困難性とかが必要で、秘密の国のアリスでやったようなアレが必要
      • ただ、↑のはログイン後の対策で、ログイン前の対策ではない。ログイン前はhiddenパラメータで値を回すのが現実的！
  • セッション管理機構を自作するな
  • クッキーにはセッションID保存しろ、情報保存するな
  • 認証成功したらセッションID変更しろ
  • 認証前はセッション変数に情報保存するな