Добавление кодировки HTML на бизнес-уровень

Question

При добавлении пользовательского ввода на веб-страницу его следует (если, конечно, это не HTML-код :) кодировать, чтобы предотвратить атаки XSS и т. Д., Например:

litForename.Text = HttpUtility.HtmlEncode(MyUser.Forename);

Я собираю шаблон для генерации уровня бизнес-логики и думаю использовать его для выполнения всего кодирования, как только данные поступают из базы данных, прежде чем они попадут в код пользовательского интерфейса. Это обеспечит кодирование всего, что должно быть (я бы, очевидно, исключил столбцы, содержащие строки Xhtml / Xml). Перегрузка методов доступа к данным позволит получать данные без кодирования (поэтому их можно редактировать):

// Get a 'User' entity with all the string fields HTML encoded
BLL.Users.GetById(int userId)

// Get a 'User' entity with optional HTML encoding
BLL.Users.GetById(int userId, bool useHtmlEncoding)

Это подход, которым кто-то еще пользуется, или это глупая идея? Какие плюсы и минусы?

Спасибо.

Answer 1

Могут быть крайние случаи, когда это имеет смысл, но в целом я бы советовал против этого. Уровень вашей бизнес-логики должен иметь дело только с бизнес-логикой и бизнес-логикой.

Аналогично, ваши контроллеры (при условии, что ASP.NET MVC) должны иметь дело со значениями, которые имеют смысл в контексте вашей бизнес-области, а не со значениями, уже измененными в ожидании определенного типа пользовательского интерфейса.

Ваш уровень пользовательского интерфейса - единственный слой, который должен знать и заботиться о том, какой это тип пользовательского интерфейса. На данный момент может показаться, что ваш единственный тип пользовательского интерфейса будет основан на HTML, но это может измениться.

Answer 2

Ваша бизнес-логика действительно не должна знать о вашей презентации. Независимо от того, используете ли вы веб-интерфейс, Windows или любой другой пользовательский интерфейс, эти подробности не должны быть включены в бизнес-логику.

Считаете ли вы, что люди, использующие ваш бизнес-уровень, могут попытаться снова закодировать данные поверх вашей кодировки? Это может привести к тому, что все будет выглядеть очень грязно.

Answer 3

Проблема с использованием HtmlEncode для данных, которые сохраняются в базе данных, заключается в том, что вам приходится иметь дело с такими вещами, как & и " в ваших данных. Например, «Tom O'Brien» будет сохранен в базе данных как «Tom O " Brien». Делать SELECT или UPDATE для этого будет сложно.

Я думаю, вы добьетесь большего успеха, используя HtmlEncode для отображения текста в пользовательском интерфейсе.

Answer 4

Изучите уроки PHP-функции magic_quotes_gpc: такая кодировка, несомненно, только запутает вещи, заставит вас покинуть себя, когда вы этого не должны, забыть сбежать, когда вам нужно, и, как правило, испытывать боль Не кодируйте свои данные, пока они не будут отправлены туда, куда они должны отправиться, будь то база данных, Интернет или где-то еще.

Answer 5

Я согласен с другими авторами, что преобразование данных на уровне представления относится к генерации представления. Вы можете начать только с представлений на основе XML (например, XHTML, VoiceXML для голосового просмотра, XML для веб-служб), но что произойдет, если вы решите, что вам также нужны представления JSON для поддержки взаимодействий AJAX? JSON Литералы Javascript используют другой механизм перехода, чем XML.

У вас также будут случаи, когда один метод логического уровня должен вызывать другой для цели, не связанной с генерацией представления. Возможно, вызывающему методу необходимо применить какое-то массовое преобразование данных, которое заполняет другую таблицу базы данных. В этом случае вызывающий метод должен будет отменить экранирование XML.