zlacker

Yes... but...

Presumably the proxy replaces any occurrence of the placeholder with the real key, without knowing anything about the context in which the key is used, right? Because if it knew that the key was to be used for e.g. HTTP basic auth, it could just be added by the proxy without using a placeholder.

So all the attacker would have to do then is find and endpoint (on one of the approved hosts, granted) that echoes back the value, e.g. "What is your name?" -> "Hello $name!", right?

But probably the proxy replaces the real key when it comes back in the other direction, so the attacker would have to find an endpoint that does some kind of reversible transformation on the value in the response to disguise it.

It seems safer and simpler to, as others have mentioned, have a proxy that knows more about the context add the secrets to the requests. But maybe I've misunderstood their placeholder solution or maybe it's more clever than I'm giving it credit for.

>>ptx+(OP)
Where would this happen? I have never seen an API reflect a secret back but I guess it's possible? perhaps some sort of token creation endpoint?

>>booi+a1
HTTP Header Injection or HTTP Response Splitting is a thing.

>>booi+a1
How does the API know that it's a secret, though? That's what's not clear to me from the blog post. Can I e.g. create a customer named PLACEHOLDER and get a customer actually named SECRET?

>>booi+a1
It depends on where you allow the substitution to occur in the request. It's basically "the big bug class" you have to watch out for in this design.

>>booi+a1
Say, an endpoint tries to be helpful and responds with “no such user: foo” instead of “no such user”. Or, as a sibling comment suggests, any create-with-properties or set-property endpoint paired with a get-propety one also means game over.

Relatedly, a common exploitation target for black-hat SEO and even XSS is search pages that echo back the user’s search request.

>>ptx+(OP)
Could the proxy place further restrictions like only replacing the placeholder with the real API key in approved HTTP headers? Then an API server is much less likely to reflect it back.

>>sothat+Pp
It can, yes. (I don't know how Deno's work, but that's how ours works.)

>>booi+a1
This is effectively what happened with the BotGhost vulnerability a few months back:

>>44359619

>>ptx+y2
This blog post is very clearly AI generated, so I’m not sure it knows either.

>>booi+a1
The point is that without semantic knowledge, there's no way of knowing whether the API actually considers it a secret. If you're using the Github API and have it listed as an approved host but the sandbox doesn't predefine which fields are valid or not to include the token, a malicious application could put the placeholder in the body of an API request making a public gist or something, which then gets replaced with the actual secret. In order to avoid this, the sandbox would need some way of enforcing which fields in the API itself are safe. For a widely used API like Github, this might be something built-in, but to support arbitrary APIs people might want to use, there would probably have to be some way of configuring the list of fields that are considered safe manually.

From various other comments in this thread though, it sounds like this is already well-established territory that past tools have explored. It's not super clear to me how much of this is actually implemented for Deno Sandboxes or not though, but I'd hope they took into account the prior art that seems to have already come up with techniques for handling very similar issues.