Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Dec 25, 2007 06:00 PM by FCsteve
Dec 25, 2007 05:23 AM|LINK
Encode on input is so very very wrong it's hard to put it into words. You would be forcing developers to do the wrong thing on input, and the wrong thing on output (no encoding) which means they'll be used to no encoding and when they pick up content that hasn't
processed through your input encoder is wide open for attack again.
One thing I'd like to reiterate at this point in the thread is that I completely agree with no encoded data in the DB. My point (and others who like the idea of encoding on input) is that you protect one of the main vectors of XSS attack - regurgitation
of input to the screen (search results being one of the main culprits).
So, to be clear: no one is suggesting you must input encoded text into your Db. Especially me. This discussion started with regards to a method that binds an object from Request.Form and the decision to encode/decode being your or ours.
Dec 25, 2007 06:00 PM|LINK
I'd like it to be overloaded.. but by default I would prefer not to encode..
I can kind of see the reason for the default to be encoded.. defaults targetting the most common scenario.. and I imagine you would love your 'product' to do as much as possible for you by default.. but stay highly custimizable and configurable..
Either way I wouldn't be too bothered what the default is as there is some option.. as otherwise it would just add to the code in .NET that becomes useless outside of its default scenario.. (disclaimer: most of the code in .NET I think it done great)..
My personal argument for the output encoding is that it should be handler by the output generators.. but it would be great if we had a simpler way to do primative output encoding (such as the <%!= idea).