Psyched to get this out (I mean, I didn't do any of the work, but I'm still psyched it's getting out). I'm also a little bit surprised Vault doesn't already have a feature like this as a Secrets Engine.
This is really cool, but I think it ends up just being a complicated decryption oracle?
If I compromise your rails app, and (hypothetically) Stripe allows me to specify the message as it appears on a users credit card statement, could I not just ask it to insert the API key in that field as well and then check my bank statement? This gets easier if there is something where a value gets reflected back to the user, say an SSO error message.
My apology if there is already a protection for this, but I didn't see any obvious use restrictions in the Github README example.
As I read the docs, I think the specification for how the secret should be injected lives "statically" within the Tokenizer service, and is not configurable by the internal service making the request.
I.e, if you only get control of the Rails app would need to find an api.stripe.com endpoint that reflects back the authentication header.
----
EDIT: No, I misunderstood it completely, you are right. But hmm. One way I can think of solving what you mentioned is if the token itself contains the processor parameters. That way it wouldn't be possible to change how the templating works after the secret have been tokenised (i.e by an attacker)
The problem described in the comment above isn't really a problem: you can only inject secrets into headers (like `X-Whatever-API-Key`); you can't inject it into the payload of a request, to, like, ask for an invoice to printed with the API key as an invoice ID.
But there are headers that can get reflected --- too many of them, in too many different environments, so we're just whitelisting which headers you can use on a per-secret basis.
The much, much better vulnerability is the byte-at-a-time attack Jann found. Also fixed! A great bug.
Did the team consider developing a custom secret engine [1] for Vault? or is it that the specific dances between Rails, tokenizer, ssokenizer cannot be accommodated by a secret engine?
We're really picky about how our existing Vault clusters are exposed to applications, so building a Secret Engine for this would have required us to run an entire new Vault cluster. Moreover, we're moving away from Vault for a bunch of use cases (not all of them! we'll be running Vault indefinitely) --- not because of any failing of Vault, but because at this point we understand our needs very well, and operational legibility has become a really big priority. This also has a clearer path to integrating with our internal Macaroon tokens.
I have to imagine somebody is going to build a Secret Engine that does this.
If I compromise your rails app, and (hypothetically) Stripe allows me to specify the message as it appears on a users credit card statement, could I not just ask it to insert the API key in that field as well and then check my bank statement? This gets easier if there is something where a value gets reflected back to the user, say an SSO error message.
My apology if there is already a protection for this, but I didn't see any obvious use restrictions in the Github README example.