Page 2 of 2

Posted: Fri Jul 07, 2006 5:14 am
by Oren
Better safe than sorry.

Posted: Fri Jul 07, 2006 5:50 am
by Jenk
Maugrim_The_Reaper wrote:User enters HTML, HTML is not stored (even temp), same user is the only one capable of seeing their own HTML.

What's to sanitise?

Unless the data is eval'd, outputted to another user, or stored I see no reason...
Hard to explain, is down to my own ethics I guess. It's not a case of better safe then sorry, it's more a case of just not wanting my site to be involved in any form of attack, be it a 'suicide' as would happen in this scenario, or used to attack other users.

Posted: Fri Jul 07, 2006 6:13 am
by Oren
When we are talking about securing our sites, applications etc... We also mean/want to prevent one user from attacking other using our site.

Posted: Fri Jul 07, 2006 8:04 am
by Ambush Commander
User enters HTML, HTML is not stored (even temp), same user is the only one capable of seeing their own HTML.

What's to sanitise?

Unless the data is eval'd, outputted to another user, or stored I see no reason...
Here's an idea. Guy makes joke website that has a big, red, fluffy DO NOT PRESS button. Obviously, people press it.

What the form does is sends the system you describe evil HTML, which the server gurgles back. Bang, compromise.

Sure, you could check referrers or use challenges to stop request forging, but wouldn't it be a lot nicer just to do the darn thing properly? (or htmlentity-ize the whole thing)

Posted: Fri Jul 07, 2006 11:09 am
by RobertGonzalez
Everah wrote:I don't think sanitizing is necessary. I might consider running it through an HTML entity conversion for safety sakes, but essentially the post data will reside in temporary space seeing as the posted data will be immediately displayed on screen to user that posted it. If anyone is going to be affected by it, it will be the person that posted it.
Hey hey, maybe that wasn't such a stupid idea? Eh? :D