「Firebase Authentication 7つの落とし穴」のリスクを再整理する

もちろんこういったリスクを列挙、検討するのは重要なことなのですが、

• Firebase Authentication関係ない話では
• あれ、仕様に関して勘違いしてる？

というのがいくつかあったので、再整理していきます。リスクは列挙することには業務上あまり意味はなく、評価され、リスクを受け入れるか外すかを判断するところが重要なので。

IDaaSは脆弱性を生み出すか

IDaaS を導入することにより、逆に脆弱性が生まれることもあります。（中略） Firebase Authentication は他の IDaaS と比べて設定項目が少ないという特徴があります。

もちろんここに書かれてることは間違いではありません。ただ、少し実装にフォーカスが寄りすぎていると思っています。セキュリティを考える上では、まずISO27018をはじめとした主要なセキュリティ規格やプライバシー規格を俯瞰する必要があります。

Firebase のプライバシーとセキュリティ

「IDaaSを導入しないと判断するならこれを自己取得してますよね？」までは大上段すぎる話ですが、実装という小さな話の前に「個人情報の管理体制」（ベネッセ大規模情報流出事件を彷彿させますね）、次に管理サーバまわりのセキュリティという話がくると思ってて、そう思うとIDaaS 導入で脆弱性が生まれることはゼロではありませんが、一方でもっと（実装コード以外の）メリットに光があてられるべきだと感じました。

自己サインアップ

ここにあるリスクはまさにその通りです。 私がつくってる社内システムでは、ドメインと email_verified （メールアドレス認証済み）のふたつをもってみたり、事前に登録のあるメールアドレスのみ許可したりしていますが、記事にあるように

「サインアップ画面を用意していないからユーザは新規登録できない」

というのは脆弱性となるので対策すべきです。

Firebase において API キーは機密情報ではありません

これは少し誤解を招きかねないので補足しておきますが、正しくは「Firebaseは、（Publicな）API Keyと管理用の秘密鍵が別に用意されております」が正しい表現です。本文にあるように「自己サインアップ等」は可能ですが、他者のアカウント操作などは行うことはできません。

落とし穴 2. ユーザーが自身を削除できる

これはそのとおりですね。自己サインアップ同様、「Public API Keyを使ってエンドポイント直たたきでユーザが削除されてしまうことによってアプリケーション上で不整合が生まれてしまうかもしれない」というリスク自体は存在します。

落とし穴 3. 他人のメールアドレスを用いたユーザー登録

リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り

「メールアドレス誤入力によるユーザー乗っ取り」は「IDaaSによる脆弱性」ではなく、Emailの所有確認をいれなかった仕様の問題です。そういう意味では、「IDaaSだから、Firebase Authenticationだから」という固有の問題と、ただの仕様策定ミスであって、IDaaSでなくても起こりうる問題は切り離して考えるべきでしょう。

リスク 3-2. 他人にメールを送りつけさせる

「大量スパムが（Firebase Authentication経由で）送れてしまう」ことについては、Firebase Authenticationは「申し込みによる割り当ての管理」を実装しています。

プロジェクトを不正行為から守るため、同じ IP アドレスでアプリケーションが使用できる新しいメールとパスワード、匿名での申し込みの数を制限しています。ここで、この割り当てを一時的に変更するようリクエストしたり、スケジュール設定したりできます。

なので、新規登録/匿名についてはここでコントロールすべき事項でしょう。パスワードのリセットについては懸念のことは実現してしまいますが、（パスワードリセットのURLが送られてきて、そのURLをクリックしたユーザ自体が新パスワードを設定するので）そういう攻撃をしても意味がないんですよね・・・。あと後述しますが、Firebaseとしては不正利用は別途の対策も行っていると述べています。

アプリケーションがユーザー名の長さや文字種に制約を課していないとします。

以下がFirebaseの定型文なのですが、本記事でふれているのは %DISPLAY_NAME% の部分です。

件名
%APP_NAME% のログイン用メールアドレスが変更されました
メッセージ
%DISPLAY_NAME% 様

ドキュメントにある以下のところですね。

重要: displayName や photoURL など、ユーザーに表示される可能性がある UI の値を設定（および後で表示）する際は注意が必要です。API は、潜在的な XSS タイプの攻撃を防ぐための値のフィルタリングを行いません。

updateProfile(user, {
  displayName: '\n以下の URL からログインしてください。\nhttps://phishing.example/signin\n\n\n'
})

以下の URL からログインしてください。 様

project-457600014723 のログイン用メールアドレスが [email protected] に変更されました。

メールの変更を依頼していない場合は、次のリンクをクリックして、ログイン用メールアドレスをリセットしてください。

auth.token.email_verified: false

Firebase Authentication は、エンドユーザーの認証とエンドユーザーのアカウント管理に個人データを使用します。
また、セキュリティを強化し、サインアップや認証時の不正行為を防ぐために、ユーザー エージェント文字列と IP アドレスを使用します

The Firebase Authentication service is monitored for abuse. Information about this monitoring and the actions taken on detected abuse is seldom documented though, since the information changes regularly and would be more helpful to abusers than to most developers.

If you think your use-case is being affected by this monitoring or the actions taken upon it, reach out to Firebase support with clear details (i.e. code)on what you're trying to do, and what behavior you seeing.

Google翻訳: 
Firebase認証サービスは不正使用がないか監視されます。ただし、この監視と検出された不正使用に対して実行されたアクションに関する情報が文書化されることはめったにありません。情報は定期的に変更され、ほとんどの開発者よりも悪用者にとって役立つためです。

ユースケースがこのモニタリングまたはそれに対して実行されるアクションの影響を受けていると思われる場合は、Firebaseサポートに連絡して、何をしようとしているのか、どのような動作が見られるのかを明確に説明してください（コードなど）。