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

61–70 of 502 posts

Re: Supabase MCP can leak your entire SQL database

#61

Post by ajross »

OtherShrezzing wrote: post #51
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…

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.

Re: Supabase MCP can leak your entire SQL database

#62

Post by tptacek »

otterley wrote: post #58
tptacek wrote: post #39

This is just XSS mapped to LLMs. The problem, as is so often the case with admin apps (here "Cursor and the Supabase MCP" is an ad hoc admin app), is that they get a raw feed of untrusted user-generated content (they're internal scaffolding, after all). In the classic admin app XSS, you file a support ticket with HTML and injected Javascript attributes. None of it renders in the customer-facing views, but the admin v…

Oh, Jesus H. Christ: https://github.com/supabase-community/supabase-mcp/blob/main...

This to me is like going "Jesus H. Christ" at the prompt you get when you run the "sqlite3" command. It is also crazy to point that command at a production database and do random stuff with it. But not at all crazy to use it during development. I don't think this issue is as complicated, or as LLM-specific, as it seems; it's really just recapitulating security issues we understood pretty clearly back in 2010.

Actually, in my experience doing software security assessments on all kinds of random stuff, it's remarkable how often the "web security model" (by which I mean not so much "same origin" and all that stuff, but just the space of attacks and countermeasures) maps to other unrelated domains. We spent a lot of time working out that security model; it's probably our most advanced/sophisticated space of attack/defense research.

(That claim would make a lot of vuln researchers recoil, but reminds me of something Dan Bernstein once said on Usenet, about how mathematics is actually one of the easiest and most accessible sciences, but that ease allowed the state of the art to get pushed much further than other sciences. You might need to be in my head right now to see how this is all fitting together for me.)

Re: Supabase MCP can leak your entire SQL database

#63

Post by nartho »

mort96 wrote: post #52
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…

[flagged]

There is an esoteric programming language called INTERCAL that won't compile if the code doesn't contains enough "PLEASE". It also won't compile if the code contains please too many times as it's seen excessively polite. Well we're having the exact same problem now, instead this time it's not a parody.

Re: Supabase MCP can leak your entire SQL database

#64

Post by borromakot »

Simultaneously bullish on LLMs and insanely confused as to why anyone would literally ever use something like a Supabase MCP unless there is some kind of "dev sandbox" credentials that only get access to dev/staging data.

And I'm so confused at why anyone seems to phrase prompt engineering as any kind of mitigation at all.

Like flabbergasted.

Re: Supabase MCP can leak your entire SQL database

#65

Post by noselasd »

otterley wrote: post #58
tptacek wrote: post #39

This is just XSS mapped to LLMs. The problem, as is so often the case with admin apps (here "Cursor and the Supabase MCP" is an ad hoc admin app), is that they get a raw feed of untrusted user-generated content (they're internal scaffolding, after all). In the classic admin app XSS, you file a support ticket with HTML and injected Javascript attributes. None of it renders in the customer-facing views, but the admin v…

Oh, Jesus H. Christ: https://github.com/supabase-community/supabase-mcp/blob/main...

It's an MCP for your database, ofcourse it's going to execute SQL. It's your responsibility for who/what can access the MCP that you've pointed at your database.

Re: Supabase MCP can leak your entire SQL database

#66

Post by tptacek »

ollien wrote: post #60
tptacek wrote: post #39

This is just XSS mapped to LLMs. The problem, as is so often the case with admin apps (here "Cursor and the Supabase MCP" is an ad hoc admin app), is that they get a raw feed of untrusted user-generated content (they're internal scaffolding, after all). In the classic admin app XSS, you file a support ticket with HTML and injected Javascript attributes. None of it renders in the customer-facing views, but the admin v…

You're technically right, but by reducing the problem to being "just" another form of a classic internal XSS, missing the forest for the trees. An XSS mitigation takes a blob of input and converts it into something that we can say with certainty will never execute. With prompt injection mitigation, there is no set of deterministic rules we can apply to a blob of input to make it "not LLM instructions". To this end, i…

Seems pretty simple: the MCP calls are like an eval(), and untrusted input can't ever hit it. Your success screening and filtering LLM'd eval() inputs will be about as successful as your attempts to sanitize user-generated content before passing them to an eval().

eval() --- still pretty useful!

Re: Supabase MCP can leak your entire SQL database

#67

Post by akdom »

A key tool missing in most applications of MCP is better underlying authorization controls. Instead of granting large-scale access to data like this at the MCP level, just-in-time authorization would dramatically reduce the attack surface.

See the point from gregnr on

> Fine-grain permissions at the token level. We want to give folks the ability to choose exactly which Supabase services the LLM will have access to, and at what level (read vs. write)

Even finer grained down to fields, rows, etc. and dynamic rescoping in response to task needs would be incredible here.

Re: Supabase MCP can leak your entire SQL database

#68

Post by tptacek »

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…

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 production data in it), there should be one LLM context that is reading tickets, and another LLM context that can drive MCP SQL calls, and then agent code in between those contexts to enforce invariants.

I get that you can't do that with Cursor; Cursor has just one context. But that's why pointing Cursor at an MCP hooked up to a production database is an insane thing to do.

Re: Supabase MCP can leak your entire SQL database

#69

Post by gregnr »

simonw wrote: post #49
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…

Really glad to hear there's more documentation on the way! Does Supabase have any feature that take advantage of PostgreSQL's table-level permissions? I'd love to be able to issue a token to an MCP server that only has read access to specific tables (maybe even prevent access to specific columns too, eg don't allow reading the password_hash column on the users table.)

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.

Re: Supabase MCP can leak your entire SQL database

#70

Post by achierius »

esafak wrote: post #13
simonw wrote: post #9

Earlier quoted context omitted.

That's the whole problem: systems aren't deliberately designed this way, but LLMs are incapable of reliably distinguishing the difference between instructions from their users and instructions that might have snuck their way in through other text the LLM is exposed to. My original name for this problem was "prompt injection" because it's like SQL injection - it's a problem that occurs when you concatenate together tr…

Isn't the fix exactly the same? Have the LLM map the request to a preset list of approved queries.

The original problem is

Output = LLM(UntrustedInput);

What you're suggesting is

"TrustedInput" = LLM(UntrustedInput); Output = LLM("TrustedInput");

But ultimately this just pulls the issue up a level, if that.

Post reply on HN