CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org

CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、

[co3k]

id:Akaza ちょっと誤解を招く書き方をしてしまいました。 BREACH の場合は HTTPS のみでサービスを提供している場合も破られます。secure 属性で意図した目的が果たせなくなるということが言いたかったのでした

[Akaza]

id:co3k ありがとうございます。後ほど再確認してみます。 / 旧コメはスター / 追記 : BREACH攻撃の事よく分かってなかった。HTTPSでも中間でレスポンスボディが再現できるので、埋め込まれたトークンを奪取できるのか。

[miya2000]

前に高木さんと金床さんが議論してた話ですね！/前者についてはXSSがある前提ならセッションIDがわからなくてもいろいろできる/後者はよくわからないのでメモ https://groups.google.com/forum/#!topic/google-app-engine-japan/t6Fb34mvYRI

[pokuwagata]

DOM上に埋め込んでいる場合の危惧

[kjirouu]

“単にセッション ID を SHA-2 ファミリのハッシュ関数あたりを通してそれを使えばいいかと思います。”

[sora_h]

最初から間違っていたのでは

[pochi-p]

内容に納得しつつも少しモヤっとしてたら https://twitter.com/HiromitsuTakagi/status/436175807199731712 以降の高木さんと海老原さんの会話でスッキリ！　XSS対策漏れの保険でどこまで工夫すべきかって話で、第2セッションIDがベターと。

[kenichiice]

cookieにHttpOnly属性を付与するならCSRF対策用トークンにセッションIDを使うのは変という話。

[oppara]

http://t.co/qPqzyoMb1N - Blog - CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある

[trashtoy]

セッションIDをハッシュ化するのがお手軽でよさげ

[kazuhooku]

参考になる > 「（CSRFトークンとして）セッション ID を SHA-2 ファミリのハッシュ関数あたりを通してそれを使えばいい」

[n2s]

XSSがあった場合Set-Cookie: httpOnlyしていてもトークンの奪取がセッションハイジャックにつながる。他BREACH攻撃についても。セッションID値のハッシュを使うことが代替案として示されている。

[tmatsuu]

HttpOnlyの部分は理解できるが、BREACH Attackは未だによくわからない。

[rryu]

兼用はセッションIDの漏洩経路を増やすということなので、あまりよろしくないとは思っていた。まあ、過去にはXSSCSSなんてのもあった訳で。

[Chisei]

オワなの？

[ktakemoto]

きをつけよう

[lesamoureuses]

“DOM ツリー上に存在する「hidden パラメータ」に CSRF 対策用トークン (= セッション ID) が含まれることになりますので、 XSS 攻撃によってこの値を盗み取り、セッションハイジャック攻撃に繋げる”

[k-holy]

そもそもCookieを前提にできない認証が必要になるケースも増えてきたので、別のセオリーを学ばないとなぁ…

[hiroshi_revolution]

http://t.co/GmDXPb0voX - Blog - CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある