質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Firebase

Firebaseは、Googleが提供するBasSサービスの一つ。リアルタイム通知可能、並びにアクセス制御ができるオブジェクトデータベース機能を備えます。さらに認証機能、アプリケーションのログ解析機能などの利用も可能です。

Swift

Swiftは、アップルのiOSおよびOS Xのためのプログラミング言語で、Objective-CやObjective-C++と共存することが意図されています

Q&A

解決済

1回答

555閲覧

FirebaseFirestoreで匿名認証のセキュリティが不安

qyoeku

総合スコア25

Firebase

Firebaseは、Googleが提供するBasSサービスの一つ。リアルタイム通知可能、並びにアクセス制御ができるオブジェクトデータベース機能を備えます。さらに認証機能、アプリケーションのログ解析機能などの利用も可能です。

Swift

Swiftは、アップルのiOSおよびOS Xのためのプログラミング言語で、Objective-CやObjective-C++と共存することが意図されています

0グッド

1クリップ

投稿2019/08/17 15:37

チャットアプリの開発をFirestoreでしているのですが、デフォルトの「allow read write」だと危ないと知り、セキュリティルールの変更を検討しています。

あまり時間をかけられないので、とりあえず認証したユーザーにだけ許可したら大丈夫だろうと思っているのですが、認証は匿名認証でも大丈夫なのでしょうか?セキュリティについてはあまりよくわからないのですが、「攻撃を防ぐために匿名認証させるー>認証しているかで全ての読み取り、書き込みを許可」という方法は効果的ですか?

いちいちログイン機能をつけようとすると、もともと長かったアプリの初期設定がさらに長くなり、ユーザーが離れてしまうのが心配なので、匿名認証を使いたいのですが、可能ですか?

長くなってしまいましたが、よろしくお願いします

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2019/08/17 16:38

firebaseは「セキュリティについてはあまりよくわからない」人が手を出して良いサービスではありません。 Osushiの二の舞になる前にアプリ自体を即刻停止すべきだと思いますが。
qyoeku

2019/08/17 17:35

アプリはまだリリース前です。 初学者ですので恐縮ですが、具体的なセキュリティ上の問題などがあれば教えていただけると嬉しいです。 なお、個人情報や金銭などは扱っておらず、チャットも基本的にオープンなもの限定なので、osushiのような重大なリスクまではないと考えております。 その点も含めて、何が問題か・どういう対策が有効なのか教えていただけると幸いです。
guest

回答1

0

ベストアンサー

一般論として少しコメントします。
※ 私が正しいことを言っている保証もないので、鵜呑みにしないで自分でもう一度調べて考えられることをオススメします。

■ 技術的な必然

  • 単一の認証情報(ID/PW)をアプリに埋め込む場合、そのアプリの利用者は自由にその権限を(アプリの実装範囲を超えて)使うことができる可能性があることにまず注意しましょう
  • 逆に、ユーザが個別にユーザ作成・ログインを行う場合は、個別の認証情報が個々のアプリに残ることになるので、ユーザ毎に異なる権限を設定できる余地があります。(余地はあるが、適切に運用していないと当然意味はないですが)。

■ アプリケーション的な話

  • 誰が使うアプリなのか(家族しか使わないなら、単一の認証情報でも良いかもしれない→誰に何を見られても改ざんされても問題ない、とする。アプリも第三者に渡らないように管理する)
  • どういうデータを読み書きするのか(他人にばれたら困るような内容なのか)(秘密のルームが作れるべき、なら単一の認証情報だと難しいかもしれない)

→→ 例えば、「個人情報はかかないで下さい」とアプリでお願いしていても、書く人がいてそれの管理が不適切で漏洩などあれば、アプリ運用者の問題となることはありそう。


とりあえず認証したユーザーにだけ許可したら大丈夫だろうと思っているのですが、認証は匿名認証でも大丈夫なのでしょうか?

「とりあえず認証したユーザー」というのが何を指すのか次第ですが、それが「単一の認証をアプリに埋め込む」とすれば、
大丈夫かどうかは、上述の「アプリケーション的な話」次第かと思います。
1チャンネルのみのOpenなチャットで、全ての情報が全てのアプリ利用者に開示される仕様なら、問題ないかもしれないです。

「攻撃を防ぐために匿名認証させるー>認証しているかで全ての読み取り、書き込みを許可」という方法は効果的ですか?

これはどういう攻撃を防いでいるつもりかで、効果的かどうかが変わるでしょう。
何かしらのアクセス制御があれば「遊び程度のcracking」を防ぐ効果はあるでしょう。
ただ真面目にいたずらしようとしているケースに対応できるかは、
色々自分で攻撃の種類を想定して考える必要があります。

投稿2019/08/18 03:45

mokemokechicken

総合スコア948

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

qyoeku

2019/08/18 06:29

すみません、「単一の認証」というのは認証の3要素の一つでの認証という意味ですか?
mokemokechicken

2019/08/18 07:07

あー、「一つの認証情報」という意味でした。利用されるIDが一種類しかない、というようなものです。 アプリ固有のアプリに埋め込んだ唯一の認証情報みたいなものです。 ※ 特に定まった用語ではないです。(雰囲気で言葉を使いました)。 ※ 本人確認手段の数が1つ、という意味ではないです。
qyoeku

2019/08/18 07:45

なるほど。匿名の認証は攻撃を防ぐ上でどういう意味があるんですか?
mokemokechicken

2019/08/18 08:44

そこは色々考えてみてほしいのですが、 firebase匿名認証 https://firebase.google.com/docs/auth/web/anonymous-auth?hl=ja を見ると要するに、ゲストとしてログインする、ということだと思うのですが、(違うのかな?) - 少なくともゲストとしてログインするという権限がある人(≒アプリユーザ)のみが、ゲストアカウントを取得できる - そのゲストアカウントでのみ許される操作(読み書き、等)を実現できる ということになると思うので、 例えば、「Crawlerのような(そのアプリを全くしらない)適当なアクセスに対しては、効果的に制限できる」でしょうね。 でも もし「アプリを起動すると自動的にゲストアカウントが作成される」ならば、「そのアプリを自動操作したり、内部のゲストアカウント作成用の情報を抜き出されたりして悪用されると、無制限にゲストアカウントを作られて荒らされるかもしれない」ですね(そんなことをするかは別問題ですが)。 ※ ソーシャルゲームのリセットマラソンが簡単にできる、みたいな感じですかね...
mokemokechicken

2019/08/18 08:49

あと > 「匿名認証させるー>認証しているかで全ての読み取り、書き込みを許可」 となると、前述したように「(他人に対して)秘密のルームや会話などが(真の意味で)一切存在しないチャットアプリ」になりますね。
qyoeku

2019/08/18 09:08

なるほど、ありがとうございました。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問