Was my app DB hacked?

It was half from Gmail and half from Hotmail.

These were not accounts created by him, as they are old customer records. That has a non-paid subscription on my system.

Good suggestions. I will do this.:wink::ok_hand:

Replied privately with info. Some sensitive info on app audit I didnā€™t want to share public.

I can confidently say this is on the development side not the bubble auth side.

7 Likes

That was my first thoughtā€¦
And to be honest, it is clever

Was he storing passwords?

1 Like

No, other leaks.

how cool would it be if the upcoming bubble ai could automatically create privacy rules with just a description of the rules in a text?

3 Likes

Iā€™m curious how leaking passwords is possible if he wasnā€™t storing passwords.

I donā€™t know how to get users passwords even if I tried.

Any chance you could share how this is possible?
Obscure anything to do with this situation, Iā€™d just love an example of how something like this is possible for learning purposes.

3 Likes

Now that heā€™s removed his appID and working at securing Iā€™ll share a bit more info.

After a quick audit of his app we could see what data was leaked. There were no passwords leaked however quite a few other details.

He was 100% correct his users data was protected however he had other data types that stored sensitive user information in plain text instead of a user object. (little things like this commonly get overlooked) Iā€™ll just use email as the example however there were a few other fields.

His dataAPI was also open as well as swagger docs this allowed me to retrieve a large amount of data and use constraints with the data API to find a few of the emails he posted a screenshot of earlier in the thread.

Ran those through a db tool and confirmed that the emails have been exposed in multiple database leaks. Then confirmed it with a larger database check that doesnā€™t give details. https://haveibeenpwned.com/

Many times bad actors use automated tools to check multiple thousands+ of websites then go with a more manual approach when they find vulnerabilities. Which is why itā€™s so important to make sure privacy rules are setup, data api is only exposing what is needed, backend workflows are secure, swagger isnā€™t exposed, sensitive data isnā€™t stored in app text or option sets, etc.

The odds of bubble itself actually having a whole leak is slim to none bc of how they encrypt data. If a leak does happen all the bad actor will get is a bunch of encrypted data that will need to be brute forced. To do something of that scale would take an insane amount of resources and still not be very effective.

@georgecollier has a great thread on some of the basic info most people donā€™t know is exposed by default in your bubble app.

@petter has a great book on bubble app security

@flusk is the best public tool to test your apps and does the best job at making it so less technical people can understand however some understanding of your app and what should/shouldnā€™t be public will still be needed.

Lastly, I personally offer full audits for security, scalability, and overall app speed.

27 Likes

Youā€™re the boss! This is why the Bubble community is so great.

3 Likes

Thanks for such a great answer! This makes way more sense. Really appreciate the detail.

1 Like

I agree. You are the bowss!

1 Like

isnā€™t that what the dynamic expressions are?

You could say that. :smiley:

But I rather think that a description such as : Secure all data in the database so that only the creator of the data can access it. However, field xy should be publicly accessible.
Field xz should also be accessible via APIā€¦

I think I can think of a few more cases here on reflection.

Basically, dynamic expressions are texts, but in bubble language. I mean that certain rules are created with simple descriptions.

Of course, this can apply not only to privacy rules, but also to workflows, if conditions and much more.

Iai, algum resultado novo?

@chris.williamson1996 great post.

One questionā€¦ regarding the paragraph I quoted here, are you saying that he had user specific data stored in other data types that were not protected by the same privacy rules as the User data type?

I ask because the way I initially read this paragraph sounds like fields in the User have some special protection vs fields in other data types. However, in my understanding, custom (Bubble user generated) fields in the User are the same as custom fields in any other data type.

Just wanted to check in to make sure I havenā€™t misunderstood anything about Bubble in this regard.

curious on this as well

@will_ericksson @incomdies

This was in reference to essentially taking user data then reusing data such as emails in other data types as plain text while indicating in either data type name or data type fields that that is indeed a user email.

Users do not have separate protections or anything fancy like you asked under privacy rules rather this was a build/security practice issue by the developer.

Hereā€™s an example related to how this happened.

user

  • email - text
  • first name - text

username

  • email - text
  • username - text
  • user - user object

This is a bad example because most of the time Iā€™d just store username on the user account but it was an easy example for me to come up with without actually referencing the original posters data.

You can have your ā€œuserā€ data type fully secure but if you leave your ā€œusernameā€ datatype public youā€™ve still exposed every single one of your users email which then just has to be bounced against a database leak list and a few passwords tried for matching emails to go from hacking an apps database into hacking an apps users accounts.

2 Likes

Ok thanks for clarifying. That is what I thought your original paragraph meant, but I wanted to double check.

1 Like