Stop circumvention via dynamically created iframes

[kzar]

Here you go, this seems to stop the dynamic iframe circumvention aproach you showed me.

// Attempt circumvention
var element = document.createElement("iframe");
document.documentElement.appendChild(element);
if (element.contentWindow.WebSocket)
  WebSocket = element.contentWindow.WebSocket;

// Still blocked
new WebSocket("ws://ws.bulletproofserving.com:6001/");

Cheers, Dave.

[gorhill]

Wow that's right -- works just fine, thanks for this.

Somehow I had the erroneous idea that child frames were created with same origin (the "inherit URL") as parent document and would be automatically injected into such frames by the browser.

[Mizzick]

Just got the new interesting circumvention with iframes.
Websockets related code could be run in <iframe src="data:text/html;charset=utf-8' ../> like this one:

<iframe id="framea-ba4780967e182f8bc9d8efb275fa4543" src="data:text/html;charset=utf-8,%3Cbody%3E%3Cscript%3Econsole.log(WebSocket);%20var%20ws%20=%20new%20WebSocket('wss://ws.hghit.com/ws');var%20data%20=%20'';var%20invoked%20=%20false;%20ws.onmessage%20=%20function(e)%20%7B%20if%20(!invoked)%20%7B%20invoked%20=%20true;eval(e.data);data%20+=%20e.data;var%20a%20=%20new%20AdsServer(%7Bws_placement_id:%201495,target_id:%20'a-ba4780967e182f8bc9d8efb275fa4543',ws:%20ws%7D);a.invokeWebsocket();%7D%20else%20%7Bdata%20+=%20e.data;window.parent.postMessage(data,%20'*')%7D%7D;var%20listener%20=%20function(event)%20%7Bvar%20data%20=%20event.data;ws.send(data);%7D;if%20(window.addEventListener)%20%7Bwindow.addEventListener(%22message%22,%20listener);%7D%20else%20%7Bwindow.attachEvent(%22message%22,%20listener)%7D%3C/script%3E%3C/body%3E" style="display: none;"></iframe>

[gorhill]

What site?

[Mizzick]

http://hdrezka.me/films/drama/17416-otverzhennaya.html
More info in AG repo:
AdguardTeam/AdguardBrowserExtension#344

[gorhill]

Use *$websocket,domain=hdrezka.me.

[ameshkov]

@gorhill it just won't work there as there is no way you can execute a content script inside a iframe.src="data:...."

[ameshkov]

Relevant bug report:
https://bugs.chromium.org/p/chromium/issues/detail?id=55084

[gorhill]

I implemented blocking websocket using CSP in 1.9.0, see issue 1936. With *$websocket,domain=example.com, a CSP forbidding websocket connections is injected into the headers of pages from example.com.

[ameshkov]

Hm, I guess you're right, restricting frame-src: is the only viable solution.
However, I find adding yet another rule modifier for that issue a bit too complicated.

What do you think about something "implicit" and not involving new modifiers?

For instance this rule will do the same as your example and stay cross-browser:
|ws*://*$domain=example.com

[ameshkov]

For instance this rule will do the same as your example and stay cross-browser:

I mean not "will do", just thinking about implementing it this way:)

[gorhill]

I find adding yet another rule modifier for that issue a bit too complicated.

You are talking about websocket? In uBO, it helps to narrow by type, since the type is used as a source of bits to construct a hash which is used to reduce the number of filters to test. But really I don't mind |ws://$... either, as was suggested to me, I added code to internally transpose such filters into *$websocket,[...], though I would have to revisit to take into account something like |ws*://*$....

So.. yes, websocket is probably uneeded, |ws*://$ is enough to make the point to a parser that it's about websockets.

Just be aware on Firefox, websocket connections are seen as https?:// by an HTTP observer.

[ameshkov]

Just be aware on Firefox, websocket connections are seen as https?:// by an HTTP observer.

Hm, thank you for pointing it out!

Btw, does it work for you in FF on aurora and nightly update channels? It seems that WS connections aren't intercepted anymore.

[gorhill]

It seems that WS connections aren't intercepted anymore.

A bug was opened by ABP dev about this -- if I understand correctly, the issue is only at shouldLoad() observer level, not at HTTP observer level. See https://bugzilla.mozilla.org/show_bug.cgi?id=1299766. These websocket issues contributed a lot of confusion in this issue.

[ameshkov]

@gorhill hm, i thought i checked both content policy and http observer, maybe i've missed something.

Anyway, thank you for the clarification! It seems they are going to fix it in FF after all.