3 ms·

Unfortunately, most of these web security standards don't work for real sites. When my app server serves a page that uses services from another subdomain, this

by jwatte 11y ago

Unfortunately, most of these web security standards don't work for real sites. When my app server serves a page that uses services from another subdomain, this breaks. When I use a CDN to cache contents, this breaks. When I terminate HTTPS and web auth at a reverse proxy and forward the request to a HTTP server, the proxy needs to know about all decisions the app server would make about origins. (The exact reasons get complex, but most of these origin policies are /not/ friendly to non-trivial site deployments)

bdupharm 11y ago
I definitely have to agree with this. It has lead to "it works in my sandbox" but breaks in our staging enviromemnt issues at work since everything in staging goes through a proxy.
- edwinjm 11y ago
  Well, I don't agree. It is certainly a nice addition to make the web more secure. I hope my bank (and every other significant website) won't toss my auth tokens to different domains. And about reverse proxies: it's a browser feature, so how can reverse proxies be a problem? The browser doesn't care what's happening behind a reverse proxy.
  - jwatte 11y ago
    Yes, let's make the web more secure! This doesn't do that. Instead, let's solve zero day advertising payloads. Let's fund a cure for email spam and phishing. Let's find a cure for site spoofing. Let's find a cure for "this dialog means I have to click OK to get on with things." Regarding "domains are controlled," that doesn't matter. If I want to serve pages from www.mydomain and static/CDN content from static.mydomain and services from api.mydomain, those are different domains. The main solution for a big site is to build all the credential and security logic into the load balancer/HTTPS terminator, which is an almost-guarantee to get version skew and security holes. All this "secure web" intention only works for small monolithic sites, and don't even solve the real security problems on the web.
    - edwinjm 11y ago
      Right. I said "nice addition".
jerf 11y ago
I think a great deal of the problem is more that the new security standards don't work for any existing sites (to speak of). Retrofitting these things on to existing sites is more work than most people are willing to take on. (I am aware of some exceptions, but many of those exceptions got there only via paying out on quite a few bug bounties first.) They're really only useful for new sites. Some of them are only useful for new sites that are security-conscious, too... my bank's web access portal touches only three domains, all owned by the bank. (Although I'm suspicious about the check-ordering component, which I didn't count in that 3.) They going to have an easier time implementing this sort of feature than someone trying to bring in twelve different advertisers and trackers and dicking around with iframes and whoknowswhat. But if you never put them in the browsers because "nobody" can use them, it is a certainty that nobody ever will. Personally, I can't say as I mind some security features that will discourage splaying web sites across dozens of unrelated domains....
Too 11y ago
Isnt the whole purpose of a CDN to be stateless and only serve all the heavy static assets? It shouldnt require any cookies.

by jwatte 11y ago

bdupharm 11y ago

I definitely have to agree with this. It has lead to "it works in my sandbox" but breaks in our staging enviromemnt issues at work since everything in staging goes through a proxy.

edwinjm 11y ago
Well, I don't agree. It is certainly a nice addition to make the web more secure. I hope my bank (and every other significant website) won't toss my auth tokens to different domains. And about reverse proxies: it's a browser feature, so how can reverse proxies be a problem? The browser doesn't care what's happening behind a reverse proxy.
- jwatte 11y ago
  Yes, let's make the web more secure! This doesn't do that. Instead, let's solve zero day advertising payloads. Let's fund a cure for email spam and phishing. Let's find a cure for site spoofing. Let's find a cure for "this dialog means I have to click OK to get on with things." Regarding "domains are controlled," that doesn't matter. If I want to serve pages from www.mydomain and static/CDN content from static.mydomain and services from api.mydomain, those are different domains. The main solution for a big site is to build all the credential and security logic into the load balancer/HTTPS terminator, which is an almost-guarantee to get version skew and security holes. All this "secure web" intention only works for small monolithic sites, and don't even solve the real security problems on the web.
  - edwinjm 11y ago
    Right. I said "nice addition".

jerf 11y ago

I think a great deal of the problem is more that the new security standards don't work for any existing sites (to speak of). Retrofitting these things on to existing sites is more work than most people are willing to take on. (I am aware of some exceptions, but many of those exceptions got there only via paying out on quite a few bug bounties first.) They're really only useful for new sites. Some of them are only useful for new sites that are security-conscious, too... my bank's web access portal touches only three domains, all owned by the bank. (Although I'm suspicious about the check-ordering component, which I didn't count in that 3.) They going to have an easier time implementing this sort of feature than someone trying to bring in twelve different advertisers and trackers and dicking around with iframes and whoknowswhat. But if you never put them in the browsers because "nobody" can use them, it is a certainty that nobody ever will. Personally, I can't say as I mind some security features that will discourage splaying web sites across dozens of unrelated domains....

Too 11y ago

Isnt the whole purpose of a CDN to be stateless and only serve all the heavy static assets? It shouldnt require any cookies.