Anthony Ferrara wrote:
Lester,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! I wasn't going to reply to you, but this is just plain wrong. You should always consider ANYTHING that's outside the runtime of your application (not in memory of the current instance) to be insecure. Feel free to store XSS in your database. Because you're not going to trust it anyway. The second you trust content in your database, you've opened more potential attack vectors. The proper solution is to do context based escaping/encoding at the moment of output. That way you can update your escaping code if you find a bug and all your content will be protected. If you find a bug in your escaper when you escape on input, how the heck to do you propose to fix it for all the content already stored without looping over every single item and updating the DB table (also a bad design). No, you should Filter In (make sure that content meets your domain criteria, eg username alphanumeric, email looks like an email, etc), and Escape Out (prevent Injection and XSS vulnerabilities when that data leaves your application). Any other way of doing it is going to lead to attack vectors. But if you diligently Escape Out, Injection and XSS are IMPOSSIBLE. And even if you have a bug in your algorithm that allows an edge case, you can fix it once and have it fixed for good. And that doesn't even approach the problem where the same data will be used in different output contexts (which require separate escaping mechanisms). Thereby completely destroying any security you thought you had by pre-escaping. So no, you're wrong. It's badly designed code to escape HTML prior to storage.
I have to strongly dispute that. I will NEVER store 'dirty' html in the database. In fact even ckeditor ensures that the stored data is clean and can be output raw if necessary. *IF* a forum post, blog or wiki need to store suspect code as an example then it should never be stored in it's dirty form. I HAVE to escape it to get it IN to the database as otherwise it will not be saved. But perhaps what I should point out here is that the formatting tags will not be escaped, only the free format text. That is the only way to ensure that users can't 'inject' extra tags into the pages manually. I could not handle escaping the user input in any other way? You can't simply 'escape' the output at all?
-- Lester Caine - G8HFL ----------------------------- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
