"If anyone knows of a noscript equivalent add-on for Internet Explorer 7, please ... leave a comment below"

I use Safari on OS X and Firefox on Windows myself and wouldn't like to chance anything else, but it is certainly possible to approach the web with a ban-everything-and-whitelist policy in IE. What you do is to take advantage of IE's security zones. Set IE to deny all active content in the Internet Zone - move the slider to high and make any other adjustments manually that you need to. Go *at least* as tough as this - and probably tougher:

http://windowssecrets.com/comp/061026/#story1

Then, whenever you find a site that needs JavaScript (or any other active content) to work, but that you nevertheless trust - e.g., Amazon - you paste the URL into IE's trusted zone. There's a fuller description here:

http://www.grc.com/sn/SN-038.htm

In effect, this is doing the same as "NoScript" - banning everything and whitelisting what you trust. The reverse in all its forms - "Default Permit" - has been called one of the six "dumbest ideas" in computer security:

http://www.ranum.com/security/computer_security/index.html

I like the noscript add-on in Firefox, but I would prefer some way of filtering javascript to allow for innocuous javascript, whilst banning functions that are possibly exploitable. Surely Math.random() is never going to hurt me, by itself. So why disallow all simple javascripting that is commonly used? Would it be possible to white-list built-in functions and block all others?

Michael, most of the Javascript functions that are used in attacks of this sort are by themselves perfectly innocuous. The same Javascript features that allow you to change an image on the fly for a mouse rollover can be used to change the post action of a web form. Dynamic HTML content revolves around modifying the active document object model by setting properties on objects representing the document nodes. Distinguishing which of these modifications are somehow safer than others might be possible for a given web page, but I believe doing it for the general case is practically impossible.

The underlying problem is really cross-site scripting, and fixing that is up to the site engineers. In this case, it looks from Brian's description as if this problem is complicated by features in Quicktime. The Myspace paradigm suffers, however, from a perpetual conundrum of transitive trust. Marketing and security would seem to be directly opposed here, and every time there's a bad call, chaos breaks out. Myspace somewhat reminds me of a medieval village that is peridically stricken by St. Vitus's dance.

Cue Peter Gabriel's "Moribund The Burgermeister"...

Just to be clear, this isn't a Javascript problem, but a problem with Apple's Quicktime.

Thats right, Apple.

You can prevent it by going through the inconvenience of preventing scripting, but that entails enduring some other problems, as described about.

Is it VU#921193 ?

http://search.cert.org/query.html?ql=a&qt=Quicktime&charset=iso-8859-1&col=certadv+incnotes+research+techtips+trandedu+vulnotes+xtracert

(note "CVE Name" at the bottom.)

Long time no see, Texas. I think the Apple Quicktime setting exploited here is not a flaw but a Quicktime "feature," according to Apple.

QuickTime lets embedded video have its own
"special type of text track that adds interactivity to a QuickTime movie. HREF tracks contain URLs that can specify movies that replace the current movie, load another frame, or that load QuickTime Player. They can also specify JavaScript functions or Web pages that load a specific browser frame or window."

Read more about HREF tracks here:
http://www.apple.com/quicktime/tutorials/hreftracks.html

QuickTime HREF Tracks are well-documented and obey the browser "same-origin policy". QuickTime movies are no more "unsafe" than HTML pages, CSS, Flash, or whatever other web content. They can not be used to effect cross-site scripting attacks. The fact is that MySpace really, um, stretches the limits of web site security by serving up the content of millions in the same domain. Notice that past worms have used completely legitimate HTML, CSS, JavaScript, and Flash to propagate through MySpace. This is just one more instance of the "black list" approach failing.

QuickTime> QuickTime HREF Tracks are well-documented and obey the browser "same-origin policy".

What same-origin policy would that be? The one that governs the Java applet "sandbox" perhaps? That has no governance over Javascript. Javascript, especially armed with an XMLHttpRequest object, can do pretty much anything the user can do as far as the DOM and the network are concerned:

http://en.wikipedia.org/wiki/Ajax_(programming)

QuickTime> QuickTime movies are no more "unsafe" than HTML pages, CSS, Flash, or whatever other web content. They can not be used to effect cross-site scripting attacks.

They are unsafe if embedding a remote Quicktime movie means implicitly allowing the person controlling the Quicktime movie's origin to execute Javascript in the context of the viewer's page--a typical example of cross-site scripting. This is different from, for example, embedding a remote image using an IMG element, since images can't include script. And an embedded Java applet would run in a sandbox. The descriptions of this attack appear to involve Javascript, which has no sandbox model, being delivered via embedded Quicktime. Perhaps you can provide a reference for the controls you say Quicktime imposes...

QuickTime> The fact is that MySpace really, um, stretches the limits of web site security by serving up the content of millions in the same domain.

That I agree with, though I'd say it's a lot worse than that...

"says this alert sent out by MySpace administrators."

That wasn't sent out by "MySpace administrators". I can assure you that the last thing they would ever post is a recommendation to install AdBlock. It blocks all of their banner ads. ;-)

Last week, after reading Burnt Pickle's blog, and his request for someone to create a blog to help the newbies on MySpace, I was moved to assist. I promptly posted a blog video tutorial (http://blog.myspace.com/observative) on how to install AdBlock. This might look like a concern for the MySpace advertising. If you properly use AdBlock, you will not block the banner ads on MySpace or any other site. After all it is their revenue generator. That's why my tutorial only blocked the *.mov files and not all of the banner ads (annoying and provocative as they are).The main point is that everyone needs to make their own effort to sensor the content they view. With the proper tools, like AdBlock and others, you can achieve the desired results.Since Google proudly powers MySpace, perhaps they will also assist in the posting of safe videos to MySpace. I would think that Google, with all their abilities, would be able to power a solution for uploading and translating the videos into a safe format we can all enjoy on MySpace.

My wife went to one of these pages and her Firefox 2.0 flashed a warning message when she clicked on the scam link. It said this was a suspected scam site. I was impressed.

I have always treated Quicktime Movies as possibly malicous due to this 'feature'.

So the way I read this is, anyone's profile can get infected, and even if you click the faulty links and realize you're at a phish site, as long as you don't enter your login and password you're account is still safe?

To antibozo:

*This* same-origin policy.
http://www.mozilla.org/projects/security/components/same-origin.html
http://en.wikipedia.org/wiki/Same_origin_policy

Nothing to do with Java applets. Try again.

QuickTime> *This* same-origin policy.

Interesting. You learn something new every day. But the referenced descriptions of that behavior are not correct, and the name seems to be a misnomer.

For example, the mozilla.org reference states, "The same origin policy prevents document or script loaded from one origin from getting or setting properties of a document from a different origin." Yet I can put a page on the domain "one.example.com" that uses a <script src='http://other.example.com/x.js'> tag to load script from a different domain, and the foreign script can modify properties on the document's DOM, even though the script's origin clearly differs from the document's.

On the other hand, I didn't mean to suggest that script can reach outside the current window to change properties on an arbitrary document in another window.

But I think the meat of you're saying, which I didn't get the first time I read it, is that because all the pages are in www.myspace.com, an XSS vulnerability in QuickTime isn't needed for script executed by the embedded QuickTime object to modify properties in the current document, as long as the QuickTime document itself is hosted on www.myspace.com.

That may be, but the way I read the references Brian provided, they seem to be suggesting that QuickTime does not enforce a so-called same origin policy. I don't have any way of testing that, but if you do, I'd be interested in any result.

This has been going on for a long time. Phished accounts are the primary means of advertising for many adult sites on MySpace. They are also very popular for promoting myspace rip-off sites as the userbases are very similiar for example this site http://www.webscutest.com

Best wallpaper and screen saver!: BestWP.ru