3 ms·

I have no association with Supabase, but in their defense, apart from adding a caution note, there's nothing else that Supabase needs to do, from my perspective

I have no association with Supabase, but in their defense, apart from adding a caution note, there's nothing else that Supabase needs to do, from my perspective. As far as I am concerned, this is not a serious security hole if the human developer exercises common sense and uses widely recognized security precautions while developing their system.

paddlepop 1y ago
This. As a platform, where do you draw the line between offering a product vs not because a developer could do something stupid with it? edit: keeping in mind the use cases they are pushing in their documentation are for local development
- frabcus 1y ago
  Reflecting on this whole situation, I suspect MCP is fundamentally insecure, in which case Supabase should refuse to implement it. MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem. Supabase's response (in the top comment in this post) of making it read-only or trying to wrap with an LLM to detect attacks... Neither of those help the fundamental problem at all. Some other tool probably has write capabilities, and the wrapping isn't reliable.
  - simonw 1y ago
    > MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem. That's exactly the problem here: the ability for end users to combine MCP tools means that those end users are now responsible for avoiding insecure tool combinations. That's a really hard thing for end users to do - they have to understand the lethal trifecta risk in order to make those decisions.
ajross 1y ago
> this is not a serious security hole if the human developer exercises common sense and uses widely recognized security precautions Just like SQL injection attacks aren't something to worry about, right? Have we learned nothing from three decades of internet security experience? Really? Yes. It seems we've learned nothing. I weep for the future.
- blackoil 1y ago
  Database still support RAW queries. So, yeah developer are responsible for proper usage of the tools.
  - ajross 1y ago
    There are whole ecosystems of tools designed around the need to isolate queries, though. You don't just throw a Postgres prompt at your developers and tell them to be careful, because if you do little Bobby Tables pwns your stuff. We know this is how this works. We lived through it. Why on earth do you think the results will be any different this time?
    - fastball 1y ago
      Database providers do just throw a postgres prompt at developers though, right? And that is what Supabase is – an infra provider.
      - ajross 1y ago
        That's an argument, I guess, for absolving Supabase for explicit responsibility for the resulting hilarity. It's not an argument that MCP prompt hacking is "not a serious security hole", which is the point I responded to upthread.
        fastball 1y ago
        It's only a security hole if you give access to users though, right? If you are the one using the Supabase MCP, how is it any different than any other root access to a DB?

paddlepop 1y ago

This. As a platform, where do you draw the line between offering a product vs not because a developer could do something stupid with it? edit: keeping in mind the use cases they are pushing in their documentation are for local development

frabcus 1y ago
Reflecting on this whole situation, I suspect MCP is fundamentally insecure, in which case Supabase should refuse to implement it. MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem. Supabase's response (in the top comment in this post) of making it read-only or trying to wrap with an LLM to detect attacks... Neither of those help the fundamental problem at all. Some other tool probably has write capabilities, and the wrapping isn't reliable.
- simonw 1y ago
  > MCP's goal is to make it easy for end user developers to impulsively wire agentically running LLM chats to multiple tools. That very capability fundamentally causes the problem. That's exactly the problem here: the ability for end users to combine MCP tools means that those end users are now responsible for avoiding insecure tool combinations. That's a really hard thing for end users to do - they have to understand the lethal trifecta risk in order to make those decisions.

ajross 1y ago

> this is not a serious security hole if the human developer exercises common sense and uses widely recognized security precautions Just like SQL injection attacks aren't something to worry about, right? Have we learned nothing from three decades of internet security experience? Really? Yes. It seems we've learned nothing. I weep for the future.

blackoil 1y ago
Database still support RAW queries. So, yeah developer are responsible for proper usage of the tools.
- ajross 1y ago
  There are whole ecosystems of tools designed around the need to isolate queries, though. You don't just throw a Postgres prompt at your developers and tell them to be careful, because if you do little Bobby Tables pwns your stuff. We know this is how this works. We lived through it. Why on earth do you think the results will be any different this time?
  - fastball 1y ago
    Database providers do just throw a postgres prompt at developers though, right? And that is what Supabase is – an infra provider.
    - ajross 1y ago
      That's an argument, I guess, for absolving Supabase for explicit responsibility for the resulting hilarity. It's not an argument that MCP prompt hacking is "not a serious security hole", which is the point I responded to upthread.
      - fastball 1y ago
        It's only a security hole if you give access to users though, right? If you are the one using the Supabase MCP, how is it any different than any other root access to a DB?