*Basically if you are STORING XSS intrusions then you have badly designed code as there is no reason that it would be stored. If you want to 'display' suspect code, then it is 'escaped' before it is stored so preventing a potential problem if another viewer accesses the raw data!*
While that is true, there is always the risk of code being injected into your data-store through another source or being initially bypassed somewhere on your script. So yes, you absolutely want to have the correct filters and sanitation in place prior to storing, but as an added precaution I think it is wise to be always escaping data prior to output as well. - Mike On Tue, Sep 18, 2012 at 2:14 PM, Lester Caine <les...@lsces.co.uk> wrote: > Anthony Ferrara wrote: > >> Personally, I'd rather have a dedicated API. It's the only way that >> semantic meaning of the API will be preserved. >> >> In this case, I would start it as a PECL extension implementing the ESAPI >> library. Get the API right, and prove it works, then pull it into core. >> > > Sounds the right way to placate the people who prefer this approach to > building code. We then have the option to leave it off if we don't use it > ;) I've even got a stock distribution that does not include any MySQL core > stuff now so I'm happy with this modular approach. > > > You can keep cramming the escaping concerns into a global filter handler >> all you want. Or we could stop, and think about designing proper APIs for >> a >> change. Where the API imparts both implementation and semantic meaning. An >> API where it's easy to see if a user gets it right or not. >> > > Looking at the output 'filtering' applied to my own systems, I am more > than happy that ACTUALLY I eliminate the problems people are quoting here, > XSS prevention, by ensuring that the data being STORED is cleaned up in a > way that I don't need to 'escape' anything. I do need to be able to > 'encode' the output date to correctly display it but nothing in that > process should be able to create an XSS problem? I do apply 'filtering' to > the html tags which removes those that I do not want to be stored in page > content, and css is similarly processed, so we have a run time dictionary > that controls the processing rather than that being hard coded in the > filters. > > Basically if you are STORING XSS intrusions then you have badly designed > code as there is no reason that it would be stored. If you want to > 'display' suspect code, then it is 'escaped' before it is stored so > preventing a potential problem if another viewer accesses the raw data! > > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - > http://lsces.co.uk/wiki/?page=**contact<http://lsces.co.uk/wiki/?page=contact> > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - > http://rainbowdigitalmedia.co.**uk<http://rainbowdigitalmedia.co.uk> > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- ----------------------- "My command is this: Love each other as I have loved you." John 15:12 -----------------------
