Hacker News Reader

Comment by HellsMaddy | Hacker News Reader

I was thinking about how to mitigate this. First thought was to rewrite links for embedded content such as images to use a proxy server, like how `camo.githubusercontent.com` works, but this wouldn't prevent passing arbitrary data in the URL.

The only other things I can think of are to only allow embedding content from certain domains (the article mentions that Writer.com's CSP lists `*.cloudfront.net` which is not good), or to not allow the LLM to return embedded content at all (sanitize it out). This should even be extended to markdown links - it would be trivial to create a MITM link shortener that exfiltrates data via URL params and quickly redirects you to the actual destination.

View on HN

They could prevent the rendering engine and llm from doing any http calls, prompting the user to allow the engine and llm for each call it needs to make, showing the call details.

That’d provide some protection, but the LLM could be prompted to socially engineer users.

For example, it could be promoted to only make malicious HTTP requests via an image when the user genuinely requests an external image be created. This would achieve consent from users who thought they were asking for a safe external source.

Similar for fonts, external searches [1], social items etc

[1] e.g putting a reverse proxy in front of a search engine and adding in extra malicious params

You could also just steganographically encode it. You have the entire URL after the domain name to encode leaked data into. LLMs can do things like base-64 encoding no sweat. Encode some into the 'ID' in the path, some into the capitalization, some into the 'filename', some into the directories, some into the 'arguments', and a perfectly innocuous-looking functional URL now leaks hundreds of bytes of PII per request.

I'm not sure I'd allow all those random base64 encoded bytes for a simple image url.

That's not a solution. You have to guard against all image URLs, because every domain and path can steganographically encode bits of information. 'foo.com/image/1.jpg' vs 'fo.com/img/2.jpg' just leaked several bytes of information while each URL looks completely harmless in isolation. A byte here and a byte there, and pretty soon you have their name or CC or address or tokens or...

Maybe you didn't read the last part of my suggestion:

> showing the call details.

If you really want to render an image, a huge base64 blob would be a bit suspisouse for a url that should simply point to a png or similar.

Google mitigated it via CSP , as did Bing Chat.

ChatGPT is still vulnerable btw

Reply on news.ycombinator.com