-
Geralmente quando uma questão generaliza demais, temos que a mesma está errada. O erro da questão é o trecho: em quaisquer circunstâncias. É possível haver situações em que dados com caracteres potencialmente perigosos não devem ser rejeitados.
-
Sabe um exemplo Silas?
-
Se eu estiver falando besteira, alguém me corrija... Creio que um exemplo seria durante testes de estresse. Neste teste, o sistema é testado ao limite. E no contexto de segurança, seria avaliado até que ponto o sistema é seguro (o limite).
Espero ter ajudado.
-
Quem trabalha com qualidade de software sabe que um dos primeiros testes é justamente verificar se o sistema rejeita caracteres inválidos, dados inválidos evitando trash no Banco de Dados por exemplo.
Agora o que é caracteres considerados potencialmente perigosos?
Me pergunto qual é a circunstância em que caracteres potencialmente perigosos não devem ser rejeitados????
CESPE!!!!
-
Acho que depende de quais caracteres (e combinções deles) você determina como perigosos para o seu negócio. Às vezes, um caráter pode ser perigoso se vier acompanhado de outro que também o é. Faz sentido rejeitarmos todo e qualquer caráter perigoso sem considerarmos o contexto em que esse está inserido?
-
Na Lista de Verificação de Práticas de Programação Segura pode ser encontrado a seguinte verificação:
"Se qualquer caractere potencialmente perigoso precisa ser permitido na entrada de dados da aplicação, certifique-se que foram implementados mecanismos adicionais como codificação dos dados de saída, APIs especificas que fornecem tarefas seguras e caminhos de auditoria no uso dos dados pela aplicação. " Isto posto, o enunciado da questão diverge com o que é preconizado pelo Guia de Referência Rápida de Melhores Práticas de Programação Segura e, portanto, está errada.
Fonte: https://www.owasp.org/images/6/6d/OWASP_SCP_v1.3_pt-PT.pdf
-
só para se proteger de html injection já é um puta trampo
http://blog.caelum.com.br/prevenindo-ataques-de-html-injection/
-
fora que tem sites com entrada em html (às vezes com certos scripts) e legítima, depende da aplicação, concordo com o gabarito
-
Ninguém deu um exemplo de aceitação de caracteres potencialmente perigosos. Há até quem concorde com a questão, mas mesmo assim não exemplificou. Mas vou me arriscar a dar um exemplo: uma entrada de senha que permita caracteres especiais por exemplo pode ser uma possível permissão de caracteres possivelmente perigosos, por exemplo: número e símbolos como *, &, #, @.
É uma forma de tentar justificar essa questão que ao meu ver, o gab é e.