セッションIDをhiddenに含める方式だと危険があるのでは?という気がしてきた。 ・投稿結果が検索できるようなサイトが攻撃対象 ・罠サイトからJSで総当たりにPOSTさせる ・罠サイトはhtt...
セッションIDをhiddenに含める方式だと危険があるのでは?という気がしてきた。
・投稿結果が検索できるようなサイトが攻撃対象
・罠サイトからJSで総当たりにPOSTさせる
・罠サイトはhttpsでリファラーを隠せる
みたいな前提で、CSRFが成功したかどうかは投稿検索でわかる。
CSRFに成功してればhiddenパラメーターの推定に成功したということになる。
で、hiddenパラメーターがセッションIDだったら、
セッションIDの推定に成功したということになる。
この攻撃方法は総当たりでセッションIDを推定するのと
試行回数的には同程度なのだけど、
どこから攻撃されているかサービス側にわかりにくいという特長がある。
「セッションで共通の1個の乱数」とセッションIDをもとにして、
ハッシュ演算しておくともうちょっと安全な気がするし、
別の穴によってより危険になっているかもしれない。
実際のところどうなんだろうなあ。
・投稿結果が検索できるようなサイトが攻撃対象
・罠サイトからJSで総当たりにPOSTさせる
・罠サイトはhttpsでリファラーを隠せる
みたいな前提で、CSRFが成功したかどうかは投稿検索でわかる。
CSRFに成功してればhiddenパラメーターの推定に成功したということになる。
で、hiddenパラメーターがセッションIDだったら、
セッションIDの推定に成功したということになる。
この攻撃方法は総当たりでセッションIDを推定するのと
試行回数的には同程度なのだけど、
どこから攻撃されているかサービス側にわかりにくいという特長がある。
「セッションで共通の1個の乱数」とセッションIDをもとにして、
ハッシュ演算しておくともうちょっと安全な気がするし、
別の穴によってより危険になっているかもしれない。
実際のところどうなんだろうなあ。
高木浩光@自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由, hiddenパラメタは漏れやすいのか?