Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development

HTTP в сжатом виде: состояние HTTP и безопасность

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Web Architecture

Russian (Pусский) translation by Dima (you can also view the original English article)

В этой последней главе мы рассмотрим аспекты безопасности HTTP, в том числе, как определить пользователей, как работает проверка подлинности HTTP и почему для некоторых сценариев требуется HTTPS (защищенный HTTP). По пути мы также немного узнаем, как управлять состоянием с помощью HTTP.


Веб без гражданства (еще с отслеживанием состояния)

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

Характер HTTP-состояния без гражданства является одним из движущих факторов успеха сети. Многоуровневые службы, которые мы рассмотрели в предыдущей главе, такие сервисы, как кэширование, становятся возможными (или, по крайней мере, проще), потому что каждое сообщение содержит всю информацию, необходимую для обработки сообщения. Прокси-серверы и веб-серверы могут проверять, преобразовывать и кэшировать сообщения. Без кэширования сеть не могла масштабироваться для удовлетворения потребностей Интернета.

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

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

К счастью, существует много вариантов сохранения состояния в веб-приложении. Один из подходов состоит в том, чтобы внедрить состояние в ресурсы, передаваемые клиенту, чтобы все состояние, требуемое приложением, вернется к следующему запросу. Этот подход обычно требует некоторых скрытых полей ввода и лучше всего подходит для состояния короткого замыкания (например, состояния, необходимого для перемещения через трехстраничный мастер). Состояние вложения в ресурс сохраняет все состояние внутри HTTP-сообщений, поэтому это очень масштабируемый подход, но он может усложнить программирование приложений.

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

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

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

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

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

К счастью, есть более надежные методы.


Идентификация и файлы cookie

Веб-сайты, которые хотят отслеживать пользователей, часто обращаются к файлам cookie. Файлы cookie определяются RFC6265 (http://tools.ietf.org/html/rfc6265), и этот RFC метко называется «HTTP State Management Mechanism». Когда пользователь впервые посещает веб-сайт, сайт может предоставить браузеру пользователя cookie с использованием HTTP-заголовка. Затем браузер знает, как отправить cookie в заголовки каждого дополнительного запроса, который он отправляет на сайт. Предполагая, что веб-сайт поместил какой-то уникальный идентификатор в файл cookie, сайт теперь может отслеживать пользователя, когда он или она делает запросы, и дифференцировать одного пользователя от другого.

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

Во-вторых, поскольку файлы cookie могут отслеживать, что делает пользователь, они поднимают проблемы конфиденциальности в некоторых кругах. Некоторые пользователи будут отключать файлы cookie в своих браузерах, то есть браузер отклонит любые файлы cookie, отправленные сервером в ответ. Отключенные файлы cookie представляют проблему для сайтов, которые должны отслеживать пользователей, конечно, и альтернативы являются беспорядочными. Например, один подход к «cookieless session» заключается в том, чтобы поместить идентификатор пользователя в URL-адрес. Сеансы cookieless требуют, чтобы каждый URL-адрес, который сайт предоставляет пользователю, содержит правильный идентификатор, а URL-адреса становятся намного большими (именно поэтому этот метод часто называют методом «толстого URL»).


Настройка файлов cookie

Когда веб-сайт хочет предоставить пользователю cookie, он использует заголовок Set-Cookie в ответе HTTP.

В файле cookie, показанном в этом примере, есть три области информации. Три области разделены точкой с запятой (;). Во-первых, есть одна или несколько пар имя-значение. Эти пары имя-значение разделены знаком доллара ($) и выглядят очень похожими на то, как параметры запроса форматируются в URL. В примере cookie сервер хотел сохранить имя и фамилию пользователя в файле cookie. Вторая и третья области - это домен и путь, соответственно. Мы вернемся позже, чтобы поговорить о домене и пути.

Веб-сайт может помещать любую информацию, которая ему нравится, в файл cookie, хотя существует ограничение по размеру в 4 КБ. Тем не менее, многие веб-сайты только помещают уникальный идентификатор для пользователя, возможно, GUID. Сервер никогда не может доверять чему-либо, хранящемуся на клиенте, если он не защищен криптографически. Да, можно хранить зашифрованные данные в файле cookie, но обычно проще хранить идентификатор.

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

Когда ID прибывает, серверное программное обеспечение может быстро искать любые связанные данные пользователя из структуры данных, базы данных или распределенного кеша в памяти. Вы можете настроить большинство фреймворков веб-приложений для управления файлами cookie и автоматического поиска состояния сеанса. Например, в ASP.NET объект Session предоставляет простой API для чтения и записи состояния сеанса пользователя. В качестве разработчиков нам не нужно беспокоиться о отправке заголовка Set-Cookie или чтении входящих файлов cookie для поиска связанного состояния сеанса. За кулисами ASP.NET будет управлять cookie сеанса.

Опять же, стоит отметить, что данные firstName и lastName, хранящиеся в объекте сеанса, не попадают в файл cookie. Файл cookie содержит только идентификатор сеанса. Значения, связанные с идентификатором сеанса, безопасны на сервере. По умолчанию данные сеанса передаются в структуру данных в памяти и остаются живыми в течение 20 минут. Когда cookie сеанса поступает в запрос, ASP.NET свяжет правильные данные сеанса с объектом Session после поиска данных пользователя, используя идентификатор, хранящийся в файле cookie. Если нет входящего файла cookie с идентификатором сеанса, ASP.NET создаст его с заголовком Set-Cookie.

Одна из проблем безопасности, связанных с идентификаторами сеансов, заключается в том, как они могут открыть возможность кого-то захватить другой сеанс пользователя. Например, если я использую такой инструмент, как Fiddler для трассировки HTTP-трафика, я могу увидеть, что заголовок Set-Cookie поступает с сервера с SessionID=12 внутри. Я мог догадаться, что у какого-то другого пользователя уже есть SessionID 11, и создайте HTTP-запрос с этим идентификатором, чтобы увидеть, могу ли я украсть или просмотреть HTML, предназначенный для другого пользователя. Для борьбы с этой проблемой большинство веб-приложений будут использовать большие случайные числа в качестве идентификаторов (ASP.NET использует 120 бит случайности). Идентификатор сеанса ASP.NET выглядит следующим образом, что затрудняет определение того, как будет выглядеть идентификатор сеанса другого пользователя.


Файлы cookie HttpOnly

Еще одна проблема безопасности, связанная с куки-файлами, заключается в том, насколько уязвимы они к межсайтовой скриптовой атаке (XSS). При атаке XSS злоумышленник вводит злоумышленный код JavaScript на чужой сайт. Если другой веб-сайт отправляет вредоносный скрипт своим пользователям, вредоносный скрипт может модифицировать или проверять и красть информацию cookie (что может привести к захвату сеанса или, что еще хуже).

Для борьбы с этой уязвимостью Microsoft представила флаг HttpOnly (см. Последний пример Set-Cookie). Флаг HttpOnly сообщает агенту пользователя, чтобы он не разрешал коду сценария получать доступ к файлу cookie. Файл cookie существует только для «HTTP only» -т.e. для перемещения в заголовке каждого сообщения HTTP-запроса. Браузеры, которые реализуют HttpOnly не позволит JavaScript для чтения или записи файлов cookie на клиенте.


Типы файлов cookie

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

Единственное различие между ними состоит в том, что постоянному файлу cookie требуется значение Expires.

Сookie -файлы сеанса могут явно добавлять атрибут Discard в файл cookie, но без значения Expires, пользовательский агент должен в любом случае отказаться от файла cookie.


Пути файлов cookie и домены

До сих пор мы говорили, что после того, как cookie будет установлен на веб-сайте, cookie отправится на сайт с каждым последующим запросом (при условии, что cookie не истек). Однако не все файлы cookie отправляются на каждый веб-сайт. Единственными файлами cookie, которые должен отправить пользовательский агент на сайт, являются файлы cookie, указанные агенту пользователя одним и тем же сайтом. Не было бы смысла использовать файлы cookie с amazon.com в HTTP-запросе на google.com. Этот тип поведения может только открыть дополнительные проблемы безопасности и конфиденциальности. Если вы установите cookie в ответ на запрос на www.server.com, полученный файл cookie будет перемещаться только по запросам на www.server.com.

Веб-приложение также может изменить область действия cookie, чтобы ограничить куки-файл определенным хостом или доменом и даже определенным контентом ресурса. Веб-приложение контролирует область действия с использованием атрибутов domain и path .

Атрибут domain позволяет куки-файлу распространять субдомены. Другими словами, если вы установили cookie с сайта www.server.com, пользовательский агент отправит cookie только на www.server.com. Домен в предыдущем примере также позволяет cookie перемещаться по любому URL-адресу в домене server.com, включая images.server.com, help.server.com и просто на сервере server.com. Вы не можете использовать атрибут домена для охвата доменов, поэтому настройка домена на .microsoft.com в ответе на .server.com не является законной, и пользовательский агент должен отклонить файл cookie.

Атрибут path может ограничивать cookie определенным контуром ресурса. В предыдущем примере cookie будет перемещаться только на сайт server.com, когда URL-адрес запроса указывает на /stuff, или местоположение под /stuff, например /stuff/images. Параметры пути могут помочь организовать куки, когда несколько команд создают веб-приложения по разным путям.


Недостатки Cookie 

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

Cookies файлы были уязвимы для атак XSS, как мы упоминали ранее, а также получают плохую рекламу, когда сайты (особенно рекламные сайты) используют сторонние файлы cookie для отслеживания пользователей через Интернет. Сторонние файлы cookie - это файлы cookie, которые устанавливаются из другого домена, чем домен в адресной строке браузера. Сторонние файлы cookie имеют такую ​​возможность, потому что многие веб-сайты при отправке ресурса страницы обратно клиенту будут включать ссылки на скрипты или изображения из других URL-адресов. Запросы, поступающие на другие URL-адреса, позволяют другим сайтам устанавливать файлы cookie.

Например, могут включать Домашняя страница на server.com <script> Это позволяет bigadvertising.com доставлять cookie, пока пользователь просматривает контент с сервера.com. Печенье может вернуться только на сайт bigadvertising.com, но если достаточно сайтов используют bigadvertising.com, тогда Big Advertising может начать профилировать отдельных пользователей и сайты, которые они посещают. Большинство веб-браузеров позволят вам отключить сторонние файлы cookie (но они включены по умолчанию).

Однако два из самых больших недостатков для файлов cookie - это то, как они мешают кешированию и как они передают данные с каждым запросом. Любой ответ с заголовком Set-Cookie не должен кэшироваться, по крайней мере, не в заголовках, поскольку это может помешать идентификации пользователя и создавать проблемы безопасности. Кроме того, имейте в виду, что все, что хранится в файле cookie, видно, когда оно перемещается по сети (и в случае постоянного файла cookie, поскольку он находится на файловой системе). Поскольку мы знаем, что есть много устройств, которые могут слушать и интерпретировать HTTP-трафик, cookie никогда не должен хранить конфиденциальную информацию. Даже идентификаторы сеанса являются рискованными, поскольку, если кто-то может перехватить идентификатор другого пользователя, он может украсть данные сеанса с сервера.

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


Проверка подлинности

Процесс аутентификации заставляет пользователя подтвердить свою личность, введя имя пользователя и пароль, адрес электронной почты и PIN-код или некоторые другие типы учетных данных.

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

Расширяемость HTTP позволяет HTTP поддерживать различные протоколы аутентификации. В этом разделе мы кратко рассмотрим верхние 5: основные, дайджест, Windows, формы и OpenID. Из этих пяти только два являются «официальными» в спецификации HTTP - базовые и дайджест-протоколы аутентификации. Сначала мы рассмотрим эти два.


Обычная проверка подлинности

При базовой аутентификации клиент сначала запросит ресурс с обычным HTTP-сообщением.

Веб-серверы позволят вам настроить доступ к определенным файлам и каталогам. Вы можете разрешить доступ ко всем анонимным пользователям или ограничить доступ, чтобы только определенные пользователи или группы могли обращаться к файлу или каталогу. Для предыдущего запроса предположим, что сервер настроен только для того, чтобы определенные пользователи могли просматривать /html5/ resource. В этом случае сервер выдаст запрос проверки подлинности.

Код состояния 401 сообщает клиенту, что запрос несанкционирован. Заголовок WWW-Authenticate сообщает клиенту собирать учетные данные пользователя и повторять попытку. Атрибут realm предоставляет пользовательскому агенту строку, которую он может использовать в качестве описания для защищенной области. Что происходит дальше, зависит от пользовательского агента, но большинство браузеров могут отображать пользовательский интерфейс для ввода учетных данных.

Figure 8: Authentication dialog
Диалог аутентификации

Имея учетные данные, браузер может отправить другой запрос на сервер. Этот запрос будет включать заголовок Authorization.

Значение заголовка авторизации - это имя пользователя и пароль клиента в кодировке base 64. Обычная проверка подлинности по умолчанию небезопасна, поскольку любой, у кого есть базовый 64-декодер, который может просматривать сообщение, может украсть пароль пользователя. По этой причине базовая аутентификация редко используется без использования защищенного HTTP, о чем мы поговорим позже.

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


Дайджест-проверка подлинности

Дайджест-аутентификация - это улучшение по сравнению с базовой аутентификацией, поскольку она не передает пароли пользователей с использованием кодировки base 64 (которая по сути передает пароль в виде простого текста). Вместо этого клиент должен отправить дайджест пароля. Клиент вычисляет дайджест с использованием алгоритма хеширования MD5 с помощью nonce, который сервер предоставляет во время проверки подлинности (nonce - это криптографический номер, используемый для предотвращения повторных атак).

Ответ на вызов дайджест похож на основной запрос проверки подлинности, но с дополнительными значениями, поступающими с сервера в заголовке WWW-Authenticate для использования в криптографических функциях.

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


Проверка подлинности Windows

Windows Integrated Authentication не является стандартным протоколом проверки подлинности, но она популярна среди продуктов и серверов Microsoft. Хотя аутентификация Windows поддерживается многими современными браузерами (не только Internet Explorer), она не работает хорошо через Интернет или где находятся прокси-серверы. Вы найдете, что это распространено на внутренних и интрасети, где существует сервер Microsoft Active Directory.

Аутентификация Windows зависит от базовых протоколов проверки подлинности, поддерживаемых Windows, включая NTLM и Kerberos. Шаги проверки / ответа Windows Authentication очень похожи на то, что мы уже видели, но сервер укажет NTLM или Negotiate в заголовке WWW-Authenticate (Negotiate - это протокол, который позволяет клиенту выбирать Kerberos или HTML).

Аутентификация Windows имеет то преимущество, что она безопасна даже без использования защищенного HTTP, и быть ненавязчивой для пользователей Internet Explorer. IE автоматически аутентифицирует пользователя при вызове сервера и будет делать это, используя учетные данные пользователя, которые он или она использовали для входа в операционную систему Windows.


Проверка подлинности на основе форм

Аутентификация форм - это самый популярный подход к аутентификации пользователей через Интернет. Аутентификация на основе форм не является стандартным протоколом проверки подлинности и не использует заголовки WWW-Authenticate или Authorization. Тем не менее, многие рамки веб-приложений предоставляют некоторую поддержку для проверки подлинности на основе форм.

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

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

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

Для ASP.NET билет проверки подлинности (значение cookie .ASPXAUTH) зашифрован и хэширован для предотвращения несанкционированного доступа. Однако без безопасного HTTP cookie уязвим для перехвата, поэтому захват сеанса по-прежнему является потенциальной проблемой. Тем не менее, аутентификация форм остается популярной, поскольку она позволяет приложениям полностью контролировать процесс входа в систему и проверку учетных данных.


OpenID

Хотя проверка подлинности на основе форм дает пользователю полный контроль над аутентификацией пользователей, многие приложения не хотят этого уровня контроля. В частности, приложения не хотят управлять и проверять имена пользователей и пароли (и пользователи не хотят иметь другое имя пользователя и пароль для каждого веб-сайта). OpenID является открытым стандартом для децентрализованной аутентификации. С OpenID пользователь регистрируется с провайдером идентификации OpenID, а поставщик удостоверений - это единственный сайт, который должен хранить и проверять учетные данные пользователя. Существует множество поставщиков OpenID, включая Google, Yahoo и Verisign.

Когда приложение должно аутентифицировать пользователя, оно работает с пользователем и поставщиком идентификации пользователя. Пользователь должен в конечном счете проверить свое имя пользователя и пароль у поставщика удостоверений, но приложение будет знать, успешна ли аутентификация благодаря наличию криптографических токенов и секретов. Google просматривает этот процесс на своей веб-странице «Зарегистрированный пользователь для пользователей учетных записей Google» (https://developers.google.com/accounts/docs/OpenID).

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


Безопасный HTTP

Ранее мы упоминали, как самоописательные текстовые HTTP-сообщения являются одной из сильных сторон сети. Любой может прочитать сообщение и понять, что внутри. Но есть много сообщений, которые мы отправляем по сети, которые мы не хотим, чтобы кто-либо еще видел. Мы обсудили некоторые из этих сценариев в этой книге. Мы не хотим, чтобы кто-либо еще в сети видел наши пароли, например, но мы также не хотим, чтобы они видели наши номера кредитных карт или номера банковских счетов. Secure HTTP решает эту проблему, шифруя сообщения, прежде чем сообщения начнут перемещаться по сети.

Безопасный HTTP также известен как HTTPS (поскольку он использует схему https в URL вместо обычной схемы http). Порт по умолчанию для HTTP - порт 80, а порт по умолчанию для HTTPS - порт 443. Браузер подключится к соответствующему порту в зависимости от схемы (если только он не должен использовать явный порт, который присутствует в URL-адресе). HTTPS работает с использованием дополнительного уровня безопасности в стеке сетевых протоколов. Уровень безопасности существует между уровнями HTTP и TCP и включает использование протокола безопасности транспортного уровня (TLS) или предшественника TLS, известного как Secure Sockets Layer (SSL).

Figure 9: Secure HTTP protocol layers
Защищенные уровни протокола HTTP

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

Есть много криптографических данных, которые мы могли бы охватить, но с точки зрения разработчика наиболее важные вещи, которые нужно знать о HTTPS:

  • Весь трафик через HTTPS зашифровывается в запросе и ответе, включая заголовки HTTP и тело сообщения, а также все после имени узла в URL-адресе. Это означает, что данные строки пути и строки запроса зашифрованы, а также все файлы cookie. HTTPS предотвращает захват сеанса, потому что никакие подслушивающие устройства не могут проверить сообщение и украсть файл cookie.
  • Сервер аутентифицирован клиенту благодаря сертификату сервера. Если вы разговариваете с mybigbank.com через HTTPS, вы можете быть уверены, что ваши сообщения действительно отправятся на mybigbank.com, а не на тех, кто запустил прокси-сервер в сети, чтобы перехватывать запросы и трафик отмахивания от mybigbank.com
  • HTTPS не аутентифицирует клиента. Приложениям по-прежнему необходимо реализовать проверку подлинности форм или один из других ранее упомянутых протоколов проверки подлинности, если им необходимо знать идентификатор пользователя. HTTPS делает проверку подлинности на основе форм и базовую аутентификацию более безопасной, поскольку все данные зашифрованы. Существует возможность использования клиентских сертификатов с HTTPS, а сертификаты на стороне клиента могут аутентифицировать клиента наиболее безопасным образом. Тем не менее, сертификаты на стороне клиента обычно не используются в открытом Интернете, поскольку не многие пользователи приобретут и установят личный сертификат. Корпорации могут требовать, чтобы клиентские сертификаты для сотрудников обращались к корпоративным серверам, но в этом случае корпорация может выступать в качестве центра сертификации и выдавать сертификаты сотрудников, которые они создают и управляют.

У HTTPS есть некоторые недостатки, и большинство из них связано с производительностью. HTTPS является дорогостоящим вычислительным процессом, а на крупных сайтах часто используется специализированное оборудование (ускорители SSL) для загрузки криптографических вычислений с веб-серверов. Трафик HTTPS также невозможно кэшировать в общедоступном кеше, но пользовательские агенты могут хранить ответы HTTPS в своем личном кэше. Наконец, HTTPS-соединения дороги для настройки и требуют дополнительного рукопожатия между клиентом и сервером для обмена криптографическими ключами и обеспечения того, чтобы все общались с надлежащим безопасным протоколом. Постоянное подключение может помочь амортизировать эту стоимость.

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


Где мы?

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

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.