возможно ли раскрыть конфиденциальную информацию через исключения Java?

Можно ли раскрывать конфиденциальную информацию о приложении или системе через Java Exceptions, когда пересекаются границы доверия?

Я имею в виду, не только теоретически, но если это произойдет в реальной среде.

например java.io.FileNotFoundException может сообщить вызывающей стороне о структуре файловой системы моего приложения и т.д. java.util.ConcurrentModificationException может дать информацию о классах, не поддерживающих потокобезопасность моего приложения.

Можно ли разрешить эту ситуацию каким-либо другим способом, кроме двух приведенных ниже?

  1. Использовать Sysouts (только с настроенным сообщением) вместо throwing exceptions для кодов, к которым должны получить доступ другие?

  2. Если обязательно генерировать исключение, дезинфицируйте свои сообщения, а затем генерируйте исключение.

Мне также интересно, можно ли полностью избежать пункта № 2 и не будет ли каких-либо обязательных ситуаций для создания исключения.

Мой вопрос касается не какого-либо конкретного приложения, а практики программирования в целом (когда на крупных предприятиях требуется взаимодействие между приложениями, например, в двух разных банках и т. д.).


java exception java-security
person Sabir Khan    schedule 08.01.2016    source источник
comment
Я лично считаю, что исключения всегда должны использоваться как конфиденциальные, поскольку они также содержат трассировку стека и другие данные, исключения НЕ должны отображаться пользователям в производственных средах. Но предоставление исключений людям, которые используют ваш API, — это хороший способ помочь им быстрее выполнять отладку.   -  person Ferrybig    schedule 08.01.2016
comment
Что вы имеете в виду под границами доверия конкретно в контексте приложения Java (этот термин можно интерпретировать по-разному). Это поможет дать более конкретный ответ.   -  person Erwin Bolwidt    schedule 08.01.2016
comment
@ErwinBolwidt - скажем, одна компания размещает платный веб-сервис Java, который будет использоваться другой организацией или около того.   -  person Sabir Khan    schedule 08.01.2016
comment
Просто был удален ответ на вопрос, где пользователь предлагал написать собственные исключения с менее подробным выводом. Почему это считается плохой практикой? Я не уверен, что трассировка стека все еще была видна (поскольку ответ был удален слишком быстро, чтобы я мог полностью его понять).   -  person hamena314    schedule 08.01.2016
comment
@hamena314: Я тоже это видел, и это то, что я имел в виду в своем вопросе № 2.   -  person Sabir Khan    schedule 08.01.2016

Ответы (1)


arrow_upward
2
arrow_downward

Самый распространенный способ раскрытия конфиденциальной информации — предоставить пользователю (клиенту) программы трассировку стека.

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

Если программа имеет файл журнала, невидимый для обычных пользователей программы, но видимый для администраторов (как в случае с серверами), это подходящее место для регистрации трассировки стека.

Аналогичные аргументы применяются в отношении другой конфиденциальной информации.

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

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

Кроме того, имейте в виду, что не все исключения указывают на проблему, о которой необходимо сообщить некоторому пользователю. Если программа автоматически обрабатывает условие, сигнализируемое исключением, во многих случаях нет необходимости сообщать пользователю об условии, сигнализируемом исключением.

person Raedwald    schedule 08.01.2016