mirror of
https://github.com/gorhill/uBlock.git
synced 2026-03-11 09:04:36 +00:00
Updated Dynamic filtering: Examples of usefulness of blocking 3rd party iframe tags (markdown)
parent
840ebb2b1b
commit
a524b35797
1 changed files with 3 additions and 1 deletions
|
|
@ -8,7 +8,9 @@ URL: <http://www.riskiq.com/resources/blog/jquerycom-malware-attack-puts-privile
|
|||
|
||||
The web site was compromised, and users of the site were served tainted web pages, which were causing a user's browser to download exploit kit from some remote servers. This was done 1st through a malicious 3rd-party `<script>`, which purpose was to dynamically create and embed a 3rd-party-sourced `<iframe>` on the page.
|
||||
|
||||
Using 3rd-party-sourced `<iframe>` to inject exploit on a user's computer is quite a common technique. Simply blocking 3rd-party `<iframe>` foils to such exploit.
|
||||
Using 3rd-party-sourced `<iframe>` to inject exploit on a user's computer is quite a common technique. [Example](http://arstechnica.com/security/2013/10/hackers-compromise-official-php-website-infect-visitors-with-malware/), [example](http://www.wired.com/2013/08/freedom-hosting/), [example](http://blog.armorize.com/2011/07/willysycom-mass-injection-ongoing.html), etc.
|
||||
|
||||
Simply blocking 3rd-party `<iframe>` by default foils such exploit.
|
||||
|
||||
In the above case, blocking 3rd-party scripts would have been even better, as the malicious code would have been prevented from creating the malicious `<iframe>` in the first place. But for users with low tolerance to site breakage, blocking 3rd-party `<iframe>` by default (i.e. on all sites by default) is really the best solution.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue