Comments on: Mitigating XSS - Why Input Validation is Bogus

By: anonymous coward

anonymous coward — Sun, 12 Aug 2007 16:22:46 +0000

Nitesh Dhanjani’s 2005 blog entry Repeat After Me: Lack of _Output Encoding_ Causes XSS Vulnerabilities talks about this..

By: Andy Steingruebl

Andy Steingruebl — Sat, 11 Aug 2007 02:48:20 +0000

Yeah, I just felt bad blaming him :)

By: scott

scott — Sat, 11 Aug 2007 00:53:09 +0000

If you are designing a new system, I highly recommend designing in an input validation framework. But, many systems are already deployed and the pragmatic answer is that adding input validation is only going to create backward incompatibility and give the IT group and “the security guy” specifically a bad name.

Err, the architectural fault for lack of separation between code and data is more deeply rooted than the web. Try von Neumann.

By: Andy Steingruebl

Andy Steingruebl — Fri, 10 Aug 2007 23:37:20 +0000

Fair enough. I’ve seen and/or heard of both types of attacks so I agree it isn’t a either/or, its a both type of answer.

Part of figuring out which to try and tackle first, assuming they both are non-ideal, is understanding the data flows and what you can solve with the least effort, or at least the order to fix them in.

Architecturally one of the problems in the web space anyway is that we don’t have a clear separation between code and data, hence this problem in the first place. We wouldn’t have so much trouble if they were actually separate and/or we had a content-restriction policy. Witness the thread on the WASC mailing list today…

By: scott

scott — Fri, 10 Aug 2007 22:19:45 +0000

Input validation is a very seductive choice for the reason you mention: there’s a choke point that can be clearly identified within the design. I further agree that the notion of trying to fix the problem at all the points where one generates output is like trying to snip off the leaves of a tree. But at the end of the day, you have to have good output encoding because all of your input validation is going to have holes - it’s just the nature of the beast.

In your example, you’re assuming that the Web app is the input source. My perspective is the opposite. I see a lot of legacy systems and B2B systems providing the bulk of the input and the Web applications are just the dashboard for the data. That’s the opposite of your example - data’s coming from all over the enterprise and the poor little (in comparision to the overall system) has to cope with this data that it doesn’t have a chance to filter.

You can certainly implement input-validation for a defense depth strategy. I’m totally on board with that. But, too often I see input validation paraded around as a silver bullet. I guess my title was a bit of a knee jerk reaction to that.

By: Andy Steingruebl

Andy Steingruebl — Fri, 10 Aug 2007 20:40:36 +0000

I was going to respond to Pravir’s earlier piece on this, but I’ll just do it here.

From an architectural basis we often have 1 place where input can enter our system (at least direct user input) but multiple places where we consume that data downstream.

Input = web application
Consumer = web application, administration interface, messagebus, database, shell script, ETL job, batch report writer, etc.

While I agree that outpt filtering is a lot cleaner way to address the issue from a proper semantic and output-type context, I worry that I’m relying on a strategy of fixing all of my endpoints rather than at least *trying* to fix the problem, or mitigate some part of it, in a single location.

Trust boundaries and borders in internal applications can be quite complicated, and ensuring that proper output validation happens at all of those points is certainly the right design, but skipping some form of input checking and relying on all of the downstream consumers to get it right seems risky.

Its sort of like the old protocol statement: Be lenient in what you accept and stringent in what you emit. I think the same thing holds for applications.