FirebaseのAuthenticationはGoogleログインやTwitterログインが簡単にできる便利なものですが、その中には匿名認証というものもあります。これが一体何のためにあるのか、セキュリティの観点から見てみます。今回はブラウザ上で動くWebアプリケーションの話です。
匿名認証というのは、ユーザーが何も操作などをしなくても、内部で勝手にログインする機能です。
基本的には公式の説明にいきなり書かれています。
JavaScript を使用して Firebase 匿名認証を行う | Firebase
アプリに登録していないユーザーが、セキュリティ ルールで保護されているデータを使用できるようになります。
Firebaseは便利ですが、怖いところがあります。Webアプリケーションの場合、JavaScriptを使うためFirebaseアプリケーションを初期化するための設定情報が丸見えになってしまいます。そのため、何のセキュリティも導入していないとその設定情報を使って誰でも勝手にそのアプリケーションの情報を読み書きできてしまいます。
それを制限する方法として、ForestoreやStorageにはセキュリティルールがあります。例えば以下のようなことが設定できます。
等。
前述の通り設定情報が丸見えですので、それをコピーして誰かが自分のプログラムに組み込めば、他人のFirebaseのアカウントで自由にデータなどを扱えるようになってしまいます。
見られてはいけないデータが見られてしまいますし、そもそも利用量によって金額も増えてしまう恐れがありとても危険です。
セキュリティ上問題ないと思われる、匿名認証を使ったシンプルな例をあげてみます。(一部誤りと追記修正を含んでいます)
認証していない場合はあらゆるデータの読み書きを不可能にします。
これで、ログイン機能がなかったり、手動でログインしたりしなくても全てのユーザーが読み書きできるようになります。
Firebase ConsoleのAuthenticationの設定でログインできるホスト名を設定することができます。ここで本番のホスト名だけを認証可能にします。こうすることで、Firebaseの設定情報を使われてもデータにアクセスすることなどは不可能となります。
localhost等も当然消しておきましょう。開発時には別途開発用のFirebaseアプリケーションを用意し、そちらの設定を使ってください。ビルド時にはcross-envを使うと良いと思います。(誤りがあるので追記をご覧ください)
追記)
このホスト設定はリダイレクト用のため、匿名認証には利用できないようです。今のところ簡単に制限する方法はなさそうです。適切なセキュリティルールを設定してください。ルールの制限がないデータは今のところ他者に自由遊ばれる事ができてしまうのかもしれません…。良い情報があればぜひ提供をお願いします。
Firebaseのコンソールでなく、GCPコンソールの方で制限が必要そうです。詳しくは下記に書きました。
GoogleからAPIキーが公開されているよとアラートが来た
このように、匿名認証を入れることで本番でしかデータを扱うことができなくなり、セキュリティのベース部分の強化を行うことができます。(追記:前述の理由から、リダイレクトがないので本番以外でも扱うことはできるため、正しいセキュリティルール設定が必要です)
とにかく、設定情報が丸見えというのは非常に恐ろしい話です。当記事の話も鵜呑みにせず、しっかりと色々なパターンを考えセキュリティを強化しておきましょう。(むしろ間違っている話があればご指摘をお願いします)
Firebaseと連携するあらゆる処理をfunctionsに実装して設定情報は公開しないようにする、くらいの強固さで考えるくらいでも良いかもしれません。(認証の連携ができないので厳しいかもしれませんが)
Crieitは誰でも投稿できるサービスです。 是非記事の投稿をお願いします。どんな軽い内容でも投稿できます。
また、「こんな記事が読みたいけど見つからない!」という方は是非記事投稿リクエストボードへ!
こじんまりと作業ログやメモ、進捗を書き残しておきたい方はボード機能をご利用ください。
ボードとは?
コメント