InformAction Forums

Options | General | Temporarily allow top-level sites by defalt => temporarily allow base 2nd level domains

Well it is that setting that is causing it.
Why, would be a question for Giorgio?

If you watch as a site loads, initially brightcove.com is not allowed, but as it progresses, you'll see that it is added, Allowed.

Suspect that loading any of the sites listed, http://www.brightcove.com/en/customers, will cause brightcove.com to be automatically Allowed.

Easiest way to see is to open a couple "unaffected" sites, open ONE site that uses brightcove. Let that tab have focus. Quit, then restart, loading the same sites from Session Restore. That same tab (with brightcove) should have focus, you'll see the top-level domain allowed, then as you hover the NoScript icon, you'll see brightcove added, additionally, as the page load progresses.

If you open http://www.channel5.com/, you'll see that five.tv is also allowed.

If you open http://www.channel5.com/, you'll see that five.tv is also allowed.

not when i tried - five.tv did not appear temporarily allowed

Options | General | Temporarily allow top-level sites by defalt => temporarily allow base 2nd level domains. Well it is that setting that is causing it.

that's not correct - to temporarily allow base 2nd level domains will and 'should' only allow rocsidiaz.com and sub-domains of it ie. photos.rocsidiaz.com, http://stuff.rocsidiaz.com - this setting should not allow brightcove and cloudfront

in more detail, i've partially answered one of my own questions concerning how to determine what other domains execute:





1.
load rocsidiaz.com
2.
observe brightcove.com in the allow list from noscript icon
3.
create new tab
4.
observe that platform.twitter.com and ajax.googleapis.com attempted to execute js, or whatever it may have been, and were subsequently blocked from doing so

with this in mind, brightcove.com ended up in the allow/temp list even though it didnt make an attempt to execute 'something bad' according to noscript...

it appears brightcove loads an ETAG image...

Full request URI: http://www.etonline.com/brightcove/hls/ ... 2911076001

...which is an image part of a brightcove platform flash plugin

follow the screen grabs below to observe how flash cookies are received from sadmin.brightcove.com and a resultant URL redirect block from ghostery











here's the tcp stream:


GET /crossdomain.xml HTTP/1.1
Host: www.etonline.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

HTTP/1.1 200 OK
Server: Apache
Last-Modified: Fri, 31 Aug 2012 13:18:53 GMT
ETag: "f9726-2af-4c88fa2257615"
Accept-Ranges: bytes
Content-Length: 687
Content-Type: application/xml
Cache-Control: max-age=300
Date: Tue, 09 Jul 2013 07:53:57 GMT
Connection: keep-alive

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cros ... policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.etonline.com" />
<allow-access-from domain="*.gigya.s3.amazonaws.com" />
<allow-access-from domain="*.gigyahosting1.com" />
<allow-access-from domain="stage.hyfn.s3.amazonaws.com" />
<allow-access-from domain="files.hyfn.s3.amazonaws.com" />
<allow-access-from domain="*.unicornmedia.com" />
<allow-access-from domain="*.unicornapp.com" />
<allow-access-from domain="*.unicornmediabeta.com" secure="true" />
<allow-access-from domain="*.brightcove.com" />
</cross-domain-policy>
GET /brightcove/hls/img/1242911076001/201307/3638/1242911076001_2523159108001_vs-51d37618e4b08a50fe0331db-1592194018001.jpg?pubId=1242911076001 HTTP/1.1
Host: www.etonline.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

HTTP/1.1 200 OK
Server: Apache
Last-Modified: Wed, 03 Jul 2013 01:03:17 GMT
ETag: "1b20e39-5819-4e09106e304ea"
Accept-Ranges: bytes
Content-Length: 22553
Content-Type: image/jpeg
Cache-Control: max-age=86400
Expires: Wed, 10 Jul 2013 07:53:58 GMT
Date: Tue, 09 Jul 2013 07:53:58 GMT
Connection: keep-alive

can anybody from the noscript dev team or advanced community follow up with any statement that says brightcove and cloudfront 'has not' defeated noscript's denial policies ?

i've reproduced this using firefox with a lot of add-ons (which may have caused issues) but also with clean installs on multiple OS's with only noscript installed in the add-ons (so, it would seem to suggest that multiple add-ons causing issues would not be the issue here)...

Giorgio any findings noteworthy when i sent my config ???

He said he was generally away & will be for about 1 week more.
I was going to bump this at that time.
Guessing that it is a bug rather then "defeat".

I am not seeing the behavior you report. Browsing those sites does not allow cloudfront for me.

What I will say is that the only way for a site to tamper with NoScript's whitelist would be to attack a security hole in the browser itself. I doubt that a site like Cloudfront could do that without getting found out and slammed.

You definitely haven't checked 'Temporarily Allow Top-Level Sites by Default'?

Are you, by any chance, confusing cloudfront.com with cloudfront.net?

I am not seeing the behavior you report. Browsing those sites does not allow cloudfront for me.

That makes perfect sense for rocsidiaz because it does not employ cloudfront - only brightcove
i guess this thread has gone from the initial cloudfront debarkle to brightcove & i concentrated more on rocsidiaz

What I will say is that the only way for a site to tamper with NoScript's whitelist would be to attack a security hole in the browser itself. I doubt that a site like Cloudfront could do that without getting found out and slammed.

You definitely haven't checked 'Temporarily Allow Top-Level Sites by Default'?

Yes, that setting must be enabled in order for allow base 2nd level domains to be active
my question all along is how does this setting allow other domains (cloudfront or brightcove or what-have-you) to appear temporarily allowed

Are you, by any chance, confusing cloudfront.com with cloudfront.net?

In any case, it does not matter if its .net or .com because neither should be temporarily allowed with my settings, true ?
only rocsidiaz.com and its sub domains should

have a look at all these certs stored by CertPatrol - are they used for tracking (i think so) ? I have the same for stats.ebay.com with other UID's
additionally, they get stored from external domains and not from even browsing cloudfront at all, for example

Guest wrote:

You definitely haven't checked 'Temporarily Allow Top-Level Sites by Default'?

Yes, that setting must be enabled in order for allow base 2nd level domains to be active
my question all along is how does this setting allow other domains (cloudfront or brightcove or what-have-you) to appear temporarily allowed

Well, it's possible that the site you visited is redirecting you to brightcove, which then redirects you back. That would make brightcove temporarily the top-level site, so it would be allowed.

By the way, the 'Temporarily allow top-level sites by default' setting is not recommended as a safe practice, for reasons exactly like this: you might allow something you didn't intend. It is a convenience feature for those who aren't willing to check sites and allow them manually.

have a look at all these certs stored by CertPatrol - are they used for tracking (i think so) ? I have the same for stats.ebay.com with other UID's
additionally, they get stored from external domains and not from even browsing cloudfront at all, for example

Well, NoScript doesn't try to block non-active content like images and stylesheets, so if sites are loading those from cloudfront, then they will be allowed.

Thrawn wrote:

Guest wrote:

You definitely haven't checked 'Temporarily Allow Top-Level Sites by Default'?

Yes, that setting must be enabled in order for allow base 2nd level domains to be active
my question all along is how does this setting allow other domains (cloudfront or brightcove or what-have-you) to appear temporarily allowed

Well, it's possible that the site you visited is redirecting you to brightcove, which then redirects you back. That would make brightcove temporarily the top-level site, so it would be allowed.

This pretty much explains everything "weird" reported in this thread.
Please check whether you can reproduce without that settings, and/or try to track page loads which can trigger the permission change and I'd say we've got no mystery anymore.

sure enough by disabling temporarily allow top level sites resulted in brightcove not doing 'naughty stuff'

noscript blocked sites c.brightcove.com and blocked objects coming from admin.brightcove.com

i'm off to take a 'selfie' in the spirit of the page in question

(not)