Comments 79
Самое печальное, когда тебе говорят "упс, что-то пошло не так", но при этом не говорят что именно пошло не так. Какая именно подсистема дала сбой? Может её отключить или поменять настройки или поменять на другую? Вместо того, чтобы сделать сообщения об ошибках понятными для всех, их делают непонятными ни для кого.
Тут разговор в основном о вебсервисах, а это просто мечта хакера, вебсервис выдающий стектрейсы и детальные ошибки.
Мечта хакера — "security by obscurity".
Как и любое другое прятанье, это — "security by obscurity". И наличие этого "obscurity" провоцирует программистов забивать на "security". А вот когда работаешь "в открытую", то просто не можешь "забить", потому, что знаешь, что это будет тут же обнаружено.
Взывание к авторитету и сливание кармы — так себе аргументы.
Я ни разу в жизни не допустил ни SQL инъекций, ни XSS уязвимостей. Не потому, что я такой внимательный или наблюдательный или иксперт по безопасности, а потому, что строю архитектуру так, чтобы эти уязвимости исключить. Поэтому мне всегда было смешно наблюдать, как многие борются за безопасность путём "скрытия текста ошибки", "фильтрации SQL конструкций во вводе пользователя" и тому подобными простыми и неэффективными способами.
Я ни разу в жизни не допустил ни SQL инъекций, ни XSS уязвимостей.А таки откуда ви знаете? :D
Недавно была атака на банки, так вот Сбербанк Онлайн выдавал пусть и не бектрейсы, но исключения Java с указанием имён пэкейджей и классов. В частности, про невозможность Hibernate подключиться к БД или ошибки рефлексии. Не то чтобы прямо что-то критичное, но я несколько удивился. Ещё раньше на запуске нынешней системы на Java у них и трейсы вылетали целиком, сейчас, вроде, убрали.
Error 500: java.lang.SecurityException: org.hibernate.exception.GenericJDBCException: Cannot open connection
"security by obscurity" не значит, что obscurity это плохо. Это значит, что когда obscurity — единственный способ обеспечения безопасности — вот это плохо.
О том и речь, что "obscurity" вообще не обеспечивает никакого "security". Это как иконки на торпеде — в лучшем случае никак не повлияет, а в худшем даст ложную уверенность.
Тут разговор в основном о вебсервисах, а это просто мечта хакера, вебсервис выдающий стектрейсы и детальные ошибки.
Простите, но ошибка, которая крушит браузер — на клиентской стороне. И бектрейс хакеру никакой дополнительной информации не даст — у него и так уже код весь есть.
Возможно, я мнителен, но раздражают советы класса «убедитесь, что компьютер включен», что наблюдалось (да и наблюдается) особенно у МС: например, IE — сейчас уже более осмысленные сообщения при обрывах связи, но были достаточно раздражающие сообщения. Что там усугубляет — наличие кнопочки «исправить проблемы подключения», результатом которого обычно является сообщение либо «у вас все хорошо» (а проблема остается) либо «у вас нет соединения» — при этом вопрос «почему?» остается.
У любого "профана" есть знакомый "эксперт", который поможет первому расшифровать хитрое сообщение об ошибке, если оно содержит хоть какую-то конкретику, а не голый "что-то пошло не так".
Затем, чтобы при разговоре со службой поддержки / знакомым экспертом / гуглом получить разумный ответ и вариант обхода проблемы вида "Вы делаете запросы в такое-то время, когда на сервере обычно происходит обновление приложения, поэтому части запросов может не повести. Просто повторите запрос, при получении такой ошибки, пока мы не научились обновлять софт без остановки сервиса."
Слишком небезопасно, обычному пользователю (даже профессионалу) это поможет меньше банальной автоматической отправки сообщения и логов на сервер, а вот хакеру поможет и сильно.
Вы уже 4 раз повторили одно и то же. Не надо так.
А банальная "автоматическая отправка сообщений и логов" обычно упирается в "завал, который некому и некогда разбирать". Пока петух не клюнет — никто особо не шевелится.
Это хорошо, что в некоторых компаниях процессы отлажены, людей хватает и каждый из них — Профессионал, а продукт отлажен настолько, что ошибка в нём — это событие века.
К сожалению, в большинстве случаев, пользователь работает с продуктами куда более приземлённых компаний, где дедлайн уже вчера, бюджет потрачен, набрали стажёров, куча легаси, рефакторинг в следующий раз, тестирование вручную, безопасность по требованию. И это не мелкие компании, а всякие фейсбуки со вконтактами.
А может быть и "для вашего аккаунта заблокирована возможность Х, которая обрабатывается сервером 12345, поэтому повторять позже бесполезно, а необходимо попросить администратора вашего аккаунта включить эту опцию", и сотня других причин. В идеальном мире, конечно, все возможные причины и пути решения будут перечислены в тексте ошибки. Но в реальном — ошибки являются следствием исключительных, не предусмотренными программистами, ситуаций.
Если же код ошибки спрятан — может, программист недоглядел/поленился,
Чем детальнее сообщения ошибках вебсервиса, тем проще работа хакера. Даже выдача код ошибки это на самом деле огромная дыра в безопасности, всякие sql инъекции и переполнения стека проводятся в разы легче. Даже если хакер не знает что код ошибки реально означает, он может перебором добиваться разных кодов ошибок и определять успешность своих атак.
а может компания не хочет выдавать никакой конкретики о своих ошибках. И это ее право, чесговоря.
Это обычно не право, а обязанность — аудит безопасности вебсервиса почти гарантировано не пропустит вебсервис, выдающий детальные ошибки или стектрейсы.
«наш сервер №12345 накрылся, поэтому ваша транзакция не прошла — попробуйте еще раз, и балансировщик вас перебросит на рабочий сервер»
Пользователю-профессионалу это все равно ничего не даст (равносильно что-то случилось, попробуйте ещё раз), а вот хакеру будет очень полезно.
Даже выдача код ошибки это на самом деле огромная дыра в безопасности
Это не дыра в безопасности. Дыра в безопасности — это склеивание sql строк без экранирования, отсутствие проверок при обращении к памяти и тому подобное. А скрытие подробностей ошибки — это так, присыпание дыр листочками.
Даже если хакер не знает что код ошибки реально означает, он может перебором добиваться разных кодов ошибок и определять успешность своих атак.
Это получится самый дешёвый и эффективный аудит безопасности, который найдёт у вас реальные дыры, а не только лишь их незамаскированность вида "стектрейс в ответе". Можно даже в теле ошибочного ответа сразу писать "Вот вам стектрейс, настройки сервера такие, сможете придумать как это эксплуатировать — получите сумму такую-то".
Пользователю-профессионалу это все равно ничего не даст (равносильно что-то случилось, попробуйте ещё раз), а вот хакеру будет очень полезно.
Пользователь-профессионал сможет догадаться, что кавычку надо заэкранировать, чтобы запрос сейчас прошёл, решив тем самым свою проблему. И сообщит в службу поддержки о возможной SQL инъекции, тем самым решив проблемы других пользователей и самого сервиса. А служба поддержки в срочном порядке сообщит ответственному программисту, что надо залатать дыру, а не закинет сотый тикет вида "изредка возникает 500 ошибка, поди разберись".
"Вот вам стектрейс, настройки сервера такие, сможете придумать как это эксплуатировать — получите сумму такую-то".
Угу, даже самые большие вознаграждения за найденные уязвимости в десятки раз меньше того что предлагают на черном рынке или конкуренты. Если вас уже ломают, хакеру ваши предложения будут не интересны в 90% случаев.
А скрытие подробностей ошибки — это так, присыпание дыр листочками.
Ошибки есть в любом софте, как бы он не защищался, облегчать работу хакера в серьезном сервисе даже на мизерную часть прост глупо. А открытость вовсе не означает что на безопасность не забьют.
Если вас уже ломают, хакеру ваши предложения будут не интересны в 90% случаев.
Значит надо предлагать в 10 раз больше, чтобы хакеру было выгоднее быть белым, а не чёрным. Это же рынок.
А открытость вовсе не означает что на безопасность не забьют.
Конечно, но мало кто будет ковыряться в носу, когда на него все смотрят. :-)
Даже выдача код ошибки это на самом деле огромная дыра в безопасности
Ну-ну. Пахнет сокрытием самого факта ошибки: «Ошибка? В нашем ПО? Быть не может, это нормально, а Вы там не ковыряйте ничего, чтобы не ломалось!»
Если уж так не хочется выдавать тех.инфо, то на худой конец можно шифровать, чтобы спецы потом расшифровали всю важную информацию.
В общем, мне очень нравятся понятные и полезные (сразу ясно, что делать) сообщения об ошибках. Но как разработчик я понимаю, что реализовать такое — часто очень сложно и затратно.
Да не только в сложности дело. Детальное сообщение об ошибках это огромная дыра в безопасности для хакера. Такой вебсервис не пройдет ни один серьезный аудит безопасности, поэтому кроме "Упс" они ничего не могут сказать.
Тоже не угадал. Там ведь латинским по синему написано: Windows NT 3.1.
Известных ошибок в production быть не должно.
Технический лог пользователю ничем не поможет, а хорошим тоном может быть номер ошибки и контакт, с которыми можно обратиться в поддержку, но никак не куча абракадабры.
На момент написания кода об этой ошибке было не известно. А может было известно, но по какой-то причине не запилили (в идеальном мире, конечно, таких причин нет).
А абракадабра, зачастую, не понятна и самим программистам, так как разработчики языков программирования и библиотек зачастую не предоставляют точной и исчерпывающей информации об ошибках. Это повод делать её понятной, а не скрывать.
За примером далеко ходить не надо — GeForce Experience. Падает через пару минут после загрузки. Никаких подсказок не даёт, почему именно на моей системе она падает. На других видимо не падает, раз уже который месяц это не исправляют.
Именно поэтому невозможно подстелить солому, как вы хотите, т.е. рассказать что произошло, кроме как технических логов.
> А абракадабра, зачастую, не понятна и самим программистам
Причем тут создатели программы, они могут логгировать эти ошибки без показа их пользователям.
> Падает через пару минут после загрузки. Никаких подсказок не даёт, почему именно на моей системе она падает.
Не думаю, что куча чужих бектрейсов поможет 9999999 пользователей из 1000000. А последний потратит месяц или отправит багрепорт? И в GeForce (как и в большинстве программ) есть отправка логов.
Автор из тех странных людей, которые заставляют программистов галстуки на работе носить.
Навеяло почему-то.
Попытаться поднять настроение пользователю какой-то весёлостью может быть лучше/равносильно/хуже распечатки полного стека Django. Кому-то это нужно, кого-то это раздражает. Кому-то пофигу.
Единого рецепта правильного сообщения об ошибки, нет. Главное, что бы про это знал разработчик и максимально быстро исправил. То, что ты — доблаёб и забыл зарядить все свои 100500 гаджетов, и в аэропорту они одновременно сдохли под плохим бесплатным вайфаем — не проблема сайта. Почему почти все почти всего думают, что им что-то должны в лучшем виде всегда?
В наше время классических меню всё меньше, но проблема осталась. Действия просто пропадают из тех мест, где они должны быть. И опять без объяснений.
1. Приложение выбросило исключение
2. Собрало информацию об ошибке
3. Положило в базу, выдав при этом уникальный идентификатор (во избежание длинных чисел можно использовать, например словарь лёгких слов или что-то ещё, облегчающее передачу разными способами)
4. Сообщило об этом пользователю, показав этот самый идентификатор, краткую информацию и контактные данные компании.
5. Пользователь связывается с администрацией, назвав выданный ему идентификатор.
6. Администрация передаёт запрос программистам, которые изучают запись в базе об этой ошибке и решают проблему.
Когда я работал в местном купонаторе, с нами (через наш колл-центр) связывались пользователи и партнёры при возникновении каких-либо вопросов по сайту, будь то ошибки или какие-либо другие непонятности. И происходило это на удивление часто (моей разработкой был кабинет партнёра и по нему звонили ещё чаще, чем по фронтендовым вопросам).
0. Настроить уведомление при вставке информации об ошибках в базу.
Эту задачу достаточно хорошо решают пользователи — если ошибка критична для пользователя — он о ней сообщит, если нет — значит мы о ней и не узнаем. Да, вариант несколько порочный, в плане — пользователь может «обидиться и уйти», но для особо критичного функционала и так должны быть автоматические проверки.
В сервисах анти-ддос также защиты частенько отображаются идентификаторы, которые по идее можно будет проверить в случае если система по какой-то причине ошибётся и закроет доступ «нормальному» пользователю.
Возможно, нечто подобное можно сделать через Sentry.
ff0a8e6c не должен был указывать на HAL.DLL
По мне так этот BSOD — достаточно информативное сообщение.
Лично меня раздражают только умники, которые всегда считают, что в гигантах IT индустрии работают идиоты и не знают что делают. Это наивность такая или гордыня? Нет, я правда не понимаю зачем об этом вот в таком виде высказываться.
В IT существует жесткая конкуренция, что и способствует направлению и методам развития. Не нравится такой подход — найдите подходящий для вас сервис. Если это единственный, который вам подходит по каким-то причинам, но в чем-то не устраивает, так это и не должно быть идеально во всем. Всем угодить невозможно. А IT гиганты работают с огромным числом клиентов/пользователей и от их методов и качества зависит их прибыль.
Лично меня раздражают только умники, которые всегда считают, что в гигантах IT индустрии работают идиоты и не знают что делают.Довольно странный вывод из статьи Вы сделали. По мне так посыл статьи диаметрально противоположный: в гигантах IT-индустрии работают умники, которые всех без исключения пользователей считают идиотами. И если этих гигантов время от времени не пинать подобными статьями, то в конце концов они окончательно забьют болт на юзеров и перестанут воспринимать конструктивную критику.
В IT существует жесткая конкуренция, что и способствует направлению и методам развития.
Назовите альтернативную операционную систему, на которой можно поиграть нормально в WoW, Civ 6 и еще несколько игр, используя клиенты Curse, Discord помимо Windows.
Назовите браузер, который можно активно и удобно использовать, но не Edge, Mozilla или Chrome.
Ну и так далее. "Конкуренция".
все из-за того, что компьютерами стали пользоваться не только программисты. :)
Никогда не забуду надписи вроде «Text for error #8 here» при каких-то обычных действиях, или что-то «Error #102 — try again or contact support». Обычно, решение было простым, и пользователь запросто мог бы решить проблему сам, если бы вместо непонятного диалога, был нормальный текст ошибки.
Перекладывание ответственности на пользователя, говорите?
Всегда старался максимально эргономично выводить сообщения об ошибках, ещё когда писал на VBA под Access, все корневые вызовы содержали On Error Goto (handler) а там модальное окно, подробное описание и предложение написать разработчику. Это как-то по-взрослому, имхо.
— пофиксит код на серверах гугла, фейсбука и айклауда
— найдет ошибку, исправит её и сделает ПР в код хрома
— исправит ошибку в проприетарных драйверах в винде (кстати, журналы ошибок пишутся, там больше деталей) или флеш
— хакнет ютуб чтобы посмотреть частное видео
— нарастит мощности ДЦ твиттера
Опаньки, я сломал вашу жизнь