4 ms·

I was mocked at at Black Hat when I asked a question several years ago why people don't consider forward proxying all third party dependencies for the user. The

I was mocked at at Black Hat when I asked a question several years ago why people don't consider forward proxying all third party dependencies for the user. Then we could disable CSR entirely. They said that doing that would fundamentally break the web. I think that it would make it so your user could never be MITM or DNS-spoofed to a malicious imposter for that dependent service or asset. Can someone speak to those criticisms?

benmmurphy 7y ago
Technically following a http link is a cross site request.
- a1369209993 7y ago
  If the browser honors a SameSite policy on links it's the browser that's broken.
  - xg15 7y ago
    Seems that is exactly the difference between "lax" and "strict" settings: "strict" will strip cookies from all cross-site requests, "lax" will keep them for GETs. The default setting will be "lax", so following links would be fine. I think the "strict" setting is for the proposed "two sessions cookies" design pattern: You have a basic "I'm logged in" cookie with SameSite=lax and a second "I can do things" cookie with SameSite=strict. The first cookie gives you read access to your account and tracks your session - however, to perform any actions on your account, you need both cookies.
    - a1369209993 7y ago
      Links are GET requests; you do not "do things" on GET requests.
      - xg15 7y ago
        Yes, that's the point. If you e.g. clicked on a link to facebook.com and had previously logged in, the browser will send the "lax" cookie with the request, so that your session is correctly tracked and Facebook shows you the logged-in view. However, the "strict" cookie will NOT be sent, so even if by some accident you have a state-changing endpoint that accepts GETs, an attacker could still not trick you into invoking it via a link. I agree though that if you have state-changing GETs, you'll have bigger problems, so the use-case for "strict" cookies seems a bit of a niche. I suspect the common case will be "lax" everywhere and "none" for special applications - i.e. what the default is encouraging.
rictic 7y ago
I'm sorry you were mocked, it's a good question. That's an option at the individual site level – and it may be possible to use a CSP policy to enforce that no cross-site requests are made. You can definitely use CSP policy to enforce what domains scripts may be fetched and executed from. However if the standard were changed to disallow CSR in browser implementations then existing sites would be broken, i.e. it would break the web. Sometimes that's worth it, sometimes it isn't, and it's a careful balance between how many sites would be broken vs the impact of the security vulnerabilities that would be prevented. (disclosure, I work at Google, but not on Chrome (any more) and have no particular knowledge of the CSRF cookie change)
deleted 7y ago
[deleted]
quickthrower2 7y ago
Interesting question. Whether it is a good idea is going to depend on a whole bunch of architectural factors. If it's a static JS library, say JQuery, then self host it seems sensible. You can host on your own CDN if needed. What about if it is, say a credit card processing service? Well now you are dealing with credit card data through your site, so perhaps PCI compliance might apply? Also you are now being the MITM to avoid an evil MITM - so you have more responsibility than every to ensure security. Make sure your proxy is secure as possible. Does it accept bad certificates for example?
- birdyrooster 7y ago
  In theory, we can still enable end-to-end encryption while forward proxying by a separate service provider, but it might not be easy to implement. The browser would need to be smart enough to route packets through the website and verify SSL coming out of the PCI environment. This will require modifications to the OS to dynamically add static routes for dependencies. 1. Browser loads the shopping cart page on example.com to transmit credit card details 2. User enters credit card details in to the form and hits enter. 3. The browser resolves the IPs for domain api.creditmerchant.net and adds static routes for those IPs pointing to example.com 4. The browser initiates SSL connection to api.creditmerchant.net using example.com as a static route 5. The browser verifies the authenticity of the certificate and chooses ciphers for the conversation 6. The credit card details are encrypted and transmitted to api.creditmerchant.net without being exposed to example.com 7. The purchase is complete and example.com is not in scope for PCI. *. If the example.com is set as the static route for any unknown dependencies, the traffic is null routed
  - xg15 7y ago
    But then, what exactly was won? Seems to me, the request to api.creditmerchant.net is still a mostly ordinary cross-site requests, except the packets are routed through example.com - but example.com can't do anything with the packets, because they are encrypted. So api.creditmerchant.net could still inject all kinds of malicious or buggy scripts and example.com can't do anything about it. The one difference I see is that api.creditmerchant.net could restrict it's endpoints to only accept packets from example.com addresses - as they should never be called directly from a browser. This sounds like some ad-hoc CSRF protection. Was that the intention?

benmmurphy 7y ago

Technically following a http link is a cross site request.

a1369209993 7y ago
If the browser honors a SameSite policy on links it's the browser that's broken.
- xg15 7y ago
  Seems that is exactly the difference between "lax" and "strict" settings: "strict" will strip cookies from all cross-site requests, "lax" will keep them for GETs. The default setting will be "lax", so following links would be fine. I think the "strict" setting is for the proposed "two sessions cookies" design pattern: You have a basic "I'm logged in" cookie with SameSite=lax and a second "I can do things" cookie with SameSite=strict. The first cookie gives you read access to your account and tracks your session - however, to perform any actions on your account, you need both cookies.
  - a1369209993 7y ago
    Links are GET requests; you do not "do things" on GET requests.
    - xg15 7y ago
      Yes, that's the point. If you e.g. clicked on a link to facebook.com and had previously logged in, the browser will send the "lax" cookie with the request, so that your session is correctly tracked and Facebook shows you the logged-in view. However, the "strict" cookie will NOT be sent, so even if by some accident you have a state-changing endpoint that accepts GETs, an attacker could still not trick you into invoking it via a link. I agree though that if you have state-changing GETs, you'll have bigger problems, so the use-case for "strict" cookies seems a bit of a niche. I suspect the common case will be "lax" everywhere and "none" for special applications - i.e. what the default is encouraging.

rictic 7y ago

I'm sorry you were mocked, it's a good question. That's an option at the individual site level – and it may be possible to use a CSP policy to enforce that no cross-site requests are made. You can definitely use CSP policy to enforce what domains scripts may be fetched and executed from. However if the standard were changed to disallow CSR in browser implementations then existing sites would be broken, i.e. it would break the web. Sometimes that's worth it, sometimes it isn't, and it's a careful balance between how many sites would be broken vs the impact of the security vulnerabilities that would be prevented. (disclosure, I work at Google, but not on Chrome (any more) and have no particular knowledge of the CSRF cookie change)

deleted 7y ago

[deleted]

quickthrower2 7y ago

Interesting question. Whether it is a good idea is going to depend on a whole bunch of architectural factors. If it's a static JS library, say JQuery, then self host it seems sensible. You can host on your own CDN if needed. What about if it is, say a credit card processing service? Well now you are dealing with credit card data through your site, so perhaps PCI compliance might apply? Also you are now being the MITM to avoid an evil MITM - so you have more responsibility than every to ensure security. Make sure your proxy is secure as possible. Does it accept bad certificates for example?

birdyrooster 7y ago
In theory, we can still enable end-to-end encryption while forward proxying by a separate service provider, but it might not be easy to implement. The browser would need to be smart enough to route packets through the website and verify SSL coming out of the PCI environment. This will require modifications to the OS to dynamically add static routes for dependencies. 1. Browser loads the shopping cart page on example.com to transmit credit card details 2. User enters credit card details in to the form and hits enter. 3. The browser resolves the IPs for domain api.creditmerchant.net and adds static routes for those IPs pointing to example.com 4. The browser initiates SSL connection to api.creditmerchant.net using example.com as a static route 5. The browser verifies the authenticity of the certificate and chooses ciphers for the conversation 6. The credit card details are encrypted and transmitted to api.creditmerchant.net without being exposed to example.com 7. The purchase is complete and example.com is not in scope for PCI. *. If the example.com is set as the static route for any unknown dependencies, the traffic is null routed
- xg15 7y ago
  But then, what exactly was won? Seems to me, the request to api.creditmerchant.net is still a mostly ordinary cross-site requests, except the packets are routed through example.com - but example.com can't do anything with the packets, because they are encrypted. So api.creditmerchant.net could still inject all kinds of malicious or buggy scripts and example.com can't do anything about it. The one difference I see is that api.creditmerchant.net could restrict it's endpoints to only accept packets from example.com addresses - as they should never be called directly from a browser. This sounds like some ad-hoc CSRF protection. Was that the intention?