Иногда есть необходимость используя XSS или CRLF Injection на одном поддомене, где нет ничего интересного, проэксплуатировать Self-XSS на другом поддомене, где расположено основное приложение с сессией пользователя.
Обычно это реализуется следующим образом:
1) Подготавливается сессия атакующего с Self-XSS, которая срабатывает на странице /foo/bar
2) С помощью CRLF Injection в браузер жертвы добавляется еще одна cookie с сессией атакующего на путь /foo/bar
Set-Cookie: sessionid=<attacker_session>; domain=.company.tld; path=/foo/bar; secure; samesite=none;
Так как у оригинальной сессии другой атрибут path, то добавленная cookie не перезапишет оригинальную.
На всем сайте пользователь будет авторизован в своей сессии, а на странице /foo/bar отправляется следующий заголовок.
Cookie: sessionid=<attacker_session>; sessionid=<victim_session>;
То есть cookie с сессией атакующего отправляется первой в заголовке, так как у нее большее совпадение префикса path. Веб-приложение в соответствии с RFC берет первое значение в качестве результирующего. И получается, что только на странице /foo/bar пользователь авторизован в сессии атакующего, в которой срабатывает XSS. Что позволяет выполнять действия от имени оригинальной сессии пользователя, отправляя запросы на другие пути.
Но что делать, если веб-приложение берет последнее значение при одинаковых ключах у сессионной cookie?
Если повторять трюк с path, то сессия атакующего будет идти первой и проигнорируется.
Если устанавливать одинаковый path, то оригинальная сессия пользователя будет перезаписана и атака теряет смысл (хотя это все еще может использоваться как CRLF Injection -> XSS, но теперь требуется третья уязвимость для демонстрации импакта).
Иногда в таком случае может помочь создание похожей cookie, которая воспринимается веб-сервером наравне с оригинальной sessionid, а для браузера как две разных.
sessionID=value;
"sessionid"=value;
sessionid =value; (кажется уже зафикшено)
x=x,sessionid=value;
Такую cookie тоже не всегда удается найти.
Но недавно появившийся атрибут cookie Partitioned, предназначенный для раздельного хранилища cookie сайтов верхнего уровеня, позволяет в Chrome создать две cookie с одинаковыми названиями и атрибутами domain и path.
Set-Cookie: sessionid=<attacker_session>; domain=.company.tld; path=/; secure; samesite=none; partitioned;
В результате чего браузер жертвы в каждом запросе будет отправлять две сессии. Cookie атакующего будет идти последней и Self XSS отработает.
Чтобы "выйти" из сессии атакующего после того, как XSS сработала, можно через JavaScript удалить добавленную cookie и в текущей странице выполнять произвольные действия уже от имени оригинальной сессии.
Подробнее про CHIPS Cookie: https://developers.google.com/privacy-sandbox/cookies/chips?hl=ru