Google — громадная компания и для поддержания её работы необходимы тысячи поставщиков.
Следовательно, появляется необходимость контролировать покупки. Google предлагает публичный онлайн инструмент, где поставщики предъявляют им накладные и счета.
Он называется Google Invoice Submission Portal и его можно найти по адресу gist-uploadmyinvoice.appspot.com.
Первое, что вы вероятно заметили — сайт расположен на домене appspot.com, который доступен для создания на нём проектов на движке Google App Engine.
Google часто используют его для создания некоторых своих сайтов, которые впоследствии будут перенесены на google.com или другие их домены.
В данном случае Google, похоже, забыли перенести сайт расположенный на appspot.com на google.com.
Загрузка счетов и накладных на Google invoice.
Первое, что нас просят ввести - Purchase Order Number (Номер Покупки). То, что мы введём особо ни на что влияет, просто напишем случайное число и нажмём кнопку Search.
Затем нас просят выбрать организацию, относящуюся к накладной(счёту). Это определяет в какую страну мы пришлём счёт. Ещё раз, просто что-то выберите и нажмите кнопку Submit.
Теперь мы можем увидеть форму для ввода почты, номера счёта, даты и кнопку выбора файла для загрузки счёта в PDF формате.
Поиск уязвимостей
Я попытался заполнить эти текстовые поля с использованием различных вариаций XSS полезной нагрузки в надежде что где-нибудь в панели счетов google не смогли корректно избежать ввода, который бы активировал blind XSS и послал бы мне уведомление. Но это не наш случай. Я не получил ничего, текстовые поля были оформлены правильно.
В дополнение к текстовому вводу, присутствует ещё и загрузка PDF файла. Но она настроена так, что только PDF файлы могут быть выбраны для загрузки.
Так как это всего лишь внешняя проверка, это не помешает нам изменить тип файла, когда мы посылаем файл через POST запрос.
Как только мы выбираем любой PDF файл, запрос на загрузку выполнен. Мы можем перехватить его с использованием сетевого proxy отладчика и изменить имя файла и его содержимое с
Во первых, мы изменяем имя файла на
В полезной нагрузке я буду использовать
Теперь, когда HTML файл был прикреплён к форме мы можем нажать на кнопку Submit Invoices для отправки формы.
Выполнение Blind XSS
Спустя несколько дней я получил уведомление о том, что blind XSS был выполнен на домене googleplex.com
Google использует googleplex.com для хостинга внутренних сайтов и приложений. Если вы попытаетесь перейти на указанных домен, вы будете перенаправлены на страницу авторизации Google Corp (Так же известную как MOMA) – она просит аутентификации (с использованием исправного google.com аккаунта). Это значит, что она доступна только для сотрудников Google.
DOM страницы совпадает с XSS полезной нагрузкой, которая была использована вместо PDF файла.
Мы видим, что это ссылка используется для отображения PDF файла. Но так как мы изменили
Влияние
Выполнение различного JavaScript когда на поддомене googleplex.com позволяет злоумышленнику получить доступ к счетам Google и другой чувствительной информации.
Пока сотрудники Google авторизированы под их корпоративными аккаунтами, возможно получить доступ к другим внутренним сайтам от их имени.
Обновлено: Сказанное в предыдущем абзаце было неверно. Я получил Больше информации от команды безопасности Google:
Исправление уязвимости
Я сразу же выслал данные о найденной уязвимости в Google. После добавления некоторой дополнительной информации, через 4 дня я получил уведомление, что отчёт был принят.
Примерно через месяц я мог подтвердить, что уязвимость была исправлена.
Несмотря на это, после того как уязвимость была исправлена, XSS всё ещё была, но не на googleplex.com, а на домене storage.googleapis.com – он представляет из себя песочницу и используется(так же как и googleusercontent.com) для хранения загруженных пользователями данных
XSS теперь на домене в песочнице, где не представляет вреда для пользователя.
График:
21.02.2019: Данные об уязвимости отправлены
22.02.2019: Приоритет изменён на P2
22.02.2019: Добавлена дополнительная информация
25.02.2019: Информация принята и приоритет изменён на P1
06.03.2019: Выдано вознаграждение
26.03.2019: Исправление уязвимости
11.04.2019: Уязвимость помечена как исправленная
Оригинал: тыц
Автор: ThomasOrlita.cz
Твиттер автора: @ThomasOrlita
Переведено для:
Следовательно, появляется необходимость контролировать покупки. Google предлагает публичный онлайн инструмент, где поставщики предъявляют им накладные и счета.
Он называется Google Invoice Submission Portal и его можно найти по адресу gist-uploadmyinvoice.appspot.com.
Первое, что вы вероятно заметили — сайт расположен на домене appspot.com, который доступен для создания на нём проектов на движке Google App Engine.
Google часто используют его для создания некоторых своих сайтов, которые впоследствии будут перенесены на google.com или другие их домены.
В данном случае Google, похоже, забыли перенести сайт расположенный на appspot.com на google.com.
Загрузка счетов и накладных на Google invoice.
Первое, что нас просят ввести - Purchase Order Number (Номер Покупки). То, что мы введём особо ни на что влияет, просто напишем случайное число и нажмём кнопку Search.
Затем нас просят выбрать организацию, относящуюся к накладной(счёту). Это определяет в какую страну мы пришлём счёт. Ещё раз, просто что-то выберите и нажмите кнопку Submit.
Теперь мы можем увидеть форму для ввода почты, номера счёта, даты и кнопку выбора файла для загрузки счёта в PDF формате.
Поиск уязвимостей
Я попытался заполнить эти текстовые поля с использованием различных вариаций XSS полезной нагрузки в надежде что где-нибудь в панели счетов google не смогли корректно избежать ввода, который бы активировал blind XSS и послал бы мне уведомление. Но это не наш случай. Я не получил ничего, текстовые поля были оформлены правильно.
В дополнение к текстовому вводу, присутствует ещё и загрузка PDF файла. Но она настроена так, что только PDF файлы могут быть выбраны для загрузки.
Так как это всего лишь внешняя проверка, это не помешает нам изменить тип файла, когда мы посылаем файл через POST запрос.
Как только мы выбираем любой PDF файл, запрос на загрузку выполнен. Мы можем перехватить его с использованием сетевого proxy отладчика и изменить имя файла и его содержимое с
.pdf на .html.
Во первых, мы изменяем имя файла на
test.html, его Content-Type на text/html и внедряем в него XSS полезную нагрузку.В полезной нагрузке я буду использовать
<script> тэг с src ссылкой на мой домен, которая будет посылать мне email каждый раз, когда она загружена. Я использую ezXSS для логирования этих blind XSS запросов.
Теперь, когда HTML файл был прикреплён к форме мы можем нажать на кнопку Submit Invoices для отправки формы.
Выполнение Blind XSS
Спустя несколько дней я получил уведомление о том, что blind XSS был выполнен на домене googleplex.com
Google использует googleplex.com для хостинга внутренних сайтов и приложений. Если вы попытаетесь перейти на указанных домен, вы будете перенаправлены на страницу авторизации Google Corp (Так же известную как MOMA) – она просит аутентификации (с использованием исправного google.com аккаунта). Это значит, что она доступна только для сотрудников Google.
DOM страницы совпадает с XSS полезной нагрузкой, которая была использована вместо PDF файла.
Мы видим, что это ссылка используется для отображения PDF файла. Но так как мы изменили
Content-type с application/pdf на text/html, она отображает XSS полезную нагрузку вместо PDF.Влияние
Выполнение различного JavaScript когда на поддомене googleplex.com позволяет злоумышленнику получить доступ к счетам Google и другой чувствительной информации.
Обновлено: Сказанное в предыдущем абзаце было неверно. Я получил Больше информации от команды безопасности Google:
Это значит, что злоумышленник всё ещё может получить доступ к поддомену, где хранятся счета, но доступ к другим приложениям на googleplex.com невозможно получить из-за CORS.
Исправление уязвимости
Я сразу же выслал данные о найденной уязвимости в Google. После добавления некоторой дополнительной информации, через 4 дня я получил уведомление, что отчёт был принят.
Примерно через месяц я мог подтвердить, что уязвимость была исправлена.
Несмотря на это, после того как уязвимость была исправлена, XSS всё ещё была, но не на googleplex.com, а на домене storage.googleapis.com – он представляет из себя песочницу и используется(так же как и googleusercontent.com) для хранения загруженных пользователями данных
XSS теперь на домене в песочнице, где не представляет вреда для пользователя.
График:
21.02.2019: Данные об уязвимости отправлены
22.02.2019: Приоритет изменён на P2
22.02.2019: Добавлена дополнительная информация
25.02.2019: Информация принята и приоритет изменён на P1
06.03.2019: Выдано вознаграждение
26.03.2019: Исправление уязвимости
11.04.2019: Уязвимость помечена как исправленная
Оригинал: тыц
Автор: ThomasOrlita.cz
Твиттер автора: @ThomasOrlita
Переведено для:
https://xss.pro/threads/29867/
Последнее редактирование: