正しいCSRF対策、してますか? 134
ストーリー by mhatta
正しいのはどちら? 部門より
正しいのはどちら? 部門より
あるAnonymous Coward曰く、"最近WebアプリのCSRF脆弱性への対策が注目されていますが、30日に金床氏が「開発者のための正しいCSRF対策」という秀逸なテキストを発表してくれました。 Googleで「CSRF 対策」で検索すると高木浩光氏の「クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法」がトップに出てきますが、金床氏によると、この方法は誤った対策であり「CSSXSS脆弱性が知られている現在では、絶対に実施すべきでないもの」とのことです。この対策は、IPAの「情報セキュリティ白書2006年版」や「用語「CSRF」@鳩丸ぐろっさり (用語集)」ほか書籍などにも書かれており、金床氏は「記事の内容を訂正していただきたい」としています。スラドの開発者のみなさんはきちんと正しいCSRF対策をしていますか?"
Microsoftは直すと言っているみたい? (スコア:5, 参考になる)
Re:Microsoftは直すと言っているみたい? (スコア:4, 参考になる)
> ここに、 Microsoft に問い合わせた?人が得た?
お取り上げ頂いた件は、 Microsoft さんからの意思表示で間違いありません。いわゆる CSSXSS 脆弱性に関しては、 Internet Explorer へのセキュリティ修正プログラムが提供されるであろうと思われます。
高木さんの同僚の方からのコメント (スコア:4, 参考になる)
http://www.oiwa.jp/~yutaka/tdiary/20060330.html
セキュリティ関係に興味のある人なら、当然大岩さんのページは常時チェックしてると思ってたんですが、そうでもないのかな? > タレコんだ人
Re:高木さんの同僚の方からのコメント (スコア:2, 参考になる)
http://www.oiwa.jp/~yutaka/tdiary/20060330.html [www.oiwa.jp]
JavaScript と Cookie 必須?! (スコア:3, 興味深い)
Re:JavaScript と Cookie 必須?! (スコア:1)
リクエスト1にGETメソッドを使いたい場合の対処法で、
POSTメソッドを使う限りJavaScriptは不要だと思います。
Re:JavaScript と Cookie 必須?! (スコア:2, すばらしい洞察)
新たにサイトを構築するような場合でも、これは困難を伴うと思います。
また JavaScript で自動POSTさせる方法を併用されると(いくつもの条件が必要ですが) CSSXSS 脆弱性の悪用の道が開けるので、POST を使えだけでは十分ではありません。
Re:JavaScript と Cookie 必須?! (スコア:1)
実際の /. には CSSXSS 脆弱性による影響は(このシナリオの範囲では)ありません。
(紛らわしい表現ですみませんでした)
後半で説明していただいたとおり、GET から(通常の A タグやブックマークから)開かれて、そのページの中の Submit で処理が呼ばれるフォームは(適切な防衛をしなければ) CSSXSS 脆弱性により悪用される可能性があるので、掲示板・BLOGやショッピングカートなど、広範囲のウェブアプリケーションが CSSXSS を受けるわけです。
Re:JavaScript と Cookie 必須?! (スコア:1, 参考になる)
> 掲示板・BLOGやショッピングカートなど、広範囲のウェブアプリケーションが CSSXSS を受けるわけです。
ですから必ずPOSTで生成されるプレビューや確認画面を挟めばいいわけです。
というか私の知る限りほとんどすべてのショッピングカートは確認画面を挟むようになっていていきなり買い物を実行したりはしませんから、それほど対策困難ではないと思われます。
(プレビュー機能のない)掲示板なら被害の程度と対策のコストを天秤に掛けて、あえて対策しないという判断もあり得るでしょう。
結局、リクエスト1がPOSTの場合、CSSXSSをCSRFに用いることはできないという理解 [srad.jp]で合っているのですよね?
Re:JavaScript と Cookie 必須?! (スコア:1)
自動POSTでCSRF脆弱性を悪用できると感じたシナリオは、よくよくかんがえると既にセッションの乗っ取りが完了しているケースでした。
基本的なシナリオは、この記事 IBM PROVISION No.48 IBMプロフェッショナル論文3 - Japan [ibm.com]
とよく似たものです。Re:JavaScript と Cookie 必須?! (スコア:1)
Cookieを使わないセッション管理は
"CSSXSSを前提とする場合"
セッションハイジャックされる可能性があるからそもそも(以下略
ってことになるのでは。
Re:JavaScript と Cookie 必須?! (スコア:2, 参考になる)
なんかですねー、発注元(某お役所)の担当者様が、JavaScript必須の機能を付けてくれという追加要求があったんですよ。
はっきりいってマンドクセかったので対応したくなかったんですけど、実装したんですわ。
それで、全体通して完成したので動作確認してもらったら、「動かない」って言うんですわ。
エロエロ調べてもらったら、あちゃらさん IE 使っている上に、全所共通のお達しとかで ActiveScript は無効の設定にしていて、それを「一時的にせよ有効にすることは出来ない」のだとか。
そんなもんで、その機能については動作確認が取れないまま、こちら側で動いているハードコピーを FAX して了解を取り付けました。
(んなもん、自分のところでさえ動かすことが出来ない代物なんだから、そういう機能を使えない環境のユーザが居ることくらい念頭に置けよ=そんな機能要求するなって)
随分前に同じ所で納品した後に XSS 対策を言われたことがあって対処したんだけど、
今回はどうしようかなー?今のところ何にも言われて無いけどさ。
(え?JavaScript と Cookie なんて七面倒な機構、使わずに済めばそれに越したこと無いでしょ?)
# これ以上(余計な)仕事量増やしたくないのでAC
追加仕様対応マニュアル (スコア:1)
接待ってそういうものだったのか?
こそこそとIDで投稿
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:JavaScript と Cookie 必須?! (スコア:1)
JavaScriptが必須である事が分かった時点で、顧客に
運用上それで問題ないか確認するべきです。
制限が掛かってるのはありがちな話ですから。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
ワンタイムトークンは不要では (スコア:3, 参考になる)
高木氏は、
(efさんのコメント [srad.jp]に POST であっても CSSXSS 問題が悪用できる場合があると書かれていて、それを僕は理解できていないので、何か見落としがあるとしたらその辺りではないかと睨んでいますが……。)
鵜呑みにしてみる?
Re:ワンタイムトークンは不要では (スコア:1, 参考になる)
それで、CSRF と CSSXSS は防げます。
ただし、対策を行わなかった場合には、Cookieに保存されている
セッションIDはCookie以外には保存されることはありません。
しかし、貴方の言うセキュリティ対策を行うと、
HTML内のhiddenフィールドにセッションIDが埋め込まれることになるわけです。
これが万が一漏洩したらセッションハイジャックの危険があります。
(他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。)
冷静に考えてみて下さい。
SCRF対策、CSSXSS対策を行ったことにより、
他のセキュリティホールが生じる可能性が高まる状況は好ましいと言えますか?
Re:ワンタイムトークンは不要では (スコア:1)
Cookieを使わずにPOSTメソッドのhiddenでセッション管理をしている会員制のWebサイトであれば、CSRF及びCSSXSSの影響は受けません。
金床氏の提案する「正しい対策その1: ワンタイムトークンを正しく使用する方法」もCookieでセッション管理することを前提で書かれていました。
「セッションIDをCookieに入れる」のと「セッションIDをCookie及びhiddenに入れる」のでは、 後者の方がセキュリティ上のリスクは高いのでは無いでしょうか。
Re:ワンタイムトークンは不要では (スコア:1)
たぶん、同じセッションIDを含んでいる他のページをGETで取得できる場合、そのセッションIDは容易に類推可能なものになってしまうからじゃないでしょうか。
高木さんの対策は本質的には正しいのですが、「一致させる値を予測することは不能であるはずなので」という前提が崩れてしまったということだと思います。
# あ、不能→不可能のTypo発見(^^;。
Re:ワンタイムトークンは不要では (スコア:1)
その場合、ブラウザ側でクッキーが無効に設定されていたら、どうやってセッション管理するのでしょうか?正直に告白すると私はクッキーとhidden以外の方法でのセッション管理のやり方を知りません。URL埋め込みというのは却下でお願いします。 [aist.go.jp]
金床さんの提案手法は、CSSXSSで仮にセッションIDが盗まれたとしても有効な対策と理解していたのですが、勘違い?
ついでに書いておくと、今回の件でセッションIDはあくまでセッションを管理・追跡するためのIDとしてのみ使うべきであって、セキュリティを確保する目的で流用するのはまずいと、個人的には思うようになりました。大事な場面ではパスワードの再入力を求めるのと根っこはいっしょというか。
もうひとつ、CSSXSSによって、hiddenがクッキーより危険になったのではなく、XSSのあるクッキーと同じレベルになってしまったと理解しているのですが、これも勘違い?
Re:ワンタイムトークンは不要では (スコア:1)
セッションIDを流用すると、すべての状態遷移をPOSTで実装しない限り、CSRF対策としては本来一致させる値を予測することは不可能な値を埋め込まなければならないのに、特定することが可能になってしまう(セッションIDと一緒)という、#914151で指摘した問題に戻ってしまいます。
で、ワンタイムトークンを都度生成すれば、類推不可能という点においてはより望ましいのではないかという理解です。
Re:ワンタイムトークンは不要では (スコア:1)
えーと、誰かも書いていたと思いますが、答えとしてすべてをPOSTで実装する(しなおす)、は現実的には無理かなと考えていました。
で、
> クッキーが使われていない前提ですから、元々すべての状態遷移をPOSTで実装するしかありません。
ということであるなら
というアプローチよりは、 というアプローチのほうが望ましいだろうというのが、「ワンタイムトークンは不要では」というコメントに対する私の意見です。Re:ワンタイムトークンは不要では (スコア:1)
言葉足らずだったようで、すみません。
後者のアプローチでは、セッション管理はセッションIDで行います。セッションIDとは別に、CSRF対策用のワンタイムトークンを生成して利用すると言うことです。そうすればPOSTで実装する必要が出てくるのは、ワンタイムトークンが利用される場面だけで済むんじゃないでしょうか。
Re:ワンタイムトークンは不要では (スコア:1)
一般論としてはその通りだと思います。
今回のケースは、言ってしまえば(ある特定のブラウザの)影響の大きい深刻なバグが放置されており、その対処法が発表されただけとも解釈できるんですが、私があの手法を評価しているのは、今後同様のバグが発見された場合でも、この手法をとっていれば回避可能であると思える点です。
あの文書の隠れた肝は、ログインからログアウトまでという比較的長い時間保持されるような情報を鍵として流用することの危険性を指摘し、ある特定のクリティカルな操作のためだけに鍵を準備して、事が済んだら即座に消す、という手法の提案を行ったという所にあるんじゃないかなあと思っているんですが、どうでしょう。
名誉毀損上等・フレーム上等だゴルァ、、、 (スコア:3, 興味深い)
技術的議論では勝てないので、
アイデンティティを守るために名誉毀損なんてくだらん文系的世間体の問題を取ったって事?
それとも、間違いと指摘した側が間違ってて、名誉毀損怖いですって尻尾を巻いて逃げたのか?
なんかさっぱり意味分からんのだが、、、
そもそも、技術的に間違ってりゃ、
それを公表し続けてる事そのものが不名誉なんだから、
如何なる指摘も名誉毀損になり得ないわけで、、、
逆に指摘が間違いなら、その指摘してる奴が不名誉であるわけだから、
技術的視点で見れば、名誉毀損なんて事が存在する事が信じられない、、、
# 結局、技術的問題において不名誉は自分で自分に付けているのだ。
だいたい俺の個人的感覚だと、どちらにしても、
技術的な問題を技術的な議論で決着できない上、
名誉毀損なんて持ち出して、技術的な議論を放棄するような奴は最低の人種だぜ、、、って感じなんだがなぁ、、、
そもそも技術者倫理ってもんがねぇよ、、、それって、、、
間違ってる方が、勉強して出直して来い!って一喝されて終わってりゃいいじゃん、、、
技術的に間違ってるんなら、名誉なんて糞にもならんのだよ、、、
つぅか、それは虚栄心だよ、、、それ、、、
uxi
こんなものは正しくないよ (スコア:1, おもしろおかしい)
この対策はまるでデタラメ。
だって「2006年4月01日 Version 1.1」だもん。
だ、騙されないぞ?!
#どうみてもそういうネタじゃありません、本当に(ry
C か X か (スコア:1, 興味深い)
「CSRF」と「XSS」で両方とも「クロスサイト〜〜」と読むのが、どうも釈然としません。
Re:C か X か (スコア:2, 参考になる)
Re:C か X か (スコア:1)
むしろ、素人が十分知っておくべきことは、そんな見ただけで分かるような用語でないと理解できないような輩に作られたサイトなど危なくって使い物にならない、という方でしょう。
Cookie依存というのがねぇ (スコア:1)
できるだけCookie使いたくないんだけどね。
ってのはダメなのかな。
Re:Cookie依存というのがねぇ (スコア:2, 興味深い)
知らないメールのリンクを踏むのはCSRF以前
人間というものは間違いを犯すものであり、技術はそういうものを
*なるべく* 前提として考えるものだと思います。なにか最近の
「自己責任」大流行の風潮の中なのか、間違いを技術で救えるかの
検討がおろそかになっていきつつあるように感じてます。
「知らないメールのリンクを踏む」のを除外すれば、知っている人が
だまされたりして送ってくるメールにも無防備になって、そういう
対策自体の効力に疑問が生じます。
Re:Cookie依存というのがねぇ (スコア:1)
よく読んでみたらCookie要らんかも。失礼しました。
出直してくる。
Re:Cookie依存というのがねぇ (スコア:1)
Cookieを使いたくないということですが、どういった形態のサイトについての話なんでしょうか?
もし、ログインが必要な会員制のサイトならば、セッションIDやパスワードなどの識別情報を、URLに含めて渡すかPOSTメソッドで送信していることになります。
そういった方式での管理ならば、セッション情報を確認していないページがあるなどの脆弱性が無い限り、そもそも、CSRF及びCSSXSS攻撃は受けません。
なぜならば、攻撃者は識別情報を予測することができないからです。
Re:Cookie依存というのがねぇ (スコア:1)
追記ですが、URLにセッションIDやパスワードを含めることは、URLに埋め込むIDに頼ったセッション管理方式の脆弱性(2) [aist.go.jp]に書かれているような問題が発生するので推奨できません。
高木さんは (スコア:1, 興味深い)
Re:高木さんは (スコア:3, 興味深い)
なので、ちょっとその姿勢を改めたほうが良いのでは?と提言しているわけです
Re:高木さんは (スコア:1, すばらしい洞察)
すべてのサービスが対応するなんてあり得ないし、対処したらしたで、「実質的な脅威は軽微」とか言い訳できてしまうでしょう。
一般人はそれで納得するでしょうから、あとでネットの片隅でピーチクパーチク薀蓄をたれたところで意味はないでしょう。
正論としては、パッチのリリースを要求するというのは誰だって分かってることです。
金床氏が違った意見を持つのも分かりますし、その為の有用な情報を提供してくれるのはありがたいことです。
しかしながら、他人の著作物にまでにまで修正を要求するのは行き過ぎでしょう。間違いの指摘部分については正しいのでしょうが・・・。
#Javascript+Cookieを強制するのと、IEを使うなというのではあんまり大差ない気もするが・・・。
「間違い」という指摘が間違い (スコア:3, すばらしい洞察)
あらゆる議論には暗黙の前提がつきもので、議論の正否はその前提の上で正しいか間違いであるかで論ずるべきです。
前提が妥当でないならば、前提が妥当でないことを論ずるべきです。
Re:「間違い」という指摘が間違い (スコア:3, 参考になる)
MLのアーカイブは公開されています。
ブログでヤマガタ氏が指摘 [int21h.jp]
金床氏がMLで反応 [freeml.com]ヤマガタ氏がMLで追記 [freeml.com]
金床氏の反論 [freeml.com]Re:高木さんは (スコア:2, すばらしい洞察)
/.J を読み書きするような人なら大差ないと思いますが、そうではない一般人だと違うと思います。前者は OS デフォルトで有効にされていますが、後者は他のブラウザをインストールさせる必要がありますから。
Re:高木さんは (スコア:1, すばらしい洞察)
拒めば済む(あるいは拒む必要すら無い)ことだから、行き過ぎとは思わないな。
IE6がダメならIE7を使えばいいじゃない (スコア:1, 興味深い)
#金床氏のは読みづらかったので全部読んでません
Re:IE6がダメならIE7を使えばいいじゃない (スコア:4, 参考になる)
Internet Optionの "Open file based on content, not file extension"(日本語版IE6 on WinXP SP2では"拡張子ではなく、内容によってファイルを開くこと") が影響するのかと思っていじってみましたけど、Enabled, Disabledどちらでも影響はないようでした。
CSSXSSとCSRFを区別したら? (スコア:1)
ちゃんと調べているね (スコア:1, 参考になる)
その通り。オープンソースに限らずセキュリティでも日本はガラパゴス諸島化しているんです、とか書くとまた叩かれるのかな。基本的に彼の書いているのは、日本以外でよく見かけるドキュメントと基本的にかわりませんが、有用であることは確かであり、いずれにしてもよく調べていると思います。
Re:ちゃんと調べているね (スコア:3, 参考になる)
CSRF が最初に Bugtraq に出たときから sessionid を POST に入れる話は出てましたよ。
The Dangers of Allowing Users to Post Images (Cross-Site Request Forgeries) 17 Jun. 2001 [securiteam.com]
参考になったブログとか (スコア:1, 興味深い)
いしなお! - なぜCSSXSSに抜本的に対策をとることが難しいか [ishinao.net]
最悪の結末 (スコア:2, 参考になる)
この人の主張 [ohgaki.net]は技術的には正しいっぽいけど、「名誉毀損」をちらつかせるのはなあ。
とはいえ、元記事のいやらしかった表現はこのあたりですかね。
なんにせよ、これで名誉毀損は絶対にないと思うね。でもこういうきっかけがないと引っ込みがつかなかったかもしれず、じつはラッキー?
Re:最悪の結末 (スコア:2, 興味深い)
「下手なこと書くと名誉毀損で訴えられる可能性がある」
「訴訟って思ったより簡単で安いです」
なんて発言したら普通の人間がどういう行動をとるか、誰でもわかりそうなものですけどねえ。
Re:定量的評価頼む (スコア:1)
A>Bになることなんてあるんでしょうか?
(オフトピ)クッキーとhidden (スコア:1)
まず、大元のコメントについてですが、hiddenにセッション(ID)を入れていて、それが漏れるだけでセッションハイジャック可能なつくりになっているサイトは、クッキーにセッションIDを入れたとしても、それが漏れれば同じようにセッションハイジャック可能だと思います。セッションIDは最低限クライアントのIPアドレスぐらいとは紐付けしておいて、安易なハイジャックの可能性は排除するものなんじゃないでしょうか。そういう意味ではセッションを乗っ取られる危険性についてはどっちもどっちだと私は理解しています。
クッキーのほうがより堅牢なサイトを作れると言う情報があったら認識を改めますので、ぜひ教えてください。(無いだろうという皮肉ではなく、これまで作ってきたものや、これから作るであろうものに対する責任とか考えると結構切実なので。)
で、将来の可能性は置いておいたとしても、現状hiddenフィールドの値とクッキーの見られやすさというのは「両者はほぼ同じ」じゃないでしょうか。
httpの盗聴については2倍の確率だという主張はできますが、通信のタイミングと流れを考慮に入れれば、その主張にあまり意味が無いことは理解していただけるかと。
蛇足ですが、A>Bとなるのは、httpsなページでクッキーを利用していてsecureフラグをつけていない場合、でしょうか。
---
hidden信者ではないが、クライアントに「hidden禁止」と言われると非常に困る