アカウント名:
パスワード:
Cookieを使わずにPOSTメソッドのhiddenでセッション管理をしている会員制のWebサイトであれば、CSRF及びCSSXSSの影響は受けません。
金床氏の提案する「正しい対策その1: ワンタイムトークンを正しく使用する方法」もCookieでセッション管理することを前提で書かれていました。
「セッションIDをCookieに入れる」のと「セッションIDをCookie及びhiddenに入れる」のでは、 後者の方がセキュリティ上のリスクは高いのでは無いでしょうか。
「セッションIDをCookieに入れる」のと「セッションIDをCookie及びhiddenに入れる」のでは、後者の方がセキュリティ上のリスクは高いのでは無いでしょうか。
前提は、ブラウザの脆弱性、プロキシのキャッシュ、第三者のコンピュータの利用なども考えられる、現実社会の環境です。
(他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。)
しかし、貴方の言うセキュリティ対策を行うと、 HTML内のhiddenフィールドにセッションIDが埋め込まれることになるわけです。 これが万が一漏洩したらセッションハイジャックの危険があります。 (他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。) プロキシサーバのキャッシュにはSet-Cookieも残りますよ。 LANでシビアな情報をやり取りするのは、パケット傍受される危険性があるよレベルの話。ここでいうCSRF対策とは既に別次元の話だから、そういう可能性(他のブラウザ以下) は考慮しないで済むので問題ありません、という事では?
しかし、貴方の言うセキュリティ対策を行うと、 HTML内のhiddenフィールドにセッションIDが埋め込まれることになるわけです。 これが万が一漏洩したらセッションハイジャックの危険があります。 (他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。) プロキシサーバのキャッシュにはSet-Cookieも残りますよ。
しかし、貴方の言うセキュリティ対策を行うと、 HTML内のhiddenフィールドにセッションIDが埋め込まれることになるわけです。 これが万が一漏洩したらセッションハイジャックの危険があります。 (他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。)
>それで、CSRF と CSSXSS は防げます。
>これが万が一漏洩したらセッションハイジャックの危険が>あります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
ワンタイムトークンは不要では (スコア:3, 参考になる)
鵜呑みにしてみる?
Re:ワンタイムトークンは不要では (スコア:1, 参考になる)
それで、CSRF と CSSXSS は防げます。
ただし、対策を行わなかった場合には、Cookieに保存されている
セッションIDはCookie以外には保存されることはありません。
しかし、貴方の言うセキュリティ対策を行うと、
HTML内のhiddenフィールドにセッションIDが埋め込まれることになるわけです。
これが万が一漏洩したらセッションハイジャックの危険があります。
(他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。)
冷静に考えてみて下さい。
SCRF対策、CSSXSS対策を行ったことにより、
他のセキュリティホールが生じる可能性が高まる状況は好ましいと言えますか?
Re:ワンタイムトークンは不要では (スコア:0)
>HTML内のhiddenフィールドにセッションIDが埋め込まれることになるわけです。
>(他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。)
他の脆弱性?それを言うなら、クッキーにセッションIDを入れる方がよっぽど危ないですから、hiddenにセッションIDを入れるべきです。
「hiddenは漏れるがクッキーは漏れない」なんて脆弱性、CSSXSS以外に聞いたことがありませんし。
Re:ワンタイムトークンは不要では (スコア:1)
Cookieを使わずにPOSTメソッドのhiddenでセッション管理をしている会員制のWebサイトであれば、CSRF及びCSSXSSの影響は受けません。
金床氏の提案する「正しい対策その1: ワンタイムトークンを正しく使用する方法」もCookieでセッション管理することを前提で書かれていました。
「セッションIDをCookieに入れる」のと「セッションIDをCookie及びhiddenに入れる」のでは、 後者の方がセキュリティ上のリスクは高いのでは無いでしょうか。
Re:ワンタイムトークンは不要では (スコア:0)
クライアント側に脆弱性がないなら、リスクは同じでしょう。
Re:ワンタイムトークンは不要では (スコア:1)
大変失礼しました。
前提は、ブラウザの脆弱性、プロキシのキャッシュ、第三者のコンピュータの利用なども考えられる、現実社会の環境です。
Re:ワンタイムトークンは不要では (スコア:0)
Re:ワンタイムトークンは不要では (スコア:0)
PCの共有でCookieが漏れないとでも?
Re:ワンタイムトークンは不要では (スコア:0)
LANでシビアな情報をやり取りするのは、パケット傍受される危険性があるよレベルの話。
ここでいうCSRF対策とは既に別次元の話だから、そういう可能性(他のブラウザ以下)
は考慮しないで済むので問題ありません、という事では?
話題がセキュリティ一般であるなら、考慮しないでよい理由は無いだろうけど。
Re:ワンタイムトークンは不要では (スコア:0)
「Cookieは漏洩しないがhiddenフィールドは漏れる」という想定が間違いという話でしょう。
Re:ワンタイムトークンは不要では (スコア:0)