Protecting Your Autotask Endpoints from Traffic Sniffing

Support Defender
1

I had a security question about triggering an Autotask linked to a Relay using a webhook.

I love the ease of simply hitting a webhook like:

https://api.defender.openzeppelin.com/autotasks/${AUTOTASK_ID}/runs/webhook/${A BIG SECRET STRING}

from a backend Node service to trigger a transaction. I was somewhat surprised that the endpoint is unauthenticated.

What is the strategy for securing these webhooks? Couldn't anyone with access to the traffic in/out of the microservice discover this webhook URL and indirectly gain access to signing that transaction with our Relay? (in my case claiming an amount of locked ERC20 to a certain address).

I of course will store the URL as an environment variable, but still I'm a bit worried about traffic sniffing.

Would it be any better or worse if I used the DefenderRelaySigner from the defender-relay-client package directly in my code?

2

Hey @flaco_jones, this is an excellent question. While that big-secret-string goes SSL-encrypted over the wire, it's true that anyone who manages to get between your SSL offloading layer and your microservice would be able to read it. You have a couple of options for securing this:

  • Setting up the Autotask in such a way that, even if an attacker calls the webhook, the autotask cannot execute anything malicious (eg keeping a whitelist of claimer addresses in the autotasks).

  • Implement an additional authentication layer within your Autotask. The autotask receives the entire http payload (plus a subset of headers) in its invocation, so you could implement your own authentication mechanism on it.

  • Use the defender-relay-client as you suggest, since the relayer API uses a secure AWS v4 signature algorithm for authentication. Note that you should only go this way if you're calling the relayer from your own services, and not from a public client where a user could exfiltrate your relayer keys.

  • Tell us which authentication mechanism you'd like to see implemented for Autotask Webhooks, so we can add it to our roadmap!

1 Like
3

Thanks @spalladino !

I think I will go with Option 2. We have a GitHub OAuth token at the time we call this Autotask, so the OAuth token can be passed along and cross-checked.

In fact, I'm thinking now the oracle process for checking that the "claimer" is the "closer" of the GitHub issue could live as an Autotask...at least until GitHub self-hosts an Airnode.

GitHub OAuth!

You guys rule. Always singing your praises: https://twitter.com/Flac0j0nes/status/1484377270001156105

1 Like
4

I'm curious - which subset of headers is that? I only see AWS related X- headers.

I'm hoping to move my entire GitHub authenticated Oracle from a custom container in my K8s cluster over to Autotask. That way there, the entire operation will happen within OZ's secure environment.

I currently use a Signed, Http-Only cookie for passing around the mission critical GitHub OAuth token. I don't see this Cookie in the header when I call my Autotask with it.

Are cookies not yet supported? I also tried with an Authorization header, but I can't access that on event.request either.

Thanks!

5

Found my answer after some digging:

"only non-standard headers with the X- prefix are provided to the Autotask"

I guess this means I should append what is currently identified as the standard "Cookie" header as a non-standard header like "X-Github-Token".

1 Like