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

[@Irker]

Я думаю вы с нетерпением ждете этот вопрос:
Каково по вашему правильное решение данной проблемы?
(* RFC 6265 / Пункты 5.1.3, 4.1.2.3 и др*)

[@d0znpp]

Обязательное использование $domain аргумента функции setcooke() php.net/manual/ru/function.setcookie.php

[@Irker]

И какое значение должно быть у этого параметра? Посмотрите пожалуйста на серый текст в моем предыдущем комментарии.

[@d0znpp]

должен быть текущий домен. да, RFC. но браузеры, они такие браузеры… В RFC прямо описание этой ошибки, вы правы: «WARNING: Some existing user agents treat an absent Domain
attribute as if the Domain attribute were present and contained
the current host name. For example, if example.com returns a Set-
Cookie header without a Domain attribute, these user agents will
erroneously send the cookie to www.example.com as well»

[@Irker]

В приведенном вами «warning» говорится о поведениях браузера при отсутствии данного параметра (как раз те самые различия между хромом и ie).
Мы же с вами обсуждаем уже присутствие параметра Domen и то каким он должен быть, чтобы поддомены не получали куки.

[@d0znpp]

Да, в этом WARNING по-сути все то, что в этом топике сжато написано.
Если вопрос в том, что указывать в домене — то ответ простой:
«domain.com», без ведущей точки впереди.

[@Irker]

Проверьте пожалуйста это, например в Chrome.

[@Irker]

Хорошо. Если не хотите пробовать, то вот вам пример из указанного RFC:

The server can alter the default scope of the cookie using the Path
and Domain attributes. For example, the server can instruct the user
agent to return the cookie to every path and every subdomain of
example.com.

Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com

[@Zagrebelion]

В скриншоте wireshark'e foo.bar.com,
а в тексте статьи про хром foo.com
а в скриншоте хрома bar.com
а в скриншоте ie bar.foo.com

Это я неправильно понял смысл статьи, или автор запутался в foo и bar?

[@miraage]

Напомнило это :)

[@d0znpp]

Правильно. По хрому скриншот переделал. Спасибо!

[@ha2bj]

Вы толко что сочинили четверостишье :)

[@gro]

cookie-неделя на хабре

[@d0znpp]

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

[@alexxxst]

Не больше 4 кило, а потом затираться начнет…

[@d0znpp]

Все не по RFC реализовано )
chrome 180 (после отправки первого запроса без кук их станет уже 150)
safari ~2800/LEN(cookie_name+cookie_val)
opera 60
firefox 149
iexplore 49

[@7313]

причем если поставить куку с адреса www.site.com, то она будет в реквест заголовках на адресе site.com, но надежно стереть ее получится только опять же с www.site.com Надежно, это значит не теоретически, а практически для всех браузеров

[@TedMosby]

Статью можно сжать до одного предложения: «при установке cookie без указания домена, IE, в отличие от других браузеров, проставляет cookie для всех поддоменов».

[@gnomeby]

Не совсем понял. Это в каких случаях опасно? Правильно ли я понимаю, что в случае когда все поддомены мои, это не так критично?

[@d0znpp]

Это опасно, так как дает возможность атаковать основной домен с поддоменов. Это не опасно, когда на поддоменах нет уязвимостей.

[@Irker]

Согласно RFC 2011 года поддомены всегда получают куки указанного домена. (Если только сам браузер не пойдет против RFC).
Поэтому указанная в топике «опасность» будет даже если указывать домен.
Правильней было бы написать, что не указывая домен мы отдаем определение охватываемых доменов на усмотрение браузера.
Наличие же заданного домена никак не влияет на поддомены. (В старом RFC и браузерах влияло). Но автор меня игнорирует =)

[@d0znpp]

Не игнорирую — проверяю. Хром у меня точно ничего не ставит на поддомены.

[@Irker]

Вы проверяли на какой домен ставится или проверяли передаются ли куки на поддомены?

[@d0znpp]

Все проверил — никто не ставит на поддомены. Вы на чем проверяли?

[@Irker]

Chromium 18.0.1025.151, Firefox 12.0

[@d0znpp]

Действительно, это так. Спасибо! При указании даже прямого домена, браузер все-равно проставяет на все поддомены. Новый RFC работает именно так. Надо думать…

[@brammator]

Браузер не «проставляет на все домены» — это бредовое предположение.

Браузер передаёт куки с родительского домена на запросы к поддоменам.

Это нормально и это сделано специально.

[@zipo]

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

[@shapeshifter08]

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

[@denver]

Единственная защита — это фильтрация куков

What? o_O

[@shapeshifter08]

Проверять входящие данные от клиента, а не как написал автор получать XSS.

[@denver]

Топик о том, что если ваш сайт ставит куку без указания домена, то зайдя на соседний домен (не ваш) и отыскав XSS можно увести у пользователя куку (и значит учетку) вашего «секьюрного» сайта.

[@Sauron]

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

Другое дело, если б вы куки выставляли с abc.foo.com, а получали на xyz.foo.com — но такого не происходит.

[@TedMosby]

Что означает слово SOP в тегах?
Это слово не встречается в тексте и по этому тегу нет других статей.

[@d0znpp]

Same Origin Policy en.wikipedia.org/wiki/Same_origin_policy

[@monolithed]

На мой взгляд, RFC 2109и RFC 2965 написаны более понятным языком, по крайней мере я так и не нашел в RFC 6265 критериев установки атрибутов.
Если кто-то более более внимательно прочитал стандарт прошу разъясните эту ситуацию.

[@Sauron]

Так а какая версия IE?

[@Sauron]

Про 8-й IE есть целая статья с quirks в работе с куками:
blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx