Как я обнаружил несколько уязвимостей отраженного межсайтового скриптинга (rXSS) в Facebook
Привет, мир! ❤️
Добро пожаловать в мой очередной пост в блоге. Я надеюсь, что у вас все хорошо и безопасно. Это сообщение об уязвимостях отраженного межсайтового скриптинга (rXSS), которые я обнаружил на Facebook. Я предлагаю вам прочитать мою предыдущую статью, прежде чем читать эту, в которой я нашел несколько SSRF на сервере Facebook, где был развернут уязвимый сторонний портал бизнес-аналитики (MicroStrategy Web SDK). Если вы сначала прочтете эту статью, вам будет легче понять.
Этот пост о каком-то сложном rXSS, который я нашел на Facebook, было немного сложно обнаружить и использовать. Как уже говорилось в моей предыдущей статье, MicroStrategy Web SDK размещался на рабочем сервере Facebook. Я искал функцию загрузки файлов, чтобы я мог загрузить веб-оболочку на сервер.
Перечислив предварительно созданные задачи, я обнаружил, что задача uploadFile была зарегистрирована и доступна.
На веб-сайте MicroStrategy не было много документации по этой задаче. Поэтому я решил вручную просмотреть исходный код для этой задачи. Я уже загрузил MicroStrategy Web SDK в свою локальную систему, я начал искать класс Java для задачи uploadFile.
Я декомпилировал каждый файл jar SDK с помощью инструмента jd-gui и начал искать класс com.microstrategy.web.tasks.UploadFileTask. Я обнаружил, что файл WebTasks.jar имеет класс com.microstrategy.web.tasks.UploadFileTask.
Я заметил, что он поддерживает загрузку файлов и их обработку. Сначала он проверит параметр URL fileFieldName, который должен совпадать с фактическим именем файла (которое мы хотим загрузить). Затем он проверит расширение файла, если это был файл Excel (xlsx и xls), он вызовет функцию parseUploadedExcelFile, а для других файлов он обработает файл с помощью parseUploadedFile функция.
Функция parseUploadedExcelFile сначала проверяет действительный сеанс, поэтому мне не удалось загрузить какой-либо файл Excel, но функция parseUploadedFile не проверила действительный сеанс.
Фактически он не сохранял загруженный файл на сервере, вместо этого использовалась задача uploadFile для обработки загруженного файла из HTML-формы и возврата содержимого файла клиенту. Невозможно было загрузить веб-оболочку, потому что она не сохранила ее на сервере.
Я заметил, что класс UploadFileTask обрабатывает данные из загруженного файла и отображает их без выходной кодировки. Это может привести к выполнению произвольного кода JavaScript в контексте m-nexus.thefacebook.com.
Было подтверждено, что существует уязвимость отраженного межсайтового скриптинга, но вопрос был в том, как ее использовать? 🤔
Я быстро создал веб-страницу, чтобы использовать этот XSS.
К сожалению, я не смог воспользоваться этим, потому что я (как злоумышленник) не могу контролировать содержимое файла. 😕
После небольшого исследования этого вопроса было подтверждено, что загрузка файлов на основе форм не позволяет злоумышленнику указывать содержимое файла.
Настоящая проблема здесь. 😨
После многих проб и ошибок я создал небольшой код HTML + JavaScript, из которого я могу отправить файл через типичную форму POST и вызвать уязвимость межсайтового скриптинга. 😎
Все, что мне нужно сделать, это разместить этот файл на моем сервере и отправить его ссылку жертве, когда она нажимает на ссылку, это вызывает всплывающее окно XSS с именем домена.
Наблюдайте за HTTP-ответом уязвимого URL-адреса в инструменте прокси-сервера Burp Suite. Отражение кода HTML / JavaScript без кодировки вывода
XSS-атаки могут позволить злоумышленнику выполнять сценарии на клиентском компьютере, которые могут собирать информацию о системе и отправлять эту информацию злонамеренной третьей стороне.
Атака XSS может иметь потенциально серьезные последствия. Злоумышленник может обманом заставить пользователя выполнить непредусмотренные задачи, манипулируя DOM приложения. Сообщив об этой проблеме в Facebook, они дали мне очень хорошее вознаграждение.
Следующая история ⏭️
Эта история связана со слепой уязвимостью SSRF, которую я обсуждал в своем предыдущем посте. Как вы знаете, я нашел задачу wikiScrapper, перечислив предварительно созданные задачи, которые используются для очистки содержимого Википедии. У него есть параметр searchString, который принимает ключевое слово и извлекает / очищает данные из Википедии.
Я заметил, что если мы предоставляем строку, начинающуюся с http: // ИЛИ https: //, то она извлекает данные с этого веб-сайта (произвольного веб-сайта). Он не кодировал данные при отображении веб-контента, это определило, что параметр searchString был уязвим для отраженного межсайтового скриптинга.
Чтобы очистить любую веб-страницу, размещенную в произвольном домене, должны быть выполнены определенные условия. Первое условие - это должна быть HTML-страница со всеми необходимыми тегами, такими как HTML, BODY и H1. Во-вторых, он должен содержать таблицу, а тег таблицы должен содержать хотя бы один wikitable класс.
Чтобы воспользоваться этим, все, что мне нужно было сделать, это разместить специальную веб-страницу, которая удовлетворяет всем вышеуказанным условиям, а затем передать ее ссылку в параметр searchString. Я быстро создал HTML-код (с полезной нагрузкой XSS) и разместил его на HTML Pasta (это позволяет анонимно размещать ваш HTML-код бесплатно)
Теперь откройте эту специально созданную ссылку в браузере и посмотрите, как всплывает XSS с именем домена.
Наблюдайте за HTTP-ответом уязвимого URL-адреса в инструменте прокси-сервера Burp Suite. Код HTML / JavaScript отражает без кодировки вывода.
После сообщения об этой проблеме в Facebook они дали мне очень хорошее вознаграждение.
Заключение
Точно так же я сообщил еще о 3 rXSS на Facebook. Я получил пятизначное вознаграждение за все это XSS. Теперь все проблемы исправлены. Домен m-nexus.thefacebook.com больше не является общедоступным.
Надеюсь, вам понравилась статья. Простите меня за ошибки.
Спасибо, что прочитали. Продолжайте учиться.
Оставайтесь в безопасности и будьте здоровы 😇
