on 11/21/01 4:09 AM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> On 11/21/01 6:59 AM, "Danny Angus" <[EMAIL PROTECTED]> wrote: > >> >> Hence my own conviction that the only safe option is no HTML in submissions. >> However I'd rather escape it on the way in than the way out to reduce load. > > That's something I intuitively agree with, and don't understand the contrary > point of accepting everything in and processing everything out. > > I would guess the amount in would be significantly less than the amount out, > and you get to leverage the context in which you are accepting input. (I.e. > There should be no HTML on the input of a simple order form, for example...) The reason why I like the idea of processing stuff on the way out instead of on the way in is that you are actually changing the value of the content if you do it on the way in. Since you may or may not want to modify that content permanently, it is better to do it on the way out, even if it is slightly more processing. Here is a really good example...what if you have a dynamic web page editor application that pulls the information out of a file on disk and sticks it into a <textarea> for people to modify. What if you actually want your administrator to be able to put javascript into the page? In some applications, it is also possible to circumvent the retrieval of form data by simply talking directly to the HttpServletRequest data instead of the libraries that you have. Therefore, if someone working on your app accidentally uses HttpServletRequest data directly, then you have a security hole right there. Of course, this can be helped by proper programming, but we all make mistakes...might as well cover our asses and practice safe sex all the time. :-) -jon -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
