あなたのプロダクトにも脆弱性が!? Flatt Securityが「Firebase」のセキュリティを重要視するワケ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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