アカウント名:
パスワード:
1.攻撃者がシステムにアクセスし、セッション ID を取得する。ログインしていないがセッション ID は発行される。2.攻撃者は、正規ユーザがそのセッション ID を使ってログインするように仕向ける3.正規ユーザがそのセッション ID でログインすると、そのセッションは「ログイン済み」となる
これって、「ログインする前にセッションIDを発行する」事が脆弱性なんじゃなくて、「2」が可能になる仕組みが脆弱性なのでは?セッションIDを先に発行していても、「2」が出来なければ問題ない訳ですよね。それとも、「2」の手法に関しては、周知の防ぎようの無い手段で可能なのかな?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
Session Fixationってなに? (スコア:2, すばらしい洞察)
というわけでリンク
用語「セッション固定攻撃」 [bakera.jp]
Re:Session Fixationってなに? (スコア:2, 参考になる)
これって、「ログインする前にセッションIDを発行する」事が脆弱性なんじゃなくて、「2」が可能になる仕組みが脆弱性なのでは?
セッションIDを先に発行していても、「2」が出来なければ問題ない訳ですよね。
それとも、「2」の手法に関しては、周知の防ぎようの無い手段で可能なのかな?
Re:Session Fixationってなに? (スコア:2, 参考になる)
DocomoはCookieが使えないから、i-mode対応を謳うログインの必要なサービスは危ないところが多いと思います。
まぁ、この場合はXoopsでの対応のようにログイン時にセッションキーを変えてしまう方法で防ぐことはできるでしょう。
Re:Session Fixationってなに? (スコア:1)
そもそも「1」のような事象を発生させないことがポイントでは?
# 考え方としてはfail-safenessを持つ方に振るべきだと
…とはいえ、端末/アプリの仕様や使い勝手やユーザーのスキル等々の(時として訳の分からない)理由により、
事前にセッションIDを発行する(せざるを得ない)ケースもありますよね…
かなり既知でしょうが、高木氏の「安全なWebアプリ開発の鉄則 2004」から
http://www.soi.wide.ad.jp/class/20040031/slides/10/33.html [wide.ad.jp]
Re:Session Fixationってなに? (スコア:0)
そうです。Firefox使いはアウトです。
IE を使いましょう。
Re:Session Fixationってなに? (スコア:0)
で、その攻撃方法としてよく挙げられるのが下記の脆弱性を利用したものなので、脆弱性に脆弱性が絡んで話がややこしくなるというわけです。
・URLからセッションIDを指定する(フレームワークなどのSession Adoption脆弱性)
・広範囲のドメインにばら撒かれるクッキーを使う(ブラウザのCookie Monsterバグ)