If you're using nginx/apache/literally anything that does reverse proxying correctly, this shouldn't be a problem unless you're routing all traffic over default_server rules unstead of server_name (or the equivalent).

They should be stopping this attack at the door (even if only to clean out your logs from scraper door knocks), which is probably why it went unnoticed for years. I don't think anyone would be deploying {A,W}SGI servers on public facing ports these days. Even if only because SSL termination is much easier in the proxy layer.

Also good lord that ARS article is a mess. What the hell happened there? An ASGI server isn't unique to AI or anything, it's just a regular supply chain dependency. I kinda expect better from ARS on stuff like this.

▲

ostif-derek 5 hours ago | parent | next [-]

You're relying on everyone in the world to set things up in a way that provides defense in depth. Not everyone is going to do that.

Which means there's going to be a lot of cases where people don't do the safe thing.

Especially, as other's have said, in the case of MCP servers, where the spec mandates exposed oauth.

▲

acdha 3 hours ago | parent [-]

The saving grace here is that people are most commonly doing this for reasons other than as a defense - serving static files efficiently, combining multiple services, caching, DDoS protection, etc. There are certainly some directly exposed FastAPI instances but it’s been against the grain for decades.

	▲	noirscape 3 hours ago \| parent [-]
		Or probably the most straightforward one, which is SSL termination. Most backend software usually has very bad support for HTTPS communication, while it's typically extensively documented for something like nginx. It also catches some other strangeness like making it easier to update the certificate. The biggest risk is incorrect usage of the default_server directive, the proper way in which to handle it isn't usually taught in most "here's how you use nginx" tutorials. Most usually just have you edit the default server blocks. Tldr that covers 99% of all cases: you want 2 default server blocks, one on port 80 and one on port 443. The one on port 80 should only return 444 (an internal nginx status code that stops the connection immediately with no response), while the one on port 443 should use ssl_reject_handshake to terminate the SSL connection as quickly as possible without causing strange errors (you also need a self-signed certificate because otherwise openssl refuses to do protocol negotiation correctly, but the cert doesn't actually do anything). After that, specify your actual domains as separate server blocks using server_name (including a separate one for each to do the port 80->443 redirect). Arguably this should be the default configuration shipped by distros, but it isn't for some reason, which doesn't help matters.

▲

anakaine 5 hours ago | parent | prev [-]

Ars has had a depreciating quality the past few years by most accounts. They've been trying a bit harder recently it seems, but shaking off the allure of half baked short form journalism is hard, I guess.