Должна ли трассировка стека быть в сообщении об ошибке, представленном пользователю?

45

У меня есть небольшой спор на рабочем месте, и я пытаюсь выяснить, кто прав, и что делать правильно.

Контекст: веб-приложение для внутренней сети, которое наши клиенты используют для учета и других ERP-приложений.

Я считаю, что сообщение об ошибке, представляемое пользователю (когда происходит сбой), должно включать как можно больше информации, включая трассировку стека. Конечно, это должно начаться с милого «Произошла ошибка, пожалуйста, отправьте разработчикам следующую информацию» большими, дружескими письмами.

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

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

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

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

Кто прав?

security error-handling Vilx-
источник
25
Ух ты. Просто вау. " Unfortunately there has been some kind of "Security audit"" - Серьезно? Что это за отношение? Аудит безопасности - в ваших интересах - чтобы улучшить ваши системы, найти проблемы раньше, чем это сделают плохие парни. Вы должны подумать о том, чтобы попытаться работать с ними, а не против них. Кроме того, вы можете попытаться получить больше информации о безопасности PoV в информационной безопасности .
AviD
7
И, между прочим, аудит безопасности не обязательно должен иметь доступ к исходному коду, они, вероятно, провели тест на проникновение в «черный ящик», имитирующий действия злоумышленника - попытка атаковать приложение как пользователя. Хотя я согласен, что доступ к исходному коду мог бы обеспечить гораздо более эффективную форму аудита. :-)
AviD
1
@AviD - по правде говоря, я не знаю, что они анализировали, но из некоторых сообщений, которые я видел, мне показалось, что это тест черного ящика. Если честно, я не хочу работать против них. Действительно, мне понравились новости, когда я их услышал. Но эта их "уязвимость" кажется мне глупой. В каждом решении по безопасности вы должны сопоставлять снижение угрозы с уменьшением удобства использования. В этом случае я думаю, что это значительно снижает удобство использования, а не безопасность.
Vilx-
1
Я очень согласен с взвешиванием, но не согласен с его применением. Это вредит безопасности больше, чем вы думаете, и я также думаю, что ваш способ (сделав это сам, пока я не поговорил с некоторыми пользователями .....) хуже для удобства использования. Подумайте об этом в терминах, ориентированных на задачу - как сказал ответ @ Jon, его путь делает работу пользователя намного лучше. Пользователю не нужно заботиться о стеке (если ваши пользователи не разработчики ...) Но мой опыт в безопасности - и риски реальны.
AviD
1
@AviD - Может быть, вы можете указать мне на некоторые ресурсы, которые объясняют, как трассировка стека может быть опасной? Я готов принять это, но я хочу чего-то большего, чем общий принцип «только покажи, что тебе нужно».
Vilx-

Ответы:

73

Я склонен создавать журнал приложений, либо в БД, либо в файле, и записывать всю такую ​​информацию в это. Затем вы можете дать пользователю номер ошибки, который определяет, к какому элементу журнала относится ошибка, чтобы вы могли получить ее обратно. Этот шаблон также полезен, так как вы можете следить за ошибками, даже если пользователи не беспокоятся о них, чтобы вы могли лучше понять, где проблемы.

Если ваш сайт установлен в среде клиента, и вы не можете с ним связаться, вы можете обратиться в ИТ-отдел, чтобы выслать вам выдержку из сообщения об ошибке №.

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

По сути, наличие системы, которая разливается изнутри, когда что-то не так, не внушает уверенности нетехническим пользователям - она ​​пугает их, заставляя думать, что что-то очень неправильно (например, насколько BSOD вы понимаете и как ты чувствуешь, когда кто-то подходит)?

На трассировке стека:

В .Net трассировка стека покажет полную трассировку прямо в сборках ядра MS, а также покажет подробности о том, какие технологии вы используете, а также возможные версии. Это дает злоумышленникам ценную информацию о возможных слабостях, которые могут быть использованы.

Джон Эгертон
источник
6
Мне нравится ваш ответ, потому что он представляет собой «среднюю дорогу» - не показывайте, а упростите поиск исключений. Я постараюсь настаивать на этом сейчас, я надеюсь, что они согласятся. Спасибо!
Vilx-
2
Я думаю, что это в значительной степени стандартный «зрелый» подход. Кроме того, stacktrace действительно дает много информации, однако мне еще предстоит найти решение, которое может автоматически регистрировать информацию о состоянии вместе со stacktrace (без повсеместного изменения кода). Кажется, что написать собственный отладчик и подключить его - один из возможных способов, но его реализация далеко не тривиальна.
Даниэль Б
@DanielB: В веб-приложениях можно получить некоторые общие сведения (например, идентификатор пользователя, клиентские данные и т. Д.) Из сеанса / кэша - поскольку они сохраняются «глобально», даже такая большая информация может помочь в значительном воспроизведении ошибок. Более гранулированный, чем это, очень сложно, как вы говорите.
Джон Эгертон
2
Некоторые пользователи очень важных приложений требуют немедленного решения любой ошибки, которая мешает нормальному ходу бизнеса. Весь процесс обмена данными, в котором задействованы различные линии связи только для того, чтобы решатель ошибок мог овладеть стеком ошибок, может легко занять 1 час или более, когда ошибка происходит поздно ночью или в выходные дни.
Тулаинс Кордова
1
@ user1598390: Согласовано, и в этом случае копирование сведений об ошибке в отслеживаемый почтовый ящик службы поддержки может ускорить сбор информации до такой степени, что персонал службы поддержки узнает, что что-то сломано еще до того, как это сделает пользователь.
Джон Эгертон
29

Да, их много.

След стека может выявить

  • какой алгоритм шифрования вы используете
  • каковы некоторые существующие пути на вашем сервере приложений
  • правильно ли вы дезинфицируете ввод или нет
  • как на ваши объекты ссылаются внутри
  • какая версия и марка базы данных стоят за вашим интерфейсом

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

Килиан Фот
источник
6
Я согласен по большей части, но некоторые из этих вещей не должны иметь значения. Например, какой алгоритм шифрования вы используете, не должно быть секретным для защиты вашей системы.
Алексей
3
Это не должно иметь значения, но мир несовершенен, и часто это имеет значение. Вот почему важна глубокая защита (одновременное выполнение многих действий, которых должно быть достаточно, если бы они были совершенными).
Килиан Фот
3
Откровенно говоря, если трассировка стека обнаруживает что- то, что может помочь злоумышленнику, то вы делаете это неправильно !
Марк Бут
3
@MarkBooth со статистической точки зрения, вы, вероятно , делаете это неправильно. Нет, поцарапайте это - статистическая уверенность, что вы ошибаетесь. Вы действительно хотите, чтобы злоумышленники нашли ваши ошибки безопасности раньше вас?
AviD
1
@AviD - Нет, я согласен, самая веская причина не отображать трассировки стека для пользователей в том, что они понятия не имеют, что с ними делать, и ваша система ведения журналов должна быть одновременно защищенной и способной регистрировать гораздо больше состояний, чем захват экрана веб-страницы когда-либо мог.
Марк Бут
15

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

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

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

Карл Билефельдт
источник
2
Пользователи извлекают выгоду из быстрого решения его / ее проблемы благодаря информации, предоставляемой трассировкой стека. Но я понимаю вашу точку зрения.
Тулаинс Кордова
11

Взгляните на этот вопрос IT Security SE . Короче говоря, трассировка стека может дать злоумышленнику больше информации для работы. Чем больше информации у злоумышленника, тем больше вероятность, что он проникнет в вашу систему. Я бы не основывал свою безопасность на том факте, что следы стека всегда скрыты, но это также не означает, что вы должны передавать эту информацию злоумышленникам.

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

Oleksi
источник
8

Вы можете не отображать трассировку стека по следующим причинам.

Безопасность

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

Пользовательский опыт

Для лучшего восприятия пользователя трассировка слишком много информации. Да, правильная информация о состоянии ошибки должна регистрироваться и получать внимание инженера. Однако попросить пользователя сделать то, что вы можете автоматизировать, не будет лучшим для него.

Ваша репутация

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

Том Ресинг
источник
6
Как разработчик программного обеспечения, когда я вижу трассировку стека на экране, я сразу же вспоминаю: «Вот придурок, который ничего не знает о работе с ошибками, меньше заботится о них и, возможно, еще меньше о пользователях». Другие вращаются вокруг "это дрянное программное обеспечение, а не на оно не работает, его обработка ошибок не работает" и "WTF .... Я не делаю эту работу, ребята за него" То, что ваш пользователь хочет знать, это то, что он должен сделать, чтобы исправить это. Как это делает трассировка стека?
Mattnz
6

Краткий ответ: в экстрасети или на сайте имеет смысл не показывать трассировку стека. В интрасети преимущества показа стековой трассировки превосходят преимущества ее скрытия.

Длинный ответ:

То же самое случилось со мной на работе. Раньше я думал, что если приложение выходит из строя, оно должно сбоить с шумом.

Но потом они объяснили мне, что потенциальный хакер может извлечь много вещей из стековой трассировки.

Я думаю, что нет необходимости в доказательствах. Очевидно, что чем больше хакер знает о вашей платформе, тем лучше для него, и чем меньше хакер знает о вашей платформе, тем лучше для вас .

Также компании не хотят раскрывать, как хакер проник в их системы.

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

Тулаинс Кордова
источник
1
Каковы некоторые из «преимуществ немедленного знания того, что пошло не так», и почему их нельзя извлечь из файла журнала? Казалось бы, с помощью интрасети вы можете получить доступ к файлу журнала даже проще, чем с клиентского сайта.
Вонко здравомыслящий
В моем сценарии есть критические приложения с приоритетом «7/24». Пользователь звонит в службу поддержки, если проблема связана с ошибкой или исключением приложения, служба поддержки звонит сопровождающему, который, возможно, находится за пределами помещения. Несмотря на информацию об ошибке, эксперт может проинструктировать человека на месте обойти ... Часто сэкономленное время драгоценно, если приложение критично для бизнеса. если эксперт, который в случае отсутствия на месте должен сначала подключиться к компании, выполнить поиск в журнале и т. д., критически важная бизнес-функция может быть излишне ждать.
Тулаинс Кордова
3
@ user1598390, поэтому создайте механизм просмотра журнала. Простая веб-страница, введите идентификатор инцидента, и служба поддержки может увидеть весь соответствующий журнал. Конечно, ограничьте доступ к этой функции и так далее ...
AviD
То, что приложение находится во внутренней сети вашей компании, не означает, что в нем нет злоумышленников. Есть много недовольных сотрудников, которые вполне могут неправильно использовать внутреннюю систему в своих собственных интересах. Поскольку эти сотрудники много знают о компании и ее политике, на самом деле они могут быть более опасными, чем внутренний хакер. Просматривать файлы журналов - довольно тривиальная задача, особенно если вы следуете хорошей практике, а также регистрируете ошибки в определенном файле журнала ошибок.
cliff.meyers
5

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

С другой стороны, если фактическое число вхождений не равно нулю, вам крайне необходима эта информация, и вы не должны полагаться на то, что клиент отправит ее вам. 99,99% времени у них не будет. Вы должны установить систему исправления ошибок, которая автоматически передает информацию, только с одобрения клиента.

ddyer
источник
Я бы назвал этот ответ только для следующей строки: «Полезность этой информации для клиента равна нулю». , Любые технические подробности о внутренностях продукта должны быть скрыты, если только нет веской причины не делать этого по простой причине простоты и удобства использования для конечного пользователя продукта.
Кьяртан