Как стать автором
Обновить

Как ездить на такси за чужой счёт — уязвимости на примере одного сервиса

Время на прочтение6 мин
Количество просмотров36K
Всего голосов 96: ↑96 и ↓0+96
Комментарии22

Комментарии 22

Позже мне выплатили ещё немного денег.

Редкий случай в практике, относительно небольших фирм, являющимися владельцами сервиса с уязвимостью.
Я тоже раньше так думал — что небольшие фирмы меньше платят и платят ли вообще без наличия официальной Bug bounty программы.
А сегодня сообщил про одну проблему в банк, и разработчики (большая независимая IT-компания с кучей клиентов) заплатила столько же, сколько и указанный выше сервис такси при первом обращении. Ожидалось, конечно, наоборот)
Как видно из данной и предыдущей статей, иногда PHPSESSID, Authorization или SecurityToken недостаточно.

Тут скорее проблема в том, что сессия пхп не хранила нужных данных. После аутентификации и авторизации такая вещь как номер телефона должна быть в сессии, либо извлекаться из СуБД на сервере из данных сессии.

Т.е. в этих запросах в принципе не должен передаваться номер телефона. Проблемы можно было избежать на этапе проектирования.
Не очень понятно, ошибка 2 заключалась в том, что система не проверяла совпадение токена, применяемого для авторизации и данных по запрашиваемому телефону — что они принадлежат одному и том же клиенту? Просто выдавала данные по любому переданному телефону?
В запросе видно что они требуют PHPSESSID, но видимо им на самом деле не пользуются.
Частые ошибки, как-то на этапе тестирования одного платежного софта, нашли похожую проблему.
При отправке кода подтверждения клиенту, обычным рестом дергался сервис рассылки, куда передавался сам сгенерированный код, а должно было на уровне бэка в кэшах.
Похожее описано в предыдущем посте, а также я находил ситуацию, когда код, который клиент должен ввести для входа, видно в запросе (сеть АЗС и сеть магазинов).
UPD: наверное, напишу когда-то о втором случае.
Сотрудничаю сейчас с одной фирмой, что создает ПО для такси.
3 менеджера-руководителя + 2 джуна, что все это пишут.
Реально.

Реальность такова, что, в общем-то написать и джуну это посильно, а то что это небезопастно ит.п. и т.п. — так для их бизнеса всё равно. Пока бизнесу ничего серьёного за это не будет — так и будут делать.

Обсуждали с ними другой проект и стоимость его — и когда я говорил о надежности (репликация), безопасности (шифрование, ключи) — видел в их глаза «да ты просто деньги с нас хочешь вытянуть дополнительно за не нужные вещи».
Как-то восстанавливал данные таксистам. Сервер — два IDE-диска в рейде. Один из них сдох давно, и никто не почесался. Электричество рубанули, оно ребутнулось. У мускуля закорраптилась одна табличка, но так, что простыми средствами не лечилась (остальные — выжили). На тупой вопрос вида — мужики, либо мы создаем ее пустой и вы теряете все звонки клиентов за последние полгода, либо мы их долго и мучительно по крупицам выуживаем из остатков файлов (но оно дорого, ясное дело) — ответ был — «Обидно конечно, база телефонов была ценная, да ну нафиг, пересоздавай». На вопрос — А бэкап вам учинить — ответ был «а ну нафиг, дорого»…

"какой-то токен" — первая мысль была о том самом для безакцептного списания. Зачем вообще токен на клиенте?! Он сам стучится в платёжный шлюз? Или просто результат select *?

А как фидлером с другого устройства перехватывать? Или приложение запущено на эмуляторе на компе?
Спасибо. Видимо, моему смартфону наплевать на настройки прокси wifi. При настройке прокси в браузере на другом компе, всё работает.
Можно это как-нибудь на роутере настроить?
Не смартфону, а приложению. Настройки прокси не обязательны к применению всеми приложениями. Настраивайте прозрачное (transparent) проксирование — ваш компьютер назначается шлюзом и весь нужный трафик уже самостоятельно заворачивает ваша ОС, как вы ей укажете. А ещё существует public key pinning, который так же может обламывать весь процесс.
Кстати, рекомендую попробовать mitmproxy. У него есть некоторые преимущества (может и недостатки тоже, но мне о них неизвестно).
У меня в самом начале была забавная ситуация, когда я не мог отслеживать запросы, не понимая, что не так — оказалось, что firewall на компьютере блокировал входящие соединения.

Сейчас всё пофиксили? Что за компания извозчик?

Да, все проблемы были исправлены несколько недель назад. Название компании сказать не могу.

Почему? Все баги же пофиксили, разве нет?
К тому же, как я понял, Вы не подписывали никаких NDA.


Мне интересен сервис, который реально признаёт свои косяки и устраняет их.
Спасибо.

Очевидно же, что компания попросила его по-человечески, без всяких NDA, не портить им имидж.

Простите не считаю такой подход верным, но это моё субъективное мнение. К тому же имидж ка раз в безопасности тут, т.к. это первый случай, когда подобные сервисы не стали угрожать, а честно исправили, да ещё и деньгами отплатили. Туту как раз всё с точностью да наоборот.

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

ну так я и прошу название в ЛС скинуть, а не всеобщее обозрение вроде… впрочем, раз автор не хочет — его право...


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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории