While playing with my app, I found something that can be a security hole (kind of impossible but still).
For example in the form if I use:
<script>alert('boo');</script>
for the attribute (e.x. title or name) which is already saved in database, and has a unique validator, a CUniqueValidator will output error with this value without any escaping, which in turn throw out some JavaScript.
I want to find others opinion about the best way of action.
-
Use CHtmlPurifier widget for error and errorSummary methods. But this way it looks performance wise too heavy.
-
Modify CUniqueValidator to encode attribute value, so it display error with escaped input.
-
Use CHtmlPurifier to process input and save it to database processed. I don’t really want to do that for simple inputs which won’t be displayed as html on the page. It will also add other problems like displaying escaped value inside form input element and inaccurate length validator.
-
Other ideas.
Hm. Wouldn’t the error just report, that
<script>alert('boo');</script>
is already taken? And that only to the current user? As far as I can see, you would then end up performing a script injection attack on yourself. If you really think, that’s a problem, you could always wrap the $form->error(…) call with CHtml.encode().
Yes, after thinking a little more about this, decided that you only run this code on yourself. Still not liking a possibility of letting JS run freely, you never know that your users might be capable of 
And wrapping $form-error(…) call with CHtml::encode won’t work because $form->error(…) returns additional error markup which gets escaped. The best bet would be to extend CUniqueValidator to encode attribute value (probably together with the flag to keep it un-encoded if needed).
I just wanted to find others opinions to get my ideas flowing before I decide which way to take for this little problem 
Well, escaping the attribute value wouldn’t prevent people from injecting their own JS-code via greasemonkey etc. And to be honest: If your users are able to do malicious things by manipulating JavaScripts on their sides, you might have larger issues.
After giving it a little more thought: This might actually be a major problem for people who value (or rely on) valid markup. Might be worth a bug report.
It is kind of impossible to do something bad, it’s just that I accidentally found something I don’t like.
Yes you are right, if you use < or > you will break valid markup. Of course it’s not a big deal because you will be breaking it on yourself and only then updating or so, but you might never know then small things will add up to big problems.
