XSS (Cross Site Scripting) is probably one of the harder problems to solve in a web application because fixing it properly implies that one has a perfect understanding of what is 'code' and what is 'data'
The problem with XSS (and most other web injection variation) is that the attacker/exploit is able to move from a 'data' field into a 'code' execution environment.
So saying that XSS is easy to fix and eradicate is the same thing as saying that Buffer Overflows are easy to fix and eradicate.
Also, saying that we know how to solve XSS is a red-herring because we DON'T know how to solve it. What do know is how to mitigate it and for the cases where we DO understand were we are mixing code and data, we can apply special protections.
But even today, in 2010, protecting against XSS is something that the developers MUST do, versus something that happens (and is enforced) by default by the frameworks/APIs used.
Take .NET for example. Although there is quite a lot of XSS protection in the .NET framework (auto-detection against common XSS exploits, most controls have auto-encoding by default, etc...) we still see a lot of XSS on ASP.NET applications. The reason these exists is because it is very hard for developers to have a full understanding of the encoding and location of the outputs they are creating. And until we solve this 'visibility' problem, we will not solve XSS
On a positive note, the SRE (Security Runtime Engine) that ships with the Anti-XSS API is an amazing tool because it transparently adds encoding to .NET Web Controls (and it takes into account double encoding problems which is what makes it amazing)
The only way we will ever start dealing properly with XSS is if:
a) the framework(s) developers use have context-aware-encoding on ALL outputs
b) there is no easy way to write raw HTML directly to the response-stream
c) there is no easy way for developers to mix HTML code with Data
d) when HTML needs to be created programatically, that needs go be outputted via an HTML DOM aware encoding API/method (like the ones that .NET AntiXSS has)
e) there are static analysis rule packs for each of the frameworks that document (in rules) the programmatically combinations that make XSS possible (in that framework/API)
f) the developers have immediate (or before checking-in code into production) feedback when they create an XSS in their applications
g) web applications have a communication channel with browsers, which will allow browsers to better understand what is code and what is data (Mozilla CSP is a great step in this direction)
The key to really deal with XSS is e) and f) , since these take into account the scenario that developers will mix code, and even in the best designed APIs/Frameworks there will ALWAYS be combinations that create XSS. Also, without this understanding of the data/code mappings (which is where XSS lives) we will struggle to create mappings for g)
One of my key strategies when developing the O2 Platform was to create an environment that helps the creation and propagation of these 'Framework Rule Packs', since from my point of view, every version of every framework (and APIs) will need one of theses Rule Packs.
Remember that: security knowledge, that is not available, in an consumable format by tools or humans, AT the exact moment when it is needed (by developers, system architects, etc...), is almost as good as non-existent.
For example: "... an MSDN article that explains that the FormsAuthentication cookie is not invalidated on logout... " is not good enough
what we need is an "...alert or note that only appears when the developers use FormsAuthentication that explains (with PoCs) the fact that (on sign out) the only thing that happens is that the client side cookies are deleted from the user's browser...". The PoCs (dynamic or static) are very important in this example, since in most cases the real vulnerability will only be relevant in more feature-rich versions of the application.
Bottom line: Solving XSS means solving the separation of Code vs Data in web applications
And THAT ... is something that we are still quite far off
