Меню Рубрики

Установка куки для другого домена

Как установить cookie для другого домена

Скажем, у меня есть сайт под названием a.com , и когда загружается конкретная страница этого сайта, скажите ссылку на ссылку, мне нравится устанавливать cookie для другого сайта под названием b.com , а затем перенаправлять пользователя на b.com ,

Я имею в виду, что при загрузке a.com/link я хочу установить cookie для b.com и перенаправить пользователя на b.com .

Я протестировал его, и браузер действительно получил cookie от a.com/link , но он не отправил этот файл cookie в запрос перенаправления на b.com . Это нормально?

Можно ли установить файлы cookie для других доменов?

Вы не можете установить файлы cookie для другого домена. Это может привести к огромному недостатку безопасности.

Вам нужно, чтобы b.com установил cookie. Если a.com перенаправляет пользователя на b.com/setcookie.php?c=value

Узел setcookie script может содержать следующее, чтобы установить cookie и перенаправить на правильную страницу на b.com

Подобно верхнему ответу, но вместо перенаправления на страницу и обратно, что может вызвать плохой пользовательский интерфейс, вы можете установить изображение в домене A.

А затем в домене B, который является example.com в файле cookie.php, вы получите следующий код:

Пробали, вы можете использовать Iframe для этого. Facebook, вероятно, использует эту технику. Здесь вы можете прочитать подробнее . Stackoverflow использует подобную технику, но с локальным хранилищем HTML5, более подробно об этом на blog

Вы не можете. Это будет неприятный риск для безопасности.

Настройка файлов cookie для другого домена невозможна.

Если вы хотите передать данные в другой домен, вы можете закодировать это в URL.

Если у вас есть a.my-company.com и b.my-company.com вместо a.com и b.com , вы можете выпустить cookie для домена .my-company.com — он будет принят и отправлен в оба домена.

Пользовательский агент будет отклонять файлы cookie, если атрибут домена определяет область для файла cookie, которая будет включать начало сервер. Например, пользовательский агент принимает cookie с Атрибут домена «example.com» или «foo.example.com» из foo.example.com, но пользовательский агент не примет cookie с Атрибут домена «bar.example.com» или «baz.foo.example.com».

ПРИМЕЧАНИЕ. Из соображений безопасности многие пользовательские агенты настроены на отклонение Атрибуты домена, которые соответствуют «общедоступным суффиксам». Например, некоторые пользовательские агенты будут отклонять атрибуты домена «com» ​​или «co.uk». (См. Раздел 5.3 для получения дополнительной информации.)

Но вышеупомянутое обходное решение с изображением /iframe работает, хотя оно не рекомендуется из-за его неуверенности.

Вы не можете, но. Если у вас есть обе страницы, то.

1) Вы можете отправить данные с помощью параметров запроса (http://siteB.com/?key=value)

2) Вы можете создать iframe сайта B внутри сайта A, и вы можете отправлять сообщения с одного места на другое. Поскольку сайт B является владельцем куки файлов сайта B, он сможет установить любое значение, необходимое для обработки правильного сообщения. (Вы должны запретить другим нежелательным отправителям отправлять вам сообщения! Это зависит от вас и от механизма, который вы решите использовать, чтобы этого не произошло)

Посмотрите другие вопросы по меткам javascript redirect cookies или Задайте вопрос

источник

Типичная ошибка при установке COOKIE в PHP

Хочу поделиться одной особенностью при установке значений COOKIE, которую очень часто забывают веб-разработчики.
В моей практике исследования веб-приложений на уязвимости, за 2009-2011 года, данная ошибка встретилась в 87% веб-приложений, написанных на PHP.
Чтобы как-то уменьшить данный показатель, решил написать этот текст.

Речь пойдет даже не о httpOnly флаге, хотя его использование не менее важно и обязательно к применению.

Рассмотрим пример кода:

Данный код, очевидно, устанавливает два значения COOKIE с именами foo и foo1.
Теперь главный вопрос — для какого домена и с какими флагами?

Обратимся к первоисточнику — HTTP-ответу веб-сервера:

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

Читайте также:  Установка 5 передачи на 4 ступку

В случае с Chrome (актуальная версия 18.0.1025.168), все будет более чем хорошо и домен будет ровно такой, с которого пришел запрос. В моем примере — foo.bar.com:

Если бы все было так хорошо, наверное, здесь бы не было текста…

Проверим Internet Explorer. Так как красивых плагинов для просмотра COOKIE для него я не знаю, проставим куки для домена foo.com и выведем document.cookie с домена bar.foo.com:

Это очень печально. И забавно с другой стороны.
При получении в НТТР-ответе сервера
Set-cookie: foo=bar
Internet Explorer ставит foo=bar для ВСЕХ поддоменов, то есть *.foo.com в моем примере без всяких флагов, таких как httpOnly.

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

А как же остальные браузеры?

Firefox 12.0 httpOnly wildcard
Safari 5.1.5 httpOnly wildcard
Opera 11.62 httpOnly wildcard

Таким образом, используя конструкции

в случае использования клиентом Internet Explorer (8-9), вы проставляете COOKIE на ВСЕ поддомены от данного.

источник

Передача кука и сессии на другой домен

Подскажите, как, один раз авторизовавшись, авторизоваться на разных доменах?

5 ответов 5

Ну что же. Можно намутить как вариант, конечно, такое — входите на один сайт. На нем стоит внизу счетчик от других сайтов (счетчик или картинка — все равно). Адрес ее делается следующим образом — http://имя-сайта/имя-скрипта.php?login=логин&pass=и мд5 , от пароля получая данное, скрипт делает проверку (на одном из сайтов, на котором надо авторизоваться) и дальше можете бегать между ними.

Не надо передавать данные аутентификации. Утекут — пиши пропало. Лучше передавать данные сессии, утечка, в таком случае, намного безопаснее. Заодно позволяет реализовать не только single sign-on (единственный вход), но и single sign-out (единственный выход).

Я рассмотрю случай, когда все сайты имеют единую клиентскую базу, и есть только один сайт (из кучи), где клиент регистрируется-аутентифицируется-авторизуется. Для ситуации с распределенной, децентрализованной пользовательской базой, этот метод не походит.

  1. Два домена, в разных TLD: example.org и example.com
  2. Аутентификация идет на example.org.
  3. Оба сайта имеют доступ к общему серверу сессий (им может являться специализированное решение типа RADIUS, БД или один из сайтов)
  4. При посещении example.com отправляем пользователя на некий example.org/a12n?return_uri=http://example.com/
  5. Наш example.org отрабатывает аутентификацию. Если надо — показывает форму логина и требует авторизации, если нет, создает анонимную сессию (если на сайте нужны анонимы).
  6. Созданная example.org сессия запоминается на сервере сессий. Сессия идентифицируется по некоторому уникальному значению (ID), которое трудно подобрать (генераторы энтропии в помощь). ID сессии хранится в cookies example.org.
  7. Перебрасываем клиента назад на example.com, добавляя к адресу параметр ?auth.data= . Для безопасности, лучше ID пошифровать любым хорошим симметричным алгоритмом, устойчивым к known-plaintext атакам, и подписать, упомянув время, в которое этот ID был выдан, и некоторое nonce-значение (для защиты от replay-атак).
  8. Наш example.com видит параметр auth.data , удостоверяется у сервера сессий, что такая сессия существует и корректна (здесь он узнает и кто, собственно, пользователь), сохраняет ID сессии в cookies и делает редирект сам на себя, на тот же адрес, но уже без auth.data .
  9. В итоге, оба сайта имеют session ID (который, вообще говоря, может быть уникален для каждого сайта, и просто ссылаться на одну сессию). Задача выполнена, single sign-on реализован.
  10. Для реализации single sign-out, любой из сайтов (лучше всего, один, тот же, который занимается и входом) отмечает сессию как закрытую, либо удаляет ее. Поскольку все сайты опираются на единый сервер сессий, то сессия будет закрыта везде.
  11. На каком-то этапе стоит проверять, принимает ли клиент cookies, чтобы не загнать его в бесконечный цикл (и не породить при этом кучу сессий).
Читайте также:  Установка brothers in arms

Собственно говоря, это такой «недо-OAuth2». Можно, кстати, и OAuth взять, даже правильнее будет. Логика, в общем смысле, та же самая — все те же токены.

Для простоты, чтобы было меньше абстракций — вариант устройства:

  1. Сервер сессий — обычная реляционная БД с SQL.
  2. Все сайты — одного владельца и ID сессии на всех сайтах одинаков.
  3. Проверка сесии — в middleware каждого сайта делать SELECT user_ >.
  4. Создание и закрытие сессии, думаю, очевидны.

источник

Как установить куки для другого домена

Допустим, у меня есть сайт под названием a.com , и когда загружается конкретная страница этого сайта, скажем, ссылка на страницу , Я хотел бы установить файл cookie для другого сайта под названием b.com , а затем перенаправить пользователя на b.com .

Я имею в виду, что при загрузке a.com/link я хочу установить cookie для b.com и перенаправить пользователя на b.com .

Я протестировал его, и браузер действительно получил куки от a.com/link , но он не отправил этот Куки по запросу перенаправления на b.com . Это нормально?

Можем ли мы установить cookies для других доменов?

8 Ответов

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

Вам нужно получить b.com, чтобы установить куки. Если a.com перенаправить пользователя на b.com/setcookie.php?c=value

Сценарий setcookie может содержать следующее, Чтобы установить файл cookie и перенаправить его на правильную страницу на b.com

Аналогично верхнему ответу, но вместо перенаправления на страницу и обратно, что вызовет плохой пользовательский опыт, вы можете установить изображение на домене A.

И тогда на домене B, то есть example.com в cookie.php, у вас будет следующий код:

Вероятно, вы можете использовать для этого Iframe . Facebook вероятно использует эту технику. Вы можете прочитать больше об этом здесь . Stackoverflow использует аналогичную технику, но с HTML5 локальным хранилищем, подробнее об этом в своем блоге

Это был бы очень большой риск для безопасности.

Установка файлов cookie для другого домена невозможна.

Если вы хотите передать данные в другой домен, вы можете закодировать их в url.

Агент пользователя будет отклонять файлы cookie, если только атрибут домена задает область действия для файла cookie, которая будет включать источник сервер. Например, агент пользователя должен принимать куки с Доменный атрибут «example.com» или «foo.example.com» из foo.example.com, но агент пользователя не примет файл cookie с именем Доменный атрибут «bar.example.com» или «baz.foo.example.com».

NOTE: по соображениям безопасности многие агенты пользователей настроены на отклонение Атрибуты домена, соответствующие «public suffixes». Например, некоторые агенты пользователей будут отклонять доменные атрибуты «com» или «co.uk». (Дополнительную информацию см. В разделе 5.3.)

Но вышеупомянутый обходной путь с image / iframe работает, хотя это и не рекомендуется из-за его ненадежности.

Если у вас есть a.my-company.com и b.my-company.com вместо просто a.com и b.com , вы можете выпустить файл cookie для домена .my-company.com — он будет принят и отправлен в оба домена.

Ты не можешь, но . .. Если вы владеете обеими страницами, то.

1) Вы можете отправить данные через запрос params ( http://siteB.com/?ключевая ценность )

2) Вы можете создать iframe сайта B внутри сайта A, и вы можете отправлять почтовые сообщения из одного места в другое. Поскольку сайт B является владельцем файлов cookie сайта B, он сможет установить любое нужное вам значение, обработав правильное почтовое сообщение. (Вы должны запретить другим нежелательным отправителям отправлять вам сообщения! это зависит от вас и механизма, который вы решите использовать, чтобы предотвратить это)

Похожие вопросы:

Привет мне нужно установить куки для другого домена на моем сайте. Я нашел сайт, который делает то, что мне нужно сделать, но я не могу понять, как они это делают. Если вы очистите все свои файлы.

Читайте также:  Установка катушек зажигания вместо трамблера

Допустим, у меня есть два домена (A, B). Страницу домена перенаправляет его страницы на страницу домена B. Но перед перенаправлением домена на страницу нужно установить куки. Я пробовал этот код на.

Можно ли установить cookie в одном домене и получить доступ к тому же в другом домене? На самом деле мне нужно установить файл cookie на странице A.com, когда пользователь нажимает кнопку, а затем.

Как я могу установить и снять куки с помощью jQuery, например создать куки с именем test и установить значение 1 ?

В принципе, у меня есть форум на домене abc.com и еще один на xyz.com. При входе пользователя в abc.com и доступе к xyz.com. Я хочу, чтобы xyz.com мог читать cookie abc.com для дальнейших запросов.

Я разрабатываю расширение Google Chrome. Впоследствии можно будет установить куки для домена, который не является моим. Как это возможно с javascript?

Может ли javascript прочитать файл cookie из другого домена?\ Если я установлю cookie в одном домене, скажем www.domain1.com. Могу ли я прочитать этот файл cookie из другого домена www.domain2.com.

У меня есть сайт, например mysite.com, который хранит куки, когда пользователь вводит и т. д. Но моя страница поиска имеет другой поддомен / домен search.mysite.com. Как мне получить файл cookie от.

Мне нужно установить куки для webview в swift. Я нашел решение, но оно для объективного-c. Как это сделать в Swift? Можно ли установить куки вручную, используя sharedHTTPCookieStorage для UIWebView.

источник

Установка куки для другого домена

Только браузер может послать куки, проанализировав откуда пришел запрос. Имхо, на другой домен передать куки он не сможет, если запросивший не прикинулся чужим сайтом, что вызывает недоверие. Единственный способ — слить куки через клиента например через JavaScript, но как это сделать я не знаю, и возможно ли вообще — тоже вопрос.

В предоставленном примере могу единственное предположить, что эти сайты связаны друг с другом. У нас были несколько с виду разных сайтов, но регистрация была единая — использовались данные одной БД. Естественно и куки у пользователя устанавливались от разных сайтов, но с информацией полученной из одного источника.

я этим пользовался, когда имел два домена — просто host.com и search.host.com, а корзина товаров была и на той и на другой странице.
Но там было очень много проблем с этим указыванием document.domain.

Добавлено 25.07.06, 10:18
Но! действует только на «родственных» доменах, так сказать.
вот:

Остается — понимание того, каким образом они оплучают эти куки? возможно, исопльзуется серверное решение?

Поподробнее пожалуйста, и может есть другая возможность узнать мой логин с того сайта, кроме как куки и связь между этими сайтами?

GET http://yandex.ru/ HTTP/1.1
Host: yandex.ru
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Cookie: yabs-frequency=1051126.1:902737.1:890073.1:839890.2:859767.2:582735.1; yandexu >
HTTP/1.x 407 Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy service is denied. )
Via: 1.1 SRVGATE
Proxy-Authenticate: NTLM
Proxy-Authenticate: Basic realm=»srvgate.gismps.ru»
Proxy-Authenticate: Kerberos
Proxy-Authenticate: Negotiate
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 2367

итак, куку передает тоже браузер.
Как он ее передает? Логично предположить, что по имени домена находит те куки, что необходимы.

Чтобы в этом убедиться, скачайте, пожалуйста, расширение для Mozilla Firefox LiveHTTPHeaders. Установите его, затем перезапустите Firefox, откройте LiveHTTPHeaders и зпросите через браузер mercenaries.ru.
Если там нет нужных cookies, значит существет скрытый обмен между mercenaries.ru и combats.ru на уровне web-сервисов, возможно.

Немного сумбурно обьяснил. Если что-то не понятно — спрашивайте

источник