Comments 87
Кстати первоисточник тоже я — поэтому не обвиняйте в корявом переводе.
У вас в первоисточнике картинка поехала. Стоит ее сделать шириной контента, все равно в окне откроется по клику. Прошу прощения за оффтоп
Все-таки вы Хомяков, а не Хомаков. :) Я чувствовал, что здесь что-то не так…
UFO landed and left these words here
Поднял у себя на локалхосте (или у ботнета), наставил куков и вуаля!
Поднял на локалхосте и испортил жизнь сам себе?

Если же есть ботнет то наверное можно делать что-нибудь поинтереснее чем выставлять длинные куки.
Можно, например, ограничивать длину таких кукисов. Скажем, до N мб или N штук. А на сервере (на основном домене, куда «бомбят») сделать проверку, чтобы чистить ненужный кукоспам. Я вообще до этого момента был уверен, что максимальный размер кукисов ограничен… А сколько туда влезает, когда возникает такая проблема?
4кб в одну штуку, всего (нагуглил) около 200 штук, т.е. даже меньше мб. Не такой-то и большой объём, чтобы обработать его и выкинуть мусор при первом запросе. Алгоритмы серверов, вероятно, сейчас отрабатывают в случае кукоспама медленно, но раз уж проблема теперь нам известна, осталось только оптимизировать их.
А я уж подумал, что можно гигабайт куков засунуть на домен, тогда бы было хуже.
Алгоритмы серверов, вероятно, сейчас отрабатывают в случае кукоспама медленно
What? Можно пояснить мысль?
эти запросы не будут обрабатываться сервером из за слишком большого размера
Наверное, имеется в виду, что nginx, apache,… или не обрабатывают запрос, или зависают. Вот, так быть не должно.
Вы не находите некое несоответствие между поведением браузера и сервера? Нужно одно из двух: или учить сервер обрабатывать такие запросы, или ограничивать в браузерах размер кукисов до объёма, который можно обработать.
Размер, который может обработать сервер, зависит от настроек сервера, те в свою очередь могут зависеть от конкретного сайта. Если знает администратор, что его сайт использует куки на десятки килобайт — настроит сервер так, чтобы тот принимал десятки килобайт.

Браузеры общаются с разными сайтами и потому поддерживают размер с запасом, тем более им это гораздо дешевле обходится.
Так-то оно так, но куки, как видим, устанавливаются не только владельцем сайта, поэтому там, где кто-то ещё имеет доступ на поддомен, надо или обязательно ставить большой размер буфера, или думать, как выкидывать спам-куки.
Как выкидывать спам-куки — описал ниже в теме.

устанавливаются не только владельцем сайта
Если сайт находится в доменной зоне третьего уровня, которая ему не подконтрольна, то он должен быть готов к тому, что завтра его вообще владелец зоны может отключить. Собственно, не надо на доменах третьего уровня рядом с сомнительными соседями размещать важную информацию.
Речь про обратную ситуацию — когда «съёмщик» третьего уровня «гадит» владельцу зоны.
После этого этот съемщик удаляется. Опять же, раздаете свою доменную зону всем подряд — будьте готовы.
будьте готовы
Так а делать-то что? Тем, кто бесплатно раздаёт домены третьего уровня? Опять же, в куках, вроде бы, не прописывается, кто из поддоменов их поставил.
Nginx не зависает, а запрос отклоняется с ошибкой. Запрос не обрабатывается, поскольку срабатывает ограничение на количество потребляемых ресурсов, заголовок не помещается в сконфигурированный буфер и весь запрос отклоняется. Вы предлагаете, чтобы веб-сервер сожрал всю память в попытке обработать запрос и был прибит OOM-киллером вместе с остальными, хорошими запросами?
Неправильно то, что он отдаёт ошибку, так сказать, общую, и пользователь не знает, что делать, Почему, например, не добавить в конфиг параметр белого списка кукисов, и в случае такого запроса найти те, которые не входят в этот список, и удалить в ответе. Задача поиска строк в данных вида a=b; без хранения в памяти всего контента вполне себе решаема.
Как вы описали — настроить nginx можно, можно даже вообще настроить так, что бы он запрещал ставить куки на .example.com. Но куки можно выставить и JS-скриптом.
А как сервер example.com может запретить что-то серверу subdomain.example.com?
Речь шла про всякие блого-сервисы. А если зону отдали вообще на чужой сервер, то куки — это не самое страшное. Может оказаться так, что будете объянять оперативникам откуда детское порно взялось на принадлежащим вам поддомене.
Кстати вот да.
Видимо, самый доступный выход для админов nginx — настроить кастомную страницу для 413 ошибки, которая джаваскриптом бы стирала все куки домена и перезагружала страницу.
Угу. И тогда Егор Хомяков напишет пост о том, как своей страничкой на вордпрессе/гитхабе стереть все куки всех других сайтов на вордпрессе/гитхабе.
Ну, это будет гораздо меньшая проблема. Ну попросит меня перелогиниться после посещения такой странички — ну и в чем беда? Всё кроме авторизации (настройки, корзину) полюбэ надо в базе хранить а не в куках.

Ну плюс логику на 413 странице можно похитрее сделать, с белым списком неочищаемых кук.
Каждый третий клиент предлагает платить водкой и ушанками. Потом сильно удивляется что русские тоже доллары любят.
Предлагаю пробовать на живую. Хочу не заходить на определенные сайты после посещения определенной страницы.
Пробую, что то бомба не работает у меня по трем ссылкам в FF. На блогспоте раз 403 вываливается и нормально дальше грузится.
400 Bad Request
Request Header Or Cookie Too Large

Ну впринципе, сервер распознает в чем дело.
Если я правильно понял автора, то смысл этого как раз в этом. Не поломать сервер сайд гигабайтами траффика(тем более что есть ограничения), а вызвать проблемы на стороне клиента.
1. Запустить подобный скрипт на mysuperpage.narod.ru
2. Пользователь, получивший такое количество кук будет испытывать проблемы на *.narod.ru. Пока не почистит куки или проблема не будет решена на сервер сайде.
Вот и поднят вопрос как это порешать.
Один из вариантов.
Что самое главное. Узнать, что что-то идёт не так, как задумано, можно будет или самому, натолкнувшись на уязвимость, или только начав получать отзывы от посетителей. Увеличения трафика нет, со стороны сервера, может, 400я ошибка выпадет.
А для пользователей — не работает.
Не отменял. Но это либо плановое (какой интервал между задачами), либо пока что-то не случится (замечено аномальное поведение, или обращения пользователей).
Ни один вменяемый человек не будет сидеть над фермой серверов и вручную логи ковырять на предмет аномальных событий.
> Ни один вменяемый человек не будет сидеть над фермой серверов и вручную логи ковырять на предмет аномальных событий.

Такие вещи обычно автоматизируют.
Придёт SMS от автомониторилки о повышении количества 4хх ответов.
Интересно, только на днях размышлял на тему: у скольких крупных сайтов настолько много куков, что они не влезают в первый TCP пакет запроса? Насколько можно оптимизировать время отклика и трафик, если от этого избавиться? Пытался даже нагуглить исследования на эту тему, но не нашел.
А почему у крупных сайтов должно быть много куков?) Если приспичело ТАК много хранить в куках, то это делается через сессию, что логично, а все кучи настроек уже на сервере.
Имхо, это как с window.opener — работает и в фб, и в тви — ибо expected behavior. Фб говорят, что просто мониторят подобное и банят, если кто-то злодействует.
P.S. Пример для хабравчан.
Ну вы ещё поспорьте со мной о том, что у меня работает, а что нет. Никакого alert`a не выскакивает. Открывал и в текущей вкладке, и в новой, и в новом окне. И обновлял. Тишина.

UDP: а по ссылке с этой страницы работает.
когда открываешь с Альтом в новом окне opener не создается. Ну а вообще это и нужная функциональность
Наверно глупый вопрос, но нельзя ли поставить куку на домен ".ru"? Или вообще на корень — "."? По какому принципу ограничивается насколько общую куку можно ставить?
Принципы достаточно сложные и проблемные, про них написали в heroku devcenter.heroku.com/articles/cookies-and-herokuapp-com

This restriction on cookie setting at the TLD level has been around since the early days of the web. It exists due to security reasons, both to prevent accidentally retransmitting cookies to 3rd parties, and to help provide some partial protection against cookie stuffing and more general types of session fixation attacks.

This becomes more complicated when we consider many countries use second-level domains (e.g., .co.uk, .ne.jp) as pseudo TLDs, and have few or no restrictions on who may register subdomains.
To address that issue, for many years browser vendors used internally-maintained lists of public domains, regardless of what level they fall in the DNS hierarchy. Inevitably this led to inconsistent behavior across browsers at a very fundamental level.

The Mozilla Foundation eventually began a project known as the Public Suffix List, publicsuffix.org/ to record all of these public domains and share them across browser vendors. Beyond Mozilla Firefox, Google and Opera have both incorporated this list into their browsers.
Еще один вариант — если домен имеет нсы на freedns.ws, то любой может создать к нему поддомен, и загадить куки.
Список: ns1 / ns2 / ns3 / ns4
На страницу с ошибкой можно встроить js, который почистит куки.
Страница с ошибкой — это та страница с 400-ой ошибкой «Request Header Or Cookie Too Large», которую выдает nginx в случае отправки ему куки превышающей размер буфера. Она то, как раз, и открывается.
Разве это не проблема браузеров? Нельзя ли установить max_body_size равный браузерному лимиту?
Причем тут max_body_size? Куки передаются в заголовке. Почему нельзя размер соответсвующих буферов установить равному, уже ответил выше в теме.
Устанавливем Cookie Monster и не разрешаем кому попало ставить печеньки. Особенно актуально для всяких CDN-ов, которым куки вообще не нужны и разрешать их — не лучшая идея (всё-таки user-content, как никак). Ну в нём вроде бы можно запретить third-level доменам ставить куки на second-level без прямого разрешения.
Одно НО — любой вменяемый вебсервис, уровня GitHub, ответит HTTP 400 и никакого флуда не выйдет.
Задача не задосить сервер, а сделать сайт недоступным для юзера. Юзер увидит 400 и что? Пойдет на улицу гулять.
Наличие флуда — заметно. Идёт борьба с проблемой.
Спадение количества пользователей при отсутствии какого-то подозрительного трафика — проблема. Ещё вычленить надо. А злоумышленнику того и надо.
CSP директиву бы придумали, чтоб разрешать браузеру посылать куки, если source домен не запрещен в CSP.
В общем-то давно пора уже подписывать cookies, решит кучу проблем и не только эту.
У меня в броузере IE9 стоит опция third-party cookie: block. Меня эта уязвимость тоже коснется?
Only those users with full accounts are able to leave comments. Log in, please.