他人のCookieを操作する - T.Teradaの日記

脆弱性検査をしていてしばしば出くわすのは、他人のCookieの値を操作できるとXSSやセッション固定等の攻撃が成功するようなWebアプリケーションです。 このようなアプリがあると、業界的には「Cookie Monsterという問題がありまして、、、でも、、、基本的に現状のブラウザではリスクは低いです」みたいな話がされることが多いのではないかと思います。 本日の日記では、それ（Cookie Monster）以外にも状況によっては考慮すべきことがある、という話をしたいと思います（過去の日記でも少し書いた話ですが、もう少しちゃんと書いておこうと思います）。 通信経路上に攻撃者がいる 被害者のブラウザとサーバの通信経路上に、アクティブな攻撃者がいると想定しましょう。 そのような状況では、攻撃者は正規のサーバになりかわってブラウザと通信をしたり、ブラウザと正規のサーバで交わされる通信に介入することが

[ockeghem]

HTTPSではSecure属性付きのCookieを盗むことはできないが、Cookieをセットすることはできるので、Cookie改変できることを前提にアプリを開発しようというお話

[monjudoh]

『通信経路上に攻撃者がいる』野良WiFiスポットを考えると現実的。で、偽のhttpのサイトでcookieを設定して、本物のhttpsのサイトにさっき設定したcookieを持った状態でアクセスさせるわけか。

[YassLab]

"通信経路に攻撃者がいてもセキュアであるべきサイト（HTTPSのサイト）については「他人のCookieは操作できない」という前提でセキュリティを考えることはできない / HTTPの通信に介入できる攻撃者はCookieを操作できるから"

[y-kawaz]

__Secure- とか __Host- プレフィックス付きのクッキーを使うようにすれば良いんじゃないかな。 http:// での送信だけじゃなく設定するのも防げるよ。／日付見たら滅茶苦茶古い記事だった。この時代はまだprefix使えないね。

[sho]

なるほどなー。興味深い。

[Itisango]

#2011年 #BLOG #HTTPS #SSL #cookie #Web #security

[kaito834]

「まとめると、通信経路に攻撃者がいてもセキュアであるべきサイト（HTTPSのサイト）については、「他人のCookieは操作できない」という前提でセキュリティを考えることはできないということです。」

[kogawam]

「(1)のCookieはHTTPでセットされたものですが、(2)のHTTPSのリクエストでサーバに送られてしまうということです。」←意識してなかったorz