The cost of falling victim to a DDoS or a similarly hostile act

[M]

So, while I love Firebase I can't help but feel a bit paranoid.

Looking through old Q&A's regarding Firebase, I have found that in the past they had burstable billing, where only the 95th percentile of usage were being charged. It seems, however, that this is no longer the case.

If I would be so unfortunate to be DDoS'ed, would that mean my bill would increase to an arbitrarily large figure until the attack stopped, as a result of unlimited, automated scaling?

And to the second part of my question. Let's pretend I have a Firestore collection called 'users' containing 10 million documents. Because my service has a feature where you can search for any given user, it is necessary to allow full READ permission. I might retrieve my search results like this:

firestore.collection('users').where('username', '==', 'George').get().then(snapshot => {
  // do stuff
});

That would cost me a single read. If someone, for kicks and giggles, decided to inject this into their browser client:

firestore.collection('users').get().then(snapshot => {
  // do stuff
});

That would cost me $6 (10,000,000 / 100,000 * 0.06) for 10 million reads. Why would someone do this? Maybe they want to run statistics on all usernames? It doesn't really matter. What worries me, is that someone this easily could run up my bills. I can easily imagine someone getting a kick out of making a Chrome extension that charges me $6 every time someone clicks it! Only a hundred clicks and I'm 

Set a monthly budget, you may say? That doesn't so much solve the problem, as it just sets a target for how long my attacker should go on until my service is dead for the remaining month; the work of a competitor perhaps? *puts on tinfoil hat*

To clarify the first part of my question: how are DDoS-attacks resolved? Both technically and billing-wise.

To clarify the second part of my question: if someone injects code and manually performs tens, or hundreds, of millions of reads, how does this affect my bills? Which precautionary measures have been made to avoid this? If any?

Is my paranoia unwarranted? Have I completely missed something? Answers are appreciated.

I understand that similar attacks also could be costly with a traditional LAMP setup. However, the difference is that the damage I am being done in that case is much less transparent, and depending on the setup, the service may just slow down and not increase the monthly bills significantly. And for excessive database reads, there are simply more hoops to jump through, whereas Firebase makes it incredibly easy.

[Juan Rubén Marrero Vizcaíno]

In the real-time db you can only read "/users/$uid" and not "/users/$another_uid" if you create appropriate database rules, and forcing your users to be authenticated, even if only anonymously. I'm sure firestore is the same.

This will at least slow down the hypothetical Dos attack

[M]

I specifically mentioned that my example included a feature to search for users, but perhaps it was a bad example.

Change the scenario to a collection called "stories" where each document is a blog post. Being an avid writer, I have written up 10 million blog posts. Surely you can see the need for a feature to search through these blog posts? That requires the security rules to grant full READ permission (that being both GET and LIST) to the collection "stories", which as mentioned, allows for the following:

firestore.collection('stories').get().then(snapshot => { /* DO STUFF */ });

This will perform 10 million read operations! Unless, as I asked, there have been put in some form of precautionary measures to avoid such a scenario.

[Juan Rubén Marrero Vizcaíno]

Using a public-facing, pay-as-you-go service for unbound consumption is not such a good idea; As you mention, storing millions of documents and reading them all, all the time *will* cost a lot of money.

I'm sure a lot of us share that same paranoia, since the chance for abuse is basically infinite, while our resources are not.

[M]

I suppose you are right that it is better to just avoid the whole thing, by locking it down.

A solution to my worries could be to use cloud functions. The client is only granted GET permissions, i.e. the client can only fetch a single specified document, whereas cloud functions will perform all other queries, e.g. search. This, of course, will mean higher costs, but perhaps it is worth the extra peace of mind.

[Brian Woodward]

You can also use algolia to enable full text searches. See this example for more information. You'll still be using cloud functions to send the documents to algolia, but it's only when the post is created or updated. This should be a lot lower costs than trying to get the entire list to search through.

[Kato Richardson]

+1, we have this approach documented in our Firestore solutions guide. Indexing the data and using a robust search engine is certainly more economical, robust, and secure than broad read access to your Firestore data.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/b68367fe-cae7-4ffd-a367-55251969b918%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Andrey]

But it's not only about full-text search. 

Any user readable/writable list has a potential for abuse.

Nothing can stop user from adding 1M records to that list and then read it multiple times, which will cost a lot of money.

I'm really excited about Firestore, but paying for reads and writes is some kinda terrifying.

It won't be the case if we can be assured that database can be accessed only through legitimate application, which use it appropriate.  

вторник, 7 ноября 2017 г., 1:10:42 UTC+3 пользователь Kato Richardson написал:

+1, we have this approach documented in our Firestore solutions guide. Indexing the data and using a robust search engine is certainly more economical, robust, and secure than broad read access to your Firestore data.

On Mon, Nov 6, 2017 at 9:47 AM, Brian Woodward <brian.w...@gmail.com> wrote:

You can also use algolia to enable full text searches. See this example for more information. You'll still be using cloud functions to send the documents to algolia, but it's only when the post is created or updated. This should be a lot lower costs than trying to get the entire list to search through.

On Monday, November 6, 2017 at 10:25:31 AM UTC-5, M wrote:

I suppose you are right that it is better to just avoid the whole thing, by locking it down.

A solution to my worries could be to use cloud functions. The client is only granted GET permissions, i.e. the client can only fetch a single specified document, whereas cloud functions will perform all other queries, e.g. search. This, of course, will mean higher costs, but perhaps it is worth the extra peace of mind.

On Friday, 3 November 2017 22:23:42 UTC+1, Juan Rubén Marrero Vizcaíno wrote:

Using a public-facing, pay-as-you-go service for unbound consumption is not such a good idea; As you mention, storing millions of documents and reading them all, all the time *will* cost a lot of money.

I'm sure a lot of us share that same paranoia, since the chance for abuse is basically infinite, while our resources are not.


El viernes, 3 de noviembre de 2017, 3:11:59 (UTC-6), M escribió:

I specifically mentioned that my example included a feature to search for users, but perhaps it was a bad example.

Change the scenario to a collection called "stories" where each document is a blog post. Being an avid writer, I have written up 10 million blog posts. Surely you can see the need for a feature to search through these blog posts? That requires the security rules to grant full READ permission (that being both GET and LIST) to the collection "stories", which as mentioned, allows for the following:

firestore.collection('stories').get().then(snapshot => { /* DO STUFF */ });

This will perform 10 million read operations! Unless, as I asked, there have been put in some form of precautionary measures to avoid such a scenario.


On Thursday, 2 November 2017 23:07:47 UTC+1, Juan Rubén Marrero Vizcaíno wrote:

In the real-time db you can only read "/users/$uid" and not "/users/$another_uid" if you create appropriate database rules, and forcing your users to be authenticated, even if only anonymously. I'm sure firestore is the same.

This will at least slow down the hypothetical Dos attack

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/b68367fe-cae7-4ffd-a367-55251969b918%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alan deLespinasse]

I've been sort of expecting a better response to this... maybe the Firebase team forgot to follow up?

For the "giant read operation" scenario, I don't know as much about Firestore, but with the Realtime Database, I'm pretty sure such a read operation would simply fail. There's a limit to how much data can be read at once. I'd think something similar would be the case with Firestore.

I'm used to thinking of all Google services as being practically immune to DDOS, but it's true that that's sort of scary when you can be billed for all activity.

[M]

Maybe they haven't thought it all through yet since it's still a beta and all? Or maybe they are just too busy. :)

I know I previously said "hundreds of millions of reads", however, that likely won't be possible (on a single request at least). "Maximum API request size" is set to 10MiB, meaning if each document only contains 100 bytes, you could maximally request around 100,000 documents on a single request. Though, maybe you could just loop through that request...

But I don't think there is any way around this when using services like Firebase... My real concern is the clear line of sight between an attack and the damage it does to me, due to the very specific pricing model.

I suppose the only way around this is if Firebase is still using some kind of burstable billing (and not telling anyone about it)? Honestly, I'd prefer if they would include burstable billing and just increase all the prices a bit and call it an insurance. More peace of mind...

[Mike McDonald]

[Firebase PM here]

Hey folks,

Apologies for the delays, Thanksgiving holidays in the US mean that this is the first day back in the office since the 22nd.

Here's a simple way to limit queries and provide some additional protection:

// index.js

firestore.collection('users').where('username', '==', 'George').limit(10).get().then(snapshot => {

  // do stuff

});

// firestore.rules

match /users/{userId} {

  allow list: if request.query.limit <= 10; // or whatever the maximum number of users you'd like to return is

}

We allow developers to write rules to verify static properties of requests (including the query properties, like limit, orderBy, etc.). These didn't get documented initially, but will be added shortly.

You can use Security Rules to limit a bunch of other things, including what properties are added to a document, the size/type/value of those properties, who is adding documents, etc. They're pretty powerful.

Thanks,

--Mike

[Alan deLespinasse]

That looks pretty awesome! I remembered that Firestore security rules were more flexible than Realtime Database (for example, I think you can allow a query on a collection without allowing full read of the whole collection), but this looks even better for preventing abuse.

I didn't think M's "they haven't thought it all through" theory seemed likely, from what I've seen of Firestore & what I know of Google's engineering in general... though the "they are just too busy" theory is always a possibility. :)

[M]

Now, that's exactly what I wanted to see! The property request.query.limit will certainly be useful.

[Mike McDonald]

Forgot to update this post over the holidays: here's the link to the reference docs where this is covered (go down to "query").

Thanks,

--Mike

[Carlos Tulloch]

I have 2 questions...
1. Can you achieve the same query limiting in the realtime database?
2. What does firebase CDN have in place to stop ddos attacks? What stops an attacker simply running the limited query 1 million times?

[Yulian Karapetkov]

I still don't understand how this could prevent someone from making your bill skyrocket. The fact that you can limit the number of reads per query doesn't mean that you can prevent a malicious user from running that same query a billion times.

[Kato Richardson]

Google infra has DDoS and similar protection which would prevent what you've described here; we don't want data centers crumbling because of abusive users. So at the point someone has the facilities to run "billions" of queries, they're going to run into limitations at the level of our load balancers and network infra. Not to mention that an attack of that breadth would require an intense amount of system resources and be cost prohibitive. If you experience something of this nature, please just reach out to support. It's not going to be isolated and you're not expected to handle attacks on our infrastructure. Running this without a host of servers would be time prohibitive--a billion is a big number.

But more realistically, there's probably some middle ground here where someone quite determined could abuse a small app and rack up a significant cost. If that happens, just reach out to support. (Hint: I created the credit policies; we'll help)

☼, Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/4abc12a0-2deb-4294-a063-7e4a56808807%40googlegroups.com.

[Erlangga Fauzan Rezaganie]

Thank you for your answer, im new with firebase thing i just wanted to know something

> what if i had web that show 10 last chat/docs with firestore rules limit , but someone just repeat the function every seconds ( i think its valid HTTP Request , since is not that spam ) and he just keep reload the chat 7/24 would that still cost so much ? 86400 * 10 * 1 client , what if we had 10 client ( using other account ) do samething ?  is there any way to prevent the bill ? if the options was to watch my bill closerly and use alarm everytime but still , when i got this i must shutdown my app if something like this happen ?

thank you

To unsubscribe from this group and stop receiving emails from it, send an email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/4abc12a0-2deb-4294-a063-7e4a56808807%40googlegroups.com.

[Nikos]

Any chance of the equivalent code for realtimeDB?

[Rachel Myers]

To limit the children returned from a node in the RealTime Database, you can use `.limitToFirst(N)` or `limitToLast(N)`. For rules, check the length of an array of the children: `".read": "data.hasChildren().length < N"`; I'd use the emulator to test edge cases.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/2e06476e-5dcf-4416-991f-8a62e84a91e4n%40googlegroups.com.