Анализатор обнаружил класс исключения, недоступного для других сборок. Если такое исключение будет выброшено, внешний код будет вынужден отлавливать объекты ближайшего доступного предка или вообще базового класса всех исключений – 'Exception'. В этом случае усложняется обработка конкретных исключительных ситуаций, ведь код других сборок не может чётко идентифицировать возникшую проблему.
Отсутствие чёткой идентификации возникшей проблемы несёт дополнительные риски с точки зрения безопасности, так как для каких-то определённых исключительных ситуаций может понадобиться специфичная обработка, а не общая. Недостаточное логирование и мониторинг (в том числе, обнаружение проблем) выделены в отдельную категорию рисков в OWASP Top 10 Application Security Risks 2017: A10:2017-Insufficient Logging & Monitoring.
Простой пример из реального проекта:
internal sealed class ResourceException : Exception
{
internal ResourceException(string? name, Exception? inner = null)
: base(name, inner)
{
}
}Чтобы можно было корректно обработать конкретную исключительную ситуацию, необходимо задать в объявлении класса модификатор доступности 'public':
public sealed class ResourceException : Exception
{
internal ResourceException(string? name, Exception? inner = null)
: base(name, inner)
{
}
}Теперь другие сборки смогут отлавливать данное исключение и обрабатывать конкретную ситуацию.
Следует учитывать, что для вложенных классов модификатора 'public' у объявления исключения может быть недостаточно. Например:
namespace SomeNS
{
class ContainingClass
{
public class ContainedException : Exception {}
....
}
}В данном примере класс исключения вложен в 'ContainingClass', который неявно объявлен как 'internal'. Вследствие этого 'ContainedException' также будет видим только в пределах текущей сборки, хотя он и помечен модификатором 'public'. Анализатор обнаруживает такие случаи и выдаёт соответствующие предупреждения.
Данная диагностика классифицируется как:
|