data: URIs

Post a reply

Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:
BBCode is ON
[img] is ON
[url] is ON
Smilies are ON
Topic review
   

Expand view Topic review: data: URIs

Re: data: URIs

by baptx » Tue May 19, 2015 5:38 pm

NoScript, since version 2.6.9.20rc1 released on March 28, 2015 is breaking data: URIs, we cannot open them unless we "allow scripts globally". In about:config, noscript.allowURLBarJS is set to true and the problem is still here.
I started talking about this bug in another thread (data:-URLs cannot be whitelisted) and shared a way to fix it (by removing "else if" block in Policy.js, line 560): viewtopic.php?f=10&t=20221&p=76079#p75748
Can someone merge the fix in the next update? I don't think there is an official git repository for NoScript. Currently NoScript users cannot right click on an HTML5 canvas and "View Image" (data:image/png;base64,xxxxx). We also can't open in URL bar data:text/html,<iframe src="http://www.youtube.com/embed/video_ID"> but we have to use javascript:document.location = "data:text/html,<iframe src=\"http://www.youtube.com/embed/video_ID\">".

Bug report: viewtopic.php?f=10&t=20221

Re: data: URIs

by barbaz » Sun Mar 29, 2015 12:47 am

@GloriaTMoeller: Try NoScript latest development build 2.6.9.20rc1, it has much safer and more expected behavior regarding data URIs; hopefully the answers you got in this thread will make more sense then.

Re: data: URIs

by Giorgio Maone » Sat Mar 28, 2015 7:14 pm

I'm well aware that data: URI entered in the location bar have a null principal now.
Nevertheless, to a NoScript user, who disables JavaScript by default often as a pre-emptive measure against 0 day vulnerability exploitation, even the execution of scripts with a null principal may be an unacceptable risk if the source is not fully verified, because even with a null principal a 0 day could be exploited.
Therefore, just like before the null principal change had landed, data: and javascript: URIs were considered dangerous to the "regular" user because of the socially engineered XSS risk, so we consider them dangerous and worth a (bypassable) warning to NoScript users because of the socially engineered bug exploitation risk.

Re: data: URIs

by GloriaTMoeller » Sat Mar 28, 2015 1:05 pm

Here are the details regarding how FF6+ treats javascript: and data: URIs:
https://bugzilla.mozilla.org/show_bug.cgi?id=656433

Re: data: URIs

by barbaz » Wed Mar 25, 2015 4:55 pm

OK based on your latest post I've done some testing on Firefox 36 and the behavior I'm getting really doesn't seem right, I think there maybe some bugs in NoScript's handling of data URIs...

Re: data: URIs

by GloriaTMoeller » Wed Mar 25, 2015 3:21 pm

barbaz wrote:
GloriaTMoeller wrote:
barbaz wrote:Because they can have effect on the page on which they're typed/pasted, and users who can't vet them for themseleves should therefore probably not be messing with it.
It sounds like you are referring to the issue that was fixed in Firefox 6. Or what is the difference between the issue fixed in FF 6 and what you are describing?
Firefox/Gecko has for a long time not allowed javascript or data URIs typed or pasted in the address bar at all. NoScript restores that functionality but keeps it behind an about:config preference.
I just tested in a vanilla profile (without NoScript installed) of the current version of Firefox (36.0.4) ... Firefox does not block data: URIs typed or pasted into the address bar.

I also tested Firefox 6.0 (from https://ftp.mozilla.org/pub/mozilla.org ... n32/en-US/) ... again, Firefox does not block data: URIs typed/pasted into the address bar. Presumably, Firefox hasn't blocked data: URIs typed/pasted into the address bar anywhere in between.
barbaz wrote:
GloriaTMoeller wrote:If there is no longer a special danger to data: URIs in the location bar,
The "special danger" that I'm aware of has nothing to do with Firefox but with the way the functionality is provided by *NoScript* itself.
If the above does not address this, please explain what NoScript does that allows for a special danger.
barbaz wrote:
GloriaTMoeller wrote:then they should be treated like any other content JavaScript (i.e. they should respect the user's setting for whether JavaScript is enabled for content).
They ARE treated like other content JS in general. The only exception is if you type it yourself in the address bar or run bookmarklet, where.. why would you want it script-blocked?
We both agree that NoScript is applying an exception to disallow data: URIs typed or pasted into the address bar ... but unless there is a security distinction (versus clicking a data: URI hyperlink) that justifies applying this exception (versus how content JS is treated), the result is that NoScript is less usable with no added security benefit, and the message that NoScript displays to the user also gives the false impression that there is a special danger (as compared with clicking a data: URI hyperlink), which is not true.
barbaz wrote:
GloriaTMoeller wrote:Otherwise the user has to also disable the javascript: URI protection (a different category of attack vector) to get data: URIs to work in the location bar.
So what? Either the user can vet javascript and data URIs for themselves or they can't. It's all to help prevent social engineering attacks against the users who can't; users who can vet those for themselves don't need the protection at all.
You have not outlined a distinction for why a data: URI typed/pasted into the address bar needs to be vetted differently from a data: URI hyperlink clicked by the user in FF6+. You have not outlined a scenario in which social engineering could be used for a data: URI typed/pasted into the address bar versus a data: URI hyperlink clicked by the user in FF6+.

If a distinction can not be drawn between behavior of a data: URI executed from the address bar and a data: URI executed from a user click on a hyperlink, then the same preference should control both.

Re: data: URIs

by barbaz » Tue Mar 24, 2015 7:54 pm

GloriaTMoeller wrote:
barbaz wrote:Because they can have effect on the page on which they're typed/pasted, and users who can't vet them for themseleves should therefore probably not be messing with it.
It sounds like you are referring to the issue that was fixed in Firefox 6. Or what is the difference between the issue fixed in FF 6 and what you are describing?
Firefox/Gecko has for a long time not allowed javascript or data URIs typed or pasted in the address bar at all. NoScript restores that functionality but keeps it behind an about:config preference.
GloriaTMoeller wrote:If there is no longer a special danger to data: URIs in the location bar,
The "special danger" that I'm aware of has nothing to do with Firefox but with the way the functionality is provided by *NoScript* itself.
GloriaTMoeller wrote:then they should be treated like any other content JavaScript (i.e. they should respect the user's setting for whether JavaScript is enabled for content).
They ARE treated like other content JS in general. The only exception is if you type it yourself in the address bar or run bookmarklet, where.. why would you want it script-blocked?
GloriaTMoeller wrote:Otherwise the user has to also disable the javascript: URI protection (a different category of attack vector) to get data: URIs to work in the location bar.
So what? Either the user can vet javascript and data URIs for themselves or they can't. It's all to help prevent social engineering attacks against the users who can't; users who can vet those for themselves don't need the protection at all.

Are you asking this because you have a specific data URI in mind you'd like to access and you can't tell whether it's safe? If so feel free to post it here or PM it to a moderator (me, GµårÐïåñ, therube, or Thrawn) and one of us can vet it for you if you can't vet it for yourself.
GloriaTMoeller wrote:At the very least, this should be moved to a preference separate from noscript.allowURLBarJS
For reasons stated above, my vote is to leave it as-is.

Re: data: URIs

by GloriaTMoeller » Tue Mar 24, 2015 1:09 pm

barbaz wrote:Because they can have effect on the page on which they're typed/pasted, and users who can't vet them for themseleves should therefore probably not be messing with it.
It sounds like you are referring to the issue that was fixed in Firefox 6. Or what is the difference between the issue fixed in FF 6 and what you are describing?
barbaz wrote:IIRC by default NoScript script-blocks the hyperlinked data URI but not the one you type/paste in the address bar. I don't think it's related to that statement about Gecko 6.0.
If there is no longer a special danger to data: URIs in the location bar, then they should be treated like any other content JavaScript (i.e. they should respect the user's setting for whether JavaScript is enabled for content). Otherwise the user has to also disable the javascript: URI protection (a different category of attack vector) to get data: URIs to work in the location bar.

At the very least, this should be moved to a preference separate from noscript.allowURLBarJS

Re: data: URIs

by barbaz » Sun Mar 22, 2015 5:47 pm

GloriaTMoeller wrote:1) Could you please explain to me the danger in allowing data URIs to be typed/pasted into the address bar?
Because they can have effect on the page on which they're typed/pasted, and users who can't vet them for themseleves should therefore probably not be messing with it.
GloriaTMoeller wrote:How is this more of a concern than a hyperlink containing the same data: URI (which NoScript does not block)?
IIRC by default NoScript script-blocks the hyperlinked data URI but not the one you type/paste in the address bar. I don't think it's related to that statement about Gecko 6.0.
GloriaTMoeller wrote:2) If the security issue is not resolved by the changes in Gecko 6.0 ... I noticed that the NoScript error message about this comes up even if the data: URI is neither typed nor pasted ... in the case where the data: URI is bookmarked and the user types the bookmark name into the URL bar and then selects that bookmark -- it seems that either NoScript should allow this through, or should update the error message wording to match this behavior.
How is it supposed to tell the difference between that and actually typing/pasting it in...?

data: URIs

by GloriaTMoeller » Sun Mar 22, 2015 4:17 pm

javascript: and data: URIs typed or pasted in the address bar are disabled to prevent social engineering attacks.
Developers can enable them for testing purposes by toggling the "noscript.allowURLBarJS" preference.
(NoScript notification)

1) Could you please explain to me the danger in allowing data URIs to be typed/pasted into the address bar? How is this more of a concern than a hyperlink containing the same data: URI (which NoScript does not block)? Is the danger resolved by the following?:
Security
Note: Prior to Gecko 6.0, data URIs inherited the security context of the page currently in the browser window if the user enters a data URI into the location bar. Now data URIs get a new, empty, security context.
(https://developer.mozilla.org/en-US/doc ... s#Security)

2) If the security issue is not resolved by the changes in Gecko 6.0 ... I noticed that the NoScript error message about this comes up even if the data: URI is neither typed nor pasted ... in the case where the data: URI is bookmarked and the user types the bookmark name into the URL bar and then selects that bookmark -- it seems that either NoScript should allow this through, or should update the error message wording to match this behavior.

Top