4 ms·

Smokescreen by Stripe [1] is the only reliable way I’ve seen apps handle untrusted URL accesses. It’s an open source CONNECT proxy project. Validating the URL

by plasma 5y ago

Smokescreen by Stripe [1] is the only reliable way I’ve seen apps handle untrusted URL accesses. It’s an open source CONNECT proxy project. Validating the URL at the app layer is difficult because a redirect could happen to an attacker URL, or DNS rebinding attack, etc, proxying via Smokescreen seems the most reliable if you’re dealing with user controlled arbitrary URLs. [1] https://github.com/stripe/smokescreen https://github.com/stripe/smokescreen

Nextgrid 5y ago
I don't see how this could help. The main danger here seems to be that the custom proxy is adding an authentication token for internal resources which is leaked if an external resource is accidentally requested, but at the same time, the auth token being included is actually required for the functionality they're trying to implement.
- plasma 5y ago
  It would have stopped the request being made to the attackers server in the first place. Smokescreen sits between your app server and the destination URL that was requested, as a proxy server, that has ACLs/rules about what URLs and domains it allows to talk to on behalf of the app server. You define allowed or blocked domains/routes in Smokescreen, and it’s the one that decides to access the remote URL or not. So in the above example, the app server would still have been tricked to request the attackers URL with its auth token included, but smokescreen would have realised that server/domain isn’t in its allow list, and blocked the app server attempt to access the attackers sever with the auth token by refusing to even attempt to connect to the attackers server in the first place (and returns a HTTP error back to the app server).
emptysea 5y ago
Is smokescreen an alternative to Squid? Seems like they cover similar ground, but I’ve never heard of smokescreen before. https://github.com/squid-cache/squid https://github.com/squid-cache/squid

by plasma 5y ago

Nextgrid 5y ago

I don't see how this could help. The main danger here seems to be that the custom proxy is adding an authentication token for internal resources which is leaked if an external resource is accidentally requested, but at the same time, the auth token being included is actually required for the functionality they're trying to implement.

plasma 5y ago
It would have stopped the request being made to the attackers server in the first place. Smokescreen sits between your app server and the destination URL that was requested, as a proxy server, that has ACLs/rules about what URLs and domains it allows to talk to on behalf of the app server. You define allowed or blocked domains/routes in Smokescreen, and it’s the one that decides to access the remote URL or not. So in the above example, the app server would still have been tricked to request the attackers URL with its auth token included, but smokescreen would have realised that server/domain isn’t in its allow list, and blocked the app server attempt to access the attackers sever with the auth token by refusing to even attempt to connect to the attackers server in the first place (and returns a HTTP error back to the app server).

emptysea 5y ago

Is smokescreen an alternative to Squid? Seems like they cover similar ground, but I’ve never heard of smokescreen before. https://github.com/squid-cache/squid https://github.com/squid-cache/squid