Well perhaps. But I think I have an argument here. Everyone's situation is different but let's imagine a scenario where you have a large web application, with numerous developers, and you
Following the standard advice would involve sending an email to the development team telling them to use contextual output encoding (I'll assume input validation is already in place). You may provide the technical details on how to do this and even a library for them to use. You then relax back in your chair with a certain satisfaction that is akin to saving the world from some great evil.
Evil on the other hand is not so easily defeated. The development team gets back to your with some questions to clarify a couple of points:
- do they have to output encode everything in all existing pages?
- who is going to tell the business of the delays this will cause and/or pay for all the extra work?
- who is going to do the regression testing on the changes to existing pages?
- how to we test?
- will developers get any training? (some of the new guys and graduates don't understand anything about security)
- what will happen if we don't do output encoding and just ignore you?
- do you really expect, with all the other pressures we have, for us to get this 100% right, all the time on every page?
Um, err ... Google! Help me Google! ... Google? Didn't I just do some epic research on Google about XSS? Why were none of these issues raised?
These issues weren't raised because output encoding is the correct technical solution to XSS, it just isn't the real problem you have to solve when you need to mitigate XSS.
This, like many technical solutions, needs to be solved by introducing process into your business. This is where the security community has really let down program managers, technical leads and developers of the world. I'll limit that criticism to XSS for now, although I have no doubt it applies to numerous other problems.
My next post will contain some suggestions to solve XSS through process and not (just) technology.