4 ms·

The web needs to start moving towards a strong same-origin policy for all embedded content-- require sites to proxy requests if they want third party content.

by nullc 7y ago

The web needs to start moving towards a strong same-origin policy for all embedded content-- require sites to proxy requests if they want third party content. The first step could be sending CORS preflight, then requiring it, then just not allowing cross origin to different domains (but allow sub-/sibling- domains).

goalieca 7y ago
The problem right now is that the originating server sets an http response header. Given the MITM can modify that header.. it indicates things need to be done automagically in the browser. But that will break A LOT.
cortesoft 7y ago
Not sure how much that would help... they could just have their own domain be a cname to the target. Your defense idea might stop layer 7 attacks, but not lower level ones.
1shooner 7y ago
How would this be different than the CNAME cloaking[1] currently being used by data collectors to circumvent ad blocking software? 1. https://news.ycombinator.com/item?id=21604825 https://news.ycombinator.com/item?id=21604825
- mrgreenfur 7y ago
  I agree that this is the next step in the ad-tech / spy-tech war. uBlock recently found an approach for blocking cnamed origins: https://github.com/gorhill/uBlock/commit/3a564c199260a857f3d78d5f12b8c3f1aa85b865 https://github.com/gorhill/uBlock/commit/3a564c199260a857f3d...
hinkley 7y ago
About a month ago we were discussing this and a few of us came to the conclusion that an eventually-required CORS header for cross-origin GETs would be a good thing. CDNs and SSO services could start sending this header so they can stay in business when the browsers turn off all cross-origin requests by default. Unfortunately (from my perspective) that'll do nothing to stop third party ad tracking but you can't have everything, I suppose.
burtonator 7y ago
Can't the CORS preflight, by itself, be a DoS?
- thw0rted 7y ago
  If you read the OP they say they were specifically crafting links that led to an image resizing webservice, so each load wasn't just requesting static content, it was consuming non-trivial compute cycles. Of course you can have a DDoS comprised of tons of requests for HTML or JPGs but the added overhead of performing a "resize" was at least a part of the plan. Failing a pre-flight would have eliminated that hit.
deleted 7y ago
[deleted]

by nullc 7y ago

goalieca 7y ago

The problem right now is that the originating server sets an http response header. Given the MITM can modify that header.. it indicates things need to be done automagically in the browser. But that will break A LOT.

cortesoft 7y ago

Not sure how much that would help... they could just have their own domain be a cname to the target. Your defense idea might stop layer 7 attacks, but not lower level ones.

1shooner 7y ago

How would this be different than the CNAME cloaking[1] currently being used by data collectors to circumvent ad blocking software? 1. https://news.ycombinator.com/item?id=21604825 https://news.ycombinator.com/item?id=21604825

mrgreenfur 7y ago
I agree that this is the next step in the ad-tech / spy-tech war. uBlock recently found an approach for blocking cnamed origins: https://github.com/gorhill/uBlock/commit/3a564c199260a857f3d78d5f12b8c3f1aa85b865 https://github.com/gorhill/uBlock/commit/3a564c199260a857f3d...

hinkley 7y ago

About a month ago we were discussing this and a few of us came to the conclusion that an eventually-required CORS header for cross-origin GETs would be a good thing. CDNs and SSO services could start sending this header so they can stay in business when the browsers turn off all cross-origin requests by default. Unfortunately (from my perspective) that'll do nothing to stop third party ad tracking but you can't have everything, I suppose.

burtonator 7y ago

Can't the CORS preflight, by itself, be a DoS?

thw0rted 7y ago
If you read the OP they say they were specifically crafting links that led to an image resizing webservice, so each load wasn't just requesting static content, it was consuming non-trivial compute cycles. Of course you can have a DDoS comprised of tons of requests for HTML or JPGs but the added overhead of performing a "resize" was at least a part of the plan. Failing a pre-flight would have eliminated that hit.

deleted 7y ago

[deleted]