Fingerprint scripts (JS et al.) [ENCHANCEMENT PROPOSAL]

[someguy]

Hypothetical situation:
I whitelist a website which gets compromised some time down the line, and, unbeknownst to me, starts serving malicious javascript (or malicious flash, or malicious whatever).

If my understanding of NoScript is correct, there is nothing it could do about it currently (and my AV would also do nothing if the exploits in malicious scripts are 0-day)

Proposal is as follows:

Compute and store hash values of scripts (javascript, Flash, Java, SL, etc. etc.) on whitelisted sites and store them.

Whenever the page loads again, recompute hash and compare to hash values from the time when site was initially whitelisted.

If, suddenly, they change, or a brand-new script is found on a page after it got whitelisted, notify the user (ideally, with a handy button allowing to bring up a summary of "novelties" that were detected).
If novelties are okay-dokay, the user re-whitelists stuff he wants.
If stuff looks fishy, user blacklists novel items specifically on the page until the time when the safety of "new scripts" can be positively established.

Is it technically feasible ? Practical ?

[Giorgio Maone]

Hypothetical situation:
I whitelist a website which gets compromised some time down the line, and, unbeknownst to me, starts serving malicious javascript (or malicious flash, or malicious whatever).

If my understanding of NoScript is correct, there is nothing it could do about it currently (and my AV would also do nothing if the exploits in malicious scripts are 0-day)

Please notice that when a whitelisted website gets compromised (usually through SQL Injection), the most practical and usually only possible way to serve malicious scripts is including them from a 3rd party server fully in control of the attacker.
In this case, the new scripts would not be whitelisted (even if included from a whitelisted website) and NoScript would block them.

That said, your proposal is interesting (and already been discussed as an opt-in CSP feature by the W3C's Web Application Security Working Group, where I'm an invited expert), but maybe not practical as a by-default countermeasure because many websites include dinamically generated scripts which would become impossible to whitelist.

[Thrawn]

Some other possible countermeasures include:

• Run Firefox inside a virtual machine, or a sandbox such as Sandboxie or AppArmor, so that it can't run amok;
• Minimise the number of sites that you permanently whitelist, by giving only temporary permissions and allowing only the specific domains that you need instead of all subdomains (configurable on the Appearance tab).
• Block plugins even on whitelisted sites (Options - Embeddings - Apply these restrictions to whitelisted sites too), to minimise attack vectors.