FuelPHPのCSRF対策トークンは何が問題だったのか (2ページ目)

@kenji_s @tanakahisateru @brtriver （他の脆弱性が無ければ）ドメインを超えて cookie 変更されない -> cookie 書き換えは心配しなくて良い、ということですかね。

2012-06-06 15:27:31

@ounziw @tanakahisateru @brtriver なんで避けるべきなんでしょうか？

2012-06-06 15:29:06

@kenji_s @tanakahisateru @brtriver 同じ値で良いなら、トークン生成ルールの推測で突破できると思います。トークンの片側をハッシュ化しておけば、トークン生成ルール＋ハッシュの両方が必要だと思います

2012-06-06 15:32:08

@ounziw @kenji_s @tanakahisateru @brtriver 定量的に堅牢性を評価していないので、実はあまり意味がないかもしれません

2012-06-06 15:34:45

@ounziw @kenji_s @brtriver 間違っていたらすみませんなんですが、他の一般的な秘密情報と公開情報を組み合わせたCSRF対策では、本当に実サーバがトークンを作らないとだめで、ロギングも可能です。(つづく)

2012-06-06 15:53:49

@ounziw @kenji_s @brtriver (つづき)が、クライアント側をいくらか攻撃しただけで使えるトークンを作れてしまう(あの実装だと123とかでも通る)と、サーバにcookieを送らせる必要すらなくて、別の攻撃手段に対して超弱くてCSRFと同じことができるリスク?

2012-06-06 16:01:09

@ounziw @kenji_s @brtriver ハッシュのsaltがサーバにしかないなら、もし別の攻撃でクライアント側のスクリプトを陥落させても、結局サーバに正しいトークンをもらわないといけないので、そこが最終砦になってくれると思います。片方を秘密情報でハッシュ化同意です。

2012-06-06 16:06:08

@ounziw @kenji_s @tanakahisateru @brtriver トークンが推測できればそれで突破できます。そこが脆弱。Cookieの値を書き換えたり知る必要はありません

2012-06-06 16:08:16

@tanakahisateru @kenji_s @brtriver 正確には、POST hidden を秘密情報ハッシュ化ですね。攻撃者が不正に設定するのは(たいていの場合) POST hidden なので、ハッシュ化するなら POST hidden

2012-06-06 16:15:18

@kenji_s @tanakahisateru @brtriver 「トークンが推測できればそれで突破できます。そこが脆弱。」了解です。

2012-06-06 16:17:10

@tanakahisateru @ounziw @brtriver 別の攻撃手段、CSRFと同じこととのいうのが、ちょっとよくわかりませんが。あの実装ではサーバにCookieが送られない限り何も動作しないと思いますが

2012-06-06 16:17:27

@ounziw @tanakahisateru @brtriver 中途半端に暗号化してもseedを解かれる可能性あります。 http://t.co/XRwstI5g 参照

2012-06-06 16:22:47

@kenji_s @ounziw @brtriver CSRF正攻法で攻撃するなら、iframeでcookieを食わせた直後jsからpostさせて、せいぜい5000回(ラグ5秒)ぐらいの試行以内で、食ったcookieの値と同じのにヒット。ここが問題の本質という理解で合ってますか?

2012-06-06 16:23:07

Masao Maeda @brtriver

@tanakahisateru @kenji_s @ounziw はい。推測可能なのが本質

2012-06-06 16:34:49

Masao Maeda @brtriver

@tanakahisateru @kenji_s @ounziw 自分自身も最初勘違いしてたわけですが。

2012-06-06 16:35:22

@kenji_s @ounziw @brtriver cookieヘッダとpost本文にでたらめな同じ値を書いていきなりpostできてしまうと、もしXSS対策漏れがあったら、すごく簡単なスクリプトで一撃でやられる気がします、という意図でした。偽のトークンの作成に試行が要らない。

2012-06-06 16:36:10

@kenji_s @tanakahisateru @brtriver なるほど。よく考えてないと逆効果、ということですね。「中途半端に暗号化してもseedを解かれる可能性あります。 http://t.co/vY6TxVbP 」

2012-06-06 16:38:58

@tanakahisateru @ounziw @brtriver 確か今のデフォルトはワンタイムになってて1回つかったらCookieは変わると思います

2012-06-06 16:39:02

@kenji_s @ounziw @brtriver なるほど、じゃあ、postを数千回じゃなくて、iframeを作って適当なタイムラグを想定してpost、というのを1試行として、それをmaxで5秒ラグぐらいの1ms刻みでやると攻略できるということですね。

2012-06-06 16:45:05

まとめ: 純粋にCSRF対策というと、トークンの推測困難さが十分に高いかどうかだけが課題であって、トークン自体がCookieに生で入っていても、サーバに保存されていても、ブラウザのセキュリティ仕様が正しく動くかぎり問題なし。

2012-06-06 16:53:50

まとめ: トークンの保存方法の危うさと、トークン自体にチェックサムが効いているかというのは、他の攻撃に対するリスク。

2012-06-06 16:55:23

特定の手法を題材に具体的な攻略方法を考えるというのは、セキュリティへの理解をずいぶん高めてくれると思いました。

2012-06-06 17:00:25