オーオース２・０におけるＣＳＲＦ対策で認可サーバーができること

• 4/2 追記
  • ブログのタイトルを「知ってるけどきっとそうじゃない。」に変更しましたが、それだとただの嘘だ、ということに気づきましたので、元のタイトルに戻します
  • 大変ご迷惑をおかけいたしました

---

• 本日から、ブログのタイトルを「知ってるけどきっとそうじゃない。」に改めました
• 今年度も、どうぞよろしくお願いいたします

By kidmissile - Identity Discs Acquired(2010) / CC BY-NC-ND 2.0

• 新タイトルになって最初の記事は、「オーオース２・０」におけるＣＳＲＦ（クロスサイトリクエストフォージェリー）についてです

• ＣＳＲＦといえば、ＵＲＬをクリックしただけで「こんにちはこんにちは！！」させられてしまう脆弱性であることを、ご存知の方は多いと思います
• 最近は、フェイスブックアカウント等でログインできるウェブアプリケーション（応用ソフト）も増えてきましたが、そこで利用されている技術がオーオース２・０です
• その部分にＣＳＲＦ脆弱性があると、いつの間にか、攻撃者のアカウントでログインさせられてしまう可能性があります
  • これが本当の「ぼくはまちちゃん！」というわけですね
    • （はまちちゃんがこの攻撃をおこなったという意味ではありません）
• つまり、それに気づかないまま、攻撃者のアカウントに銀行口座情報等を登録してしまうかもしれないという、怖そうで怖くない少し怖い脆弱性なのです
• さらに、既存のアカウントにオーオース２・０でログイン可能にする機能においてＣＳＲＦが成功すると、そのアカウントは乗っ取られてしまうでしょう
  • 「アカウントをフェイスブックアカウントと連携させる」的な機能のことです

• クライアント側の対策方法は仕様で述べられています
  • ｈｔｔｐ：／／ｏｐｅｎｉｄ−ｆｏｕｎｄａｔｉｏｎ−ｊａｐａｎ．ｇｉｔｈｕｂ．ｃｏｍ／ｄｒａｆｔ−ｉｅｔｆ−ｏａｕｔｈ−ｖ２−ｄｒａｆｔ２２．ｊａ．ｈｔｍｌ＃ＣＳＲＦ
    • ｓｔａｔｅパラメーターを使う説明ですが、よくわかんないですね。やめましょう

• そこで、クライアントがＣＳＲＦを理解しなくても脆弱性が生じないよう、認可サーバー側でできることを考えました

1. 仕様をちょっぴり変える
   • 認可リクエストで、ｓｔａｔｅパラメーターを「推奨」から「必須」にする
   • 認可レスポンスに、ｓｔａｔｅパラメーターを含めない
   • アクセストークンリクエストで、ｓｔａｔｅパラメーターを必須とし、認可サーバーは認可リクエストで渡されたｓｔａｔｅパラメーターとの一致を確認する
     • こうすれば、クライアントはおのずとｓｔａｔｅパラメーターを、セッション情報として保存するでしょう
     • しかし、ｓｔａｔｅパラメーターは依然クライアントが決定するので、必須だからといって毎回、ｓｔａｔｅ＝ｍｅｎｄｏｉを送られてこないか心配です
2. 仕様をもうちょっとだけ変える
   • クライアントは、ｓｔａｔｅパラメーターを発行するエンドポイントにリクエストする
   • 認可サーバーは、ｓｔａｔｅパラメーターを返す
   • 以下、認可サーバーから返されたｓｔａｔｅパラメーターを用いて、１．と同様の手順をおこなう
   • 認可サーバーは、クライアントに発行したｓｔａｔｅパラメーターであるか、常にチェックする
     • 認可サーバーから、適切なｓｔａｔｅパラメーターを提供することができます
     • パラメーター名が、もはやｓｔａｔｅとは言いがたいため、ｔｏｋｅｎなどに変更したほうがいいかもしれません
     • あとは、ｔｏｋｅｎをｓｅｃｒｅｔとペアにしたり、すべてのリクエストとレスポンスに署名を付けたりすれば、さらにセキュアになるでしょう

• いわゆるオレオレ仕様ですが、オーオース２・０は永久に更新され続ける仕様なので、多少違ってもばれることはないでしょう
• もしかしたら、ドラフト１００くらいで取り込まれるかもしれません