Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase MCP can leak your entire SQL database

generalanalysis.com

Post reply on HN
Print view View original

151–160 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#151

Post by LinXitoW »

qualeed wrote: post #127
simonw wrote: post #29

Earlier quoted context omitted.

But how can you sanitize text? That's what makes this stuff hard: the previous lessons we have learned about web application security don't entirely match up to how LLMs work. If you show me an app with a SQL injection hole or XSS hole, I know how to fix it. If your app has a prompt injection hole, the answer may turn out to be "your app is fundamentally insecure and cannot be built safely". Nobody wants to hear that…

I'm not denying it's hard, I'm sure it is. I think you nailed it with this, though: > If your app has a prompt injection hole, the answer may turn out to be "your app is fundamentally insecure and cannot be built safely". Nobody wants to hear that, but it's true! Either security needs to be figured out, or the thing shouldn't be built (in a production environment, at least). There's just so many parallels between thi…

We're talking about the rising star, the golden goose, the all-fixing genius of innovation, LLMs. "Just don't use it" is not going to be acceptable to suits. And "it's not fixable" is actually 100% accurate. The best you can do is mitigate.

We're less than 2 years away from an LLM massively rocking our shit because a suit thought "we need the competitive advantage of sending money by chatting to a sexy sounding AI on the phone!".

Re: Supabase MCP can leak your entire SQL database

#152

Post by abujazar »

Well, this is the very nature of MCP servers. Useful for development, but it should be quite obvious that you shouldn't grant a production MCP server full access to your database. It's basically the same as exposing the db server to the internet without auth. And of course there's no security in prompting the LLM not to do bad stuff. The only way to do this right in production is having a separate user and database connection for the MCP server that only has access to the things it should.

Re: Supabase MCP can leak your entire SQL database

#153

Post by gregnr »

jonplackett wrote: post #137
gregnr wrote: post #69

Earlier quoted context omitted.

We're experimenting with a PostgREST MCP server that will take full advantage of table permissions and row level security policies. This will be useful if you strictly want to give LLMs access to data (not DDL). Since it piggybacks off of our existing auth infrastructure, it will allow you to apply the exact fine grain policies that you are comfortable with down to the row level.

This seems like a far better solution and uses all the things I already love about supabase. Do you think it will be too limiting in any way? Is there a reason you didn’t just do this from the start as it seems kinda obvious?

The limitation is that it is data-only (no DDL). A large percentage of folks use Supabase MCP for app development - they ask the LLM to help build their schema and other database objects at dev time, which is not possible through PostgREST (or designed for this use case). This is particularly true for AI app builders who connect their users to Supabase.

Re: Supabase MCP can leak your entire SQL database

#154

Post by cyanydeez »

jacquesm wrote: post #125
tptacek wrote: post #68

Earlier quoted context omitted.

Can this ever work? I understand what you're trying to do here, but this is a lot like trying to sanitize user-provided Javascript before passing it to a trusted eval(). That approach has never, ever worked. It seems weird that your MCP would be the security boundary here. To me, the problem seems pretty clear: in a realistic agent setup doing automated queries against a production database (or a database with produc…

The main problem seems to me to be related to the ancient problem of escape sequences and that has never really been solved. Don't mix code (instructions) and data in a single stream. If you do sooner or later someone will find a way to make data look like code.

Others Have pointed out one would need to train a new model that separated code and data because none of the models have any idea what either is.

It probably boils down a determistic and non deterministic problem set, like a compiler vs a interpretor.

Re: Supabase MCP can leak your entire SQL database

#155

Post by cyanydeez »

ajross wrote: post #61
OtherShrezzing wrote: post #51

Earlier quoted context omitted.

Pragmatically, does your responsible disclosure processes matter, when the resolution is “ask the LLM more times to not leak data, and add disclosures to the documentation”?

Absolutely astounding to me, having watched security culture evolve from "this will never happen", though "don't do that", to the modern world of multi-mode threat analysis and defense in depth... ...to see it all thrown in the trash as we're now exhorted, literally, to merely ask our software nicely not to have bugs.

Late stage grift economy is a weird parallelism with LLM State of art bullshit.

Re: Supabase MCP can leak your entire SQL database

#156

Post by saurik »

tptacek wrote: post #129
saurik wrote: post #121

Earlier quoted context omitted.

Adding more agents is still just mitigating the issue (as noted by gregnr), as, if we had agents smart enough to "enforce invariants"--and we won't, ever , for much the same reason we don't trust a human to do that job, either--we wouldn't have this problem in the first place. If the agents have the ability to send information to the other agents, then all three of them can be tricked into sending information through…

I don't know where "more agents" is coming from.

You said you wanted to take the one agent, split it into two agents, and add a third agent in between. It could be that we are equivocating on the currently-dubious definition of "agent" that has been being thrown around in the AI/LLM/MCP community ;P.

Re: Supabase MCP can leak your entire SQL database

#157

Post by andy99 »

cyanydeez wrote: post #154
jacquesm wrote: post #125

Earlier quoted context omitted.

The main problem seems to me to be related to the ancient problem of escape sequences and that has never really been solved. Don't mix code (instructions) and data in a single stream. If you do sooner or later someone will find a way to make data look like code.

Others Have pointed out one would need to train a new model that separated code and data because none of the models have any idea what either is. It probably boils down a determistic and non deterministic problem set, like a compiler vs a interpretor.

You'd need a different architecture, not just training. They already train LLMs to separate instructions and data, to the best of their ability. But an LLM is a classifier, there's some input that adversarrially forces a particular class prediction.

The analogy I like is it's like a keyed lock. If it can let a key in, it can let an attackers pick in - you can have traps and flaps and levers and whatnot, but its operation depends on letting something in there, so if you want it to work you accept that it's only so secure.

Re: Supabase MCP can leak your entire SQL database

#158

Post by e9a8a0b3aded »

gregnr wrote: post #43

Supabase engineer here working on MCP. A few weeks ago we added the following mitigations to help with prompt injections: - Encourage folks to use read-only by default in our docs [1] - Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data [2] - Write E2E tests to confirm that even less capable LLMs don't fall for the attack [2] We noticed that t…

I wouldn't wrap it with any additional prompting. I believe that this is a "fail fast" situation, and adding prompting around it only encourages bad practices.

Giving an LLM access to a tool that has privileged access to some system is no different than providing a user access to a REST API that has privileged access to a system.

This is a lesson that should already be deeply ingrained. Just because it isn't a web frontend + backend API doesn't absolve the dev of their auth responsibilities.

It isn't a prompt injection problem; it is a security boundary problem. The fine-grained token level permissions should be sufficient.

Re: Supabase MCP can leak your entire SQL database

#159

Post by freeone3000 »

jchanimal wrote: post #57
gregnr wrote: post #43

Supabase engineer here working on MCP. A few weeks ago we added the following mitigations to help with prompt injections: - Encourage folks to use read-only by default in our docs [1] - Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data [2] - Write E2E tests to confirm that even less capable LLMs don't fall for the attack [2] We noticed that t…

This is a reason to prefer embedded databases that only contain data scoped to a single user or group. Then MCP and other agents can run wild within a safer container. The issue here comes from intermingling data.

You can get similar access restrictions using fine-grained access controls - one (db) user per (actual) user.

Re: Supabase MCP can leak your entire SQL database

#160

Post by blibble »

gregnr wrote: post #43

Supabase engineer here working on MCP. A few weeks ago we added the following mitigations to help with prompt injections: - Encourage folks to use read-only by default in our docs [1] - Wrap all SQL responses with prompting that discourages the LLM from following instructions/commands injected within user data [2] - Write E2E tests to confirm that even less capable LLMs don't fall for the attack [2] We noticed that t…

> Sadly General Analysis did not follow our responsible disclosure processes [3] or respond to our messages to help work together on this.

your only listed disclosure option is to go through hackerone, which requires accepting their onerous terms

I wouldn't either

Post reply on HN