Обеспечение безопасности передачи данных http

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

Самым простейшим является расширение HTTPS, при котором данные, передаваемые по протоколу HTTP, "упаковываются" в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Чтобы подготовить веб-сервер для обработки HTTPS соединений, администратор должен получить и установить в систему сертификат для этого веб-сервера.

SSL (Secure Sockets Layer) - криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создается защищенное соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший название TLS. Этот протокол использует шифрование с открытым ключом для подтверждения подлинности передатчика и получателя. Поддерживает надежность передачи данных за счет использования корректирующих кодов и безопасных хэш-функций. На нижнем уровне многоуровневого транспортного протокола (например, TCP) он является протоколом записи и используется для инкапсуляции различных протоколов (POP3, IMAP, SMTP или HTTP). Для каждого инкапсулированного протокола он обеспечивает условия, при которых сервер и клиент могут подтверждать друг другу свою подлинность, выполнятьалгоритмы шифрования и производить обмен криптографическими ключами, прежде чем протокол прикладной программы начнет передавать и получать данные.

Для доступа к веб-страницам, защищенным протоколом SSL, в URL вместо схемы http, как правило, подставляется схема https, указывающая на то, что будет использоваться SSL-соединение. Стандартный TCP-порт для соединения по протоколу https — 443. Для работы SSL требуется, чтобы на сервере имелся SSL -сертификат.

В сети Веб поддерживаются 3 типа аутентификации при клиент-серверных взаимодействиях:

• Basic - базовая аутентификация, при которой имя пользователя и пароль передаются в заголовках http-пакетов. Пароль при этом не шифруется и присутствует в чистом виде в кодировке base64. Для данного типа аутентификации использование SSL является обязательным.

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

• Integrated - интегрированная аутентификация, при которой клиент и сервер обмениваются сообщениями для выяснения подлинности друг друга с помощью протоколов NTLM или Kerberos. Этот тип аутентификации защищен от перехвата удостоверений пользователей, поэтому для него не требуется протокол SSL. Только при использовании данного типа аутентификации можно работать по схеме http, во всех остальных случаях необходимо использовать схему https.

Cookie

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

Если сервер будет проверять TCP-соединения и запоминать IP-адреса компьютеров-клиентов, он все равно не сможет различить запросы от двух браузеров, выполняющихся на одной машине. И даже если допустить, что на компьютере работает лишь одна клиент-программа, то никто не может утверждать, что в промежутке между двумя запросами она не была завершена, а затем запущена снова уже другим пользователем.

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

Такие сведения позволяет получить дополнительное средство под названием cookie. Механизм cookie позволяет серверу хранить информацию на компьютере клиента и извлекать ее оттуда.

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

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

1. Передача запроса серверу А.

2. Получение ответа от сервера А.

3. Передача запроса серверу В.

4. Получение ответа от сервера В. В состав ответа входит поле заголовка SetCookie. Получив его, клиент записывает cookieна диск.

5. Передача запроса серверу С. Несмотря на то что на диске хранится запись cookie, клиент не предпринимает никаких специальных действий, так как значение cookie было записано по инициативе другого сервера.

6. Получение ответа от сервера С.

7. Передача запроса серверу А. В этом случае клиент также никак не реагирует на тот факт, что на диске хранится cookie.

8. Получение ответа от сервера А.

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

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

Рассмотрим подробнее, какие данные передаются в поле заголовка Set-cookie и как они влияют на поведение клиента.

Поле Set-cookie имеет следующий формат:

Set-cookie: имя = значение; expires = дата; path = путь; domain = имя_домена, secure

где

• Пара имя = значение – именованные данные, сохраняемые с помощью механизма cookie. Эти данные должны храниться на клиент-машине и передаваться серверу в составе очередного запроса клиента.

• Дата, являющаяся значением параметра expires, определяет время, по истечении которого информация cookie теряет свою актуальность. Если ключевое слово expires отсутствует, данные cookie нe удаляются по окончании текущего сеанса работы браузера.

• Значение параметра domain определяет домен, с которым связываются данные cookie. Чтобы узнать, следует ли передавать в составе запроса данные cookie, браузер сравнивает доменное имя сервера, к которому он собирается обратиться, с доменами, которые связаны с записями cookie, хранящимися на клиент-машине. Результат проверки будет считаться положительным, если сервер, которому направляется запрос, принадлежит домену, связанному с cookie. Если соответствие не обнаружено, данные cookie не передаются.

• Путь, указанный в качестве значения параметра path, позволяет выполнить дальнейшую проверку и принять окончательное решение о том, следует ли передавать данные cookie в составе запроса. Помимо домена с записью cookie связывается путь. Если браузер обнаружил соответствие имени домена значению параметра domain, он проверяет, соответствует ли путь к ресурсу пути, связанному с cookie. Сравнение считается успешным, если ресурс содержится в каталоге, указанном посредством ключевого слова path, или в одном из его подкаталогов. Если и эта проверка дает положительный результат, данные cookie передаются серверу. Если параметр path в поле Set-Cookie отсутствует, то считается, что запись cookie связана с URL конкретного ресурса, передаваемого сервером клиенту.

• Последний параметр, secure, указывает на то, что данные cookie должны передаваться по защищенному каналу.

Для передачи данных cookie серверу используется поле заголовка Cookie. Формат этого поля достаточно простой:

Cookie: имя=значение; имя=значение; ...

C помощью поля Cookie передается одна или несколько пар имя = значение. Каждая из этих пар принадлежит записи cookie, для которой URL запрашиваемого ресурса соответствуют имени домена и пути, указанным ранее в поле Set-cookie.

HTTP cookie

[править | править вики-текст]

Материал из Википедии — свободной энциклопедии

У этого термина существуют и другие значения, см. Cookie

HTTP

Постоянное соединение ·Сжатие · HTTPS

Методы

OPTIONS · GET · HEAD · POST ·PUT · DELETE · TRACE ·CONNECT · PATCH

Заголовки

Cookie · ETag · Location · Referer

DNT · X-Forwarded-For

Коды состояния

301 Moved permanently

302 Found

303 See Other

403 Forbidden

404 Not Found

Шаблон: Просмотр • Обсуждение • Править

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

• аутентификации пользователя;

• хранения персональных предпочтений и настроек пользователя;

• отслеживания состояния сеанса^[en] доступа пользователя;

• ведения статистики о пользователях.

Приём браузерами куки требуют многие сайты с ограничениями доступа, большинство интернет-магазинов.^[1] Настройка оформления и поведения многих веб-сайтов по индивидуальным предпочтениям пользователя тоже основана на куки.^[2]С момента своего появления куки вызывали обеспокоенность пользователей Интернета, поскольку слежение за действиями и предпочтениями пользователей может подвергнуть опасности тайну личной жизни. Как результат, в Европейском союзе, Соединённых Штатах, и в других странах были приняты соответствующие законы, регулирующие применение куки^{[источник не указан 2016 дней]}. Куки легко перехватить и подменить (например, для получения доступа к учетной записи), если пользователь использует нешифрованное соединение с сервером. В группе риска пользователи, выходящие в интернет при помощи публичных точек доступа Wi-Fi и не использующие при этом таких механизмов какSSL. Шифрование позволяет также решить и другие проблемы, связанные с безопасностью передаваемых данных. Имеется и ряд заблуждений о куки. Они главным образом основаны на уверенности людей, что куки являются компьютерными программами. На самом деле, куки — это простые текстовые данные, набор символов, передаваемый при запросах к веб-сайту, и они не могут выполнять какие-либо действия самостоятельно. В частности, куки не могут быть ни вирусами, ни шпионскими программами. Таким образом, куки могут быть опасны только в плане деанонимизации и слежения за действиями пользователя. Большинство современных браузеров позволяют пользователям выбрать — принимать куки или нет, но их отключение делает невозможной работу с некоторыми сайтами. Кроме того, необходимость частого ввода логина и пароля делает работу с сайтами менее удобной.