[mike_d]

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.

[filleokus]

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)

[mike_d]

Self-reply since I can't edit my comment anymore. It looks like they are fixing this:

https://github.com/superfly/tokenizer/pull/9

[tptacek]

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.