4 ms·

Putting a proxy on your own hostname solves the performance problem, but you need something that parses and re-sends requests, not just a general HTTP proxy - o

Putting a proxy on your own hostname solves the performance problem, but you need something that parses and re-sends requests, not just a general HTTP proxy - otherwise, the third party can e.g. serve malicious Javascript code to your users within your origin.

yomly 8y ago
Are you able to elaborate further on what attack vector you're thinking of (if only so I can google it) - JSON hijacking maybe? The implicit assumption being that internally everything trusts the proxy?
- graystevens 8y ago
  I believe they are referring to proxying requests to third parties, rather than the first part of the post which refers to proxying to your own backend. Proxying requests to a third-party will mean browser security features like CORS will assume they are entirely safe due to them appearing to come from your domain, and not “gist.github.com” etc.
dasil003 8y ago
I'm not following this. In the given example you would configure a proxy to route /api requests to your API cluster. How would an attacker inject a different backend origin?
- tptacek 8y ago
  They wouldn't, but if you proxy arbitrary requests for UnicornGifs.sexy through your CatSharing.com backend, and UnicornGifs.sexy gets owned up (or even just mischievous), it can now generate malicious content in the same origin as CatSharing.com --- the browser can't differentiate which is which. And that forged CatSharing content will be valid in any page on CatSharing.com, not just the specific pages that include it. The point is that when you serverside-proxy requests to third parties, you're implicitly trusting the third party to control the DOM for any app in your domain.
  - dasil003 8y ago
    Oh right, I missed the last sentence where OP suggested proxying to third parties.
  - krallja 8y ago
    How is that different from the unproxied scenario? If unicorngifs.sexy gets pwned, your users get pwned, whether or not there’s a proxy in the middle.
    - deleted 8y ago
      [deleted]
    - deleted 8y ago
      [deleted]
    - wolf550e 8y ago
      If you load javascript from there - yes, but if you iframe to there - no. You can design a solution that uses cross-origin browser protection to protect your users from getting owned in case a partner is compromised.
tootie 8y ago
I'm assuming this is a trusted endpoint. Either something you own or a vendor with a contract. If you're calling random endpoints from your pages, then that's another kettle of fish.
- JoachimSchipper 8y ago
  Yes, sorry for writing such a short message - I figured you were probably aware of these considerations, but I was pretty sure that not all your readers were. ;-)

yomly 8y ago

Are you able to elaborate further on what attack vector you're thinking of (if only so I can google it) - JSON hijacking maybe? The implicit assumption being that internally everything trusts the proxy?

graystevens 8y ago
I believe they are referring to proxying requests to third parties, rather than the first part of the post which refers to proxying to your own backend. Proxying requests to a third-party will mean browser security features like CORS will assume they are entirely safe due to them appearing to come from your domain, and not “gist.github.com” etc.

dasil003 8y ago

I'm not following this. In the given example you would configure a proxy to route /api requests to your API cluster. How would an attacker inject a different backend origin?

tptacek 8y ago
They wouldn't, but if you proxy arbitrary requests for UnicornGifs.sexy through your CatSharing.com backend, and UnicornGifs.sexy gets owned up (or even just mischievous), it can now generate malicious content in the same origin as CatSharing.com --- the browser can't differentiate which is which. And that forged CatSharing content will be valid in any page on CatSharing.com, not just the specific pages that include it. The point is that when you serverside-proxy requests to third parties, you're implicitly trusting the third party to control the DOM for any app in your domain.
- dasil003 8y ago
  Oh right, I missed the last sentence where OP suggested proxying to third parties.
- krallja 8y ago
  How is that different from the unproxied scenario? If unicorngifs.sexy gets pwned, your users get pwned, whether or not there’s a proxy in the middle.
  - deleted 8y ago
    [deleted]
  - deleted 8y ago
    [deleted]
  - wolf550e 8y ago
    If you load javascript from there - yes, but if you iframe to there - no. You can design a solution that uses cross-origin browser protection to protect your users from getting owned in case a partner is compromised.

tootie 8y ago

I'm assuming this is a trusted endpoint. Either something you own or a vendor with a contract. If you're calling random endpoints from your pages, then that's another kettle of fish.

JoachimSchipper 8y ago
Yes, sorry for writing such a short message - I figured you were probably aware of these considerations, but I was pretty sure that not all your readers were. ;-)