Хабрахабр

[Из песочницы] Как я нашел свою первую уязвимость?

Предисловие

Всем привет. Мне 20 лет. Еще недавно я учился в лицее и готовился поступать в медицинский ВУЗ, а сейчас я — фулстэк разработчик в одной американской компании. На самом деле я очень рад, что с медициной у меня не вышло — программирование было моим хобби, а сейчас я могу им заниматься постоянно. Сейчас я хотел бы написать скорее не об успехе в IT. Прямо сейчас я хочу поговорить о том, как я прочитал пару книг по уязвимостям (для защиты своих проектов) и мне удалось применить эти знания на практике.

Дисклеймер

Все материалы, скриншоты, а так же ссылки на сторонние ресурсы, размещены в образовательных целях. Автор не несет ответственности за их использование другими посетителями хабра. Компания заранее уведомлена за 48 часов об уязвимости и получила достаточно данных для ее исправления.

Как все начиналось

Был вполне обычный день. Я выполнил несколько задач на работе и заварил себе чашку кофе. За одно решил прочитать одну статью про деплой приложения на AWS, которую некогда репостнул себе в вк (кстати, статью я так и не прочитал). В колонку справа от статьи выведено несколько других статей и партнерский баннер на хостинг-провайдера.

image

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

Если сравнить промокод, который находится в поле для ввода и в адресной строке — увидим что они полностью совпадают.

image

Что мы с этим можем сделать?

Банально — попробовать изменить. Если промокод сравнивается со значением в базе — с большой вероятностью нам вернут ошибку. Но При изменении в инпуте — на сервер запроса нет и выходит, что инпут проверяется только при нажатии на кнопку регистрации.

Если у них нет промокода специально под хабр, который я так слету угадал,, а так же еще сотню разных наборов символов — мы точно можем менять значения поля для ввода с помощью адресной ссылки. Думаю тут уже можно сделать что-то более интересное: меняем наш промокод прямо в адресной строке и смотрим что же выйдет.

image

ПКМ по полю для ввода -> Просмотр кода элемента. Следущий шаг — смотрим HTML-код.

image

Попробуем выйти из него и добавить например ссылку. Здесь сразу видно, что мы меняем value поля для ввода. Для этого нам достаточно изменить ссылку и мы сможем изменить контент страницы:

image

Результат: только что мы нашли xss-уязвимость на сайте хостинг-провайдера.

И что дальше?

Думаю стоит пойти глубже. Ссылка — как-то мелко и не интересно. Мы же хотим это все рассказать владельцам сервиса и, в идеале, получить вознаграждение (компания, кстати, не имеет bug bounty, а значит все это не оплачивается, но тогда я еще об этом не знал). Попробуем разместить блок, застиллизовать его и вставить изображение. Что для этого нужно? все то же — менять url.

Хабр блокирует часть тегов, другие отбрасывает — не могу выложить код ссылки сюда. Думаю описывать html и css не стоит, поэтому я просто положу тут то, что вышло.

image

Не знаю работает ли она в данный момент, но при выкладывании поста работала. Выложу сюда ссылку. Кому надо — вытащит ссылку и распарсит.

Вознаграждение

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

Как можно использовать эту уязвимость?

Тут все просто: можно начать со сбора данных всех новых пользователей, а закончить фишинговыми сайтами и использованием чужого хостинга в качестве своего. Можно заменить все ссылки на странице на собственные или подменить форму у пользователей. Достаточно их отправить как рефералов. И конечно же можно подменять запрос к серверу с формы, чтобы он не проверял промокод (при регистрации промокод проверяется, а на клиент возвращается ответ с ошибкой, но это все решается включением жс).

Что забыли сделать разработчики:

Все просто — валидировать пользовательский ввод. SQL-Inj там не проходит — сервис висит на вордпрессе, а он в свою очередь, обрабатывает входящие строки.

Поэтому мы можем:

  1. Сверять с базой промокод при рендере страницы

    Не стоит дополнительной нагрузки на базу, да и смысла в этом нет, если он все равно проверяется при регистрации.
    Это медленно и не оправдано.

  2. Прогонять через регулярку входной промокод

    Причем это работает быстрее чем запрос к базе, а эффект не хуже — XSS снята.
    /[A-Z0-9]/g — вполне достаточно для валидации значений и защиты от уязвимости.

Заключение

Владельцы сервиса были уведомлены за 48 часов + 2 дня до этого я вел переговоры по электронной почте и LinkedIn с теми, кто хоть как-то относится к разработке. Все разговоры приходили к: «Скажите нам пожалуйста как вы это сделали, но за уязвимости мы, конечно же, платить не будем.». Так же добавлю, что точно таким же образом сайт принимает сторонние js-скрипты: как через сторонний источник, так и прямым написанием кода, однако во втором случае Google Chrome автоматически обнаруживает xss и рендерит страницу ошибки вместо страницы сервиса.

А так же уверен что статья была поможет кому-то заблаговременно заметить + исправить эту проблему у себя. Надеюсь каждый программист будет валидировать все входные данные и не будет забывать про querystring.

Большое спасибо за внимание.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть