Это не совсем о XSS вообще.Тема, на которую вы ссылаетесь, называется фиксация сеанса или перехват сеанса .
If so, wouldn't a website reject a cookie it didn't set?
HTTP не имеет состояния.Он не помнит, какие куки он давал тем или иным людям.
Сессии по-разному реализуются в разных средах исполнения (например, PHP и JSP), но общий принцип тот же.Данные сеанса хранятся на сервере и идентифицируются уникальным, трудно угадываемым ключом.Этот ключ сообщается клиенту при первоначальном запросе, если запрос еще не содержит его.
Иногда ключ передается в виде файла cookie, что удобно, поскольку клиент обычно всегда отправляет файлы cookie автоматически.Но идентификатор сеанса может быть передан и другими способами, например, в строке запроса.Например, вы видите много веб-сайтов с такими URL-адресами:
http://jksiusjkakek.com/path/to/app?SESSIONID=1jk98s9sji29sk2lui2
Обычно это не очень хорошая вещь, потому что это означает идентификатор сеансафиксируется в любых созданных закладках или ссылках, отправляемых другим людям, что значительно упрощает фиксацию сеанса.
Пишут ли злоумышленники собственный сценарий для ручной отправки любых вредоносных HTTP-запросов по своему усмотрению и сначала устанавливают вредоносные cookie-файлы?
Если сайт передает идентификатор сеанса в URL-адресе, как я показал выше, то все просто: злоумышленник просто копирует / вставляет идентификатор сеанса в строку URL-адреса.
Еслисайт передает идентификатор сеанса в виде файла cookie, тогда злоумышленнику необходимо вручную установить файл cookie в своем браузере.Самый простой способ сделать это - буквально открыть окно настроек cookie и вручную скопировать / вставить идентификатор сеанса в новый cookie ...
Хотя я уверен, что у настоящих плохих парней есть еще более эффективные способычем это:)