OAuth徹底入門の読書感想文 -7章-
OAuth徹底入門を読んだので感想と概要を書いていきます
6章については先日書きました
7章 よく狙われるクライアントの脆弱性
この章ではOAuthクライアントを実装する際に注意するべき、狙われやすいポイントについて説明されています
クライアントに対するCSRF攻撃
CSRFについては以前記事を書きました
OAuthにおけるCSRFでは、攻撃者はあらかじめ認可サーバーから認可コードを取得し、偽造する
攻撃者は被害者を騙して、攻撃者が偽造した認可コードを被害者のクライアントが使用するように仕向ける
これにより、攻撃者の認可情報とクライアント・アプリケーションが結びついてしまう
対策としては推測できないstateパラメータを生成し、認可サーバーを呼び出す最初の手順でこれを渡す
クライアントはリダイレクトされた際にstateパラメータをチェックし、最初に送ったものと変わっていないか確認する
そうすることで、攻撃者の認可コードを使ったり、被害者のクライアントに注入したりすることを防ぐことができる
クライアント・クレデンシャルの不当な取得
ネイティブ・アプリなどのデバイスにインストールして使われるものは、内部にクレデンシャルを隠していてもデコンパイルされてクライアント・クレデンシャルが漏洩し、誰でもクライアントとして認可サーバーに認証されてしまう恐れがある
動的クライアント登録 (Dynamic Client Registration)を呼ばれる機能を使うと、OAuthのトークンのリクエストを行なった際にクライアント・シークレットが発行され、ネイティブ・アプリケーション中に最初からクレデンシャルが埋め込まれている状態を防ぐことができる
リダイレクトURIの登録
クライアントが認可サーバーにredirect_uriを登録する際にはできるだけ完全なURIを登録するべきである
下に良い例と悪い例を示す
// 良い例 https://foobar.com/oauth/oauthprovider/callback // 悪い例 https://foobar.com/
悪い例のようにドメインのみ登録したり、パスの一部しか登録しないと、容易にトークンの乗っ取りが可能になってしまう
もちろん認可サーバーもURIの完全一致のみ検証方法として用いるべきではあるが、サブディレクトリを許可するような設定になっていてもトークンが乗っ取られないように、リダイレクトURIは正しく記載しておく必要がある
認可コードの不正な取得
認可コードによる付与方式を狙った攻撃として多いのがHTTPリファラーを利用したもの
HTTPリファラーとはHTTPヘッダーのフィールドで、あるページから別のページに遷移する際にブラウザによって、どのURIから来たかという情報が記録されるもの
認可サーバーがリダイレクトURIにサブディレクトリを許可している場合、攻撃者はリダイレクト先にHTTPリファラーを有効にしたリンクを置いておきユーザーにクリックさせる
HTTPリファラーにはパラメータも一緒に参照できるため、認可コードが攻撃者から丸見えになってしまう
やっぱりリダイレクトURIは正しく登録しておく必要がある
感想
いろんな攻撃手法があるが、きちんとOAuthのやり方に則っていれば少なくともこの章で書いてあった攻撃は防げそうだと感じた
stateパラメータを使う、クライアントにあったフローを選ぶ、リダイレクトURIは完全に指定する、簡単だけど強力なセキュリティ
