Critical Bubble Vulnerability (Terms of Service Violation) They Don't Seem To Care Enough About

Bugs
1

I was working on my PDF Merger plugin, trying to add backend support. This entailed needing a way to upload merged files to the database. I stumbled across @aaronsheldon 's post (Native File Operations in Server Actions) explaining the process. In it, he describes how, to upload a file, you must make a POST request to the Bubble.io application’s home url, at the “/fileupload” endpoint.

I wanted to test my plugin in something easier to debug (the plugin editor is atrocious) so I was working with the code locally and using python and Postman to test things out.

Upon trying this in Postman, without ANY authentication, I was able to upload files to my application… At first, I thought Postman was using the session cookies from my browser to authenticate, so I logged into a remote server, and in python, tried the exact same functioning code to post the request. And it worked… without ANY authentication. This is a remote Ubuntu server, i.e. not the Bubble backend.

This is a huge “Unrestricted File Upload” vulnerability. Essentially, anyone can upload any files to any Bubble application, all they need is its URL.

Any malicious actor could (theoretically) send hundreds of file uploads to your application, quickly draining all of your database storage. Then, any file upload/create workflows on an application would fail, severely impacting your applications and associated business with them.

I immediately wrote to the Bubble support team to fix this. This needs to be patched. They don’t seem to care:

Screen Shot 2022-07-30 at 1.59.04 PM
Screen Shot 2022-07-30 at 1.59.04 PM2210×1204 300 KB

For the amount Bubble costs, and their controversial decision to begin cracking down on database storage (which we pay an arm and a leg for), the ability for anyone in the world to flood and fill my database is absolutely absurd.

They need to limit that endpoint to internal servers/same origin only.

I wasn’t going to post about this until it was patched, but they don’t seem to want to patch it, and it needs awareness and outrage in order for them to patch it.

Violation of their own Obligations:
This likely violates Bubble’s own obligations under the Terms of Service:

Bubble will employ industry-standard technical, logical, and physical security measures and practices for the Platform and any Bubble systems on which Direct User Content (as defined in Section 5(a)) is stored or processed designed to preserve the security and integrity of, and prevent unauthorized access to, the Platform, Bubble Sites, and Direct User Content.

@emmanuel there is no way this type of vulnerability is an “industry-standard… security measure”.

“prevent unauthorized access to” is pretty clear…

12 Likes
2

Hi @nicholasrbarrow,

This is concerning

Maybe email security@bubble.io? They might have a different team to investigate security concerns rather than the support email

3

Just forwarded everything to this email, thank you… that response came from their Bug Submission team, and from that reply, it is clearly something they’ve known about. Only posted to spread awareness and hopefully enough pressure to get them to finally fix it.

1 Like
4

More on why this is very bad:
The ability for someone to spam our database with file uploads creates headaches.

  • we can only view 50 files in the web version at a time, without having to click “load more” every single time

  • while I know how to code and use APIs to (theoretically) delete malicious uploads a lot faster, 95% of bubble users do not (the fact that they use a no-code platform is testament to their knowledge of more complex software engineering)

  • if a malicious actor were to spam 1 KB files to my database, on Bubble’s entry-level 20 GB storage plan, that is 20,000,000 files that they could potentially upload

  • no user should have to click “load more” the amount of times it would take to delete those 20,000,000 files

5 Likes
5

@emmanuel this needs more attention than your team is willing to give it.

7

Yes, this has come up before (more than once), and I have notified them as well with basically the same response. They said to just let them know if I suspect my app’s storage is being hijacked.

Another user reported a client’s app failing a penetration test due to this issue, but still the same response from Bubble.

I intentionally did not post to the forum precisely because I didn’t want to publicize the issue too widely.

BTW, it’s important to emphasize that this issue is purely a storage related issue and not a security issue in the sense that a non-authenticated party could access protected (private) files in your Bubble storage. Rather, as you point out, it just enables a bad actor to eat away at your storage.

It’s not clear to me that this issue would be straightforward to monitor and/or combat in an automated proactive manner, so I feel it should be a priority for Bubble to address.

2 Likes
8

@sudsy I agree, I didn’t want to publicize it, but seeing as they repeatedly declined to fix it or even take it seriously, I posted about it to hopefully force an actual response.

I also agree that they need to make this a priority to fix!

9

Thanks for let us know.

Indeed, this is very concerning. Please let’s keep this post up until someone at Bubble sees it.

And please keep us updated about their feedback!

1 Like
10

I don’t mean to belabor this issue, but I did want to address a couple things so as not to cause undue concern or confusion for anyone stumbling upon this thread…

It seems as though you might be conflating Bubble’s file storage with database storage. They are in fact two completely different things.

Every Bubble app has some AWS storage allocated for holding uploaded files, and this issue relates to the potential for an outside party to use up some of that file storage quota. This issue has no impact whatsoever on a Bubble app’s database.

To be fair, I don’t think Bubble is not taking it seriously. It’s a deep-rooted issue and not a “quick fix”. I’ve no doubt it’s in their internal issue tracker to be addressed when it’s feasible. Like you, I’d prefer to see it resolved sooner rather than later, but there are presumably technical reasons a quick fix isn’t feasible.

Lastly, I wanted to point out that the file upload endpoint in question is neither officially documented nor supported by Bubble. A better way to upload a file via POST request is to create your own endpoint via backend workflow. I’ve done this for both image and file data types. This post might be helpful.

1 Like
11

@sudsy you’re differentiation is correct… AWS is not a literal database, and I should’ve been more clear that the “file manager” is nothing more than a man-in-the-middle provided by Bubble to accessing that storage provided by Amazon. However, it may have no impact on Bubble’s database (which seems to have unlimited storage size), it does have a very real impact on the 10GB+ limit on the AWS/“File Manager” storage. Exhausting this storage causes workflows creating additional files to fail, so clearly it does have an impact on the overall usability of (paying) customers’ applications.

I wish I could agree that Bubble is taking it seriously. Between three emails with the support Rep, they repeatedly downplayed this very-real vulnerability that is a clear breach of their terms of service in terms of their obligations to their paying customers.

This is true that it is not documented, but out-right false that it is not supported by Bubble. Clearly, from the screenshot of the email in my original post, they intentionally designed this endpoint, and did so as unprotected. The fact that it is in every Bubble application without documentation is even more concerning, not less. If Bubble included it, and is actively leaving it in production code, then that are “supporting” it.

2 Likes
12

As an aside, this is absolutely the way to do it. The problem is that Bubble is exposing a work-around to make things easier, but is not including the proper protections to prevent malicious actors and trolls.

13

I can only agree with this concern. This is a security issue because it’s not just a question on how many files that can be uploaded from an external source… but also the type of file that can lead to serious problems.
Any external request to this endpoint should request an API key.

7 Likes
14

Pinging @emmanuel again

1 Like
15

It is baffling that the file upload endpoint is not protected by bearer token authentication, considering every other endpoint has the option available. Maybe this is some quirky limitation in how Bubble connects to AWS S3? Anyways I don’t see why Bubble couldn’t simply add a switch in the app settings to enable/disable file upload security.

As far as being able to clean out malicious files, while being theoretically possible to do manually, good luck with that. Trying to compare what file links are stored in database fields to files on S3 would be painfully tedious for even a few dozen files, and downright impossible for more than that. Bubble lacks two important pieces of app building functionality to be able to garbage collect files:

  1. The ability to list all files with links in database fields
  2. The ability to list all files currently stored on S3 under the app

You need to be able to compare both of these lists to be able to, in any way, automate garbage collection to keep your file storage clean.

7 Likes
16

Maybe it is created so as to allow an easy upload from an unauthenticated user, but it is a very dangerous system for the creators… Please do something to correct it if it is true !

1 Like
17

I agree, bearer tokens make the most sense and should not be that difficult, as you point out, since this is a standard (even across most other Bubble services). Pinging @emmanuel again!

18

I see Bubble support sometimes replying recently to people’s posts and the guy seemed pretty active, anyone know his name?

19

@sam.morgan

20

Hi All,

Sam here, from the success team. Thank you everyone for expressing your concerns - feedback like this is how we learn and grow as a company, and we appreciate everyone sharing their thoughts on this subject.

A few notes about how we respond to reports of security vulnerabilities in general:

  • We assign a criticality level based on the impact the vulnerability has and what mitigations exist.
  • Based on criticality and what it would take to fix the vulnerability, we prioritize & schedule engineering work accordingly.
  • It’s really important to note that there are no bonafide reports of security vulnerabilities that we, as a team, don’t care about or intend to ignore. Items on our roadmap that have a lower urgency level are still things that we care about and intend to resolve, just on a longer timeframe than items with a critical urgency level.

In regards to this specific vulnerability report:

  • The most important factor that went into assessing this vulnerability as low impact is the fact that it does not allow an attacker to gain access to data that they shouldn’t otherwise be able to see.
  • We have mitigation plans in place that would allow us to temporarily give more file storage for free to a user who is legitimately affected, while running scripts on the backend to delete malicious data, as well as blocking suspicious uploads.
  • We have various capabilities to deter various forms of DDoS attacks such as one that would take advantage of this vulnerability. We don’t disclose the details of those capabilities publicly to make it harder for attackers to work around them.
  • Resolving this particular vulnerability is going to require user-facing feature changes, because the concept that “anonymous visitors to your app can upload files” is part of the required functionality of some people’s apps. So part of the delay here was that in order to fix it well – and not impact our users with multiple changes in a row or half-baked features – we wanted some time to plan out what those user-facing features would entail.
  • None of the above 4 points are intended to imply that we don’t view this as a problem and that we don’t want to fix it. They just mean that we at Bubble view this as a “low,” rather than a “high” or “critical” vulnerability.

Specifically as it relates to security issues, we would like to generally discourage these types of posts. There is nothing productive to be gained from publicizing any security concern outside of a responsible disclosure process, which in our case involves using our bug report form and working with our support team. It only serves to make potential bad actors aware that a particular vulnerability exists, thus needlessly increasing the potential impact on millions of active Bubblers.

That said, we hear the user response here, and we understand that some of you view this issue with a higher level of urgency than we initially assessed as a team. Our engineering team is looking into ways that we can resolve this behavior sooner rather than later. While we don’t have an exact timeframe at this time, I’ll be sure to keep this thread updated.

11 Likes
21

At the very least a means to automate garbage collection of files that do not have explicit URL references within the database would give developers a lot more control over their own resource consumption.

1 Like