Уязвимость Clickjacking DOM XSS на Google.org
Проект Google Crisis Map — это малоиспользуемая, но важная инициатива Google, предназначенная для предоставления пользователям по всему миру важной информации о чрезвычайных ситуациях. Запущенный в 2012 году, этот инструмент позволял частным лицам и организациям создавать и распространять критически важные карты, связанные с кризисами, такими как природные катастрофы и другие чрезвычайные ситуации.
Хотя платформа остаётся работоспособной, обновления происходят редко, что делает её привлекательной целью для исследователей безопасности, заинтересованных в обнаружении уязвимостей в устаревших приложениях, поддерживаемых крупными организациями.
Обзор домена Google.org и вопросы безопасности
Хотя Crisis Map размещена на домене google.org, который обычно вызывает меньшие опасения по поводу уязвимостей на стороне клиента по сравнению с google.com, это всё равно актив Google, требующий надёжных мер безопасности. Устаревшие проекты, такие как этот, могут непреднамеренно содержать ошибки безопасности из-за редких обновлений или менее строгих защит.
Доступ и управление картой кризисов
При посещении google.org/crisismap пользователей перенаправляют на интерактивную карту по умолчанию с названием «Погода и события». Эта карта с возможностью только для просмотра предоставляет базовый функционал без разрешения на редактирование или управление содержимым.
Чтобы получить доступ к функциям создания и управления картами, необходимо добавить .maps к URL, перейдя на google.org/crisismap/.maps. Пользователи должны аутентифицироваться с помощью аккаунта Google, после чего им становится доступна панель управления с отображением карт по умолчанию и созданных пользователями.
Создание карт и ограничения по доменам
При попытке создать новую карту, пользователи с обычным аккаунтом gmail.com получают ошибку, блокирующую создание карты. Это ограничение требует использования почты GSuite или кастомных доменов для публикации карт. После успешной аутентификации с разрешённым доменом пользователи могут создавать новые карты и использовать инструменты редактирования.
Обнаружение уязвимости DOM-базированного XSS
Добавление слоёв с потенциально вредоносными URL
В редакторе карт пользователи могут добавлять слои, указывая название и исходный URL. При тестировании с таким значением, как javascript:alert(document.domain) в поле «Исходный URL» возникает ошибка валидации на стороне клиента, требующая включения протокола (например, http:// или https://).
Фронтенд-код использует простое регулярное выражение для проверки протокола в URL, но эта проверка не реализована на стороне сервера, что создаёт возможность для эксплуатации.
Обход валидации на фронтенде путём изменения запроса
Инструменты для тестирования безопасности, такие как Fiddler или Burp Suite, позволяют перехватывать и изменять HTTP-запросы. Отправляя сначала валидный URL (например, https://example.com), а затем изменяя JSON-пayload POST-запроса к API карт, можно повторно вставить схему javascript:, обходя ограничения фронтенда.
POST https://google.org/crisismap/.api/maps/1234
{
"id": "1234",
"title": "Безымянная карта",
"base_map_type": "GOOGLE_ROADMAP",
"layers": [{
"id": "1",
"title": "Тестовый слой",
"visibility": "DEFAULT_ON",
"type": "KML",
"source": {
"kml": {
"url": "javascript:alert(document.domain)"
}
}
}]
}
Эксплуатация и тестирование XSS
После сохранения изменённой карты, при перезагрузке интерфейса и переходе на вкладку «Слои» появляется ссылка «Скачать KML» с вредоносным URL javascript:. Щелчок по этой ссылке вызывает JavaScript-оповещение, подтверждающее наличие уязвимости DOM-базированного Cross-Site Scripting.
Методы смягчения, применённые Google
Вместо усиления проверки URL на стороне сервера, Google решил проблему, очищая URL перед вставкой его в DOM. Если URL не прошёл проверку, он заменялся на безопасный заглушечный адрес, например, about:invalid, что предотвращало выполнение вредоносного JavaScript при взаимодействии с страницей.
<a href="about:invalid#zClosurez">Скачать KML</a>
Анализ воздействия и оценка серьёзности
Изначально данная XSS-уязвимость классифицировалась как self-XSS, поскольку только аутентифицированный пользователь, создавший карту, мог активировать вредоносный код. Требование входа в систему и прав на редактирование карты ограничивало немедленный риск.
Однако пользователи могут публиковать свои карты публично по URL вида https://google.org/crisismap/example.com/test. В этом случае любой посетитель сможет получить доступ к странице, возможно выполнить XSS-пейлоад и увеличить серьёзность уязвимости.
Тем не менее для срабатывания эксплуатации пользователь должен выполнить несколько действий (открыть вкладку «Слои» и нажать «Скачать KML»), что ограничивает практическую применимость атаки.
Использование Clickjacking для эскалации атаки
Ключевым фактором, позволившим усилить эту уязвимость, было отсутствие HTTP-заголовка X-Frame-Options в ответах с домена google.org. Этот заголовок указывает браузерам, разрешено ли встраивание страницы в iframe, что защищает от рисков clickjacking.
Что такое Clickjacking?
Clickjacking — это техника атаки, при которой вредоносный сайт накладывает невидимые или обманные элементы интерфейса на надёжные сайты, загруженные внутри iframe, заставляя пользователей совершать нежелательные действия.
Поскольку ответы с google.org не содержали заголовок X-Frame-Options, злоумышленник мог встроить опубликованные карты в iframe на своём сайте, наложить элементы управления с помощью CSS и симулировать клики для выполнения XSS-пейлоада без перехода пользователя на другую страницу.
Путём масштабирования и стратегического позиционирования iframe жертва могла случайно пройти необходимые шаги (вкладка «Слои» и ссылка «Скачать KML») незаметно — в результате многоступенчатый self-XSS превращался в более опасную эксплуатацию с помощью clickjacking.
Визуальная демонстрация
Оригинальный доказательный пример использовал CSS для масштабирования iframe в 50 раз и точного позиционирования кликов, с непрозрачным оверлеем, чтобы пользователи не замечали встроенное содержимое Google. Хотя живой демо-пример завершён вместе с Google Crisis Map, концепция остаётся полезной для понимания подобных уязвимостей.
Основные выводы и лучшие практики безопасности
- Никогда не доверяйте лишь валидации на стороне клиента. Надёжная проверка и очистка пользовательских данных на сервере необходимы для предотвращения атак инъекций, включая XSS.
- Реализуйте строгие меры защиты от встраивания в iframe. Используйте HTTP-заголовки, такие как
X-Frame-Options, или директивы политики безопасности контента (CSP), чтобы запрещать неавторизованное встраивание и снижать риски clickjacking. - Уделяйте внимание эскалации серьёзности уязвимостей. При обнаружении дефектов безопасности исследуйте возможности увеличения их воздействия, например через эксплуатацию неправильных настроек или цепочек уязвимостей, чтобы лучше понять риск.
- Обращайте внимание на устаревшие и малоизвестные проекты. Часто забытые старые приложения продолжают использоваться и могут содержать серьёзные уязвимости — лёгкая добыча для исследователей и атакующих.
Контекст с учётом глобальных исследований и тенденций
Постоянные проблемы в защите от XSS и clickjacking остаются актуальными по всему миру. Согласно отчёту 2023 года OWASP Top 10, уязвимости инъекций, включая XSS, неизменно входят в число самых критичных рисков безопасности веб-приложений.
Академия веб-безопасности PortSwigger подчёркивает, что недостаточная защита от встраивания значительно расширяет поверхность атаки, особенно в сочетании с уязвимостями на стороне клиента.
Инцидент с Google Crisis Map служит наглядным примером того, что даже технологические гиганты должны применять комплексную многоуровневую защиту для обеспечения безопасности онлайн-сервисов.
Заключение
Подводя итог, уязвимость Clickjacking DOM XSS в Google.org Crisis Map подчёркивает важность комплексной валидации вводимых данных, настройки HTTP-заголовков безопасности и понимания того, как, казалось бы, незначительные пробелы могут объединяться в значительные уязвимости.
Хотя Google устранил конкретную проблему, принципы и методы атак, продемонстрированные здесь, остаются актуальными для современной безопасности веб-приложений.
Внимательное отношение к устаревшим веб-ресурсам, обеспечение серверной валидации и защита от clickjacking посредством ограничений на встраивание — ключевые шаги для обеспечения безопасности пользователей и поддержания доверия к цифровым платформам.