How Dangerous is XSS on web based CMS (Content Management Systems)

I was recently talking to a product manager of a large (and popular) commercial web based CMS (Content Management System or Documents Management Center or Records Management Center, etc...), who was saying that he doesn't think that XSS (Cross Site Scripting) is a problem or (at least from his point of view) something that needs addressing in the short-term in his product.

This shows a serious lack of understanding of the implications of XSS on these types of web applications which (by design) collect, edit and present user data back to its users (supported by all sorts of built-in collaboration tools).

The fundamental problem is that what client's browser receives from the server contains a mix of both data & code (i.e. content & scripts). It like we keep going back in circles, just like buffer overflows, the problem here is lack of separation between CODE and DATA

The moment the attacker is able to control (or inject into) those scripts, the attacker can do everything that the user is able to do on that application! In addition to the fact this blows out of the water any CIA (Confidentiality, Integrity and Availability) and Non-Repudiation guarantees provided by the application, the attacker will also be a couple of degrees of separation away from being able to gain administrative privileges.

And how is that possible (gain administrative privileges)? Well, if you to add up everything that the user is able to do, you will see that once the attacker is able to edit the user's content, he will be able to put payloads on pages that will be seen by (or exposed to) other users. Eventually the attacker will reach a point where the payloads are executed by with people with higher privileges than the current user (eventually reaching a user with administrative control on that application).

And even if you take the view that it is not possible for one user to affect another user and the attacker is not able to gain more privileges, just the fact that it is now NOT POSSIBLE to guarantee/prove/show HOW, WHEN and WHAT user(s) did on the system creates an UNACCEPTABLE scenario for most BUSINESS OWNERS.

Basically, once we lose the ability to track activities back to users (i.e. track behavior back to real users) we really lose the ability to trust the system.

And once you don’t trust the system, what do you have left?

If you actually show most C-Level business buyers that:

• they can’t really trust the data that they get from those systems,
• that they can’t really trust the authenticity or integrity of the data that comes from these systems,

most of them would seriously (re)consider the wisdom of implementing such solution!

If fact, depending on the values of the assets & business processes stored/handled by those systems, most of them should say "if I can’t trust the data that is in here, then I can't afford to depend my organization on top of it".

And that is the problem with XSS! Is not about little Javascript alert pop up box , but about the fact that malicious attackers can get users to do actions as the user themselves.

But WHY isn't XSS taken more seriously today?

I think it is because:

1. the Attacker's business model has not evolved to a stage where they are building services on top of what XSS allows them
2. most (with some notable exceptions) clients buying these tools don't care or don't have the resources to gain the required understanding of the security implications of what they are buying
3. the government, standard's body and insurance companies are not focused on this problem (which they will eventually)

Finally, I will argue that in 2009 the 'I was not aware of the problem' excuse is no longer a valid excuse!

I really wished the discussion would move from "I don't care! / why is it a problem?" to "How to we solve it? / How can clients measure when we get it right?"