OAuth2.0 Security Best Current Practiceを読んでみる（８）

こんにちは、富士榮です。

ようやくこのシリーズも終わりです。

引き続き攻撃パターンと緩和策です。最後の3つを読んでいきます。

攻撃パターンと緩和策

• クリックジャック
• 認可エンドポイントにアクセスした時に表示する画面に透明なiFrameを仕込むなどのクリックジャックの話です
• 認可エンドポイントはMUSTとしてクリックジャック対策をしなければなりません
• W3CのContent Security Policy Level2以上を適用すべきです
• こんな風にする感じですね

HTTP/1.1 200 OK

Content-Security-Policy: frame-ancestors https://ext.example.org:8000

Content-Security-Policy: script-src 'self'

X-Frame-Options: ALLOW-FROM https://ext.example.org:8000

• 認可サーバがフィッシングサイトにリダイレクトする
• 前も出てきたかもしれませんが、正しくredirect_uriが設定されていたとしても攻撃者によってフィッシングサイトに誘導されてしまう可能性はあります。
• 例えば、無効なスコープの値を指定することでフィッシングサイトへ誘導するケースや、有効出会っても攻撃者によってコントロールされたclient_id、redirect_uriを使った誘導（同意拒否をしても誘導される。他にもprompt=noneで誘導する）ケースがあげられています
• 認可サーバでこれらを防ぐためにはprompt=noneのケースをのぞき、必要に応じてユーザ認証を行う必要があります
• また、リスクに応じて追加のアクションを講じるのも一つの手段です
• 基本的にredirect_uriが信頼できない状況ではリダイレクトするべきではありませんが、信頼できない場合にユーザがリダイレクトするかしないかの判断をするような実装を行なっても良い（MAY）ということです
• ブラウザ内の通信フローに対する攻撃
• 認証応答がリダイレクトではなくpostMessageなどで送信されるケースにおいて悪意のある通信先に対して通信が行われるケースがあります
• 例えば、送信先の制限が不十分な実装をするケースなどが挙げられています。ワイルドカードで送信先が設定されていますね

window.opener.postMessage(

  {

    code: "ABC",

    state: "123"

  },

  "*" // any website in the opener window can receive the message

)

• 他にも送信先のURIの検証が不十分で攻撃者の設定した値になってしまったり、送信元の検証が不十分なケースも想定されるのでURI検証やCSRF対策はしっかりとしておく必要があります
• その意味で推奨される実装としては、
• 明確なクライアントオリジンを示す

window.opener.postMessage(

  {

    code: "ABC",

    state: "123"

  },

  "https://client.example" // use explicit client origin

)

• メッセージのバリデーションを行う

window.addEventListener("message", (e) => {

  // validate exact authorization server origin

  if (e.origin === "https://honest.as.example") {

    // process e.data.code and e.data.state

  }

})

• といった実装が必要となります

ということで、ようやくこれで最後まで読みました。

実装する暇がなかなか取れませんが、徐々にやっていきたいと思います。