Подход «черного списка» чреват проблемами.И для SQLi, и для XSS проверка входных данных по белому списку имеет важное значение, т.е. определите, что вы ожидаете , а не то, чего не ожидаете .Помните также, что пользовательский ввод - или «ненадежные данные» - происходит из разных мест: форм, строк запросов, заголовков, тегов ID3 и exif и т. Д.
Для SQLi убедитесь, что вы всегда используете параметризованные операторы SQL,обычно в форме параметров хранимой процедуры или любого приличного ORM.Также примените «принципал наименьших привилегий» и ограничьте ущерб, который может нанести учетная запись, подключающаяся к вашей базе данных.Подробнее о SQLi здесь: http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-1.html
На фронте XSS всегда кодируйте свои выходные данные и убедитесь, что вы кодируете их для соответствующего языка разметки, в котором они отображаются. Выходная кодировка для JavaScript отличается от HTML, которыйотличается от CSS.Не забудьте закодировать не только ответы, которые немедленно отражают входные данные, но также и ненадежные данные, хранящиеся в базе данных, которые могут содержать постоянную угрозу XSS.Подробнее обо всем этом здесь: http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-2.html
Я знаю, что это выходит за рамки вашего первоначального вопроса, но я пытаюсь подчеркнуть, что допустимые символы - это лишь небольшая часть изображения.Другие практики, упомянутые выше, возможно, более важны (но вы также должны использовать эти белые списки).