3 ms·

This kinda happened with Netlify recently (https://www.reddit.com/r/webdev/comments/1b14bty/netlify_just_sent_me_a_104k_bill_for_a_simple/ https://www.reddit.co

by mdasen 2y ago

This kinda happened with Netlify recently (https://www.reddit.com/r/webdev/comments/1b14bty/netlify_just_sent_me_a_104k_bill_for_a_simple/ https://www.reddit.com/r/webdev/comments/1b14bty/netlify_jus..., https://news.ycombinator.com/item?id=39520776 https://news.ycombinator.com/item?id=39520776). They got a bill over $100,000 via spam requests. Unauthorized requests are a weird thing. They still do cost money for a web service to handle and if you (the customer) have screwed things up that's kinda on you. I've run SaaS where a customer forgot to send their key and their software would just keep retrying requests to the point that they were sending thousands of requests per second with no key. However, it's kinda crappy when it's happening through no fault of your own. One doesn't even have to make unauthorized requests to run up a bill. One can simply make lots of spam requests to a real file in a bucket - run up the request total and bandwidth at the same time.

margalabargala 2y ago
> Unauthorized requests are a weird thing. They still do cost money for a web service to handle and if you (the customer) have screwed things up that's kinda on you. Who pays when the unauthorized requests contains truly random data, i.e. they point at an org and bucket that do not exist? Amazon does. Part of their cost of doing business is building the infrastructure that routes authorized requests correctly, and if a request is for invalid data, it's dropped. That should be par the course. Large numbers of unauthorized requests can be effectively considered a DDOS on the service itself. That the attacker can add a note onto their attack that says "btw bill X customer for all this" and have that honored is ridiculous.
yencabulator 2y ago
> They still do cost money for a web service to handle and if you (the customer) have screwed things up that's kinda on you. They cost a lot less than a multiple disk write (PUT), a disk read (GET). They cost the same to AWS whether the target bucket belongs to me, Amazon themselves, or does not exist. And in this case, the customer definitely didn't "screw things up". Charging for unauthorized requests is just weird and customer-hostile. Like, how am I supposed to prevent that? I get that a service provider might want to "punish" a customer who misconfigures their systems and DoSes themselves with e.g. no backoff on 403 error, but I find it hard to believe that that's the common case -- and how is typo in authentication supposed to be so different from typo in bucket name?

by mdasen 2y ago

margalabargala 2y ago

> Unauthorized requests are a weird thing. They still do cost money for a web service to handle and if you (the customer) have screwed things up that's kinda on you. Who pays when the unauthorized requests contains truly random data, i.e. they point at an org and bucket that do not exist? Amazon does. Part of their cost of doing business is building the infrastructure that routes authorized requests correctly, and if a request is for invalid data, it's dropped. That should be par the course. Large numbers of unauthorized requests can be effectively considered a DDOS on the service itself. That the attacker can add a note onto their attack that says "btw bill X customer for all this" and have that honored is ridiculous.

yencabulator 2y ago

> They still do cost money for a web service to handle and if you (the customer) have screwed things up that's kinda on you. They cost a lot less than a multiple disk write (PUT), a disk read (GET). They cost the same to AWS whether the target bucket belongs to me, Amazon themselves, or does not exist. And in this case, the customer definitely didn't "screw things up". Charging for unauthorized requests is just weird and customer-hostile. Like, how am I supposed to prevent that? I get that a service provider might want to "punish" a customer who misconfigures their systems and DoSes themselves with e.g. no backoff on 403 error, but I find it hard to believe that that's the common case -- and how is typo in authentication supposed to be so different from typo in bucket name?