🎉 Introducing the most advanced security platform for Bubble for free (Bubble App Audit)

[ramzizi]

It sounds like Bubble is aware of and ok with his platform. I don’t see how it’s giving an upper hand to a hacker, prior to verification it just tells you that there are a number of issues but it isn’t detailing those issues.

[randomanon]

@ramzizi

upper hand to a hacker

Not everything is about “hackers.” This isn’t a movie. There are real-world issues around IP, competitive intelligence, and defamation.

@ramzizi

just tells you that there are a number of issues

The word “just” is doing a lot of work here. At the enterprise level, all people care about is security and compliance. You could sabotage a competitor by showing them the public results of a tool that shows “10 Critical Issues.” The crazy part here is that the words are arbitrarily defined and are not validated against any known standards, so NQU itself could be responsible for defamation. Additionally, Bubble has massive enterprise accounts itself like Seagate and others, who would definitely not be happy about a public tool that publicly claims that their platform has a number of security gaps. Overall there is massive amounts of liability, very easy fix. This is ignoring my earlier concerns about violating OpenAI’s ToS, which requires that you own the rights to any data that you enter into their API. I am not sure if you ignored that on purpose or if you just happened to miss it.

[ihsanzainal84]

Again what’s the point on you harping on this despite knowing that Bubble has reviewed and decided to allow/endorse this project.

Some of your points are valid but what is it you want to happen?

[randomanon]

@ihsanzainal84

despite knowing that Bubble

Bubble isn’t a monolith. There are random developers, the Head of Legal, Josh/Emmanuel, etc. Who is aware and the extent to which they’re aware of what’s going on are yet unanswered questions and have implications for the future of this tool.

@ihsanzainal84

your points are valid but what is it you want to happen?

To repeat: I’m advocating for two simple fixes before any other “features” are implemented.

• No scan or summary before verification
• LLM analysis disabled by default (opt-in)

These would mitigate the previously discussed issues, protect users’ IP, and ensure that the tool remains viable long-term.

[boston85719]

@randomanon

This is ignoring my earlier concerns about violating OpenAI’s ToS, which requires that you own the rights to any data that you enter into their API. I am not sure if you ignored that on purpose or if you just happened to miss it.

I think he might be aware of it

[FREE] New AI Privacy Rules Checker by Flusk

Just a quick point - if you’re using GPT by sending the potentially sensitive data to GPT API to classify it, that may create a privacy problem as OpenAI retains that data.

[randomanon]

Slightly different, that’s the “Custom GPT” part of the API. In this case the API doesn’t retain the data, but the ToS requires that you own the data that you’re sending to it. You can’t send other people’s data/IP through their API.

But yeah it’s ironic he called it out when it was someone else making the tool.

[johnny]

Mike’s back!

[georgecollier]

As reminder, we require people own the apps they choose to scan, and if they don’t they are violating our terms of service.

Anyway, thanks for your concern, but trust I can worry about our ToS, Bubble can worry about theirs, and you can merrily carry on Bubbling

And if it really bothers you, then stop bumping the thread to the top of the forum.

[randomanon]

@georgecollier

As reminder, we require people own the apps they choose to scan

Require how? Just saying a sentence isn’t good enough. You need to show a good faith effort at doing so, like for example the verification wall that currently comes too late in the process.

@georgecollier

stop bumping the thread

No, I’ll continue discussing this alongside other community members with concerns.

[boston85719]

@georgecollier

why adding conditions to workflows is improtant.

Make sure to suggest to use the most secure conditional possible

do a search for user: constraint 1. email = current user email. constraint 2. Role = Admin. Count >0

With the above conditional a server side evaluation is forced due to the user of do a search, which obviously is more secure than a client side evaluation for a conditional like current user role is admin since that role can be changed client side by a bad actor.

The most secure conditional also forces a bad actor to know the email address of an admin user, which if privacy rules are in place, that wouldn’t be exposed, but also, it is not possible to change the current user email address client side since it can only happen via a server side action, and that action requires the password of the user, so a bad actor not logged in will not have a password, or a bad actor logged in will not be able to change their email address to that of an existing admin user since, well, the user already exists and you can not have two users of the same email address.

@georgecollier

From the ashes, he rises…

GOATs do not rise from the ashes, that is a Phoenix

Welcome back @mikeloc, glad to see you are still with us.

@georgecollier

This has been added! In the near future, I may allow you to view screenshots of pages in your app with all of the elements forced visible so that you can see how an attacker might use hidden buttons in places like admin panels and why adding conditions to workflows is improtant.

This sounds awesome

@randomanon

No summary before verification

Yes, verification should take place before anything is done

@georgecollier keep up the good work with this tool, as I’ve stated on one of the previous posts about the tool, it is cool. I do think that implementing some of the suggestions to make the tool more secure itself would help it ensure it does less harm than good.

[georgecollier]

@randomanon

The word “just” is doing a lot of work here. At the enterprise level, all people care about is security and compliance. You could sabotage a competitor by showing them the public results of a tool that shows “10 Critical Issues.”

You’re gonna have a nasty surprise when you realise this isn’t as unusual as you might think.

@boston85719

I do think that implementing some of the suggestions to make the tool more secure itself would help it ensure it does less harm than good.

Thank you for the feedback

@boston85719

Make sure to suggest to use the most secure conditional possible

do a search for user: constraint 1. email = current user email. constraint 2. Role = Admin. Count >0

With the above conditional a server side evaluation is forced due to the user of do a search, which obviously is more secure than a client side evaluation for a conditional like current user role is admin since that role can be changed client side by a bad actor.

I’ll get back to this in another thread next week where I’ll talk about page workflow conditions and what works/what doesn’t etc!

[randomanon]

@boston85719

Make sure to suggest to use the most secure conditional possible

do a search for user: constraint 1. email = current user email. constraint 2. Role = Admin. Count >0

With the above conditional a server side evaluation is forced due to the user of do a search, which obviously is more secure than a client side evaluation for a conditional like current user role is admin since that role can be changed client side by a bad actor.

I believe Current user is logged in AND Current user is admin would be equivalent. However a privacy rules system is absolutely 100% foolproof, my concern would just be the WU unit expenditure from the “base search” cost.

@georgecollier

this isn’t as unusual

Try this excuse next time a cop pulls you over for speeding and let me know how it goes.

@georgecollier

I’ll talk about page workflow conditions and what works/what doesn’t etc

When you say conditions on page workflows. Do you mean to say that, given a secure condition, using a “Show element” event in a workflow is more secure than conditional formatting using the exact same condition?

[georgecollier]

@randomanon

Do you mean to say that, given a secure condition, using a “Show element” event in a workflow is more secure than conditional formatting using the exact same condition?

Well, neither are secure. All elements on any page can be forced visible.

That’s generally okay - it’s workflows that I care about e.g only an admin should be able to do X, where X might be delete a user, send an email, etc.

So, conditions on the workflow itself protect against that even if the user can force themselves into your admin panel which you thought was secured by a server side redirect and being invisible by default!

And privacy rules don’t fix that, because Privacy Rules effectively restrict data read, but so long as you can see that data, you can do whatever you want to it through workflows as far as Bubble is concerned.

[randomanon]

Yeah that was always my assumption. I thought you had discovered a way to protect a group from loading using workflow conditions, nevermind.

@georgecollier

And privacy rules don’t fix that

I am referring to using privacy rules for workflow conditions. See this post by @keith as an example. This is what @boston85719 was referring to:

How do I password protect an entire page?

@luke2’s suggestion is essential. For any “controlled access” type of page – whether that’s an administrator-only page or a page where a registered user makes/changes data, etc. – you usually want to keep all page elements hidden by default and only show them via the page workflow(s) that check that the current user is authorized to view them. Additionally: There are many different ways of handling administrator access and a couple have been mentioned above, including: If you’re the only ad…

[sem]

@randomanon has very valid points here. Strange that so few act on it.

I think @georgecollier did something great here but security 101 means also that at least you should not make it easier for others to do something with possible vulnerabilities.

It surprises me that not only this tool but it seems also tools in the past can do whatever they want with our apps and share whatever they want about our apps.

It is clear that George does not seem to care and it seems that Bubble is ok with breaking their own term of service.

And just for the record, this again does not mean that George is not providing a great service that can benefit us all. And I understand that this is selling 101, reveal the problem and people will buy. Just on the boat with @randomanon on this one.

[georgecollier]

@randomanon

I thought you had discovered a way to protect a group from loading using workflow conditions

Nah, because the group code is always downloaded whether it’s visible or not - it’s just not rendered.

@sem

this is selling 101, reveal the problem and people will buy

Do consider that this isn’t a paid tool at all - no payment gateway is even integrated, it’s completely free. In future maybe that’ll have to change, but if what I’m selling is free app security, than that’s a different question to letting them scan an app and pay $199 for the results!

[sem]

You are missing the point I was trying to make. You need people to talk about what you have to offer and this is a smart way of doing it. How convenient would it be when millions of apps and users first use your tool to scan for issues.

So again, great product, great way of pushing it to market.

[georgecollier]

@sem

You need people to talk about what you have to offer

Oh yeah absolutely. I’m perfectly content to hear all kinds of feedback in this thread, it keeps it active.

[boston85719]

@georgecollier

And privacy rules don’t fix that, because Privacy Rules effectively restrict data read, but so long as you can see that data, you can do whatever you want to it through workflows as far as Bubble is concerned.

That is why it essential in privacy rule to make it so the data is not found in searches…if it is not found in searches, it is not possible to write to it or delete, because it is not possible to be found at all, as far as I know, but I look forward to being proven wrong on that as hacking is not my thing.

@randomanon

I believe Current user is logged in AND Current user is admin would be equivalent. However a privacy rules system is absolutely 100% foolproof, my concern would just be the WU unit expenditure from the “base search” cost.

True, but you need to use the AND operator which makes it a bit more cumbersome to work with (at least for me as I don’t use the parentheses, so I don’t want to use up my AND operators too early in the expression).

Additionally, it is trying to avoid redundancy with privacy rule, which most likely is current user role is admin, so to add an extra layer of protection, use a different conditional.

Also, in my testing there is no cost for this search, but again, WUs are so messed up that maybe there is supposed to be but in my app it was not charged…

And lastly, I do think that if the user can spoof client side the role is admin, they are likely sophisticated enough actually just change it in the DB, so user is logged in and current user role is admin would on server still evaluate as true, since a real bad actor, likely can just change it in the DB…but again, I don’t know and I look forward to be proven wrong on that as well.

@sem

You are missing the point I was trying to make. You need people to talk about what you have to offer and this is a smart way of doing it. How convenient would it be when millions of apps and users first use your tool to scan for issues.

So again, great product, great way of pushing it to market.

Yes, @georgecollier is very adept at marketing…give value before you ever ask for value from client and clients will trust you and are more likely to use your paid services…and spoofing the agency rankings (collaborators get acknowledged as contributions to bubble ecosystem if an agency I believe, but I may be wrong, I haven’t spent much time looking at how Bubble calculates the tiers.) It is smart.

[georgecollier]

@boston85719

That is why it essential in privacy rule to make it so the data is not found in searches…if it is not found in searches, it is not possible to write to it or delete,

Yeah so this is correct, but my point is more that privacy rules are necessary but not sufficient. Just because I can see something, does not mean I should be able to do something.

Suppose your admin panel has a ‘delete user’ workflow. I bypass your server side redirect, and force all the buttons to be visible. As my privacy rules allow me to see User X, because this is also - public marketplace, I can run the user deletion workflow on User X as it’s not protected by a workflow level condition.

@boston85719

that if the user can spoof client side the role is admin, they are likely sophisticated enough actually just change it in the DB

If you have exploitable workflows (e.g your admin panel’s ’promote to admin’ button doesn’t have a condition on it) to that effect then sure.

The second most common way is people having ‘var - user type’ during a signup flow and assigning a user’s role based on that. That’s easily exploitable to make ‘var - user type’ = admin.

@boston85719

and spoofing the agency rankings (collaborators get acknowledged as contributions to bubble ecosystem if an agency I believe

We get credited if we’re a collaborator for more than 50 days. This is a positive side effect of NQU Secure for us - if Bubble wants to manually override us then sure (though we’re clearly delivering a different sort of value if people want us on their apps!).

It’s certainly not the primary purpose. Unless there’s a technical requirement (e.g you want to use the backups feature), we never require collaborator access and allow people to verify in other ways like adding an HTML header or creating a test page as we don’t want to require that we get added.

——

I’ve made it no secret that we primarily intend to monetise NQU Secure through the agency leads and reputation it generates - kind of a win win for everyone as people who want to use it for free can, and we can still fund it indirectly and hopefully break even.