Re^3: Removing malicious HTML entities (now with more questions!)

I don't think it's a good idea to escape the values upon reading them. What if you are gonna need them raw? What if you're gonna need them URL escaped or escaped for inclusion in a JavaScript string literal or or or or.

Besides not all data will come into your script from the form/query so you'll have to either escape everything, no matter where it comes from or keep track of what is and what is not escaped.

Escape before you output, not when you input. Because only at the output do you really know how are you going to know how do you need to escape.

Jenda
Support Denmark!
Defend the free world!

Comment on Re^3: Removing malicious HTML entities (now with more questions!)

Replies are listed 'Best First'.
Re^4: Removing malicious HTML entities (now with more questions!) by techcode (Hermit) on Aug 17, 2008 at 02:35 UTC
I thought that too at first, but there are so many different ways to output things - read from DB, directly from the form (in case of form error) ... and so many different modules are involved (TemplateToolkit, DBD::MySQL, Data::FromValidator, HTML::FillInForm ...) that I couldn't find an easy bulletproof way to encode everything (automatically) on output. And either way - I need it 90% of the time in escaped (secure) format for printing out as part of web pages, forms and similar. I store them that way in a DB, and just print them out as-is. Actually, I would say ~ 100% - as I either need that escaped or not in some special cases - which I mentioned, like WYSIWYG editor as part of CMS. But it continues to be in same format, and very rarely do I need to undo something escaped. So this is fire and forget approach. /ex-Yugoslavia languages: Sipas i ne mislis !/ Performance wise it's also better - as with anything else that you can pre-calculate, instead of escaping it over and over ... You can also think about it as tainted mode - everything "is protected" and you need to untaint anything you might need - no way to forget to escape something. Which is quite easy (to forget) in web world where you add new and change old fields like socks. Have you tried freelancing? Check out Scriptlance - I work there. For more info about Scriptlance and freelancing in general check out my home node.	[reply]

Replies are listed 'Best First'.

Re^4: Removing malicious HTML entities (now with more questions!)
by techcode (Hermit) on Aug 17, 2008 at 02:35 UTC

And either way - I need it 90% of the time in escaped (secure) format for printing out as part of web pages, forms and similar. I store them that way in a DB, and just print them out as-is. Actually, I would say ~ 100% - as I either need that escaped or not in some special cases - which I mentioned, like WYSIWYG editor as part of CMS. But it continues to be in same format, and very rarely do I need to undo something escaped.

So this is fire and forget approach. /ex-Yugoslavia languages: Sipas i ne mislis !/

Performance wise it's also better - as with anything else that you can pre-calculate, instead of escaping it over and over ... You can also think about it as tainted mode - everything "is protected" and you need to untaint anything you might need - no way to forget to escape something. Which is quite easy (to forget) in web world where you add new and change old fields like socks.

Have you tried freelancing? Check out Scriptlance - I work there. For more info about Scriptlance and freelancing in general check out my home node.

[reply]