InformAction Forums

I've never seen this one before. A site that NoScript simply shows as "https://scripts" -- no TLD, nothing else. I'm concerned that if I allow this element as shown, it will allow any domain that starts with "https://scripts", is this possible?

Here is a screen:



Is this an internal NoScript object, or an incomplete entry, or something not safe? Should I allow it or forbid it? (This is at Raxco.com [PerfectDisk Defragmenter], on their credit card check-out page.)

Thanks!

It's very likely a broken <script> element.

Giorgio Maone wrote:It's very likely a broken <script> element.

Thanks for the quick reply!

Does that mean it is unsafe to allow? Will allowing it also allow all domains that start with "https://scripts" regardless of TLD?

Thanks.

Pending Giorgio's return, I'd ask first: Can you finish checking out without allowing it? If so, then do so, and don't allow it.

I've never seen a site, or a script name, that starts with https://scripts, but I'd hesitate to allow it.

If you can't check out, then as a workaround pending Giorgio's solution, you might install JSView add-on, then use it to look at which scripts are in https protocol.
If they are site scripts, or third parties that you trust, you could manually add them to the Whitelist (NS Options > Whitelist).

Also checked Recently Blocked Sites sub-menu for relevant and trusted names, such as "Temporarily allow all from raxco.com", or similar.

I hope this helps.


ETA, @ Giorgio:

FWIW, when I duplicated OP's permissions, but not allowing https/scripts, RequestPolicy did indeed show a request to "scripts". (or with full addresses enabled in RP, to "https://scripts") Very strange.

poee wrote:Does that mean it is unsafe to allow?

It's basically an invalid entry. It will probably make no difference whether you allow it, since you probably don't have an entry related to this in your hosts file and your DNS server will probably (or should at least) issue a domain-not-found response for this (since there is no such domain on the internet).

poee wrote:Will allowing it also allow all domains that start with "https://scripts" regardless of TLD?

No, it would just allow content from "https://script", e.g. if you had a SSL/TLS-enabled webserver running on your network and an entry in your hosts file mapping the domain "script" to the IP of the webserver then it would allow every script transported using HTTPS from that domain, not more, not less.

Tom T. wrote:FWIW, when I duplicated OP's permissions, but not allowing https/scripts, RequestPolicy did indeed show a request to "scripts". (or with full addresses enabled in RP, to "https://scripts") Very strange.

Well, it's possibly a valid request, e.g. in the local webserver example I just mentioned. But since RP/NS block access to it before even the hostname is resolved they can't know whether allowing it would lead to a successful request/script inclusion.

dhouwn wrote:

poee wrote:Does that mean it is unsafe to allow?

It's basically an invalid entry. It will probably make no difference whether you allow it, since you probably don't have an entry related to this in your hosts file and your DNS server will probably (or should at least) issue a domain-not-found response for this (since there is no such domain on the internet).

poee wrote:Will allowing it also allow all domains that start with "https://scripts" regardless of TLD?

No, it would just allow content from "https://script", e.g. if you had a SSL/TLS-enabled webserver running on your network and an entry in your hosts file mapping the domain "script" to the IP of the webserver then it would allow every script transported using HTTPS from that domain, not more, not less.

Tom T. wrote:FWIW, when I duplicated OP's permissions, but not allowing https/scripts, RequestPolicy did indeed show a request to "scripts". (or with full addresses enabled in RP, to "https://scripts") Very strange.

Well, it's possibly a valid request, e.g. in the local webserver example I just mentioned. But since RP/NS block access to it before even the hostname is resolved they can't know whether allowing it would lead to a successful request/script inclusion.

Some bad person who sees this thread (possibly reprinted eslewhere) may set up such a domain name, containing malicious script, of course. So I'd still not allow it, But I'd report it to the webmaster of the site.

And place telephone orders with raxco until then, if necessary.

IDK whether OP has RequestPolicy. Just mentioning that the "broken <SCRIPT> element" to which Giorgio referred is in fact attempting a cross-site call to this domain, which we hope is still non-existent.