あなたのプロダクトにも脆弱性が!? Flatt Securityが「Firebase」のセキュリティを重要視するワケ
eye
あなたのプロダクトにも脆弱性が!? Flatt Securityが「Firebase」のセキュリティを重要視するワケ
やぎこ
2021.05.05
この記事でわかること
Firebaseのセキュリティ対策はまだ体系化されておらず、学習が難しい状況が続いている
Firebaseプロジェクトの脆弱性を突かれると、気付かないうちに情報を盗まれたり、データを改ざんされてしまうことも
セキュリティ対策も一度原理原則を学習しておくと応用が効き、最終的にコスパがいい

バックエンドの構築を最短化することができることで有名な、GoogleのFirebase

煩わしいサーバーの構築をスキップし、目的のウェブアプリケーションやモバイルアプリケーションを構築できるmBaaS(mobile Backend as a Service)と呼ばれる類のクラウドプラットフォームです。

しかし、その便利さの陰で見逃されがちなのが、セキュリティ。 手軽な開発を進められるその裏で、世に生み出されたプロダクトにはFirebase特有の脆弱性が大量に潜んでいることをご存知でしょうか?

今回はFirebaseにまつわる脆弱性や、Firebaseを用いるうえで実際に気を付けるべきセキュリティについて、Flatt Securityにて執行役員を務める豊田恵二郎さん、セキュリティエンジニアの梅内翼さん・ぴざきゃっとさんの3名へお話を伺いました。

image

セキュリティ診断を受けるベストタイミングは、プロダクトの「設計」段階!?

やぎこ

Flatt Securityさんといえば先日Firebaseにおけるセキュリティについての記事がバズっていましたよね。

Firebaseにおけるセキュリティの概要と実践
Flatt Security 豊田さん

そうですね、予想以上の伸びだったのでFirebaseのセキュリティに関する情報の需要を感じました。

やぎこ

私も読ませていただきましたが、Firebaseのセキュリティについて非常に整理されており、すごく読みやすかったです!

やぎこ

そんなFlatt Securityさんが提供されているサービスは「セキュリティ診断」とのことですが、セキュリティ診断って具体的にはどんなことをしているんでしょうか?

Flatt Security 豊田さん

Flatt Securityが提供している診断では、調査依頼されたアプリケーションやクラウド環境をセキュリティエンジニアが自らの手でチェックし、脆弱性がないかを調べています。

Flatt Security 豊田さん

具体的には、よくある脆弱性のようなものをリストにしておいて、それぞれについて実際にハッキングと呼ばれるような行為が成功するかをエンジニアがテストしていく作業をしていますね。

やぎこ

「診断」って言うと、単にソースコードを眺めて終わりというイメージがあったので、そこまできっちりやっているのは正直少し意外でした。

Flatt Security 梅内さん

中には攻撃用のコードを自動的に実行するスキャンのみの診断もありますが、弊社では基本的に手動による診断を提供しています。 また、世の中で提供されている診断の多くはソースコードを読むことは行わないブラックボックス診断と呼ばれるものですね。

やぎこ

診断の中にもいくつか種類があるんですか?

Flatt Security 梅内さん

そうですね。 一般的に、セキュリティ診断にはブラックボックス診断とホワイトボックス診断の2種類があります。

Flatt Security 梅内さん

ホワイトボックス診断は、普通のユーザーからは見られないような、例えばお客さんのソースコードのような情報をもらってアプリケーションの仕様と実装の差異がないかをテストしていく作業です。

Flatt Security 梅内さん

一方、ブラックボックス診断は、一般のユーザーから見える範囲の情報を手掛かりにして、裏側の環境がどうなっているのかを一切知らない状態で攻撃を仕掛けてみるテストになります。

boxtest
Flatt Security 豊田さん

基本的にFlatt Securityとしては、隅から隅まで見れるということでホワイトボックス診断をオススメはしているんですが、工数は増えるので必然的にお値段も高くなってしまいます。そこはお客さんとの相談ですね。

Flatt Security 豊田さん

ちなみに、弊社のセキュリティ診断では20~30万円程度のお値段から診断可能なエントリープランもご用意しています。

やぎこ

どういった経緯でエントリープランを用意されたんですか? どうせ診断してもらうなら、高くてもきっちりテストしてもらわないとあまり意味がない気がしますが…。

Flatt Security 梅内さん

アプリケーションの仕様策定や設計の段階からライトに相談していただきたいんです。 もしやぎこさんがセキュリティ診断を受けるとしたら、開発のどのタイミングで受けますか?

やぎこ

私だったら、リリースの直前に診断を受けます。 万が一リリース後に攻撃されて問題が起きたら怖いですし。

Flatt Security 梅内さん

まさにやぎこさんがおっしゃったとおり、セキュリティ診断を受けるタイミングとして最も多いのがプロダクトのリリース直前なんです。 でも、このタイミングだと手遅れなことがあるんです。

やぎこ

え、でもまだ攻撃されてないですよね…? パッチを当てれば大丈夫なんじゃないですか?

Flatt Security 梅内さん

前提として、セキュリティ対策は実装がある程度進んだ段階やリリース直前ではなく、仕様策定や設計の段階から取り組んでいくことが好ましいんです。 セキュリティを全く意識していないプロダクトだと、リリース直前に診断しても「設計が間違ってるので一から作り直してください」としか言えないことがあります。

Flatt Security 梅内さん

多少セキュリティが意識されていても、大量に脆弱性が見つかった場合には、作り直してもらってもまた新しい脆弱性が出てくることがあります。 リリース直前になって即座に修正することが困難な脆弱性が存在すると、我々も具体的な対策を提案することが難しくなってしまいますし、お客さんにとっても仕様の見直しや実装の修正といった作業が大きな負担になってしまうんです。

やぎこ

やっと完成した!と思ったらまた根本から設計や実装をやり直すことになるのはめちゃくちゃ辛いですね…。

Flatt Security 梅内さん

だからこそ仕様策定の段階からエントリープランでセキュリティの診断をしていただければと考えています。 もちろん、エントリープランは今お話ししたような仕様策定や設計の段階でなくとも利用可能ですし、すでに開発が完了しているプロダクトであっても可能です。

Firebaseを使用したプロダクトには、特有の脆弱性がある

やぎこ

Flatt SecurityさんはこれまでにいくつものFirebase診断をおこなわれていますよね。 Firebaseを用いた開発では、どんな脆弱性が多かったんでしょうか?

Flatt Security ぴざきゃっとさん

例えばFirebaseの中には、認証に関するAuthenticationというサービスがあるのですが、これが案外くせ者です。 基本的には、ドキュメントに書いてあることは何でもクライアント側でできるようになっており、色々なことができてしまいます。

Flatt Security ぴざきゃっとさん

具体的には、「自己サインアップ」という機能を不正に使うことで、開発者が意図しないアカウントを作成できてしまったりします。

やぎこ

「自己サインアップ」ってなんですか…?

Flatt Security ぴざきゃっとさん

Firebase AuthenticationのAPIを直接叩くことでアカウントを作れるのですが、これを自己サインアップと言います。

Flatt Security ぴざきゃっとさん

なので、例えば有料の会員制サービスなんかでは、お金を払ってないユーザーが勝手にアカウント登録して、お金を払わずにコンテンツを閲覧したり有料機能を使ってしまう、なんてことも……。

やぎこ

サービス自体へのダメージもさることながら、売上が過剰に報告されて経営上の判断に支障がでてきそうなのも怖いですね…! 他にはどのような脆弱性があるんでしょうか?

Flatt Security 梅内さん

Firebaseの中にはFirestoreというNoSQL型のデータベースサービスもあるのですが、ここに格納するデータのバリデーションルールを適切に定義しておかないと、不正なデータを作成されたり、既存のデータを改ざんされてしまったりします

Flatt Security 梅内さん

これを利用すると、※インジェクション攻撃のように仕様に反するデータをFirestoreに格納させたり、ECサイトであれば架空注文のようなことができてしまったりしますね。

※インジェクション攻撃: 悪意のあるデータやコード、リクエストを送ることにより、サービス運営者の意図しない挙動を引き起こす攻撃

やぎこ

サービスの規模にもよりますが、ヘタすると年収より大きい金額が吹っ飛んでいきそうで怖いですね…!

Flatt Security 梅内さん

あと、実はよく知られていないバリデーションの制約みたいなものもあって。 Firestoreには、今のところドキュメントに含まれるリスト型のデータを検証する方法はほとんどないんですよ。

やぎこ

そうなんですか!? それを知らずにリスト型のデータを多用するとまずいことが起きそうですね…。

Flatt Security ぴざきゃっとさん

また、HostingではHTTPヘッダーの設定漏れで※クリックジャッキングが起きてしまうこともありますね。 これは、通常のページが他のページへフレームとして不正に埋め込まれてしまい、ユーザの誤ったクリックが誘導される攻撃のことです。

clickjack
※クリックジャッキング: 攻撃者が用意したサイトの上に透明な通常のサイトを重ねることで、ユーザの意図しないクリックを誘発することIPAのサイト例
Flatt Security ぴざきゃっとさん

あとは、デプロイするファイルの設定が漏れてしまうと、ユーザーに公開する必要のないソースコードやドキュメントが紛れ込んだりしてしまうこともあります。 一時期有名になった、サービスのパスに.gitをつけるとGitのファイルが見える、というようなものですね。

やぎこ

なるほど。 FirebaseはなんとなくGoogleのサービスだからといって安心しがちですが、意外に落とし穴が多いんですね。

Firebaseを用いたプロダクトに脆弱性が目立つのは、「ドキュメント不足」と「機能要件重視」が原因だった!?

やぎこ

そういえば、そもそもどうしてFlatt SecurityさんはFirebaseのセキュリティに注力されているんでしょうか?

Flatt Security 豊田さん

一番大きな理由は、Firebaseを用いたプロダクトに脆弱性が目立つからですね。 もちろんどんなサービスにも脆弱性があるはあるんですが、特にFirebaseに関しては対策が適切に行われていな場合も多いです。

やぎこ

なるほど。 ちなみに、今まで見てきたFirebaseのプロダクトの中だと、どのくらいの割合で脆弱性があったんですか?

Flatt Security ぴざきゃっとさん

基本的にほぼすべてのものに脆弱性がありました。 それも攻撃されるとサービスの継続が困難になるような脆弱性が少なくなかったですね。

やぎこ

ほぼすべて……!? 恐ろしい状況ですね…。

Flatt Security 梅内さん

私のほうでも、脆弱性が存在しないケースはなかったですね。 Firebaseはマネージドサービスなので、例えば「特定のリクエストを大量に送るとサーバがダウンする」といったサービスの基盤を脅かすような脆弱性はあまり考慮しなくてよいのですが、逆に先述したFirebaseならではの脆弱性が多いので、注意していただきたいと考えています。

やぎこ

開発者のみなさんが思っているより状況は深刻なんですね…。 なぜ、Firebaseを使った開発で脆弱性が生まれてしまいやすいのでしょうか?

Flatt Security 梅内さん

一番大きいのは、Firebaseはまだ若い技術であり、セキュリティを確保するための方法論が確立されていないことだと思います。 AWSやGCPのような他のクラウドサービスではセキュリティのベストプラクティスがリファレンスとして出ていますし、書籍の数も少なくないです。

firebase
「Firebase セキュリティ」と検索すると、Googleによる公式ドキュメントの次にFlatt Securityさんのブログが出てくる
やぎこ

たしかにAWSやGCPのセキュリティ関連の本はAmazonでもよく目にしますし、セキュリティルールに対する言及もTwitterでよく流れてきますね。

Flatt Security 梅内さん

それにもかかわらず、設定ミスなどを起因とするセキュリティインシデントが相次いでいるのが現状です。 AWS・GCPですらこのような状態ですので、Firebaseも当然セキュアに使われているとは言えないでしょう。

やぎこ

Firebaseを使ったアプリケーションをセキュアに保つのは難しいんですね。

Flatt Security 梅内さん

もちろんFirebaseでもリファレンスや実装例などのリソースは複数存在するので、それを適切に参照した上で設計や実装に取り組めば、セキュアなアプリケーションを作るというのは不可能ではないです。

Flatt Security 梅内さん

ですが、リソースの量が少ないのと、リファレンスの奥の奥まで読まないと使えない機能があったり、コーナーケースでどのような挙動になるのかのようなナレッジが広く浸透していなかったりするのは結構大きな問題ですね。

Flatt Security ぴざきゃっとさん

FirebaseのセキュリティルールはFirebase特有のDSL(Domain Specific Language; ドメイン固有言語)を使って定義するので、慣れた方法でルールが書けずに、そこでバリデーションの不足とかも起きやすくなってるのかなと思います。 アプリケーションの仕様に沿ってルールを書くのって結構難しいんですよね。

Example of security rule of Firestore
Firestoreのセキュリティルール例(公式ドキュメントより)。DSL(ドメイン固有言語)とも呼ばれるような、Firebase特有の言語で記述されている。
Flatt Security 梅内さん

他にも、Firebaseってデフォルトの設定が一部を除いて本当にまっさらになっているので、何も気にせずに使っているとセキュリティを確保するための機能が全部オフになっていた、なんてこともあったりします。

Flatt Security 梅内さん

そして何よりも怖いのは、Firebaseにはアクセスの履歴などを保持しておくロギングの機能があまり整備されていないことですね。 そもそも攻撃を受けてるのか受けていないのか、どんなデータを読まれたり書き込まれたりしているのか、こういったことを知るのが難しいんです。

Flatt Security 梅内さん

なので、セキュリティルールをきちんと設定しないまま運用していると、知らぬ間に権限を持たない第三者にデータを読まれていたり、仕様に反するデータを作られてもそれに気付かなかった、なんてこともあり得ます。

やぎこ

ずっと前から自分のサイトが悪用されていたり情報が漏れていたりしたのに、それに気づかなかった……なんてこともあり得るんですね。 それは恐ろしい……。

Flatt Security 梅内さん

また、これはあくまで予想なんですが、Firebaseは個人開発やスタートアップで選ばれることが多いのも脆弱性が多い要因だと思います。

Flatt Security 梅内さん

大規模なクラウドを使うのではなくて、早くMVP(Minimum Viable Product; 要件を満たした最小規模のプロダクトのこと)を作れる、みたいなスピード感を背景にFirebaseはよく使われていますよね。

やぎこ

そうですね、私も個人開発でFirebaseを採用したことがありますが、それも手軽にWebサービスが作れるからでした。

Flatt Security 梅内さん

そういった環境だと、どうしても機能要件が重視されてしまって、セキュリティのような非機能要件が無視されやすいのかなと感じています。 セキュリティはどれだけ意識してもビジネス上の利益に繋がることはないですから。

セキュリティ対策に必要なのは「学習」+「経験」

やぎこ

とはいえ、個人だったり数人規模の小さな開発だと、なかなかセキュリティにまで手が回らないという現実もあったりしますよね。 そんな中でも、開発者が心がけるべきポイントってありますか?

Flatt Security 豊田さん

まずはセキュリティに関するスキルや知識を身に着けていただくのが先決かなと思います。 様々な学習に共通することですが、セキュリティも一度原理原則を学習してしまえばあとはいろいろと応用を効かせることが可能だと思います。

Flatt Security 豊田さん

もちろん学習するコストはかかってきてしまいますが、どんなにリソースが不足していても、最低限はセキュリティを確保して欲しいというのが本音です。 何か事が起きてから対処するほうがコストは膨れ上がりますし、まず最低限問題の無いところまでセキュアに保つというのは、サービスを公開するうえでの責務と捉えていただきたいなと。

やぎこ

一度学習してしまえばその後の運用コストはそこまでかからないんだから、とにかくちゃんと学習しておけ、みたいなところなんですかね。

Flatt Security 豊田さん

はい。やっぱり、知るということはめちゃくちゃ大事だと思うんですよね。 セキュリティを知らないと、「こういうことが起きてしまうんだ」みたいなものがそもそも分からない状態だと思うので。 でも、何が起こり得るのかを自覚したら、「リソースを割けない」とか、もはや言ってられないようになりますし。

Flatt Security 豊田さん

Flatt Securityでも、セキュリティの学習サービスとして、ハンズオン形式の「KENRO」をリリースしました。 脆弱性が含まれたソースコードをこちらから配布して、それを直してもらう「堅牢化演習」などを通じて、セキュリティについて学んでいただけます。

kenro
堅牢化演習の実際の画面。脆弱性の含まれたソースコードを修正してアップロードすると特許出願中の技術によりテストが実行され修正結果が判定される。
Flatt Security 梅内さん

セキュリティはプロダクトの機能拡張に対して直接的に貢献するものではありません。 いくら勉強してもプロダクト開発に直結する知識やスキルが得られるわけではないですし、「マイナスをゼロにする」みたいな作業であると考えられがちです。

Flatt Security 梅内さん

ですけど、最低限絶対に必要なものであるのも事実です。 いわゆるDevSecOpsのような、まず仕様策定の段階からセキュリティのことを考えるプロセスを踏んでいけば、後々のコストはそこまでかかってこないのかなと。

Flatt Security 梅内さん

加えて、セキュリティに関する設計や実装を積極的に進めていくことで、気付きにくい仕様の漏れを発見したり、システムの設計をよりクリーンにできたりするといった副次的な効果もあります。セキュリティは、単に「マイナスをゼロにする作業」ではないのです。

やぎこ

なるほど……。でも、実際にどうやってセキュリティのことを学習するか、というのは大きな課題ですよね。

Flatt Security 梅内さん

そこはFlatt Securityでやっている「KENRO」もそうですし、Firebaseに絞らなければたくさんリファレンスとなる本も出ているので、そちらを参照していただければいいのかなと。

Flatt Security 梅内さん

とはいえ、やっぱりセキュリティって体系的に学習するのが難しいジャンルではあるんですよね。 結局のところは経験をコツコツ積んでいくしかないのかもしれないです。

セキュリティを学習し、「我が子」を守ろう

やぎこ

今までのお話を伺っていると、Firebaseって実はけっこう危ないサービスなのかな?と思ってしまうのですが、そのあたりどうなんでしょうか。

Flatt Security 梅内さん

いろいろ言ってしまったんですけど、やっぱりFirebaseは素敵なサービスだと思っていて。 アプリケーションを簡単に、しかも結構大規模に作り込むことができるというのは本当に素晴らしいです。

Flatt Security 梅内さん

ただ、やっぱりセキュリティというところは無視できなくて、その素敵さを壊さないように、セキュリティのことを学習していただいたり、心の隅に置いておいていただければいいのかな、と。

Flatt Security ぴざきゃっとさん

最近はSNSなどで突然注目されて、突然攻撃の的になってしまうみたいなプロダクトも多いので。 自分のプロダクトを愛している方には、セキュリティのことも少し考えてみていただきたいですね。

Flatt Security 豊田さん

まさに我が子を守る両親の気分で、道路に飛び出しそうになってたら連れ戻す、みたいなレベルの話なんだと思います。

やぎこ

そう言い換えると、プロダクトへの愛があるからこそセキュリティに気を遣ったほうがいいんだ、というのは本当によく分かりますね……。 本日はとても勉強になるお話をありがとうございました!

Flatt Securityでは、Firebaseをはじめとする各種プロダクトのセキュリティ診断をおこなっており、エンジニア向けeラーニングサービス「KENRO」が4月13日より正式リリースされました。

また、Flatt SecurityさんのWebサイトではFirebase診断の専用メニューが紹介されています。

Firebaseのセキュリティが気になる方は、ぜひご一読ください!

ライター

やぎこ
某首都圏の国立大学で農学専攻の22歳。Webエンジニアとライターで4年くらい個人事業主。 最近は「けいおん!」「ウマ娘」と音響・撮影機材いじりがマイブーム。 お仕事では主にPHPとJavaScriptをがんばってます。
やぎこの記事一覧を見る
Twitterをフォローしよう!
アンドエンジニアの公式LINEができました! ピッタリの記事や役立つ情報が届きます!

編集部オススメコンテンツ

eyecatch_visual_coder
Adobe製品を使わない"デザイナー"?「ビジュアルコーダー」が考える、自己満足で終わらないWebデザインとは
三角
2020.06.16

アンドエンジニアへの取材依頼、情報提供などはこちらから

お問い合わせ・情報提供
この記事をシェア
Twitter
Facebook
LINE
Hatena
アンドエンジニアの公式LINEができました! ピッタリの記事や役立つ情報が届きます!

編集部おすすめコンテンツ

アンドエンジニアへの取材依頼、情報提供などはこちらから