HTTP - идентификация клиента

Внимание

Данный материал является частью цикла статей «Протокол HTTP». Не забудьте посмотреть другие статьи по этой теме :-)

  1. HTTP - обзор основных концепций протокола
  2. Архитектурные аспекты HTTP
  3. HTTP - идентификация клиента
  4. HTTP - механизмы аутентификации
  5. HTTP - безопасность, TLS и сертификаты
  6. HTTP справочник

Идентификация клиентов и почему это чрезвычайно важно

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

Что я имею в виду?

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

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

Но как мы можем жить, не зная, как наша любимая команда забила вчера вечером или что сделали знаменитости прошлой ночью?

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

Давайте посмотрим, как веб-серверы могут идентифицировать вас для достижения этого эффекта.

Различные способы идентификации клиента

Веб-сервер может идентифицировать вас несколькими способами:

  • Заголовки HTTP-запроса
  • IP-адрес
  • Длинные URL
  • Cookies
  • Информация для входа (аутентификация)

Пройдемся по каждому.

Заголовки HTTP-запроса, используемые для идентификации

У веб-серверов есть несколько способов извлечь информацию о вас прямо из заголовков HTTP-запросов.

Эти заголовки:

  • From - содержит адрес электронной почты пользователя, если он указан.
  • User-Agent - содержит информацию о веб-клиенте.
  • Referer - содержит исходный пользователь, пришедший из
  • Authorization - содержит имя пользователя и пароль
  • Client-IP - содержит IP-адрес пользователя
  • X-Forwarded-For - содержит IP-адрес пользователя (при переходе через прокси-сервер)
  • Cookie - содержит метку идентификатора, созданную сервером.

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

Заголовок user-agent содержит такую ​​информацию, как версия браузера и операционная система. Хотя это важно для настройки контента, это не позволяет более точно определить пользователя.

Заголовок Referer сообщает серверу, откуда пришел пользователь. Эта информация используется для лучшего понимания поведения пользователя, но не для его идентификации.

Хотя эти заголовки предоставляют некоторую полезную информацию о клиенте, этого недостаточно для значимой персонализации контента.

Остальные заголовки предлагают более точные механизмы идентификации.

IP-адрес

Метод идентификации клиента по IP-адресу чаще использовался в прошлом, когда IP-адреса было не так легко подделать / подменить. Хотя его можно использовать в качестве дополнительной проверки безопасности, он недостаточно надежен, чтобы использовать его самостоятельно.

Вот некоторые из причин, почему:

  • Он описывает сервер, а не пользователя.
  • Межсетевые экраны NAT - многие интернет-провайдеры (поставщики услуг Интернета) используют межсетевые экраны NAT для повышения безопасности и решения проблемы нехватки IP-адресов.
  • Динамические IP-адреса - пользователи часто получают динамический IP-адрес от интернет-провайдера.
  • HTTP прокси могут скрыть исходный IP-адрес. Некоторые прокси используют Client-IP или X-Forwarded-For для сохранения исходного IP-адреса.

Длинные URL

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

Вы можете увидеть, как выглядит длинный URL-адрес, просмотрев магазин Amazon.

https://www.amazon.com/gp/product/1942788002/ref=s9u_psimh_gw_i2?ie=UTF8&fpl=fresh&pd_rd_i=1942788002&pd_rd_r=70BRSEN2K19345MWASF0&pd_rd_w=KpLza&pd_rd_wg=gTIeL&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=&pf_rd_r=RWRKQXA6PBHQG52JTRW2&pf_rd_t=36701&pf_rd_p=1cf9d009-399c-49e1-901a-7b8786e59436&pf_rd_i=desktop

При использовании этого подхода возникает несколько проблем.

  • Это некрасиво
  • Это неюзабельно
  • Нарушает кеширование
  • Это ограничено конкретным сеансом
  • Увеличивает нагрузку на сервер

Файлы cookie

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

Существует два типа файлов cookie: сеансовые файлы cookie и постоянные файлы cookie. Сеансовые файлы cookie удаляются при выходе из браузера, а постоянные файлы cookie сохраняются на диске и могут длиться дольше. Чтобы файл cookie сеанса обрабатывался как постоянный файл cookie, необходимо установить свойство Max-Age или Expiry.

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

Так как же работают файлы cookie?

Файлы cookie содержат список пар имя = значение, которые сервер устанавливает с помощью заголовка ответа Set-Cookie или Set-Cookie2. Обычно информация, хранящаяся в файле cookie, представляет собой своего рода идентификатор клиента, но некоторые веб-сайты хранят и другую информацию.

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

Пример жизненного цикла HTTP-запроса.

1. Пользовательский клиент -> Сервер

POST /acme/login HTTP/1.1
[form data]

Пользователь идентифицирует себя через ввод формы

2. Сервер -> Пользовательский клиент

HTTP/1.1 200 OK
Set-Cookie2: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"

Сервер отправляет заголовок ответа Set-Cookie2, чтобы указать клиенту пользователя (браузеру) установить информацию о пользователе в файле cookie.

3. Пользовательский клиент -> Сервер

POST /acme/pickitem HTTP/1.1
Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
[form data]

Пользователь выбирает товар в корзину.

4. Сервер -> Пользовательский клиент

HTTP/1.1 200 OK
Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1"; Path="/acme"

Корзина покупок содержит товар.

5. Пользовательский клиент -> Сервер

POST /acme/shipping HTTP/1.1
Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"; 
        Part_Number="Rocket_Launcher_0001";
[form data]

Пользователь выбирает способ доставки.

6. Сервер -> Пользовательский клиент

HTTP/1.1 200 OK
Set-Cookie2: Shipping="FedEx"; Version="1"; Path="/acme"

Новый файл cookie отражает способ доставки.

7. Пользовательский агент -> Сервер

POST /acme/process HTTP/1.1
Cookie: $Version="1";
        Customer="WILE_E_COYOTE"; $Path="/acme";
        Part_Number="Rocket_Launcher_0001"; $Path="/acme";
        Shipping="FedEx"; $Path="/acme"
[form data]

Заключение

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