I learned about the following article in the morning Twitter Space run by https://twitter.com/kuwahara_jsri:
https://blog.flatt.tech/entry/firebase_authentication_security
Listing and reviewing risks like this is important, of course, but I found several points that:
- Are not really about Firebase Authentication
- Seem to misunderstand the specs
So I want to reorganize them here. Listing risks alone is not very useful in practice; what matters is evaluating them and deciding whether to accept or mitigate each one.
Does IDaaS Create Vulnerabilities?
Introducing IDaaS can also create vulnerabilities. (omitted) Firebase Authentication has fewer configuration options than other IDaaS products.
Nothing written here is wrong. Still, I think the focus is a bit too narrow on implementation. When thinking about security, you first need a view of major security and privacy standards such as ISO 27018.
"If you decide not to use IDaaS, you obtain these certifications yourself, right?" is perhaps too big a leap, but before the small topic of implementation come personal-data governance (the Benesse leak comes to mind) and security around admin servers. IDaaS can introduce vulnerabilities, but I felt more attention should go to benefits beyond implementation code.
Self Sign-Up
The risks described here are exactly right. In internal systems I build, I sometimes rely on domain plus email_verified (email verified) or allow only pre-registered email addresses. Still, as the article says,
"No sign-up screen, so users cannot register"
is a vulnerability and should be mitigated.
In Firebase, the API key is not confidential information
This can be misleading, so let me clarify: the accurate statement is "Firebase provides a separate public API key and separate admin secret keys." As the article notes, self sign-up and similar flows are possible, but you cannot operate other people's accounts.
Pitfall 2. Users Can Delete Themselves
That is correct. Like self sign-up, there is a real risk that hitting endpoints directly with the public API key could let users delete themselves and create inconsistency in the application.
Pitfall 3. Registering Users with Someone Else's Email Address
Risk 3-1. Account takeover through mistyped email addresses
"Account takeover through mistyped email addresses" is not an "IDaaS vulnerability." It is a specification problem caused by skipping email ownership verification. Problems that could happen without IDaaS should be separated from issues specific to "because it is IDaaS" or "because it is Firebase Authentication."
Risk 3-2. Forcing someone else to send email
Regarding "mass spam sent through Firebase Authentication," Firebase Authentication implements quota management for sign-ups:
プロジェクトを不正行為から守るため、同じ IP アドレスでアプリケーションが使用できる新しいメールとパスワード、匿名での申し込みの数を制限しています。ここで、この割り当てを一時的に変更するようリクエストしたり、スケジュール設定したりできます。
So sign-up and anonymous registration should be controlled here. Password reset can still be abused as described, but the attack is mostly pointless because the victim clicks the reset URL and sets the new password themselves... Firebase also says it has other abuse countermeasures, as I mention later.
Suppose the application imposes no constraints on username length or character set.
The following is Firebase boilerplate, and the article focuses on the %DISPLAY_NAME% part:
件名
%APP_NAME% のログイン用メールアドレスが変更されました
メッセージ
%DISPLAY_NAME% 様
That corresponds to this documentation note:
重要: displayName や photoURL など、ユーザーに表示される可能性がある UI の値を設定（および後で表示）する際は注意が必要です。API は、潜在的な XSS タイプの攻撃を防ぐための値のフィルタリングを行いません。
https://firebase.google.com/docs/auth/web/manage-users?hl=ja&authuser=0
I tested it anyway:
updateProfile(user, {
displayName: '\n以下の URL からログインしてください。\nhttps://phishing.example/signin\n\n\n'
})
After changing displayName, the email I received looked like this (I changed the address):
以下の URL からログインしてください。 様
project-457600014723 のログイン用メールアドレスが info@example.com に変更されました。
メールの変更を依頼していない場合は、次のリンクをクリックして、ログイン用メールアドレスをリセットしてください。
Newlines and the URL were stripped. You cannot send a phishing email this way.
That is what I saw in my testing, but did this attack actually succeed in the original article??
Attackers can send phishing emails to victims.
I could not.
Combined with missing verification, this can escalate into sophisticated phishing.
I could not.
Example 3-2-2. An application that sends promotional email
Verify ownership (sending promotional email without ownership verification is the problem anyway, and Firebase Authentication is not involved)
Example 3-2-3. An application that can perform many email-sending operations in a short time
Verify ownership.
Risk 3-3. Bypassing access control based on email addresses
Verify ownership.
"Prevent users who have not verified their email address from logging in"
Let me explain the spec. Firebase issues a token to newly registered users, but even after authentication at that stage
auth.token.email_verified: false
So unless you treat "having a token" as logged in, they are not logged in. When integrating with a backend, you can always check email_verified. The original article also says:
By checking the email_verified property across every backend—Firestore, Cloud Storage, Functions, and so on—you can prevent users who have not completed email verification from using the application.
If that is your spec, it is obvious; leaks cause problems in any implementation, so calling this a Firebase Authentication risk feels off to me personally.
Pitfall 4. You Can Tell Whether a User Exists for an Email Address
Letting others know someone uses the service may harm the user.
That is exactly right. Like pitfalls 1 and 2, this shows up in Firebase Authentication traffic logs, so it is inherent to Firebase Authentication.
In a brute-force attack, narrowing to email addresses used by the application before trying email/password pairs reduces attempts compared with having no usage information.
This is awkward to comment on. Firebase Authentication mentions abuse as follows:
Firebase Authentication は、エンドユーザーの認証とエンドユーザーのアカウント管理に個人データを使用します。
また、セキュリティを強化し、サインアップや認証時の不正行為を防ぐために、ユーザー エージェント文字列と IP アドレスを使用します
So I do not read the spec as accepting every malicious brute-force attack.
There is a Stack Overflow thread like this:
https://stackoverflow.com/questions/50134344/firebase-auth-brute-force-attack-prevention
The Firebase Authentication service is monitored for abuse. Information about this monitoring and the actions taken on detected abuse is seldom documented though, since the information changes regularly and would be more helpful to abusers than to most developers.
If you think your use-case is being affected by this monitoring or the actions taken upon it, reach out to Firebase support with clear details (i.e. code)on what you're trying to do, and what behavior you seeing.
Google翻訳:
Firebase認証サービスは不正使用がないか監視されます。ただし、この監視と検出された不正使用に対して実行されたアクションに関する情報が文書化されることはめったにありません。情報は定期的に変更され、ほとんどの開発者よりも悪用者にとって役立つためです。
ユースケースがこのモニタリングまたはそれに対して実行されるアクションの影響を受けていると思われる場合は、Firebaseサポートに連絡して、何をしようとしているのか、どのような動作が見られるのかを明確に説明してください（コードなど）。
I cannot cite more sources than that, but I wonder how thoroughly the article verified wording like "up to 30,000 login attempts per minute from the same IP address are allowed" (if Firebase support confirmed that even suspicious IPs are fully allowed up to 30,000 attempts, I apologize)
Pitfall 6. Weak Password Composition Requirements
Passwords only need to be six characters or longer, so even simple passwords like aaaaaa are allowed.
Of course you should add your own frontend validation, but like pitfalls 1 and 2, it is true that someone can read the public API key and use curl to set a weak password. Whether users who go that far should be treated as a risk is debatable...
Pitfall 7. Distinguishing Auth Providers Enabled for Different Purposes
As the article says.
Summary
Looking at it this way, the one spec-level issue that can be inherent to Firebase Authentication is:
- Client operations are possible with the public API key and curl
These likely fall under that:
- Self sign-up
- Users deleting themselves
- Verifying that a user exists
- (Weak passwords being set?)
One thing to confirm: all of these tie back to the public API key. If that is fatal for your product, you should not touch Firebase Authentication from the frontend; you need your own backend in between.
Still, implementing authentication while complying with privacy laws and, for overseas expansion, GDPR is very hard today. Personally, I hope more teams adopt IDaaS when it fits.
See you next time.