令和３年春「情報処理安全確保支援士試験」午後１問１の振り返りメモになります。
お話
利用者認証を他社の認証サービスを使って行うように改修していくお話です。
他社サービスを使うと自分は用意しないので楽ですが、連携することで受けてしまう脆弱性攻撃やデメリットその対策などが出題されました。
また、サービス連携はOAuthのやりとりが採用されました。（OAuthは令和４年春でも出ています。）
どんな問題が出た？
多要素認証を他社サービスと連携してやってもらう利点は？
自サービス側で多要素認証を用意しなくて良い。
逆に、やってもらう場合可用性観点での欠点は？
連携先サービス障害時に自社サービスも利用できなくなる
「利用者」「自サービス」「連携先サービス」。OAuthで他社サービスと連携すると「誰」は「誰」の権限付与によって「誰」のリソースにアクセスできる？
「自サービス」が「利用者」の権限付与により「連携先サービス」のリソースにアクセスできるようになる
サービス連携時攻撃者アカウントに紐付けられる攻撃が出題。対策はどうすればよい？
stateパラメータを自サービス側が付与する対策がテストで出ました。
何も対策しない場合の攻撃の流れ
- 攻撃者は自サービスにアクセスして連携先サービスとの連携を試みる。
- 連携要求を受けて自サービスは連携先サービスにリダイレクト。
- 連携してOKか利用者に確認する画面が出る→攻撃者は当然許可する。
- 連携先サービスから認可コードを付与した自サービスへのリダイレクトが発生。ここで攻撃者はこの通信をリダイレクトさせずにリダイレクト先URLだけ取得。
- 攻撃者はリダイレクトURL(罠URL)を誰かにメール等で送りつける
- 被害者が罠URLをうっかりクリックすると、サービスは攻撃者が仕込んだリダイレクトの続きの応答が来たと判断してしまい、被害者が攻撃者のリソースを使えるようになる。
- このリソースにうっかり秘密の情報をアップロードすると、（攻撃者のリソースの中なので）攻撃者が好き勝手にダウンロードできてしまう。
ここで、攻撃受けていると誰のアカウントでアップロード、ダウンロードされるか？が出題されました（答えはいずれも攻撃者アカウント）
stateパラメータをつけた場合の流れ
- 攻撃者は自サービスにアクセスして連携先サービスとの連携を試みる。
- 連携先サービスにリダイレクト。このとき自サービスはURLに「stateパラメータ」も付与。さらに自サービスも攻撃者のセッションにstateパラメータ情報を紐づけ保存する。
- 連携先サービスから認可コードを付与した自サービスへのリダイレクトが発生。ここで攻撃者はリダイレクトさせずにリダイレクト先のURLだけ取得。（このURLこにstateパラメータが付与）
- 攻撃者はリダイレクトURL(罠URL)を誰かにメール等で送りつける
- 被害者が罠URLをうっかりクリックしても、自サービスが保存している被害者のセッションにstateパラメタが無い。URLにあるstateパラメータと不一致なので、攻撃が防御可能になる。
問題ではどの通信のときstateパラメータをつけるかが問われました。(最初に連携先サービスへリダイレクト送るときにつけて、認可コードが来るときにチェック）
以下サイトがとてもわかり易いです。
連携先サービスが停止したので自社のパスワード認証に戻した。この場合アクセスできなくなる人は？
自社サービスの認証で利用者IDとパスワードを登録していない人。
サービス連携前の人は既にパスワード登録しているが、サービス連携後だと登録していないので使えなくなってしまうお話でした。
利用者認証を連携先サービスでやっているとき、自サービスはどのように確認するか？
連携先サービスで認証を受けた利用者のIDが、自サービスに登録されていることを確認する。注記に記載があり、問題文を読み解く問題でした。
