Нет смысла пытаться запретить «злые» символы при вводе, и еще меньше смысла пытаться запретить версии, закодированные в различных формах. Вы будете ложно-положительными и заблокируете действительный ввод, не защищая себя от всех возможных форм отверстия для инъекций. Я не уверен, какую атаку вы пытаетесь предотвратить, запретив Ow==
, а не, скажем, & или ".
Правильный способ остановить внедрение HTML - это вызвать htmlspecialchars() для любой текстовой строки, выводимой на страницу HTML. Правильный способ остановить внедрение URL-компонента - вызвать rawurlencode() для текстовых строк, выводимых в URL. Правильный способ остановить SQL-инъекцию - вызвать соответствующую функцию экранирования БД (например, mysql_real_escape_chars()) для любого текста, выводимого в строковый литерал SQL.
И так далее, для каждого, кто может сбежать, вы можете столкнуться. Дело в том, что это функция выходного уровня, которую нужно применять, когда вы помещаете текст в новый контекст, используя правильную функцию для того типа контекста, который у вас есть. Это не то, что вы можете сделать один раз на этапе ввода, а затем забыть о нем, потому что на этапе ввода вы не знаете, будет ли текст, который вы обрабатываете, заканчиваться литералом SQL, страницей HTML, строкой JavaScript литерал, параметр URL или что.
Это не значит, что проверка на этапе ввода бесполезна; Вы хотите, чтобы проверенное поле, которое должно быть числом, действительно выглядело как число, или дата, дата или что-то еще. Но проверка правильности ввода не является решением проблем с выходом, таких как проблема внедрения HTML, которая вызывает большинство XSS. Чтобы это сработало, вам придется запретить почти все знаки препинания, что будет довольно враждебно для пользователя.