Я сделал следующее:
-
Отфильтрованный опасный символ
-
Закодированные данные формы перед сохранением в SQL Server 2008
public static string EncodeData(string str) { string getStr = str; getStr = getStr.Replace(";", " "); getStr = getStr.Replace("&", ""); getStr = getStr.Replace("<", ""); getStr = getStr.Replace(">", ""); getStr = getStr.Replace("'", ""); getStr = getStr.Replace("--", ""); getStr = getStr.Replace("/", " "); getStr = getStr.Replace("%", ""); getStr = getStr.Replace("*", ""); getStr = getStr.Replace(":", ""); getStr = getStr.Replace("!", ""); return HttpUtility.HtmlEncode(getStr); }
Это то, что я сделал правильно?
Не кодируйте перед сохранением, а затем кодируйте в ближайшей точке для вывода. При кодировании перед хранением у вас есть пара проблем
- Вы ограничиваете свои данные в одном формате. Что делать, если вы хотели бы вернуть эти данные как JSON? Или RSS? Правила кодирования различны, и теперь вы в значительной степени вынуждаете данные быть HTML.
- Что делать, если кодер изменяется из-за ошибки? Ни одна из ваших сохраненных данных не приведет к тому, что исправление ошибки применяется, потому что вы не кодируете, вытаскивая его из хранилища.
И в стороне, я согласен, что вы должны использовать параметризованные запросы или ORM, которые делают это для вас, чтобы вы были защищены от SQL-инъекции, не пытаясь вручную лишить символов.
Это полностью, 100%, неправильно.
Вы должны использовать параметры, чтобы механизм базы данных отправлял текст отдельно от SQL-запросов.
Вы не должны произвольно лишать персонажей или применять нерелевантные escape-последовательности.
Сохранение символов в базе данных не является большой проблемой. Большая проблема заключается в отображении данных на веб-странице. Если вы не уверены в том, насколько безопасна ваша строка, тогда не стесняйтесь использовать HtmlEncode/HtmlDecode при отправке данных в браузер.