
Комментарии 8
Пример: Если сообщение зашифровано и при этом используется аутентификация (скажем, MAC), то нужно и в слечае неправильной расшифровки (invalid padding), и в случае неправильного MAC вернуть одинаковое сообщение об ошибке. В противном слечае может получится что-то типа «Bleichenbacher’s attack».
А вот нет. Мода на обфускацию сообщений об ошибках или, что хуже всего, полного запрета на показ текста и стека вызовов — это попытка прикрыться фиговым листом.
Нет (я даже повторю: нет!) причин не показывать абсолютно всю информацию об ошибке. Да хоть регистры показываете. Это никак не должно влиять на безопасность приложения. Если влияет — приложение или middleware — говно.
При этом, сам протокол и все алгоритмы в полном порядке, атака использует разницу в ошибках (кодах), которые сервер возвращает на «неправиьное» сообщение.
Я вообще-то говорил про стеки вызовов, версии софта и тому подобное, что пытаются от пользователя скрыть. Сидишь теперь и втыкаешь на «Oops».
это им наших ГОСТов не хватает, и нормоконтроля)) сразу бы не возникало вопросов как и что написать
Отличная статья, спасибо!
P. S. Хабр со временем растерял часть изображений, вот тут есть копия статьи, но с картинками: https://www.pvsm.ru/dokumentatsiya/290673
«Вот и всё!» Фраза кажется довольно безобидной вне контекста, но представьте, как воспринимаются определённые слова вроде «легко», «просто», «тривиально» и «несложно», когда у вас проблемы — не здорово! Когда человек застрял, пытаясь заставить API работать, такая фраза подвергает сомнению его интеллект и заставляет задать вопрос: «Значит, я глупый?» Это деморализует.
This. Всегда напрягало когда спрашиваешь как сделать х, а тебе отвечают в духе "Ну вот так, но вообще это элементарно"
Пишем техническую документацию: руководство для непрофессионала