Взламывают всех. Нет такого защищенного портала, который еще никогда не ломали. Если вас не взломали вчера и сегодня — вас взломают завтра. Любая атака начинается с изучения портала, сайта или ресурса, чтобы понять, с какой стороны проще зайти. Для этого существуют разные механизмы: XSS, SQL-injection и другие. Меня зовут Сергей Рысин, я — специалист по кибербезопасности в hh.ru, и в этой статье я расскажу об XSS.
XSS: вас взломали
Вы точно слышали об атаках на большие инфраструктуры, при которых похищались персональные данные, медицинские данные пользователей и клиентов. Основная задача DevOps-разработчиков и специалистов по кибербезопасности — обеспечить защиту этих данных. Необходимо создать такие условия, чтобы коварный хакер тратил на взлом максимально возможный объем знаний, времени и денег. При таких раскладах атака на ваш ресурс была невыгодна для злоумышленников.
XSS — это межсайтовый скриптинг. Проще говоря, это попытка управления вашим браузером без вашего ведома. С помощью XSS злоумышленник может сделать как минимум три вещи — скриншот ваших активных сессий, похищение всех паролей из браузера и кража всех куков. Потом он, конечно, сможет провернуть еще много разных неприятных вещей, но об этом позже.
Суть любой XSS — это внедрение JavaScript в кишочки вашего портала и выполнение их на стороне вашего браузера или браузера-жертвы. Это производится методом включения дополнительных полей в скрипт или внедрения и переопределения переменных вашей страницы.
Работает это достаточно просто. Браузер воспринимает любой код, который мы передаем и обрабатываем на веб-сервере, как набор html-форм JavaScript и CSS. При внедрении XSS в ваш ресурс браузер начинает обрабатывать его как легитимный код, который необходимо выполнить. Цель любого девопса и специалиста по кибербезопасности — минимизировать риск выполнения произвольного кода, который передается в формы на ваших сайтах, порталах и ресурсах.
Внедрение XSS
Есть два вида XSS: первый не требует взаимодействия с пользователем, а второй — да. Взаимодействием с пользователем может считаться элементарное наведение курсора на XSS. Одно легкое движение — и XSS уже будет выполнен. Здесь стоит ввести два важных определения, которые нам понадобятся, чтобы разобраться, что такое XSS:
XSS-вектор — это механизм, который мы внедряем в портал, сайт или ресурс. Это набор html-кода и JavaScript.
XSS-контент — это место, куда мы внедряем XSS-вектор. Форма или переменные, которые мы пытаемся заменить на портале жертвы.
Эксплуатировать XSS можно везде, где пользователь способен ввести свой текст — любая форма, поисковый запрос и обращение к службе поддержки. Хороший пример множественных взломов опенсорсных CMS привел в одном из своих докладов гуру XSS Игорь Саксаковский (@psihoz26):
(СКРИН) https://swarm.ptsecurity.com/fuzzing-for-xss-via-nested-parsers-condition/
Звучит, наверное, уже очень страшно. Но давайте посмотрим на те примеры, которые подготовил для вас я. Пример элементарного чатика:
Здесь мы видим, как пользователь обращается в поддержку. Он отправляет ссылку на какую-то страничку и говорит, что там невозможно, например, открыть определенную вкладку. Внутренний парсер формы обратной связи обрабатывает нашу страничку как a href-ссылку. Вот пример как это должно отображаться в html-коде нашего чата:
Здесь злоумышленник понимает, как парсер html-запросов и разбор типов протоколов существуют в чате. Дальше он отправляет свой email и просит связаться с ним по указанному адресу. Обработка этого сообщения происходит следующим образом: добавляется “mailto”, а html-форма выглядит как “a href=mailto” плюс адрес того ящика, который злоумышленник направил в чат. В эту форму можно отправить и XSS, которая легко распарсится, а когда сотрудник техпода перейдет куда надо, злоумышленник получит управление над браузером специалиста технической поддержки.
Защищаемся
Существует несколько методов защиты от взлома через XSS. Один из них — формирование content security policy, которая запрещает на портале межсайтовый скриптинг и загрузку картинок, дополнительного кода, html-форм и всего остального. Это позволит минимизировать риск использования XSS. Еще один метод защиты от XSS — это использование фреймов, которые тегируются для форм обратной связи и того, куда именно пользователи вводят данные. Например, контроль входных параметров и контроль этих полей с дополнительными методами.
С точки зрения разработки необходимо всегда контролировать формы, которые заполняют пользователи, полностью экранировать их, осуществлять парсинг и анализ всего, что вводится пользователями в формы. Еще один механизм по борьбе с XSS, который используют девопсы и инженеры по кибербезопасности — это WAF, web application firewall. Но, сразу хочу сказать, WAF — это не ультрасупермегапилюля, которая решит вашу проблему. Этот механизм призван защитить те формы, которые вы заведомо завели в WAF и смогли описать, что можно делать в этой форме, а что нельзя.
В следующей статье планирую рассказать об SQL-injection и других популярных инструментах и способах киберпроникновения со взломом. Stay tuned!
