Se o líder da equipe decidir adotar como prática geral a san...

Alternativa correta: E - errado

A questão aborda a prática de sanitização de exceptions no contexto do desenvolvimento de sistemas. Esta prática é essencial para a segurança, pois ajuda a evitar que informações sensíveis ou detalhes internos do funcionamento do sistema sejam expostos aos usuários finais. A sanitização é um processo no qual dados potencialmente perigosos são limpos ou modificados para prevenir ataques, como injeção de SQL ou scripts maliciosos. No entanto, quando aplicamos isso ao contexto de exceptions em Java, a questão é um pouco mais complexa.

O erro na afirmativa está no fato de que, embora a sanitização de exceptions possa ajudar a remover informações sensíveis dos objetos Throwable antes de serem passados para camadas superiores, não é possível garantir que todas as informações sensíveis sejam removidas apenas por esta prática. Os objetos Throwable podem conter pilhas de chamadas (stack traces) e outras informações que, se não gerenciadas corretamente, podem revelar detalhes do sistema. É preciso um esforço consciente e específico para assegurar que nenhuma informação sensível seja exposta, o que pode incluir a customização da exceção, o logging apropriado e o tratamento de erros.

A sanitização pode reduzir a quantidade de informações sensíveis disponíveis, porém, não elimina por completo o risco de exposição de dados críticos. Além disso, a alternativa sugere erroneamente que a medida sozinha é suficiente para alcançar a segurança desejada. Na verdade, para garantir a segurança, outras práticas e medidas devem ser adotadas em conjunto, como o emprego de logging seguro, políticas de segurança bem definidas e uma abordagem de security by design.

Portanto, é importante compreender que a segurança em desenvolvimento de software é uma questão multifacetada que requer uma combinação de técnicas e práticas para ser efetiva, e a sanitização de exceptions é apenas uma parte desse quebra-cabeça.

"It is not necessary to sanitize exceptions containing information derived 
from caller inputs. If a caller provides the name of a file to be opened, 
for example, do not sanitize any resulting FileNotFoundException thrown when 
attempting to open that file as it provides useful debugging information. ' 

Extraído do Secure Coding Guidelines for the Java Programming Language 
http://java.sun.com/security/seccodeguide.html

 

Não achei o erro nessa questão! De acordo com o secure coding guidelines do jee, a questão estaria certa:

Guideline 2-1 / CONFIDENTIAL-1: Purge sensitive information from exceptions

Exception objects may convey sensitive information. For example, if a method calls thejava.io.FileInputStream constructor to read an underlying configuration file and that file is not present, a java.io.FileNotFoundException containing the file path is thrown. Propagating this exception back to the method caller exposes the layout of the file system. Many forms of attack require knowing or guessing locations of files.

Exposing a file path containing the current user's name or home directory exacerbates the problem. SecurityManager checks guard this information when it is included in standard system properties (such as user.home) and revealing it in exception messages effectively allows these checks to be bypassed.

Internal exceptions should be caught and sanitized before propagating them to upstream callers. The type of an exception may reveal sensitive information, even if the message has been removed. For instance, FileNotFoundException reveals whether or not a given file exists.

It is sometimes also necessary to sanitize exceptions containing information derived from caller inputs. For example, exceptions related to file access could disclose whether a file exists. An attacker may be able gather useful information by providing various file names as input and analyzing the resulting exceptions.

Be careful when depending on an exception for security because its contents may change in the future. Suppose a previous version of a library did not include a potentially sensitive piece of information in the exception, and an existing client relied upon that for security. For example, a library may throw an exception without a message. An application programmer may look at this behavior and decide that it is okay to propagate the exception. However, a later version of the library may add extra debugging information to the exception message. The application exposes this additional information, even though the application code itself may not have changed. Only include known, acceptable information from an exception rather than filtering out some elements of the exception.

Exceptions may also include sensitive information about the configuration and internals of the system. Do not pass exception information to end users unless one knows exactly what it contains. For example, do not include exception stack traces inside HTML comments.

acertei em 2013 e errei agora.. Será que realmente o examinador quis saber se sanatizar é ou não uma boa prática?