I never ceases to amaze me!

Is it just me?

If you solved the problem, or the problem cannot be reproduced, please feel free to delete this comment.

:D

-L

This is a perfect illustration of McAfee (who honestly considers them "one of the leading providers..." anyway?) just not getting it, period.

How sad.

It's nothing to do with the "windows ecosystem" you moron!

Cross-site scripting is by far not the "worst it can get", not even among web application vulnerabilities. SQL injection, Remote File Inclusion and Local File Inclusion weigh in significantly higher. More over, this isn't even persistent XSS (which is considered much more dangerous than the non-persistent XSS, as was reported in McAfee's case).

Speaking from experience, XSS is barely acknowledged as anything other than a buzzword by real security experts, and is often handled as an amateur (read: easy, simple, useless in most cases) security topic. Researchers who emphasize on cross-site scripting are often ridiculed within the industry for hyping its lackluster impact.

Additionally, a great percentage of the Internet is susceptible to XSS and most cases are not exploitable beyond a PR issue. Granted this instance may mean a little more in context, as any security problem is bad PR for a security firm. However, take note that the hundred thousand other XSS cases which were discovered in various sites were not reported. The truth is, the media reacts blindly without knowing better than to trust the words of incompetent attention-hungry security researcher. The result is a misinformed public.

Don't take my word for it. Perform your own research, and compare XSS to any other vulnerability class: buffer overflows, command injection, remote file inclusion, SQL injection; cross-site scripting is insignificant. Then again, you could obsess over it along with Swine Flu or Conficker or the 100 other things that the media hypes which never materialize.

User Stupidity is independent of Operating Environment, and before you say it, yes, there are stupid *nix users

Well said Cliff!

I appreciate your pointing out how XSS is leveraged to use real exploits, and I am by no means denying this. However, you did not point out how any of the other vulnerability classes discussed in contrast to XSS may also be used to achieve the same objective (such as, SQL injection used to forge data on a site to trigger a client-side vulnerability in the browser, like those you described). These classes yield not only potential of compromise the server, but also allow an attacker to lower their standards to gain any spoils also attainable through XSS. These vulnerability classes are therefore intrinsically more potent. I retort with my earlier statement, that in comparison to any other class of vulnerabilities (even in the web category), XSS is insignificant.

Further more, each case of non-persistent XSS used in order to target a user to perform client-side exploitation would require user interaction, relying on premises which could likely be used independently of XSS to achieve the same goal. In other words, if an attacker can inject a link and ascertain that a user will pursue it, the attacker has already won the client-side exploitation game. I will agree that the user's trust of any given site may contribute in their accepting of content from it, but having said that I also return to the statement regarding the hundred thousand other (likely, trustworthy) sites which have XSS in them and were not reported. I would be willing to bet that the users whom are most susceptible to this style of exploitation (that is, relying on user-interaction) have marginal variance in the different levels of trust between security vendors and foundational software vendors (such as Microsoft, Apple, etc) or even foundational service vendors (Amazon, eBay).

Best regards,
Cliff

"most cases are not exploitable beyond a PR issue"

1. PR has hard business value. Whether or not it is positive or negative depends on context. TJX found it positive. A security provider might find this negative.

By example -- I find them funny in my personal website, but take them very seriously in my business websites.

2. XSS escalation of privilege -- XSS is a data/function boundary exploit just like SQLi or a Buffer Overflow. What's worse -- we have no stack canaries, ASLR, or parameterization of user-tainted data to provide a "transparent" containment of attack surface, which is why you see BoFs and SQLi going away in terms of broad exploitability. XSS will be the LHF of choice when those are gone I expect.

In AV vendor sites that use ActiveX controls for remote hosted AV scanners, for example, this gives you a fairly direct and immediate way to exploit a trust relationship to take control of the local system. Users expect to have to click okay to a lot of "stuff" including installables.

Today's Threat Landscape isn't about "rooting the box" anymore. Come on. It's all about taking control of the target parser, and leveraging that to steal data, or elevate privilege to install a bot/back door on the local system. Those are two different but equally important outcomes.

My mother would consider control of her PC worse than control of a website's remote servers. She can mitigate the latter by not using their websites. She cannot clean up her own box or browser reliably.

When you show a General Counsel or a CFO how you can use an XSS to grab their personal data, or gain control of their browser, if not the file system of their Windows laptop (via things like ActiveX or trojaned binaries) they consider that *a lot worse* IMHE than finding out someone compromised the web server of a website they may occasionally visit, and chose not to visit again.

Now I do not think all websites are equal candidates for these type of attacks, to be fair. There are ephemeral, hard-to-calculate qualities like type of users, expectations, and viability of social engineering.

By example again -- my mother will install anything she is prompted to (or looks interesting) off of Yahoo and Ebay, but not so much from other sites.

In that regard there is a definite difference between an XSS and a reliable remote BoF.

And, finally: XSS are exploited in the wild. I've known folks to make physical gains without getting caught using them. Reflected & Persistent. 'nuff said.

$0.02 USD. Adjust to your liking for pending inflation.

It appears as though you should perform a little more research.

Addressing ASLR, stack canaries, and DEP: these do inhibit buffer overflow exploitation in many cases, however as demonstrated some of the very clever exploit engineers, they are not a panacea and have all been broken. (I will agree that these protections probably disable researchers whom only have skill sets strong enough to exploit XSS. Again this is considered an amateur vulnerability class in the industry.)

To correct your statement on protections, there exists MANY protection mechanisms against XSS including add-ons like NoScript for Firefox, as well as anti-XSS technologies shipped by default in newer Internet Explorer. The HTTP-Only option exists for web servers and aims to prevent cookie theft in the cases where an attacker does find XSS. There are appropriate escaping functions available in every major web application language in order to avoid XSS. There are URL white listing add-ons for web servers which to restrict submitted character sets. The list goes on and on; honestly I am saddened that your limited experience with security has rendered you more susceptible, as you have not been exposed to the available protection mechanisms. I can only recommend information resources such as Wikipedia and OWASP to help you on your way.

As far as your mother's concern over control of her PC, it would seem she has more to worry about client-side application security (proper use of ActiveX, properly audited code that is less prone to overflows, etc) than cross-site scripting. Being that with just XSS, (read: only XSS), she will not lose control of her PC unless she willingly hands it over. Unfortunately misinformation campaigns such as that given by the security researcher featured in this article certainly don't help her understand that.

Please don't confuse XSS with the remote code-execution vulnerabilities in the browser or its components. Albeit an excellent delivery mechanism to trigger these vulnerabilities, XSS is still less potent of a delivery mechanism than SQL Injection or Remote File Inclusion (please see my post above - #23), and is not what is actually being exploited. Again, I restate that if an attacker convinces a user to click a link (as they would for non-persistent XSS), its already game over as far as client-side exploitation is concerned.

Finally, with regards to "it is not about rooting the box": the Internet is fraught SQL Injection and Remote File Inclusion. I have no doubt that you have known people who have leveraged XSS, congratulations. This does not add any merit to the fact that XSS is the bottom of the barrel for skills required or gains from exploitation. Nor does it add any merit to the statement "It can't get much worse".

Best regards,
Cliff

Anthony - That's exactly it...

Question - yes, sorry, I did ask a security expert to talk to McAfee about this before I wrote this up and was told they were aware of the issues.

Leon - I'm unsure who you think should have authorize our tests. But yes, you're right it does get worse.

Rafal - Unfortunately, a lot of people with computers still use McAfee - just ask any regular user, generally the best known are McAfee and Symantec. To me, that makes it very sad.

Atul - I'm glad to hear you're happy with Avast - maybe I"ll give it a go

Devendra - Interesting point. We noticed that late Sunday night. Both Firefox and Chrome don't pick it up, but IE did - nice one for Microsoft

Cliff - Thanks for your detailed response. Two things I wanted to mention. One, a security provider being vulnerable - to me that's shocking. Also, the entire idea behind this post was to me security more understandable by those who are unfamiliar with the jargon. I think we managed that. And sure, there are other issues that can come into play - but slowly, slowly.

ecosystem - check my comment above to Devendra - You might not like Windows, but give IE a shot - you might be pleasantly surprised.

Anthony - That's exactly it...

Question - yes, sorry, I did ask a security expert to talk to McAfee about this before I wrote this up and was told they were aware of the issues.

Leon - I'm unsure who you think should have authorize our tests. But yes, you're right it does get worse.

Rafal - Unfortunately, a lot of people with computers still use McAfee - just ask any regular user, generally the best known are McAfee and Symantec. To me, that makes it very sad.

Atul - I'm glad to hear you're happy with Avast - maybe I"ll give it a go

Devendra - Interesting point. We noticed that late Sunday night. Both Firefox and Chrome don't pick it up, but IE did - nice one for Microsoft

Cliff - Thanks for your detailed response. Two things I wanted to mention. One, a security provider being vulnerable - to me that's shocking. Also, the entire idea behind this post was to me security more understandable by those who are unfamiliar with the jargon. I think we managed that. And sure, there are other issues that can come into play - but slowly, slowly.

ecosystem - check my comment above to Devendra - You might not like Windows, but give IE a shot - you might be pleasantly surprised.

To try it, just click "Track Rebate". In the "Enter tracking number" field, enter the following string literally:

" onchange="alert(1)

Press enter as if submitting the tracking number. If you now enter some number in the track rebate field and then leave the field, a message box appears with a 1: this is the result of injecting the onchange hander into the rebate field.

Although this is perhaps not sufficient for an attack, it does show that the site is coded sloppy, and that there is no sufficient generic mechanism in place that properly catches wrong input.

Roland Bouman
http://rpbouman.blogspot.com/

It seems to me the problem with vulnerabilities like this is that they make it very easy for just about anybody to modify (part of) the content of the page.

Granted, you need to convince users to visit such a page using a link or a page that you provide. This isn't that hard though, and once you can convince them, they will be looking at a page they can't distinguish from the real thing.

I think companies have a responsibility to protect their webvisitors against these attacks, especially as it is quite easy for the site builder to prevent this alltogether.

If you're interested in reading more about the security concerns that open APIs and data feeds pose, you can check out the blog post I wrote on this topic, http://stratusec.com/blog/2009/05/nytimescom-danger-for-your-browser

For example...

">https://www.symantec.com/connect/endpoint-management-virtualization/forums}">alert(String.fromCharCode(88,83,83))?sym=">alert(String.fromCharCode(88,83,83))

http://nemesis.te-home.net/News/20090510_Vulnerabilities_in_Websites_of_6_Antivirus_Vendors.html

Who wrote this. Does he know what he is talking about? things to tink of b4 you runn out to the store and buy a new AV or just stop shopping online.

Lidija Davis, were you paid by another ASV or AV company to wright this?

I never like McAfee

And even worse - McAfee doesn't want to do anything about those mistakenly blocked sites. It takes 3 months for them to change the status of a site back to normal. I'm a web developer and I've seen this too many times.

I strongly advise against using junky toolbars like McAfee Site Advisor.

thanks for good article. mcaffee must die