Well done for testing your app, many people don’t bother. Don’t worry about storing that string in your database it won’t do any harm and changing it may give you problems with other, valid, entries. As vstm says, escape it when you use it.
However, as you are specifically talking about a ‘First Name’ field there is probably some more validation that you can do, such as rejecting any names with a
/ in them. I’m not aware of any language that has that as part of a name. If there is, I’d love to know how it’s pronounced. You could probably add
. = and some others to that list too, but don’t get too carried away.
You should carefully consider every field in your form with regards to what input you would reasonably expect to receive and validate the input accordingly. Anything that doesn’t pass validation is rejected. A string like
'<script>window.location = "http://www.google.com";</script>' should certainly never pass validation for a field expecting a person’s name.
Personally, I never filter input. It either passes validation and is accepted, or it doesn’t and is rejected. I can’t make good input out of bad input by filtering it, so it gets rejected and the user is asked to re-enter their data. For example, using a
StripTags filter on
<script>window.location = "http://www.google.com";</script>
will leave you with
window.location = “http://www.google.com”;
which is still not a valid name and should be rejected.
Your validation will never work 100% of the time and that is why you should always escape values received from user input before echoing them out to the browser.
Zend Framework has a raft of validators that you could use and don’t forget the validators and filters that PHP has already available for you. Use them properly and you will greatly reduce the risk of malicious input hurting either your application or, more importantly, your users.
Those validators and filters are there for you to use, but neither PHP nor Zend Framework know what kind of data you are expecting, so it is very important that you read the documentation and learn exactly how they work, how to use them and when to use them.
There is an excellent resource at The Web Application Security Project that every web dev should be forced to read on pain of death.
Validate input and escape output.