Чи повинен слід відстежувати стек у повідомленні про помилку, поданому користувачеві?

У мене на робочому місці є трохи аргументів, і я намагаюся з’ясувати, хто правий, і що правильно робити.

Контекст: веб-додаток інтранет, який користуються нашими клієнтами для бухгалтерського обліку та інших матеріалів ERP.

Я вважаю, що повідомлення про помилку, представлене користувачеві (коли аварійне завершення роботи), повинно містити якомога більше інформації, включаючи трасування стека. Звичайно, це має початися з приємного "Помилки сталося, будь ласка, надішліть розробникам нижче інформацію" великими, доброзичливими листами.

Моє міркування полягає в тому, що скріншот програми, що вийшов з ладу, часто є єдиним легко доступним джерелом інформації. Звичайно, ви можете спробувати влаштуватися у системного адміністратора клієнта, спробувати пояснити, де знаходяться ваші файли журналів тощо, але це, ймовірно, буде повільним і болісним (розмова з представниками клієнта в основному є).

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

На жаль, був якийсь "аудит безпеки" (навіть не уявляю, як вони це зробили без джерел ... але що б там не було), і вони скаржилися на повідомлення про повне виключення, вказуючи їх на загрозу безпеці. Звичайно, клієнти (принаймні одного, про якого я знаю) сприйняли це за номінал і тепер вимагають очистити повідомлення.

Я не бачу, як потенційний зловмисник може використати слід стека, щоб зрозуміти все, що він не міг раніше з'ясувати. Чи є приклади, будь-які задокументовані докази того, хто хтось робив це? Я думаю, що ми повинні боротися з цією дурною ідеєю, але, можливо, я тут дурень, так що ...

Хто прав?

Я схильний будувати журнал додатків, або в БД, або у файлі, і всю цю інформацію записую до цього. Потім ви можете надати користувачеві номер помилки, який визначає, з яким елементом журналу пов’язана помилка, щоб ви могли отримати її назад. Ця закономірність також корисна, оскільки ви можете слідувати за помилками, навіть якщо користувачі не намагаються піднімати їх із вами, тож ви можете краще зрозуміти, де проблеми.

Якщо ваш сайт встановлений у середовищі клієнта, і ви не можете його дістати, ви можете отримати ІТ-відділ на сайті, щоб надіслати вам якийсь витяг на основі помилки №.

Інша річ, яку ви можете врахувати, - це наявність у системній пошті реквізитів помилок у поштовій скриньці, яку ви бачите, тож ви знаєте, коли все йде не так.

По суті, система, яка проливає свої кишки, коли щось не в порядку, не викликає довіри у нетехнічних користувачів - вона, як правило, лякає їх думати, що щось дуже не так (наприклад, скільки BSOD ви розумієте, і як це робити ти відчуваєш, коли хтось підійде)?

На стек-трек:

У .Net трак стека покаже повний слід прямо у основних вузлах, що базуються на MS, і розкриє деталі про те, які технології ви використовуєте, а також можливі версії. Це дає зловмисникам цінну інформацію про можливі слабкі місця, які можна було б використати.

Так, їх багато.

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

• який алгоритм шифрування ви використовуєте
• які існують шляхи на вашому сервері додатків
• чи правильно ви дезінфікуєте вхід чи ні
• як внутрішньо посилаються на ваші об'єкти
• яка версія та бренд бази даних стоїть за вашим фронтом

... список продовжується і продовжується. В принципі кожне проектне рішення , у великому додатку може бути , пов'язаної з безпекою, і майже всі з них можуть бути віддані через метод або модуль імена. Зауважте, це не означає, що все ще не має сенсу відображати слід стека, якщо середовище, до якого він подається, є безпечним (наприклад, інтранет, а не веб-сайт), але вартість безпеки, безумовно, не дорівнює нулю .

Вся справа в тому, що наша головна робота не полягає в тому, щоб полегшити собі справи. Наша робота - полегшити роботу кінцевому користувачеві. Для нас слід стека виглядає як надзвичайно корисна інформація, яку слід надати розробнику. Користувачеві це виглядає як цілковита безглуздість, яка ні до чого. Навіть якщо ви їм скажете інакше, вони цього не усвідомлюють. Якщо ви думаєте, що важко отримати цю інформацію від системних адміністраторів, отримання її від кінцевих користувачів ще гірше.

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

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

Погляньте на це питання IT Security SE . Коротше кажучи, слід стека може дати зловмиснику більше інформації для роботи. Чим більше інформації має зловмисник, тим більше шансів проникнути у вашу систему. Я б не базував свою безпеку на тому, що сліди стека завжди приховані, але це також не означає, що ви повинні давати цю інформацію нападникам.

Ви можете отримати більшу частину переваг від правильного ведення бекенду. Це трохи менш зручно, але, мабуть, не варто ризикувати безпекою вашої системи та засмучувати своїх клієнтів.

Можливо, ви не можете відобразити слід стека з наступних причин.

Безпека

Показ сліду стека виявляє можливі поверхні атаки для хакерів. Інтранети не застраховані від злому. Це погано відобразиться на вас, якщо ваша мережа була зламана через додаток, за який ви несете відповідальність

Досвід користувача

Для найкращого досвіду користувача, слід дуже багато інформації. Так, інженер повинен записувати належну інформацію про стан помилки та приділяти їй увагу. Однак прагнення користувача зробити те, що ви можете автоматизувати, буде не найкращим для користувача.

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

Кожен раз, коли на веб-сайті відображається слід стека, це виглядає погано. Більшість людей не мають поняття, що це таке, і це змушує їх відчувати, що веб-сайт не є привітним до них. Для тих, хто насправді знає, що це таке, це може бути вказівкою на те, що заявка не була продумана. Багато погано написаних додатків занадто часто показують сліди стека, оскільки це за замовчуванням в деяких структурах, таких як ASP.Net

Коротка відповідь: На екстранеті чи веб-сайті має сенс не показувати стек-трек. В інтрамережі переваги показу стек-траса перевершують користь його приховування.

Довга відповідь:

Те саме трапилось і зі мною на роботі. Раніше я думав, що якщо програма виходить з ладу, вона повинна шумно вийти з ладу.

Але потім вони пояснили мені, що потенційний хакер може заразити багато речей із стек-треку.

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

Також компанії не хочуть розкривати, як хакер увірвався в їхні системи.

З іншого боку, це інтрамережа , і я вважаю, що переваги того, щоб знати негайно, що пішло не так, якщо не потрібно шукати файл журналу, є великою перевагою та ризиком для безпеки відображення стек-треків у межах вашої компанії не такі високі, як вони говорять.

У будь-якому постачаному продукті очікувана кількість помилок цього типу має бути нульовим. Корисність цієї інформації для замовника дорівнює нулю. В обох підрахунках немає підстав представляти слід стека. Якщо є якийсь корисний контекст, він повинен бути представлений зручним для клієнта способом, а не як слід стека.

З іншого боку, якщо фактична кількість випадків не дорівнює нулю, вам відчайдушно потрібна ця інформація, і ви не повинні розраховувати на те, щоб клієнт надсилав її вам. 99,99% часу вони не будуть. Вам слід встановити систему звітування про помилку, яка подає інформацію автоматично, лише "добре" від замовника.