Comments 25
Все это следствие появления всяких модных фреймворков, когда сайт с "helo world" пишется месяц и содержит 100500 строчек кода. А так же общего падения уровня программистов, разделения на вякие фронтенды, бекэнды и прочие хренды. Подобная ошибка еще 10-15 лет назад была бы абсолютно недопустима не только для крупной компании но и для школьника начавшего изучать программирование! Ведь это обсолютный непроффесионализм- допустить ошибку в нескольких строчках с if else! С моей точки зреня посе такой ошибки проект нужно закрывать, а всех "программистов" ( так их можно называть только в кавычках" расспускать.
обсолютный непроффесионализм
Мои глаза...
Мне кажется, тут больше ошибка тестировщика, который прошёл не по всем кейсам и не проверил вариант с очень длинным именем пользователя.
Мое мнение нет. Тестировщик тут вообще не нужен, и все возможные комбинации он все равно не переберет, а ведь ошибки могут быть самые разные. А нужен тут грамотный аудит кода. А лучьше самоаудит. Грамотному программисту достаточно пятнадцати мирут что бы выявить все проблемы кода по исходникам.
А это прям нормальный кейс тестирования проверять 52+ символа логин с неправильным паролем и какими-то не очень внятными дополнительными условиями.
Да вроде обычный кейс. Вводишь логин максимальной длины + пароль максимальной длины. Я думаю, что все тестировщики знают о популярной проблеме с обрезкой хэшей, когда в пароле учитывается только часть символов, либо когда не учитываются заглавные/строчные буквы. Этот кейс покрыл бы и эту проблему тоже.
Тут ведь дело не в количестве символов, а в количестве байтов. В ASCII и в UTF8 будет разная максимальная длина.
А если проблема бы возникала при длине в 104 символа или 1024? Где понять "чуть больше максимума"?
А бэкенд тестировщики смогут протестить таким образом? То есть, длина поля ввода ограничивается на фронте и всё ок, но на бэке нормальной проверки нет и тестировщик не факт что сможет добраться до проблемы.
Тестировщик заходит в бар и заказывает один бокал пива. Заказывает 0 бокалов пива. Заказывает 99999999999999999 бокалов пива. Заказывает ящерицу. Заказывает -1 бокал пива. Заказывает лджвыоелдоетйцдтк.
В бар заходит первый покупатель и спрашивает "а где тут у вас туалет?". Бар с грохотом рушится.
Думаю, что нет ошибки тестировщиков потому как их скорее всего просто нет.
Компании уже давно пришли к выводу, что тестировщики не нужны.
Это ошибка разработчика, который не изучил используемый алгоритм и не узнал о его ограничениях. Об особенности bcrypt известно уже больше 10 лет.
Надеяться на тестировщиков в таком случае не очень то надёжно.
То есть вы не осилили понять причину бага по 4 небольшим абзацам статьи?
Интересно, как эту ошибку отловили и почему через 3 месяца.
Возможно, какой-то из пользователей с длинным именем как-то раз заметил, что при ошибке в пароле всё-равно пускает в учетку. А там можно проверить и любой рандомный пароль и понять, что любой пароль подходит
Крупная компания, которая специализируется на аутенифкации. Проводили какой-нибудь white box security audit и нашёлся некто знающий про ограничение в 72 байта для bcrypt (я до прочтения этой заметки не знал, например). Этого уже достаточно.
Соответственно проверили, не используется ли bcrypt где-нибудь со входными данными длиннее этих 72 байт. Ну а дальше видим, что хешируется строка " идентификатора пользователя + имени пользователя + пароля" и делаем очевидный вывод, что с длинным юзернеймом пароль вылетает дальше 72 байт и не влияет на итоговый хеш. Если это не падает с ошибкой, а входная строка тупо отсекается, то всё, вот она дыра.
нашёлся некто знающий про ограничение в 72 байта для bcrypt (я до прочтения этой заметки не знал, например)
Даешь уязвимость в массы:
https://www.php.net/manual/ru/function.password-hash.php
А ранее обсирали тех, кто использует md5. А тут такой поворот.
В одном из ранних apache (, как оказалось,) использовалась какая-то слабая криптофункция, которая проверяла только первые N символов пароля. Я открыл небольшой кирпичный заводик, когда я опечатался в пароле — а меня пустило!
Вспоминаю недавнюю уязвимость https://en.wikipedia.org/wiki/RegreSSHion , которую случайно заметили из-за того, что соединение проходило на ~0.5с медленнее. Мне тот случай служит напоминанием, как важно, чтобы у программистов было свободное время, не только исполнение задач из jira, но и какое-то время чтобы могли делать то, что сами считают нужным.
Уязвимость оказалась обнаружена почти вовремя потому что звезды сошлись - один из немногих людей, кто мог разобраться в коде ssh заметил эту странность (едва уловимую! ее всегда можно списать на "показалось" или "потеря пакета, наверное" или "пора обновлять сервер") - и начал тратить время на исследование этой проблемы, которая скорее всего могла оказаться не проблемой.
Примерно как история с Митником, когда его начали ловить после расхождения бухгалтерии на 1 цент. Должно быть "время на любопытство". Технари ведь для того и работают, чтобы руководители сверху про мелкие проблемы даже и не знали (у них и так есть, о чем думать). А когда технарь делает только задачи сверху, мы получаем ситуацию, когда он работает под управлением слепого. Начальник с высоты своего птичьего полета знает бизнес-задачу, (нужно какую-то фичу сделать в проекте), но он не знает того, что увидел программист или админ, когда с лупой на земле муравейник разглядывал.
Не будете тестировать вы - будут другие. Предрекаю, что автоматическое обнаружение логических ошибок и тех, подобной этой, после рефакторинга или миграции станет новым классом ошибок. Личный опыт уже был, а там скорее всего было банальное "забыли прописать условие" или ошиблись в булевой логике.
С тем как улучшается инструментарий выходят на первый план другие вещи. Когда-то просто было заовнить почтовый клиент, сегодня для кражи банковских средств проще нанять людей и обзванивать в поисках доверчивых простофиль.
Ошибка входа в учётку Okta позволяла обойти проверку пароля при вводе имени пользователя с более чем 52 символами