Предисловие
Всем привет. Мне 20 лет. Еще недавно я учился в лицее и готовился поступать в медицинский ВУЗ, а сейчас я — фулстэк разработчик в одной американской компании. На самом деле я очень рад, что с медициной у меня не вышло — программирование было моим хобби, а сейчас я могу им заниматься постоянно. Сейчас я хотел бы написать скорее не об успехе в IT. Прямо сейчас я хочу поговорить о том, как я прочитал пару книг по уязвимостям (для защиты своих проектов) и мне удалось применить эти знания на практике.
Дисклеймер
Все материалы, скриншоты, а так же ссылки на сторонние ресурсы, размещены в образовательных целях. Автор не несет ответственности за их использование другими посетителями хабра. Компания заранее уведомлена за 48 часов об уязвимости и получила достаточно данных для ее исправления.
Как все начиналось
Был вполне обычный день. Я выполнил несколько задач на работе и заварил себе чашку кофе. За одно решил прочитать одну статью про деплой приложения на AWS, которую некогда репостнул себе в вк (кстати, статью я так и не прочитал). В колонку справа от статьи выведено несколько других статей и партнерский баннер на .
Не помню уже что именно заставило меня перейти на сайт, но при переходе я заметил одну интересную особенность: ссылка ведет на страницу регистрации и на ней сразу заполнено одно поле — промокод.
Если сравнить промокод, который находится в поле для ввода и в адресной строке — увидим что они полностью совпадают.
Что мы с этим можем сделать?
Банально — попробовать изменить. Если промокод сравнивается со значением в базе — с большой вероятностью нам вернут ошибку. Но При изменении в инпуте — на сервер запроса нет и выходит, что инпут проверяется только при нажатии на кнопку регистрации.
Думаю тут уже можно сделать что-то более интересное: меняем наш промокод прямо в адресной строке и смотрим что же выйдет. Если у них нет промокода специально под хабр, который я так слету угадал,, а так же еще сотню разных наборов символов — мы точно можем менять значения поля для ввода с помощью адресной ссылки.
Следущий шаг — смотрим HTML-код. ПКМ по полю для ввода -> Просмотр кода элемента.
Здесь сразу видно, что мы меняем value поля для ввода. Попробуем выйти из него и добавить например ссылку. Для этого нам достаточно изменить ссылку и мы сможем изменить контент страницы:
Результат: только что мы нашли xss-уязвимость на сайте .
И что дальше?
Думаю стоит пойти глубже. Ссылка — как-то мелко и не интересно. Мы же хотим это все рассказать владельцам сервиса и, в идеале, получить вознаграждение (компания, кстати, не имеет bug bounty, а значит все это не оплачивается, но тогда я еще об этом не знал). Попробуем разместить блок, застиллизовать его и вставить изображение. Что для этого нужно? все то же — менять url.
Думаю описывать html и css не стоит, поэтому я просто положу тут то, что вышло. Хабр блокирует часть тегов, другие отбрасывает — не могу выложить код ссылки сюда.
Вознаграждение
Не стоит думать, что upCloud напрочь отказались платить. Вместо этого они предложили бесплатно свои услуги. Но я отказался от такого типа оплаты, так как меня мало интересует сейчас.
Как можно использовать эту уязвимость?
Тут все просто: можно начать со сбора данных всех новых пользователей, а закончить фишинговыми сайтами и использованием чужого в качестве своего. Можно заменить все ссылки на странице на собственные или подменить форму у пользователей. Достаточно их отправить как рефералов. И конечно же можно подменять запрос к серверу с формы, чтобы он не проверял промокод (при регистрации промокод проверяется, а на клиент возвращается ответ с ошибкой, но это все решается включением жс).
Что забыли сделать разработчики:
Все просто — валидировать пользовательский ввод. SQL-Inj там не проходит — сервис висит на вордпрессе, а он в свою очередь, обрабатывает входящие строки.
Поэтому мы можем:
- Сверять с базой промокод при рендере страницы
Это медленно и не оправдано. Не стоит дополнительной нагрузки на базу, да и смысла в этом нет, если он все равно проверяется при регистрации.
- Прогонять через регулярку входной промокод
/[A-Z0-9]/g — вполне достаточно для валидации значений и защиты от уязвимости. Причем это работает быстрее чем запрос к базе, а эффект не хуже — XSS снята.
Заключение
Владельцы сервиса были уведомлены за 48 часов + 2 дня до этого я вел переговоры по электронной почте и LinkedIn с теми, кто хоть как-то относится к разработке. Все разговоры приходили к: «Скажите нам пожалуйста как вы это сделали, но за уязвимости мы, конечно же, платить не будем.». Так же добавлю, что точно таким же образом сайт принимает сторонние js-скрипты: как через сторонний источник, так и прямым написанием кода, однако во втором случае Google Chrome автоматически обнаруживает xss и рендерит страницу ошибки вместо страницы сервиса.
Надеюсь каждый программист будет валидировать все входные данные и не будет забывать про querystring. А так же уверен что статья была поможет кому-то заблаговременно заметить + исправить эту проблему у себя.
Большое спасибо за внимание.
Автор: EgorVolokitin
