Possible Configuration Issue on Alchemy/Infura Endpoints

[james-a-morris]

Issue Statement

The issue I found has to do with the configuration of the production Alchemy/Infura endpoints on https://across.to/. Specifically, the domain whitelisting is not enabled to prevent external websites from querying Infura/Alchemy data via production endpoints.

Possible Vulnerability

These public endpoints could be used on a different website at Across/UMA's expense. And, if the API requests exceed Across' monthly quota, it could mean a denial of service (API endpoints returning failed responses) or a surcharge in additional fees.

Evidence

I've run several tests on a jsFiddle and deployed one test site to Netlify to query a randomly chosen production API endpoint against various origins. As a control, I created a free Infura endpoint and applied whitelisting for across.to (for prod) and for *.vercel.app to cover the preview deployments.

In all the environments I've tested, the production endpoint returns a valid value and the free Infura endpoint returns a 403 "Forbidden" error.

A successful call of an in-production Infura Endpoint being fetched from a different host outside of the prod/preview environment (account.to and *.vercel.app)

A failed call of the test Infura Endpoint (endpoint now disabled) with whitelisting set for prod/preview environments (across.to & *.vercel.app)

Possible Solutions

I would recommend applying domain whitelisting on Infura/Alchemy for across.to and *.vercel.app in the Infura configuration panel.

For the ETH endpoints on Infura,

1. Visit https://infura.io/dashboard/ethereum/b14cb6f39de44042802cf5c83d69c6f1/settings
2. Navigate under the "Security Tab"
3. Update the "origins" tab to include the production, preview, and possibly local domains

[mrice32]

@james-a-morris thanks for raising this!

I would recommend applying domain whitelisting on Infura/Alchemy for across.to and *.vercel.app in the Infura configuration panel.

That this doesn't really protect against an attacker, right? Couldn't they just overload the endpoint from nodejs with custom headers? Going a step further, can't they replicate any request the frontend makes, so any sort of secret would also be exposed, right?

I think a good long term solution is probably to have server that sits between the frontend and infura that's protected by Cloudflare or a similar DOS protection service. That server could do a lot of the aggregate computation needed by the UI, while leaving simple user-specific queries, like balances, to be done by the wallet's provider.

However, that has some tradeoffs:

• It would centralize the UI s.t. it depends on a single API to be running to work.
• It's a lot of work :)

Thoughts?

[james-a-morris]

@james-a-morris thanks for raising this!

I would recommend applying domain whitelisting on Infura/Alchemy for across.to and *.vercel.app in the Infura configuration panel.

That this doesn't really protect against an attacker, right? Couldn't they just overload the endpoint from nodejs with custom headers? Going a step further, can't they replicate any request the frontend makes, so any sort of secret would also be exposed, right?

I think a good long term solution is probably to have server that sits between the frontend and infura that's protected by Cloudflare or a similar DOS protection service. That server could do a lot of the aggregate computation needed by the UI, while leaving simple user-specific queries, like balances, to be done by the wallet's provider.

However, that has some tradeoffs:

* It would centralize the UI s.t. it depends on a single API to be running to work.

* It's a lot of work :)

Thoughts?

Hi, Matt! Thanks for this detailed response. These are great points, 100%. I agree that this would not solve the case where an entity utilizes Node with custom-headers.

An alternate vulnerability: at the current moment, a user/company/product can locate these endpoints and use them in a separate dApp with a similar configuration to Across (having client-code directly interact with Infura). Any web traffic that this dApp gets will effectively share a usage quota with Across. Adding a whitelist would mitigate this entirely because the "Origin" header is a forbidden header name on most mainstream browsers.

--

Regarding your points on the long-term health of Across' (front/back)end, I agree wholeheartedly that a wrapper API could simplify the process and lock-down any endpoints with rate-limits, CSRF, CORS whitelisting, etc. At the same time, I also think using Alchemy/Infura directly on the client-side is also a valid approach which I've seen multiple times within various projects.

I suppose the reason for why I wanted to raise this issue is two-fold:

1. The above-mentioned vulnerability is easy to exploit if an entity wishes to circumvent paying for Alchemy/Infura. And, if that frontend happens to get a lot of traffic and the 'shared' quota is reached, it could cause every V3 Infura endpoint using b14cb6f39de44042802cf5c83d69c6f1 to fail at once. Or, it could cause Across to be liable for overage fees.
2. I've noticed this configuration issue on several protocols. Most recently, I've reached out to NuCypher/Keep/Threshold and they've since updated their configuration.

[james-a-morris]

I'm going to close this issue. I believe this is resolved 🙂

[james-a-morris]

cc'ing @pxrl for visibility.