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.

▲

sothatsit 15 minutes ago | parent | next [-]

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.

▲

booi 2 hours ago | parent | prev [-]

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?

	▲	mananaysiempre an hour ago \| parent \| next [-]
		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.
	▲	tptacek 2 hours ago \| parent \| prev \| next [-]
		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.
	▲	ptx 2 hours ago \| parent \| prev \| next [-]
		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?
	▲	Tepix 2 hours ago \| parent \| prev [-]
		HTTP Header Injection or HTTP Response Splitting is a thing.