はじめに
こんにちは、@okazu_dm です。 今回自分がぴざきゃっとさんが2022年4月に書いた以下の記事を更新したため、本記事ではその差分について簡単にまとめました。
Firebase Authentication利用上の注意点に関して生じた差分とは、すなわち「この2年強の間にどのような仕様変更があったか」と同義だと言えます。IDaaSに限らず認証のセキュリティに興味のある方には参考になるコンテンツだと思います。
更新した記事につきましては、以下をご覧ください。
差分について
Firebase Authenticationの落とし穴と、その対策を7種類紹介する、というのがオリジナルの記事の概要でしたが、2年ほどの時間の中で対策については大きく進歩したものが4点ありました(残念ながら落とし穴が無くなった、とまでは言えませんが)。
今回記事の中で更新したのは以下4点です。
- 落とし穴 1. 自己サインアップ
- 落とし穴 2. ユーザーが自身を削除できる
- 落とし穴 4. メールアドレスに紐付くユーザーが存在するかどうか判定可能
- 落とし穴 6. パスワードの脆弱な構成要件
それぞれの差分について、以下で紹介していきます。
落とし穴 1. 自己サインアップ
自己サインアップとは、サービス提供者が想定していないユーザが勝手にアカウントを作成できてしまうリスクです。 2022/04当時はFirebase AuthenticationをアップグレードしてIdentity Platformの機能を使うことで自己サインアップを禁止できました。
また、アップグレードしない範囲での対策としては、カスタムクレームの利用をオリジナルの記事では推奨していました。 ユーザに公開されているAPIキーでは、カスタムクレームは付与できないため、開発者が想定したフローの登録処理の中でカスタムクレームを付与するような実装を行うことで、登録されたユーザが想定されたフローでサインアップしたのか否かを見分けることができます。しかし、こちらの手法は認証済みユーザが行うすべての処理でユーザのカスタムクレームを確認する必要があるため、サービスの規模に応じて実装漏れが発生するリスクなどが高まることが懸念されます。
一方で、現在では無料枠の範囲内で自己サインアップを禁止することが可能であり、Firebase Authenticationの設定画面の操作のみで完結します。今回の更新ではこちらの方法を推奨するようにしました。
落とし穴 2. ユーザーが自身を削除できる
サービス提供者が想定しないユーザ削除フローで不具合が発生するリスクです。
オリジナルの記事では対策として「ユーザが自分自身を削除しても不具合が発生しないような設計・実装にする」といったことを推奨していました。
しかし、こちらも落とし穴 1と同じでIdentity Platformの機能だったものがアップグレード無しで使えるようになりました。すなわち、Firebase Authenticationの設定で対処することでアプリケーション側は(サービスの設計にもよりますが)意図しないユーザの削除を意識する必要はなくなりました。
落とし穴 4. メールアドレスに紐付くユーザーが存在するかどうか判定可能
基本的に望ましくないことですが、マッチングアプリに友人/恋人のメールアドレスが登録されているかどうかが判別できる...といったシチュエーションを想定すると理解しやすいリスクです。また、アプリケーションに登録されているメールアドレスリストが収集されることで次なる攻撃の足がかりになるかもしれません。
オリジナル記事では以下のような対策を推奨していました。
- そもそもメールアドレスと紐づかない認証方法として、OAuth2.0 プロバイダを使う。
- Identity Toolkit API の割り当てを小さくすることで、攻撃者がメールアドレスの存在確認をできる回数を絞る。
上記のような対策は現在でも、Firebaseセキュリティチェックリストの中で推奨されています。
これらの対策は2024年8月時点でも有効です。
また、オリジナル記事との差分として、メールの列挙保護機能についても紹介しています。有効なメールアドレスの収集に対してはAPIの割り当てを小さくすることに代わる根本対策となりますが、これはあくまで「列挙」からの保護であり、記事中で想定したような特定のメールアドレスのみを狙った攻撃に対しては無力です。
落とし穴 6. パスワードの脆弱な構成要件
Firebase Authenticationのデフォルト設定ではパスワードポリシーが弱すぎるという観点です。
オリジナル記事ではパスワードを設定する際にフロントエンドでバリデーションを行うことを推奨していました。
しかし、現在はパスワードポリシー機能が無料で利用可能なため、こちらの利用を推奨しています。
なお、ユーザの自己サインアップ/自己削除の禁止機能と同じくこちらも以前は利用にはアップグレードが必要な機能でした。
まとめ
以上のように、Firebase Authenticationは新機能やアップグレード無しで使える範囲が広がったことで更に安全に使えるようになっています。 また、今回更新しなかった落とし穴については、大まかには以下のように分類できます。
- Firebase側での対応がされていないもの/対策に更新がなかったもの
- 落とし穴 3. 他人のメールアドレスを用いたユーザー登録
- 落とし穴 5. メールアドレス / パスワード認証のブルートフォース
- そもそも対策がFirebaseの責務に含まれないもの
- 落とし穴 7. 異なる目的で有効化された認証プロバイダーの区別
設定のみで完結する部分は増えたとはいえ、未だにアプリケーション側の実装やサービスの仕様として考慮しないといけない部分はあるため、個々のサービスの設計に応じたFirebaseの機能が守ってくれる範囲と、自分たちで守らないといけない範囲の整理は引き続き重要です。
さて、本稿ではFirebase利用に伴って発生するおそれのあるリスクについて説明しましたが、実際のところ今回紹介したものはほんの一部であり、実際の診断事例では分類が難しい複雑な脆弱性や仕様を深く理解していなければ発見できない難易度の高い脆弱性等が見つかることが多々あります。
株式会社Flatt Securityでは、専門のセキュリティエンジニアによる Firebase に対する脆弱性診断サービスを提供しています(もちろん、Firebase を活用しているアプリケーション全体の診断も可能です)。もし、Firebase を用いた開発におけるセキュリティ上の懸念事項が気になる場合や、実際に診断について相談したいという場合は、ぜひ下記バナーからお問い合わせください。
上記のデータが示すように、診断は幅広いご予算帯に応じて実施が可能です。ご興味のある方向けに下記バナーより料金に関する資料もダウンロード可能です。
また、Flatt Security はセキュリティに関する様々な発信を行っています。 最新情報を見逃さないよう、公式X のフォローをぜひお願いします！
では、ここまでお読みいただきありがとうございました。
Flatt Securityは外部パートナーと連携して技術記事を発信しています
本稿はFlatt Securityの外部パートナーが執筆し、Flatt Securityが監修を行った記事です。通常、企業の技術ブログは自社の技術力やカルチャーの発信のため、雇用関係にある社内メンバーの執筆によって発信されることがほとんどだと思います。
一方、Flatt Securityの技術ブログでは、本稿のようにセキュリティの知見をお持ちの外部の方に依頼しているケースがあります。種々の脆弱性情報や情報発信に知見を持つFlatt Securityの技術ブログ編集部が執筆者の方と連携することで、テーマや構成の検討・レビューをサポートしています。
これは、Flatt Securityの技術ブログの目的が自社のアピールにとどまらず、セキュリティに関する有益な情報をより多く社会に還元し、セキュリティ企業とセキュリティサービス利用者の間の情報の非対称性を無くすことを目的としているためです。
本文章は執筆者がセキュリティ診断のようなFlatt Securityのサービス提供に直接的に関わっているかのような誤解を防ぐために明記していますが、執筆にご興味を持たれた方はお問い合わせください。
