Как удалить 1500000 записей из базы данных Yahoo

http://thehackernews.com/2014/03/yahoo-vulnerability-allows-hacker-to_1.html
  • Перевод
На четвертом по посещаемости сайте — Yahoo.com, была обнаружена очередная уязвимость, на этот раз на поддомене suggestions.yahoo.com. Эта уязвимость позволяет злоумышленнику удалить всю ленту доски предложений (Yahoo Suggestion Board), а так же все комментарии к ней.




Ибрагим Раафат (Ibrahim Raafat), специалист по информационной безопасности, обнаружил уязвимость типа 'Небезопасная прямая ссылка на объект' на одном из поддоменов сайта Yahoo. Пользуясь уязвимостью пользовательских привилегий, атакующий мог бы удалить более 365 000 сообщений и 1155000 комментария из базы данных раздела предложений по совершенствованию сайта Yahoo.

Технические подробности


В процессе удаления своего комментария, Ибрагим обратил внимание на HTTP заголовок. POST запрос выглядел следующим образом:

prop=addressbook&fid=367443&crumb=Q4.PSLBfBe.&cid=1236547890&cmd=delete_comment

Где параметр 'fid' — ID топика, а 'cid' — ID комментария. Выяснилось, что изменение значений ID топика и комментария позволяет удалить соответствующий комментарий, написанный другим пользователем.

Далее был протестирован механизм удаления топика, в следствии чего была найдена схожая лазейка. HTTP заголовок запроса удаления топика выглядит так:

POST cmd=delete_item&crumb=SbWqLz.LDP0

Выяснилось, что добавление fid (ID топика) переменной в URL позволяет удалять посты, написанные другим автором. Например:

POST cmd=delete_item&crumb=SbWqLz.LDP0&fid=xxxxxxxx

Таким образом, любой недоброжелательно настроенный программист мог написать скрипт, что привело бы к удалению всех предложений и комментариев к ним. Об уязвимости было сообщено в отдел безопасности Yahoo, на данный момент ее профиксили.

Видео-презентация уязвимости:

Поделиться публикацией
Комментарии 20
    +15
    Ну просто-таки классика жанра.
      +5
      Размер вознаграждения автору?
        +3
        Такой информацией не обладаю.
        Тоже стало интересно, написал Ибрагиму напрямую, как ответит отпишусь.
          +24
          Футболка?
          +2
          Помнится, а Facebook похожая бага была в прошлом году.
          Она позволяла удалить любую фотографию любого пользователя.

          Вознаграждение автору от FB составило $12 500.
          thehackernews.com/2013/09/vulnerability-allowed-hacker-to-delete.html

          Уж очень интересно, как Yahoo на подобный баг отреагирует в финансовом плане.
          –18
          Ок, нашёл уязвимость, протестировал несколько раз. Но зачем надо было удалять столько данных? Не поверю, что исключительно ради тестирования.
            +3
            Столько? Он удалил пару записей всего. Читайте внимательнее.
              +8
              Впервые за долгое время не узнал автора по заголовку.
                +1
                Принял за Ализара?
                  +4
                  Да, похоже у Ализара появились последователи…
                    +3
                    Заголовок просто пропитан ализарщиной
                    Ну удалит кто-то 100500 записей
                    — для рядового пользователя: ад!!! шок!!! крах интернета!!!
                    — для рядового админа: запрос в тех.поддержку на 3 минуте работы скрипта, запрет на удаление записей, закрытие дырки, откат базы на 5 минуты назад, налить новую чашку кофе
                      +1
                      откат базы данных на 5 минут в таких масштабах может удалить на много больше чем было до отката.
                  +1
                  Скорее, не угадал. :-)
              0
              А нет ли какого-нибудь паттерна работы с реляционными базами чтобы такую частую ошибку исключить? Добавить if (owner_id != user_id) может забыть каждый. А вот если бы у каждой записи были бы атрибуты, например, как в файлах: владелец, группа, права доступа, то ошибиться было бы тяжело.
                +6
                Создавайте обёртку над функциями, которые у вас работают с таблицей с данными, где будет поле с правами. Функция автоматически будет проверять права. Примерно то, что вам нужно.
                  +2
                  Ну многие думали о том чтобы добавить «row-level permissions» к реляционным базам данных. Но для web это всё равно не подходит — придётся на каждого активного пользователя создавать свое персональное соединение с базой данных, что несколько накладно и в финансовом(в случае коммерческих баз) и техническом планах.

                  Так что обычно это делается на уровне приложения в библиотеке работы с базой.
                    0
                    Обычно логика permissions чуть сложнее, чем «владельцу можно, а остальным — нет». Могут быть группы (вложеные), политики безопасности, суперюзеры и.т.д
                    –4
                    > Ибрагим Раафат (Ibrahim Raafat), специалист по информационной безопасности, обнаружил уязвимость типа 'Небезопасная прямая ссылка на объект' на одном из поддоменов сайта Yahoo

                    ололо, постоянно угораю над «важными» новостями с thehackernews. Как очередной индуский exp3rt нашел XSS в им же созданном вордпресс плагине.

                    Видео презентации отличная лакмусовая бумажка. Нормальный эксперт не будет делать ютюб видео чтобы объяснить уязвимость, потому что ее надо понять а не увидеть.

                      0
                      Зачем нужен crumb? Было бы логично именно по этому параметру отсекать попытки удалять чужие топики.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое