I was trying to look at this from the standpoint of how does the offending script get on your site in the first place. Let's say you have a discussion board and you want to make sure no one puts nasty suff in SCRIPT tags in their postings. But from what I gather is your interested in blocking on the way out. I'll re-read the CERT advisory.
gio Jon Stevens wrote: >on 11/20/01 10:58 AM, "Steve Giovannetti" <[EMAIL PROTECTED]> wrote: > >>In the interest of breaking the chains of my cross site scripting >>ignorance, I'm assuming that the offending SCRIPT needs to be blocked >>from POST or GET requests made by users to JSP/Servlets on the target >>server? >> > >Nope. The only thing that needs to be done is that certain content needs to >be filtered when it is sent to the browser client so that it is not >interpreted by the client in a bad way. > >> Wouldn't an input filter on the servlet just do the trick? >> > >Filtering all of the content would be a performance killer and doesn't make >much sense. You also don't want to filter input, only output. > >I'm not trying to solve the problem of doing the filtering of the content >that I want to filter...I know how to do that...I'm trying to solve the >problem that no one has created any code in Java (that I can find) to deal >with the CSS issue itself. > >Part of the problem with this security hole is that, for some reason, it is >hard for a lot of people to even get a basic comprehension of it (even >though it is so well documented). I think that is why a lot of people just >ignore it as being a problem. > >-jon > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
