Глубокое погружение в печенье.

Моя личная история

На прошлой слабой работе я пытался реализовать систему аутентификации с использованием маркера обновления. Этот тип аутентификации популярен, когда мы отправляем auth-токен и refresh-токен клиенту, а когда срок действия JWT-токена истекает, мы генерируем новый auth-токен, используя refresh-токен, и отправляем его обратно клиенту.

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

Итак, что такое куки браузера и как их установить?

Cookies — это пары ключ=значение вместе с другими атрибутами, которые контролируют, когда и где используются cookies.

В основном мы используем куки для сохранения состояния сайта и передачи сохраненных состояний на сервер.

Одно из преимуществ, которое мы получаем при использовании cookies, заключается в том, что cookies передаются на сервер браузером в заголовке HTTP.

Мы можем читать и обновлять файлы cookie на стороне клиента следующим образом

//update cookies
document.cookie = "test-cookie=this is test cookie"

//read cookies
document.cookie // "test-cookie=this is test cookie;"

Вы можете запустить приведенный выше скрипт в консоли браузера и получите результат, как показано выше.

Cookies на сервере

Cookies устанавливаются на сервере с помощью res.cookie, используя node.js express framework.
Cookie будет отправлен с заголовком Set-Cookie с сервера, а затем браузер должен вернуть cookie в заголовке запроса cookie. Браузер может не возвращать куки, потому что куки могут быть заблокированы пользователем или хост или источник ограничил куки с помощью атрибутов, которые мы обсудим позже.

Мы можем получить доступ к cookies, отправленным браузером, используя req.cookies, при этом cookies будут разделены ;.

Лучшим вариантом будет использование cookie cookie-parser в качестве промежуточного ПО для express.js. Это очень облегчит вам жизнь.

Итак, печенье — это здорово, теперь давайте попробуем его на вкус.

Отказ от ответственности: Ниже приведен наивный пример стороннего cookie. Позже в этом блоге я также расскажу вам о недостатках и проблемах безопасности сторонних cookie.

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

Вы можете добавить cookie с imageid=12; liked:true. И поскольку по умолчанию куки передаются через HTTP-запросы. Вы можете обновлять понравившиеся изображения на сервере.

Такие типы cookie называются сторонними cookie.

Куки кажутся хорошими, давайте поместим все в куки😈 🤯 🙅🏼♂️

Пожалуйста, не кладите все в печенье

Вот почему мы не должны помещать все в куки. Во-первых, куки отправляются в HTTP-заголовках, а отправка огромного количества куки скажется на производительности.
Ниже я подробно рассказываю о влиянии куки на производительность, вы можете просто перейти к разделу «Безопасность», если хотите.

Влияние куки на производительность.

Когда страница добавляет файлы cookie большого размера, это может сильно повлиять на производительность. Cookies добавляются автоматически с HTTP-заголовками при каждом запросе.

Как правило, провайдеры предоставляют большую пропускную способность загрузки, чем выгрузки. А поскольку файлы cookie передаются с каждым запросом браузера, низкая пропускная способность канала загрузки иногда может стать узким местом.

Защита файлов cookie.

Одна из проблем с куки заключается в том, что они подвержены атакам межсайтовой подделки (CSRF). Позвольте мне объяснить, куки по умолчанию могут передаваться из одного домена в другой домен. Это называется сторонним cookie. Так что если вы посетите какой-нибудь злой сайт, скажем evil.com, и они могут попытаться вызвать запрос на ваш сайт, браузер прикрепит cookie и сделает запрос на ваш сайт, если ваш сервер не проверяет cookie должным образом. evil.com может подделать ваши данные.

Чтобы предотвратить CSRF-атаку, мы должны защитить куки, добавив атрибут SameSite к куки. Но прежде чем перейти к атрибуту SameSite, давайте разберемся, что такое «тот же сайт».

Понимание того, что такое один и тот же сайт?

Сайт создается с использованием доменов верхнего уровня и части доменов.

В приведенном выше примере .com является TLD и пример рассматривается как домен.

Но такие домены, как .co.jp или .github.com используют .jp или .com в качестве TLD. Поэтому возникла необходимость в создании нового списка эффективных ДВУ или (eTLD), который был создан Public Suffix List.

Так что теперь сайты строятся с использованием eTLD и доменного имени (или eTLD + 1).
Так что же считается одним и тем же сайтом, а что нет?

Теперь у нас есть четкое представление о том, что считается одним и тем же сайтом и кросс-сайтом, мы можем двигаться дальше, используя атрибут cookie SameSite.

Примечание: Вы можете узнать больше о кросс-сайте и кросс-оригинальности здесь.

Атрибут SameSite

SameSite=Strict

Теперь мы знаем, что такое один и тот же сайт, но как атрибут SameSite предотвращает атаку подделки межсайтового запроса (CSRF)?

Если файл cookie установлен как

Set-cookie: some_cookie=1; SameSite=Strict;

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

SameSite=Lax

Теперь у вас есть требование сохранить предпочтения пользователя. Скажем, вы отправляете по электронной почте список обуви, которая интересует пользователя, и когда пользователь нажимает на изображение какой-либо обуви, пользователь перенаправляется на ваш сайт, и вам нужно сохранить эту обувь в предпочтениях пользователя, но с атрибутом SameSite предпочтения, cookie не будет отправляться из навигации верхнего уровня.

Set-cookie: preffered_shoe=addidas; SameSite=Lax;

С SameSite=Lax cookie будут передаваться, когда пользователь щелкнет изображение обуви и будет перенаправлен на ваш сайт.

SameSite=None

Если вы хотите, чтобы cookies вели себя по умолчанию, т.е. передавали cookies с любого стороннего сайта.

Примечание: Если атрибут не отправлен, то по умолчанию атрибут SameSite=Lax будет установлен большинством новых браузеров.

Еще один важный момент: если установлен SameSite=None, то необходимо также установить атрибут Secure, иначе cookies будут отклонены браузером.

Будут отклонены браузером 🙅🏼♂️

Set-Cookie: cookie_name="will be rejected"; SameSite=None;

Не будут отклонены браузером 👍

Set-Cookie: cookie_name="will be rejected"; SameSite=None; Secure

Атрибут Secure

Атрибут Secure cookie отправляется только по HTTPS соединению, а не по HTTP соединению. Добавляя безопасные атрибуты, вы можете предотвратить атаку «человек посередине» и ограничить манипуляции с куками на безопасных HTTP-соединениях.

HttpOnly

С помощью этого атрибута мы можем позволить cookies устанавливаться и читаться только сервером. Клиентский javascript не сможет обновить этот файл cookie. Этот заголовок помогает предотвратить XSS-атаки.

Но только добавление заголовка HttpOnly не сможет полностью защитить вас от XSS-атак. Злоумышленник не сможет извлечь сессионные куки пользователя с помощью javascript на стороне клиента. Это также называется эксфильтрацией сеансовых маркеров. Но может существовать и другой вариант, которым можно воспользоваться. Существуют способы полной блокировки XSS-атак, но пока не будем углубляться в эту тему.

Атрибут домена

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

Поэтому, чтобы сделать браузеры менее устойчивыми, чтобы куки с поддомена могли быть отправлены и доступны, мы используем этот куки. Итак, предположим, что если клиентский javascript может получить доступ к cookie с доменом. Тогда он сможет читать только куки с тем же доменом (т.е. в URL).

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

Примечание: Основное различие между атрибутом домена и SameSite заключается в том, что с помощью атрибута домена мы ограничиваем хост, с которого будет отправлен cookie. SameSite ограничивает происхождение, с которого отправляется cookie.

Атрибут пути

Указав атрибут path, мы можем ограничить доступ к cookie только этим путем и его подпутями. Например, если установить cookie с Path=/cart, то cookie будет доступен только для /cart и всех его подпутей, таких как /cart/items, /cart/id=122323 и т.д.

Атрибут Expire

Установка даты истечения срока действия приведет к уничтожению и удалению cookie. Один из самых распространенных случаев использования, который приходит мне на ум, — это использование для показа рекламы. Предположим, вы хотите показывать рекламу пользователю в течение определенного времени (допустим, в течение месяца), вы можете установить, что срок действия cookie истечет через месяц.

Заключение

Спасибо вам, ребята, что дочитали меня до конца. Надеюсь, этот блог будет полезен и пригодится вам при работе с печеньем. Пожалуйста, оставьте комментарий, если я что-то упустил.