Adicionando a codificação HTML para a camada de negócios

Question

Ao adicionar a entrada do usuário para uma página web, ele deve (a menos que o HTML é claro :) ser codificado para ajudar a prevenir XSS ataques etc .. assim:

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

Estou montando um modelo para gerar minha camada de lógica de negócios, e eu estou pensando em usá-lo para fazer toda a codificação, logo que os dados vêm do banco de dados, antes que ele chegue ao código UI. Isso irá garantir que tudo está codificado que deve ser (eu, obviamente, excluir as colunas que contêm XHTML / cordas XML). Uma sobrecarga sobre os métodos de acesso a dados vai permitir a recuperação de dados, com nenhuma codificação (de modo que pode ser editada):

// 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)

Esta é uma abordagem que ninguém mais usa, ou é uma idéia idiota? Quais são os prós e contras?

Graças.

Answer 1

Pode haver casos extremos onde isso faz sentido, mas, em geral, gostaria de aconselhar contra isso. Sua camada de lógica de negócios deve lidar com lógica de negócios e lógica de negócios somente.

Da mesma forma seus controladores (assumindo ASP.NET MVC) deve estar lidando com valores que fazem sentido no contexto do seu domínio do negócio, ao invés de valores já alterados em antecipação a um determinado tipo de interface do usuário.

A sua camada de interface do usuário é a única camada que deve saber e cuidado sobre que tipo de interface do usuário que é. Pode parecer, no momento, que o seu único tipo de interface do usuário vai ser baseado em HTML, mas isso pode mudar.

Answer 2

O problema com o uso HtmlEncode em dados que é salvo no banco de dados é que você então tem que lidar com coisas como & e " em seus dados. Por exemplo, "Tom O'Brien" vai ser salvo no banco de dados como "Tom O"Brien". Fazendo um SELECT ou UPDATE em que vai ser complicado.

Eu acho que você vai fazer melhor usando apenas HtmlEncode para exibir texto na interface do usuário.

Answer 3

A sua lógica de negócios realmente não deve saber sobre a sua apresentação. Quer a sua alimentação de uma web, janelas ou qualquer outro tipo de interface do usuário, você não deve ter esses detalhes em sua lógica de negócios.

Você considerou que as pessoas que utilizam a sua camada de negócios pode tentar para codificar os dados novamente no topo da sua codificação? Isso poderia causar coisas também parecem realmente confuso.

Answer 4

Eu concordo com os outros cartazes que a conversão de dados em nível de vista pertence na geração vista. Você pode começar com apenas pontos de vista baseados em XML (por exemplo, XHTML, VoiceXML para navegação de voz, XML para serviços web), mas o que acontece quando você decidir que visualizações JSON também precisa interações suporte AJAX? literais JSON Javascript usar um mecanismo de fuga diferente do XML.

Você também terá casos em que uma lógica método de Nível precisa chamar outro para um propósito não relacionado à geração de vista. Talvez o método chamando precisa aplicar alguma transformação de dados em massa que preenche outra tabela de banco de dados. O método chamando teria que desfazer as fugas XML nesse caso.

Answer 5

Saiba as lições de recurso magic_quotes_gpc do PHP: como codificação, sem dúvida, apenas as coisas confundir mais do, fazer com que você unescape quando você não deve, se esqueça de escapar quando você deve, e, geralmente, ser uma dor. Não codificar os seus dados até que ele está prestes a ser enviado onde ele precisa ir, seja o banco de dados, a Web, ou em outro lugar.