Your search routine should remove characters it doesn't support, and when printing that back out, it should show what it actually accepted, not what was submitted.įor general purpose fields in a form, consider adding client-side validation for a more pleasant user experience I'd rather know before I hit submit that you're not going to accept non-digits in the Phone Number field. Writing Javascript to stop characters being entered does not stop anyone from submitting them to your search. If you don't want to perform this work for each possible input field, a web application firewall might be an alternative. You have to actually think about what input should be allowed and what shouldn't, because as you have said, if you filter out too much, it might limit users.
The downside is that it's a lot more work. It's also not bad from a user experience point of view (if a user enters invalid data, it's good to report this back to them, so that they know what went wrong, and can now enter valid data).
#VISUALLIGHTBOX LIMITED CHARACTERS ON FOTO NAME CODE#
When your code base gets large enough, the probability that you forget proper encoding in just one place increases, so having additional protection - in the form of server-side input validation - against it is not a bad idea. Your approach will also not catch security bugs in your code. And escaping/encoding/prepared statements are definitely a must-have and your main line of defense.īut as you specifically mention search boxes, your approach might for example not catch SQL wildcard DOS attacks (see here and here), which could be caught by input validation (server-side you obviously shouldn't do this with client-side JavaScript). Your approach - if used correctly - would protect you against two very common attacks: SQL injection and XSS. Given all that, does it still make sense to limit allowed characters which arrive from the client? using parameters for SQL, HtmlEncode for outputting to HTML, etc). The question is about server side, and the assumption is that all the proper encodings/escapings are in place when using the string (e.g. If the user enters garbage, he will see garbage, but the system will work correctly.Īdded: It seems that I've not been very clear. I think that the best practice is to make your application accept anything, and then use the proper encoding functions (and parametrized queries if they are available) to make sure that the entered string passes through unmodified and is displayed/used as entered.
I on the other hand am of the opinion that this will only annoy the users and not offer any additional security.
This prevents the user entering all kinds of unprintable Unicode control characters and whatnotelse. My colleague is of the opinion that the best practice (from a security viewpoint) is to limit the allowed characters to some letters, digits, and a subset of symbols. However this applies equally to all the textboxes in the application, not just the search box. This was prompted by the discovery that you can enter anything in the search box and the application will dutifully perform a search by that string. I got into a (somewhat heated) discussion with my colleague today about what characters our application should accept.
0 kommentar(er)
