「Firebaseの脆弱性で1億件超漏洩」の真相とは？ #Firebase #FJUG

tl;dr

開発者の責任
ただし，もう少しFirebase自身でも対策の余地があるのは確か

発端：某メディア記事

合計1億件以上の個人情報がFirebaseの脆弱性によって公開状態に
https://gigazine.net/news/20180625-firebase-vulnerability-data-loss/

このような記事が見受けられた．

一体どのような脆弱性だろうと当該記事を見てみると，このような表現が目につく；

データを適切に保護できないという脆弱性
Firebaseデータベースの認証が適切に行われていないときに顕在化
アプリ開発者によるデータ格納の保護が不完全なときに情報が露出

しかしこれらからは，サービス側の問題なのかアプリ開発者側の問題なのかが不明瞭である．

原文プレスリリース

そこで原文プレスリリースを確認してみると，このように記載されている；
https://www.appthority.com/company/press/press-releases/62-of-enterprises-exposed-to-sensitive-data-loss-via-firebase-vulnerability/

that occurs when app developers fail to require authentication to Google Firebase databases
not due to any code in the app, but to the app developers’ failure to properly secure backend data stores

だがここでも fail to や failure が「しない」だけでなく**「できない」とも解釈しうる**ため，責任の所在は確定できない¹．

しかし上述した通り「開発者がセキュアに保てない」と解釈すべきである可能性は否定できない．
屁理屈だ，文脈から解釈しろ，と思うかもしれないが， any code in the app がバックエンド側のセキュリティルールを含まない可能性は十分あるだろう．
何せクライアント側のアプリ内部のコードではなくバックエンド側のコードなのだから．

より厳密に言えば due to (any) code という表現も多義的である．
コードはただの文字列に過ぎない．
コードの実行系に問題があるという意味合いなのか，コードを書いた開発者に問題があるという意味合いなのか，曖昧である．

従ってこの一文で確かなことは言えない．

レポート

そのため詳細なレポートを紐解いてみる．
http://info.appthority.com/-q2-2018-mtr-download-Firebase-vulnerability

こちらでも同様に fail to を含む表現が散見され腹立たしいが，5ページに以下のような表現がある．

The result is a trove of data that is open to the public internet unless the developer
explicitly imposes user authentication on each individual table or directory.

開発者が細かく明示的にルールを設定せねば公開されてしまう，とのことで，やはり本案件は開発者の責任に過ぎないことがわかる．
とは言え，Firebaseのセキュリティ周りの現状に関する興味深い指摘も見られる；

Firebase does not secure user data by default nor are third-party tools available to provide encryption for it. And finally, Firebase does not provide security checkup reports to identify insecure data and potential vulnerabilities.

初期状態としてテストモード²かロックモード³か選ぶことは可能だが，ユーザデータなど細かい部分に関しては自分で設定せねばならない．

そしてセキュリティ状況を容易にチェックできるツールもない．
詳細さ厳密さを求めるのは厳しいにしても，どのデータ群が公開状態なのかなど表示させることは出来るのではなかろうか．

結論

上記のような指摘を踏まえると，フールプルーフ⁶ではないが，Firebaseのサービスとしても改善の余地があるというのは事実だろう．

しかしいずれにせよ，一般的に**「脆弱性」と言われた時のイメージとの相違があるのも確か**だろう．
この単語を断りもなくタイトルに付けるのはいかがなものかと思われる．

アンテナは敏感だがしばしばミスリードを誘発するGigazineと，誇大に不安を煽るというありがちなセキュリティ系企業，この二者によるコンボが決まってしまった案件であった．

余談

なお，当該記事公開当日にGigazineに問い合わせてみたものの，返答はまだない．

あとトマトイプーのリコピン⁷とかいうクソマンガクソ面白い．

　
　
#コミュニティ
Slackありますのでよろしければぜひ．
Firebase Japan User Group
Join our Slack!

　

週間Firebaseも始めました．

　

　

1. まさにGigazineがどっちともつかない翻訳をしてしまったのも，この表現によるものだろう．
   　
   ウェブ界隈では「"not due to any code in the app, but to the app developers’ failure to properly secure backend data stores"と書かれているから脆弱性ではない」という論調もある．
   確かに，「コードが原因ではなく開発者がバックエンドをセキュアに保たないのが原因」と読めば，そのような結論に落ち着くのも理解できる． ↩

2. すべての読み書きを許可する状態． ↩

3. すべての読み書きを拒否する状態．
   例えば，ユーザデータ保護に関してレコメンドすることは可能ではなかろうか．
   Cloud Firestoreでindexを張ることをレコメンドしてくれる⁴ように． ↩

4. エラーメッセージ内に専用のリンクを準備してくれる．https://firebase.google.com/docs/firestore/query-data/indexing
   　
   暗号化されていないというのも確かである．
   実はCloud Firestoreではサーバ側での暗号化は自動でなされている⁵が，セキュリティルールで許可されている場合は復号も自動でしてしまう． ↩

5. https://cloud.google.com/firestore/docs/server-side-encryption
   改善案として，クライアント側での復号も，SDKに内包する形であれば利便性損なわずに可能とは思われる． ↩

6. ユーザが誤っても安全に動作するようなシステムのことを指す．
   特にFirebaseは開発に注力できると謳っているため，セキュリティ面へのサポートがより充実しているべきとも言える．
   これらのような意味では広義の脆弱性ということも不可能ではない． ↩

7. http://www.shonenjump.com/j/rensai/lycopene.html
   　 ↩