data: URIs

[GloriaTMoeller]

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.

[barbaz]

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.

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.

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...?

[GloriaTMoeller]

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?

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

[barbaz]

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.

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.

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?

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.

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.

[GloriaTMoeller]

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.

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.

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.

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.

[barbaz]

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...

[GloriaTMoeller]

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

[Giorgio Maone]

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.

[barbaz]

@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.

[baptx]

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