Unable to block browser take-over scripts in malware/phishing sites, or at least block redirects to such sites

[vassudanagunta]

An evil and ever more common phishing trick is to redirect a search result to a site that throws up an impossible to dismiss popup window warning that your system is comprimised by viruses. For example:

(warning, do not click on these unless you're prepared to kill your browser)
http://mac-system-alert.com/warning.html
http://informationdoc.com/rr/

I've made many attempts to craft custom filters and dynamic filters to prevent these. I'm pretty sure there is no way to do so. NoScript would do the trick, but it doesn't exist for Safari. It seems like this is something that uBlock could or should do.

This article describes the problem and maintains a list of such sites:
https://sites.google.com/site/appleclubfhs/support/advice-and-articles/browser-popup-hijack-safari

[gorhill]

Blocking inline scripts worked for the two sites offered as example. Inline script can be blocked using static filtering:

||mac-system-alert.com^$inline-script
||informationdoc.com^$inline-script

Further adding:

||mac-system-alert.com^
||informationdoc.com^

Cripples them more.

[gorhill]

Actually just using plain:

||mac-system-alert.com^
||informationdoc.com^

Worked too.

https://sites.google.com/site/appleclubfhs/support/advice-and-articles/browser-popup-hijack-safari

Someone should use the information in that list to create a ABP/uBlock compatible filter lists which I would enable by default in uBlock.

[gorhill]

Closed due to lack of feedback.

[vassudanagunta]

Sorry I didn't get back to you quicker. It is not working for me. Maybe I am doing something wrong? I added all of the following to the My Filters tab of uBlock Dashboard:

||mac-system-alert.com^$inline-script
||informationdoc.com^$inline-script
||mac-system-alert.com^
||informationdoc.com^

Then I clicked on http://mac-system-alert.com/warning.html, at which point a popup hijacked Safari and I was forced to force-quit Safari to escape.

[gorhill]

Maybe Safari does not support the blocking of inline scripts, I don't remember.

Some thoughts...

These sites are definitely a threat to users. One thing that would work is to block the main document, i.e. the root document would not be downloaded from the site. This is something that ABP filter syntax does not semantically support.

There is the document option, but it is always used as an exception in ABP. So I propose that uBlock support the document option for when a whole document has to be blocked. document option as an exception still won't be supported though, as per #5.

[vassudanagunta]

Thanks for reopening. I'd like to understand what's going on better, and help in any way I can (though I'm a novice JS coder).

I get that ||mac-system-alert.com^$inline-script may not work because of a Safari limitation, but I am unclear about ||mac-system-alert.com^. Is it because ABP filter rules only apply to resources of a page, but never the page itself? In other words, this rule only limits loading images, frames, and scripts from mac-system-alert.com referenced by any root document, but it does not prevent loading of root pages on that domain, such as by clicking on http://mac-system-alert.com/warning.html?

I can attempt to implement the JS if it would help... in which case some clues as to where I should start looking at the code would be helpful :)

[gorhill]

Is it because ABP filter rules only apply to resources of a page, but never the page itself?

Yes.

I believe document is not used anymore anywhere in a blocking filter, so we can resurrect its original purpose, which was to block the pages themselves. In uBlock, I will probably choose to redirect to about:blank.

[vassudanagunta]

I think it a strange and inconsistent syntax that ||mac-system-alert.com^$document would be "greater" than ||mac-system-alert.com^ rather than the other way around.

As to redirect, I would recommend redirecting to a static (hardcoded) page explaining what just happened, perhaps even showing the list and filter rule that applied.

I believe document is not used anymore anywhere in a blocking filter, so we can resurrect its original purpose, which was to block the pages themselves. In uBlock, I will probably choose to redirect to about:blank.

Hm, I wonder why is this necessary? Those sites can already be blocked in uBlock either by Dynamic Filtering or by simply adding the hostname to My Filters. Using document could be a future incompatibility if ABP ever reintroduces this option in some other way.

EDIT: Not quite ....

[vassudanagunta]

Ok, I looked at https://adblockplus.org/en/filter-cheatsheet and now understand that $ is used for options, and what the syntax is saying is that by default filters only apply to resources, and that if you want them to apply to root pages, you must use an option, in this case document. If so, I guess it's not inconsistent. Would be less strange for the default to be everything, and an option required for the filter to only apply to resources, but of course you can't change ABP filter syntax.

[gorhill]

@tlu1024 Because to prevent the behavior reported in issue, one need to block inline script, which I believe is not possible in Safari -- whether through static or dynamic filtering.

Anyways, the ability to whole block a site has been requested before, and here we have a very valid reason for this: those sites are dangerous, it's their primary purpose. To have the ability to block them whole is a good thing, especially for non-technical users, who are actually the target for such sites.

The original purpose of document was to block the page, so I am just complying with the definition. What changed is that nobody use it anymore as blocking filter. I will just bring back support for its defined use as blocking filter option.