Remix clone Hacker News

>Saying MCP is vulnerable is like saying "Web applications are vulnerable”

Just for reference, this GitHub follows in the tradition of many an example project all of which have the explicit intent of demonstrating not that the underlying concept is inherently vulnerable, but that implementations can be.

Damn Vulnerable Web App is probably the best known, but there are others for REST apis, web sockets, GraphQL, and more. They’re educational reference implementations that are deliberately insecure to use as an educational tool.

▲

eddythompson80 7 days ago | parent [-]

Except that all the “vulnerabilities” listed are addressed (or can be only addressed) by treating tbr MCP server as a client application.

If a Damn Vulnerable Web App demo was just 10 or 20 different “there no authn/authz on this endpoint”, it would be a crappy demo

▲

Xelynega 7 days ago | parent [-]

How will this work when people are talking about third party MCP servers(e.x. booking.com, GitHub, etc.)

▲

eddythompson80 6 days ago | parent [-]

The same way you'd write a third party client to any software/API.

The MCP uses some kind of identity to talk to booking.com or GitHub. That's your security boundary. You assume that anything the MCP has access to (including that identity), the user has access to. If you add a `list_available_hotels()` tool to your booking.com MCP, that tool needs to run with the same identity as the person talking to the LLM. It doesn't have any more permissions or access to your system than the booking.com react app does.

Think of the MCP server as a natural language interface to your application. Like a CLI or a WebApp. Instead of writing specific commands to a cli, or following a series of clicks in a GUI app, you "chat" with it.

▲

sanderjd 6 days ago | parent | next [-]

I think one major issue here is with the "server" terminology in MCP. It honestly just seems like the wrong word for what these things are, to me.

▲

Xelynega 6 days ago | parent | prev [-]

If you're authenticating the exact same way you would to an HTTP api(put an API key in the config), why does MCP need to exist instead of just plugging in the API key + link to openapi specs in an "Agent API Config"?

I was responding to you saying that the security model is different because servers can be treated as client applications for the security model, but that doesn't make sense for third party servers that you aren't hosting and just sending/receiving data from.

From the client PoV, booking.com could return malicious information to my prompt telling it to do unauthorized things with my computer(e.x. upload banking cookies to a remote endpoint). This doesn't sound secure, and just saying "it's part of the client" doesn't change that.

	▲	alphan0n 5 days ago \| parent [-]
		If booking.com is malicious then it wouldn’t matter how you connected. This is a different problem entirely unrelated to the implementation of MCP. Like, what if google decided to blow their multibillion dollar company to steal my banking cookies?!?!