Привет, хакеры, я Лив, исследователь веб-безопасности и разработчик полного стека.
Бесполезная открытая переадресация
Давайте перейдем сразу к делу. Мне была представлена цель биржевого маркетинга, которая на первый взгляд кажется довольно странной на странице входа —
Если вы знакомы с уязвимостью Open Redirects, вам было бы интересно сначала увидеть ввод URL-адреса Remote Page Layout Redirect.
Ну… не так просто -
Я начал тестирование, поместив некоторые URL-адреса в введите, чтобы проверить поведение функции, есть ли белый список утвержденных URL-адресов? или это просто перенаправление без фильтра на любой веб-сайт, который я хочу.
После некоторого тестирования кажется, что ничего там нет, страница не перенаправляется после входа в систему, нет ничего!
Я пошел дальше и попытался проверить другие параметры, затем обнаружил странное поведение. При вводе любого символа, который не является нулевым, в поле URL-адрес макета удаленной страницы в сочетании с полем перенаправления я получил открытое перенаправление при входе в систему.
Хорошо, красиво, очень странно и странно, но приятно! При попытке дальнейшей эскалации кажется, что веб-приложение возвращает код ошибки в параметре GET следующим образом:
*javascript:alert() тоже не работал :(
Я попытался поместить переменные с полезной нагрузкой в URL-адрес, чтобы создать открытую фишинговую ссылку перенаправления для отправки, но снова эта странная цель не отражала значение из параметра GET для ввода HTML даже после тестирования JS, HTML и отладки. это. Бесполезный открытый редирект без возможности даже передать его другим пользователям?
Не совсем, оставайтесь со мной.
Сохраненный XSS, но эгоистичный
Позже я проверил поле ввода псевдонима для XSS, опять же, параметры GET не отражаются на странице входа. Я попытался внедрить полезную нагрузку и выполнить поиск XSS второго порядка на странице индекса после входа в систему. К сожалению, все входные данные казались отфильтрованными или закодированными в HTML, но подождите секунду… Я вернулся на страницу входа для дальнейшего тестирования и кое-что увидел. интересный!
Параметр псевдонима не санируется, а еще лучше сохраняется на сервере после входа в систему. Исправим пейлоад и выполним XSS —
У нас есть сохраненный XSS, это верно?
1. Самосохраняемый XSS :(
2. XSS срабатывает только тогда, когда пользователь возвращается на страницу входа, что может быть полезно для кражи его файлов cookie после того, как он вошли в систему, но не так выполнимо.
Сцепление багов для победы
И тут меня осенило… Что, если я совмещу CSRF входа (этот тип CSRF обычно не защищен из-за характера атаки), открытое перенаправление Я нашел это раньше, и сохраненный XSS все вместе?
Это выглядит следующим образом:
1. Жертва заходит на мой веб-сайт, POST Login CSRF запускается автоматически с открытой полезной нагрузкой перенаправления и полезной нагрузкой XSS .
2. Полезная нагрузка открытого перенаправления — это страница входа на веб-сайт.
3. Жертвы входят на веб-сайт, перенаправляются после входа обратно на страницу входа, и XSS выполняется мгновенно.
Я поговорил со своим коллегой-партнером Ошером Збади, чтобы это произошло вместе, и мы закодировали POC.
Помните код ошибки из предыдущего перенаправления?
Атака не удалась. Мы были очень разочарованы, но я ни в коем случае не отказываюсь от этого.
Обман синтаксического анализатора
Мы подумали, как обойти этот код ошибки, дело в том, что я контролирую URL-адрес перенаправления. Код ошибки добавляется как параметр GET, что, если я добавлю фрагмент в конце открытого URL-адреса перенаправления, чтобы сервер игнорировал код ошибки при разборе URL-адреса?
Для тех из вас, кто не знаком- «Фрагмент — это внутренняя ссылка на страницу, которую иногда называют именованным якорем. Обычно он появляется в конце URL-адреса и начинается с символа решетки (#), за которым следует идентификатор».
Этот прием может сработать, потому что браузер игнорирует все после объявления фрагмента в URL-адресе.
Поэтому сервер интерпретирует URL-адрес как обычный URL-адрес входа, сохраненные параметры с XSS возвращаются в качестве ответа от сервера, и XSS выполняется :)
Я и Ошер Збади были так счастливы видеть, что это сработало!
Мы сообщили об этом цели, и это было исправлено как можно скорее.
Учитывая окончательный результат и вынос ключа
На веб-сайте используется базовая аутентификация HTTP, поэтому, если жертва вошла в систему, злоумышленники потенциально могут запретить ей вход в систему, перенаправляя его каждый раз, когда он входит в систему. страница авторизации. Кроме того, кража его файлов cookie и даже всплывающее окно iframe для проведения кликджекинговой атаки или фишинга основных аутентификационных данных HTTP.
Ключевой вывод, который следует извлечь из этой статьи, — никогда не недооценивать ошибку с низким уровнем серьезности, иногда ее можно усугубить, объединив ее с другими ошибками и получив награду или улыбку на вашем лице.
Спасибо, что уделили время чтению моей статьи, надеюсь, вы узнали что-то новое или, по крайней мере, улыбнулись или две (видите, что я там сделал?)
