New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ws-gateway websocket circumvention ? #1936
Comments
This only happens on Chromium based browsers. It works fine on Firefox and the browsers based on it. Secondly, pornhub is now using invalid hostnames to bypass WebSocket blockage and it's also happening on Chromium based browsers only, it makes me wonder why on chromium only... By the way, this is what pornhub is using as it's hostname domain for WS - ws://ws.00zasdf.pw**.**/nsoj Notice that . at the end of the domain, that makes the domain invalid and that's how it's inserting ads on chrome since the past 48 hours... |
I could reproduce. Meanwhile I created a filter to at least prevent the ads and circumvention of WebSocket until I figure what is going on. Quick look is that the WebSocket is created into an iframe with a |
"normal" filters: |
Actually, the fullest expression of a hostname has a period at the end, to represent the root zone in the DNS, which has no name; it's just that most software allows us to keep it off, and it's much easier to not type the dot at the end, and then as a result, some software developers don't properly account for the case where the trailing dot is left on. |
Yeah aside from that technical mumbo jumbo, pornhub is using that as an exploit for bypassing the blockage of WS on chrome, that's the point here and because of this, uBO isn't able to detect the WS connection either!! |
https://issues.adblockplus.org/ticket/4372#comment:6
|
uBO can handle the dot at the end of a FQDN -- this is not the issue here. |
I figured that since this was only happening on Chrome and not on uBO on Firefox. So what was the issue really ? |
tested ubo 1.9 , chrome 53
|
These are all from embedded frames. The new code does not detect WebSocket connections, it just injects a CSP directive preventing such connections from occurring at all, and when that policy is injected, it creates a log entry -- just like when inline-scripting is blocked, a log entry is created as well, even if uBO does not detect the execution of inline scripts. However, the CSP directive should not be injected for embedded frames not being a target of the filter, this needs fixing (this is true for the CSP to prevent inline-script too, which means the bug has existed since a long time). |
Fix verified working with the following test case:
Result before fix: demo not working. Result after fix: demo working. |
For the popup, this should be added to EasyList: |
I know, but ubo should not close even the test page or it happens only for me ? |
The test page did not close for me. When I clear the cookies and refresh the page and click anywhere on the page, I get an alert about "Chrome PDF viewer" and at the same time a nasty popup opens and does not close. |
Did you clear "local storage" too ? |
I'm talking about 1.9.0, unchecking "ublock filters", deleting cookies + local storage, all on that page above (parentherald) |
it's weird. Without adding this filter using the filter it seems ok. |
Looks like the
Not sure I follow. That is why the |
well ... disabling "ublock filters" the filter So, it was all generated by the websocket, sorry. |
http://www.parentherald.com/articles/63071/20160824/the-pirate-bay-tpb-shut-down-imminent-after-service-partner-faces-piracy-lawsuit.htm
see also
https://issues.adblockplus.org/ticket/4372
The text was updated successfully, but these errors were encountered: