Pull to refresh

Comments 87

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

Если же есть ботнет то наверное можно делать что-нибудь поинтереснее чем выставлять длинные куки.
UFO just landed and posted this here
UFO just landed and posted this here
Алгоритмы серверов, вероятно, сейчас отрабатывают в случае кукоспама медленно
What? Можно пояснить мысль?
UFO just landed and posted this here
А зачем им обрабатывать такой огромный запрос?
UFO just landed and posted this here
Размер, который может обработать сервер, зависит от настроек сервера, те в свою очередь могут зависеть от конкретного сайта. Если знает администратор, что его сайт использует куки на десятки килобайт — настроит сервер так, чтобы тот принимал десятки килобайт.

Браузеры общаются с разными сайтами и потому поддерживают размер с запасом, тем более им это гораздо дешевле обходится.
UFO just landed and posted this here
Как выкидывать спам-куки — описал ниже в теме.

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

Ну плюс логику на 413 странице можно похитрее сделать, с белым списком неочищаемых кук.
Не решение совсем. Могу создать httponly куку например.
Окей, принято возражение.
Но httponly куку нельзя поставить яваскриптом, если не ошибаюсь.
А как проставить куку на .googleusercontent?
Егор, прекрати ломать интернеты! (с)
Егор, Вы уже предлагали Google, Wordpress и GitHub свой аудит за 1000$?
за 1000$ уже и не работаецо как то(
Да что там $1000, лучше уже сразу за $100.
Каждый третий клиент предлагает платить водкой и ушанками. Потом сильно удивляется что русские тоже доллары любят.
Ну правильно, на доллары же можно купить водки и ушанок :)
Предлагаю пробовать на живую. Хочу не заходить на определенные сайты после посещения определенной страницы.
Пробую, что то бомба не работает у меня по трем ссылкам в FF. На блогспоте раз 403 вываливается и нормально дальше грузится.
Краткий пример уязвимости
jsfiddle.net/6t97K/
После воспроизведения скрипта, ломается окно result. Проверял в Chrome и Firefox.
400 Bad Request
Request Header Or Cookie Too Large

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

Такие вещи обычно автоматизируют.
Придёт SMS от автомониторилки о повышении количества 4хх ответов.
Интересно, только на днях размышлял на тему: у скольких крупных сайтов настолько много куков, что они не влезают в первый TCP пакет запроса? Насколько можно оптимизировать время отклика и трафик, если от этого избавиться? Пытался даже нагуглить исследования на эту тему, но не нашел.
А почему у крупных сайтов должно быть много куков?) Если приспичело ТАК много хранить в куках, то это делается через сессию, что логично, а все кучи настроек уже на сервере.
Не работает. Google Chrome 32.0.1700.76
Все работает, ибо стандарт (коммент ниже).
Ну вы ещё поспорьте со мной о том, что у меня работает, а что нет. Никакого 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.
На страницу с ошибкой можно встроить 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. Меня эта уязвимость тоже коснется?
Sign up to leave a comment.

Articles