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.
