OAuth徹底入門の読書感想文 -9章-
OAuth徹底入門を読んだので感想と概要を書いていきます
8章については先日書きました
今回は9章についてです
9章 よく狙われる認可サーバーの脆弱性
認可サーバーはOAuthの構成要素の中でも最も複雑
ユーザーとのやりとりを行うWebサイトと、マシンとのやりとりを行うAPIの両方を提供しており、以下に述べるような一般的なセキュリティがまず求められる
- サーバーのログを安全にする (クレデンシャルなどをログに出さない)
- TLSを有効な証明書と共に使う
- 適切なアカウントのアクセス制御をする
また、OAuthにおける認可サーバーとしては以下のことに気をつける必要があります
セッションの乗っ取り
問題
認可コードによる付与 (Authorization Code Grant)を行なっている認可サーバーの場合、認可サーバーは生成した認可コードをURIのリクエスト・パラメータに含め、リダイレクトを使ってそれをクライアントへ運ぶようにする
この際、認可コードはブラウザを経由してクライアントへ運ばれるため、ブラウザ履歴に残ってしまう
もし共用のパソコンで作業をしていた場合、たとえ自分は作業が終わった段階でログアウトしても後からきた悪意あるユーザーが自分のID、パスワードでログインし、履歴に残っていた認可コードを使って認可サーバーへ注入したとすると、最初に認可コードを取得したリソース所有者のリソースにアクセスできるようになってしまう
対策
OAuthの仕様ではこうした自体を防ぐため、一度認可コードがトークンとの交換に使用されたらその場で認可コードを削除するようにしている
そうすることで、認可コードは認可サーバーに一度しか受け入れられなくなる
リダイレクトURIの不正操作
問題
OAuthではredirect_uriの検証方法については完全に認可サーバーに一任されている
認可サーバーは一般的に3つの検証アルゴリズム (完全一致、サブディレクトリの許可、サブドメインの許可)のどれかを使ってredirect_uriの検証を行う
サブディレクトリやサブドメインを許可していると、もし攻撃者がクライアント・サーバー内に悪意あるページを作成できた場合、redirect_uriを操作して認可コードやアクセストークンを持ったままユーザーを攻撃者の悪意あるページにリダイレクトすることができてしまう
対策
とてもシンプルだが、認可サーバーが利用すべき唯一の安全なredirect_uriの検証方法は完全一致である
オープン・リダイレクトによる脆弱性
問題
オープン・リダイレクトとは未検証のリンクへリダイレクトしてしまうことで悪意あるページにユーザーを遷移させてしまう脆弱性
たとえば、攻撃者が新しいクライアントを認可サーバーへ登録し、redirect_uriを以下のような特殊なものにしておく
https://hogehoge/fugafuga/authorize?response_type=code?client_id=attcker-client-id&scope=WRONG_SCOPE&redirect_uri=https://attacker.com
攻撃者はこのような不正な認証を行うリクエストのURIを作成しておくことで、正当なクライアントを攻撃者のサーバーにリダイレクトすることができる
対策
リクエストの処理でエラーが起こった際はリダイレクトするのではなく、400 Bad Requestを返すことでオープン・リダイレクトによる脆弱性をなくすことができる
感想
ちょっと難しかった
攻撃者、攻撃者のサーバー、攻撃者のクライアント、ユーザー、クライアント、認可サーバーなど登場する役が多いのでちょっと自分の頭の中でも整理しきれてない感じはする
ただやらなきゃいけないことはシンプルで明白なので実装時には心がけていこう
