Работа с http протоколом


Содержание

Принципы работы HTTP — протокола

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

· Proxy представляет собой промежуточный агент, который принимает запрос клиента и передает запрос далее по цепочке другим серверам. В момент принятия запроса proxy может работать как сервер, а при передаче запроса – как клиент. На proxy могут создаваться копии наиболее часто запрашиваемых Web- страниц. В этом случае клиент получает информацию с proxy, что ускоряет работу Интернет. Как правило, proxy представляет «главные ворота » выхода пользователей из внутренней сети в Интернет. В зависимости от настроек proxy может изменять часть или все сообщение запроса .

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

· Tunnel представляет собой программу- посредник между клиентом и сервером. Туннели используются в тех случаях, когда необходимо организовать поток данных через какой- нибудь промежуточный объект (например proxy), который не может интерпретировать структуру потока данных.

Отметим, что ответы серверов могут храниться в КЭШе – локальной базе данных, которая возвращает их клиенту, не передавая запрос следующему серверу.

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

Тенденции развития протокола HTTP:

1. Увеличение производительности за счет более эффективной работы с КЭШем, промежуточными агентами.

2. Происходит расширение возможностей передачи распределенных ресурсов

3. Развиваются дополнительные механизмы защиты передаваемых данных.

Не нашли то, что искали? Воспользуйтесь поиском:

Работа с http протоколом

HyperText Transfer Protocol (HTTP) — это протокол высокого уровня (а именно, уровня приложений), обеспечивающий необходимую скорость передачи данных, требующуюся для распределенных информационных систем гипермедиа. HTTP используется проектом World Wide Web с 1990 года.

Практические информационные системы требуют большего, чем примитивный поиск, модификация и аннотация данных. HTTP/1.0 предоставляет открытое множество методов, которые могут быть использованы для указания целей запроса. Они построены на дисциплине ссылок, где для указания ресурса, к которому должен быть применен данный метод, используется Универсальный Идентификатор Ресурсов (Universal Resource Identifier — URI), в виде местонахождения (URL) или имени (URN). Формат сообщений сходен с форматом Internet Mail или Multipurpose Internet Mail Extensions (MIME-Многоцелевое Расширение Почты Internet).

HTTP/1.0 используется также для коммуникаций между различными пользовательскими просмотрщиками и шлюзами, дающими гипермедиа доступ к существующим Internet протоколам, таким как SMTP, NNTP, FTP, Gopher и WAIS. HTTP/1.0 разработан, чтобы позволять таким шлюзам через proxy серверы, без какой-либо потери передавать данные с помощью упомянутых протоколов более ранних версий.

Общая Структура

HTTP основывается на парадигме запросов/ответов. Запрашивающая программа (обычно она называется клиент) устанавливает связь с обслуживающей программой-получателем (обычно называется сервер) и посылает запрос серверу в следующей форме: метод запроса, URI, версия протокола, за которой следует MIME-подобное сообщение, содержащее управляющую информацию запроса, информацию о клиенте и, может быть, тело сообщения. Сервер отвечает сообщением, содержащим строку статуса (включая версию протокола и код статуса — успех или ошибка), за которой следует MIME-подобное сообщение, включающее в себя информацию о сервере, метаинформацию о содержании ответа, и, вероятно, само тело ответа. Следует отметить, что одна программа может быть одновременно и клиентом и сервером. Использование этих терминов в данном тексте относится только к роли, выполняемой программой в течение данного конкретного сеанса связи, а не к общим функциям программы.

В Internet коммуникации обычно основываются на TCP/IP протоколах. Для WWW номер порта по умолчанию — TCP 80, но также могут быть использованы и другие номера портов — это не исключает возможности использовать HTTP в качестве протокола верхнего уровня.

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

Общие понятия

Запрос — это сообщение, посылаемое клиентом серверу.
Первая строка этого сообщения включает в себя метод, который должен быть применен к запрашиваемому ресурсу, идентификатор ресурса и используемую версию протокола. Для совместимости с протоколом HTTP/0.9, существует два формата HTTP запроса:

Если HTTP/1.0 сервер получает Простой-Запрос, он должен отвечать Простым-Ответом HTTP/0.9. HTTP/1.0 клиент, способный обрабатывать Полный-Ответ, никогда не должен посылать Простой-Запрос.

Строка Статус

Строка Статус начинается со строки с названием метода, за которым следует URI-Запроса и использующаяся версия протокола. Строка Статус заканчивается символами CRLF. Элементы строки разделяются пробелами (SP). В Строке Статус не допускаются символы LF и CR, за исключением заключающей последовательности CRLF.

Следует отметить, что отличие Строки Статус Полного-Запроса от Строки Статус Простого- Запроса заключается в присутствии поля Версия-HTTP.

Метод

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

Список методов, допускаемых отдельным ресурсом, может быть указан в поле Заголовок-Содержание «Баллов». Тем не менее, клиент всегда оповещается сервером через код статуса ответа, допускается ли применение данного метода для указанного ресурса, так как допустимость применения различных методов может динамически изменяться. Если данный метод известен серверу, но не допускается для указанного ресурса, сервер должен вернуть код статуса «405 Method Not Allowed», и код статуса «501 Not Implemented», если метод не известен или не поддерживается данным сервером. Общие методы HTTP/1.0 описываются ниже.

Метод GET служит для получения любой информации, идентифицированной URI-Запроса. Если URI- Запроса ссылается на процесс, выдающий данные, в качестве ответа будут выступать данные, сгенерированные данным процессом, а не код самого процесса (если только это не является выходными данными процесса).

Метод GET изменяется на «условный GET», если сообщение запроса включает в себя поле заголовка «If-Modified-Since». В ответ на условный GET, тело запрашиваемого ресурса передается только, если он изменялся после даты, указанной в заголовке «If-Modified-Since». Алгоритм определения этого включает в себя следующие случаи:

  • Если код статуса ответа на запрос будет отличаться от «200 OK», или дата, указанная в поле заголовка «If-Modified-Since» некорректна, ответ будет идентичен ответу на обычный запрос GET.
  • Если после указанной даты ресурс изменялся, ответ будет также идентичен ответу на обычный запрос GET.
  • Если ресурс не изменялся после указанной даты, сервер вернет код статуса «304 Not Modified».

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

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

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

  • Аннотация существующих ресурсов
  • Добавление сообщений в группы новостей, почтовые списки или подобные группы статей
  • Доставка блоков данных процессам, обрабатывающим данные
  • Расширение баз данных через операцию добавления

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

Клиент может предложить URI для идентификации нового ресурса, включив в запрос заголовок «URI». Тем не менее, сервер должен рассматривать этот URI только как совет и может сохранить тело запроса под другим URI или вообще без него.

Если в результате обработки запроса POST был создан новый ресурс, ответ должен иметь код статуса, равный «201 Created», и содержать URI нового ресурса.

Метод PUT запрашивает сервер о сохранении Тело-Запроса под URI, равным URI-Запроса. Если URI-Запроса ссылается на уже существующий ресурс, Тело-Запроса должно рассматриваться как модифицированная версия данного ресурса. Если ресурс, на который ссылается URI-Запроса не существует, и данный URI может рассматриваться как описание для нового ресурса, сервер может создать ресурс с данным URI. Если был создан новый ресурс, сервер должен информировать направившего запрос клиента через ответ с кодом статуса «201 Created». Если существующий ресурс был модифицирован, должен быть послан ответ «200 OK», для информирования клиента об успешном завершении операции. Если ресурс с указанным URI не может быть создан или модифицирован, должно быть послано соответствующее сообщение об ошибке.

Фундаментальное различие между методами POST и PUT заключается в различном значении поля URI-Запроса. Для метода POST данный URI указывает ресурс, который будет управлять информацией, содержащейся в теле запроса, как неким придатком. Ресурс может быть обрабатывающим данные процессом, шлюзом в какой нибудь другой протокол, или отдельным ресурсом, допускающим аннотации. В противоположность этому, URI для запроса PUT идентифицирует информацию, содержащуюся в Содержание-Запроса. Использующий запрос PUT точно знает какой URI он собирается использовать, и получатель запроса не должен пытаться применить этот запрос к какому-нибудь другому ресурсу.

DELETE

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

Метод LINK устанавливает взаимосвязи между существующим ресурсом, указанным в URI-Запроса, и другими существующими ресурсами. Отличие метода LINK от остальных методов, допускающих установление ссылок между документами, заключается в том, что метод LINK не позволяет передавать в запросе Тело-Запроса, и в том, что в результате работы данного метода не создаются новые ресурсы.


Метод UNLINK удаляет одну или более ссылочных взаимосвязей для ресурса, указанного в URI- Запроса. Эти взаимосвязи могут быть установлены с помощью метода LINK или какого-нибудь другого метода, поддерживающего заголовок «Link». Удаление ссылки на ресурс не означает, что ресурс прекращает существование или становится недоступным для будущих ссылок.

Поля Заголовок-Запроса

Поля Заголовок-Запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

Кроме того через механизм расширения могут быть определены дополнительные заголовки; приложения, которые их не распознают, должны трактовать эти заголовки, как Заголовок-Содержание.

Ниже будут рассмотрены некоторые поля заголовка запроса.

В случае присутствия поля From, оно должно содержать полный E-mail адрес пользователя, который управляет программой-агентом, осуществляющей запросы. Этот адрес должен быть задан в формате, определенном в RFC 822. Формат данного поля следующий: From = «From» «:» спецификация адреса. Например:

Данное поле может быть использовано для функций захода в систему, а также для идентификации источника некорректных или нежелательных запросов. Оно не должно использоваться, как несекретная форма разграничения прав доступа. Интерпретация этого поля состоит в том, что обрабатываемый запрос производится от имени данного пользователя, который принимает ответственность за применяемый метод. В частности, агенты-роботы должны использовать этот заголовок для того, чтобы можно было связаться с тем человеком, который отвечает за работу робота, в случае возникновения проблем. Почтовый Internet адрес, указывающийся в этом поле, не обязан соответствовать адресу того хоста, с которого был послан данный запрос. По возможности, адрес должен быть доступным Internet адресом вне зависимости от того, является ли он в действительности Internet E-mail адресом или Internet E-mail представлением адреса других почтовых систем.

Замечание: Клиент не должен использовать поле заголовка From без позволения пользователя, так как это может войти в конфликт с его частными интересами или с местной, используемой им, системой безопасности. Настоятельно рекомендуется предоставление пользователю возможности запретить, разрешить или модифицировать это поле в любой момент перед запросом.

If-Modified-Since

Поле заголовка If-Modified-Since используется с методом GET для того, чтобы сделать его условным: если запрашиваемый ресурс не изменялся во времени, указанного в этом поле, копия этого ресурса не будет возвращена сервером; вместо этого, будет возвращен ответ «304 Not Modified» без Тела- Ответа.

Пример использования заголовка:

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

User-Agent

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

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

Структура ответа

После получения и интерпретации запроса, сервер посылает ответ в соответствии со следующей формой:

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

Строка Статус

Первая строка Полного-Запроса является Строкой-Статус, состоящей из версии протокола, за которой следует цифровой код статуса и ассоциированное с ним текстовое предложение. Все элементы Строки-Статус разделены пробелами. Не разрешены символы CR и LF, за исключением завершающей последовательности CRLF.

Так как Строка-Статус всегда начинается с версии протокола «HTTP/» 1*ЦИФРА «.» 1*ЦИФРА (например HTTP/1.0), существование этого выражения рассматривается как основное для определения того, является ли ответ Простым-Ответом, или Полным-Ответом. Хотя формат Простого-Ответа не исключает появления подобной строки (что привело бы к неправильной интерпретации сообщения ответа и принятию его за Полный-Ответ), вероятность такого появления близка к нулю.

Статус-Код и пояснение к нему

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

Первая цифра Статус-Кода предназначена для определения класса ответа. Последние две цифры не выполняют никакой категоризирующей роли. Существует 5 значений для первой цифры:

  1. 1xx: Информационный — Не используется, но зарезервирован для использования в будущем
  2. 2xх: Успех — Запрос был полностью получен, понят, и принят к обработке.
  3. 3xx: Перенаправление — Клиенту следует предпринять дальнейшие действия для успешного выполнения запроса. Необходимое дополнительное действие иногда может быть выполнено клиентом без взаимодействия с пользователем, но настоятельно рекомендуется, чтобы это имело место только в тех случаях, когда метод, использующийся в запросе безразличен (GET или HEAD).
  4. 4xx: Ошибка клиента — Запрос, содержащий неправильные синтаксические конструкции, не может быть успешно выполнен. Класс 4xx предназначен для описания тех случаев, когда ошибка была допущена со стороны клиента. Если клиент еще не завершил запрос, когда он получил ответ с Статус-Кодом- 4xx, он должен немедленно прекратить передачу данных серверу. Данный тип Статус-Кодов применим для любых методов, употребляющихся в запросе.
  5. 5xx: Ошибка Сервера — Сервер не смог дать ответ на корректно поставленный запрос. В этих случаях
    сервер либо знает, что он допустил ошибку, либо не способен обработать запрос. За исключением ответов на запросы HEAD, сервер посылает описание ошибочной ситуации и то, является ли это состояние временным или постоянным, в Содержание-Ответа. Данный тип Статус-Кодов применим для любых методов, употребляющихся в запросе.

Отдельные значения Статус-Кодов и соответствующие им Фразы-Об’яснения приведены ниже. Данные Фразы-Об’яснения только рекомендуются — они могут быть замещены любыми другими фразами, сохраняющими смысл и допускающимися протоколом.

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

Поля Заголовок-Ответа

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

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

Общие Понятия

Полный-Запрос и Полный-Ответ может использоваться для передачи некоторой информации в отдельных запросах и ответах. Этой информацией является Содержание-Запроса или Содержание-Ответа соответственно, а также Заголовок-Содержания.

Поля Заголовок-Содержания

Поля Заголовок-Содержания содержат необязательную метаинформацию о Содержании-Запроса или Содержании-Ответа соответственно. Если тело соответствующего сообщения (запроса или ответа) не присутствует, то Заголовок-Содержания содержит информацию о запрашиваемом ресурсе.

Некоторые из полей заголовка содержания описаны ниже.

Allow

Поле заголовка Allow представляет собой список методов, которые поддерживает ресурс, идентифицированный URI-Запроса. Назначение этого поля — точное информирование получателя о допустимых методах, ассоциированных с ресурсом; это поле должно присутствовать в ответе со статус кодом «405 Method Not Allowed».

Конечно, клиент может попробовать использовать другие методы. Однако, рекомендуется следовать тем методам, которые указаны в данном поле. У этого поля нет значения по умолчанию; если оно оставлено неопределенным, множество разрешенных методов определяется сервером в момент каждого запроса.

Content-Length

Поле Content-Length указывает размер тела сообщения, посланного сервером в ответ на запрос или, в случае запроса HEAD, размер тела сообщения, которое было бы послано в ответ на запрос GET.

Илон Маск рекомендует:  Что такое код error_log

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

Content-Type

Поле заголовка Content-Type идентифицирует тип информации в теле сообщения, которая посылается получающей стороне или, в случае метода HEAD, тип информации (среды), который был бы послан, если использовался метод GET.

Типы сред определены отдельно.
Пример:

Поле Content-Type не имеет значения по умолчанию.


Last-Modified

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

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

Тело сообщения

Под телом сообщения понимается Содержание-Запроса или Содержание-Ответа соответственно. Тело сообщения, если оно присутствует, посылается в HTTP/1.0 запросе или ответе в формате и кодировке, определяемыми полями Заголовок-Содержания.

Тело сообщения включается в запрос, только если метод запроса подразумевает его наличие. Для спецификации HTTP/1.0 такими методами являются POST и PUT. В общем, на присутствие тела сообщения указывает присутствие таких полей заголовка содержания, как Content-Length и/или Content- Transfer-Encoding, в передаваемом запросе.

Что касается сообщений-ответов, наличие тела сообщения в ответе зависит от метода, который был использован в запросе, и Статус-Кода. Все ответы на запросы HEAD не должны содержать тело сообщения, хотя наличие некоторых полей заголовка сообщения может указывать на возможное присутствие такового. Соответственно, ответы «204 No Content», «304 Not Modified», и «406 None Acceptable» также не должны включать в себя тело сообщения.

Схема функционирования HTTP-сообщений и возможные риски

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

Автор: Ryan Brown

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

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

HTTP-запросы

Простой HTTP-запрос:

Рисунок 1: Элементарный HTTP-запрос

HTTP/1.1 – Версия протокола HTTP

HTTP-методы:

Протокол HTTP поддерживает несколько методов. В самой первой версии HTTP/1.0 было три метода: GET, POST и HEAD. В HTTP/1.1 появилось несколько новых методов (см. RFC 2616): OPTIONS, CONNECT, TRACE, PUT и DELETE. В RFC 5789, появившегося в 2010 году, добавился метод PATCH.

Рисунок 2: Перечень методов, поддерживаемых протоколом HTTP/1.1

GET используется для простого запроса ресурсов с веб-сервера. Параметры для этого метода передаются через URL.

POST используется для отсылки данных на веб-сервер через тело HTTP-запроса.

HEAD схож с методом GET, но выводит только заголовки HTTP-ответа, который возвращает сервер.

OPTIONS используется для получения списка методов, принимаемых веб-сервером, которые хранятся в заголовке ‘Allow’ в HTTP-ответе.

PUT предназначен для замены существующего или создания нового ресурса на веб-сервере.

TRACE используется при тестировании и отсылает полное сообщение, полученное веб-сервером, обратно клиенту, что позволяет увидеть конкретное содержимое, полученное веб-сервером.
CONNECT используется редко и совместно с прокси-сервером, который может динамически переключаться в режим туннеля.

PATCH схож с методом PUT. Отличие заключается в этом, что PATCH поддерживает частичную модификацию, в то время как метод PUT поддерживает только полную замену ресурса.

Примечание:

В большинстве приложений используются в основном GET и POST, поскольку HTML поддерживает только эти два метода. Если предполагается использование методов OPTIONS, PUT, DELETE, PATCH, TRACE или CONNECT, необходимо все тщательно продумать и оценить риски в отношении приложения или веб-сервера.

URL:

URL или Uniform Resource Locator (унифицированный указатель ресурсов) является подмножеством унифицированных идентификаторов ресурсов (Uniform Resource Identifiers; URI). Типичная структура URL выглядит так:

По сути, это способ обозначения местонахождения сетевого ресурса и метод передачи данных целевому ресурсу.

Рисунок 3: Переменная HOST представляет собой сетевой адрес веб-сервера, куда клиент отсылает HTTP-запрос

Рисунок 4: Наиболее распространенные заголовки HTTP-запроса

User-Agent содержит информацию о браузере.

Accept определяет тип содержимого, который может принять клиент.

Accept-Encoding определяет тип кодировки, которую может принять клиент.

Content-Length определяет длину тела запроса в октетах. Это значение не имеет особой важности, но некоторые HTTP-методы (например, PUT) требуют этот заголовок. Если необходимо, в значение этого заголовка можно установить 0.
Referer содержит URL-источник запроса.

Cookie предназначен для отправки cookies на сервер для управления сессией.

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

Authorization содержит информацию, имеющую отношение к аутентификации на конкретной платформе.

HTTP-ответы

Пример простого HTTP-ответа:

Рисунок 5: Элементарный HTTP-ответ

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

Рисунок 6: Перечень кодов статуса

Код ответа «100 Continue» редко когда-либо используется. Наиболее распространенный код «200 OK», который сигнализирует о том, что запрос корректен, ресурс существует, сервер обработал запрос и вернул ресурс в теле ответа. Код 201 означает, что ресурс, запрашиваемый в запросе, был успешно создан. Этот код обычно является результатом запроса с использованием метода PUT. Коды статуса 3xx возвращается приложениями со ссылкой на ресурс, куда нужно перенаправить клиента. Ссылка находится либо в тебе ответа, либо в заголовке «location». Коды статуса 4xx отсылаются в случае, если запрашиваемого ресурса на сервере не существует или пользователь не авторизован для получения содержимого или при возникновении ошибки в запросе, отправленном серверу. Коды статуса 5xx возвращаются в случае, когда сервере возникает ошибка, и нет возможности обработать запрос.


Рисунок 7: Наиболее распространенные HTTP-заголовки ответов

Date содержит дату, когда получен запрос.

Server содержит информацию о веб-сервере (например, IIS/Apache).

X-Powered-By содержит информацию, касающуюся технологии, используемой в скриптах, и текущую версию (например, PHP или Asp.net).

Content-Length схож с аналогичным заголовком в запросе. Содержит длину тела ответа в октетах.

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

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

Cache-Control указывает клиенту, нужно ли кэшировать возвращаемые запросы.

Пример HTTP-запроса с использованием метода GET:

Рисунок 8: Пример использования метода GET

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

Пример ответа на запрос с использованием метода GET:

Рисунок 9: Ответ на запрос с использованием метода GET

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

Пример использования метода POST:

Рисунок 10: Пример отправки информации методом POST

HTTP-запрос с использованием метода POST во многом схож с запросом с методом GET, который мы только что рассматривали. Основное отличие заключается в том, что параметры передаются не через URL, а через тело запроса. Этот метод более безопасен и пригоден для передачи конфиденциальной информации, поскольку передаваемые сведения нельзя получить из кэша на стороне клиента. Если планируется передавать параметры, имеющие отношение к аутентификации, следует использовать протокол HTTPS вместе с TLS с целью включения функции шифрования передаваемой информации. Заголовок Content-Length содержит длину тела запроса в октетах. И, наконец, заголовок Referer указывает серверу место возникновения запроса.

Пример HTTP-запроса с методом TRACE:

Рисунок 11: Запрос с использованием метода TRACE

Пример ответа на запрос с методом TRACE:

Рисунок 12: Ответ на запрос с методом TRACE

Как видно из рисунка выше, при использовании метода TRACE сервер возвращает в теле ответа все, что было отправлено в запросе. Эта функция может быть полезна в том случае, если клиенту нужно точно знать, что получено сервером. Метод TRACK выполняет ту же самую функцию, но используется при работе с сервером Microsoft IIS. Уязвимости, которые могут возникать при использовании метода TRACE, связаны с межсайтовой трассировкой (Cross-Site Tracing; XST). Этот класс брешей злоумышленник может использовать для кражи cookie или другой конфиденциальной информации (например, учетных записей), хранимых в заголовке Authorization при помощи межсайтового скриптинга (XSS).

Пример HTTP-запроса с методом PUT:

Рисунок 13: Создание простейшей страницы при помощи метода PUT

Метод PUT требует использования в запросе заголовка Content-Length. Значение этого заголовка особого значение не имеет и может быть установлено нулевым без каких-либо непредсказуемых последствий. Если директория, указанная в URL, уже существует на сервере, соответствующий ресурс будет полностью заменен. Если ресурса, указанного в URL, не существует, то будет создан новый ресурс (предполагается, что соответствующий метод реализован на сервере). Содержимое ресурса, который нужно создать, указывается в теле запроса. В примере выше создается простая html-страница.

Пример ответа на запрос с методом PUT:

Рисунок 14: Ответ с кодом об успешном создании страницы

В идеале от сервера должен прийти ответ с кодом статуса «201 Created», свидетельствующий о том, что ресурс создан. Кроме того, в HTTP-запрос можно было бы вставить заголовок «Expect: 100-continue», чтобы удостовериться, что сервер готов к обработке и не закроет сокет до того, как получит содержимое, которое вы указали в теле запроса. При использовании в запросе заголовка «Expect» в ответ может прийти один из двух кодов статуса: «100 Continue» или «417 Expectation Failed».

После ознакомления с вышеуказанной информации становится понятно, почему этот метод может стать причиной потенциальных проблем и привести к тому, что злоумышленник завладеет вашим сервером. В реальных условиях использование метода PUT разрешено нечасто, и для того, чтобы сервер принял содержимое тело запроса, необходимо наличие заголовка «Authorization».

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

Пример HTTP-запроса с методом PUT и вставкой кода шелла:

Рисунок 15: Пример использования кода шелла в теле запроса

Пример HTTP-запроса с методом DELETE:

Рисунок 15: Запрос на удаление ресурса при помощи метода DELETE

Пример ответа на запрос с методом DELETE:

Рисунок 16: Ответ на запрос об успешном удалении ресурса

После успешного удаления ресурса, указанного в URL, сервер должен вернуть код статуса 200 OK.

Пример HTTP-запроса с методом OPTIONS:

Рисунок 17: Запрос методов, доступных на сервере, при помощи метода OPTIONS

Пример ответа на запрос с методом OPTIONS:

Рисунок 18: Ответ с перечнем методов, доступных на сервере

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

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

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Блог Vaden Pro

В статье раскрывается сущность работы протокола HTTP, кроме этого рассказывается о разных схемах его работы. Особое внимание уделяется сущности взаимодействия браузера и сервера.


Сущность работы HTTP

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

Обмен данными между сервером и браузером идет через HTTP протокол. Сам браузер с точки зрения программирования является HTTP клиентом, так как он пользуется этим протоколом при отправке запросов и для получения ответных данных.

Теперь раскроем суть понятия HTTP протокол

HTTP (англ. HyperText Transfer Protocol) – процесс, согласно которому проводятся все виды обмена информацией в всемирной сети Интернет.

Нас, как веб-разработчиков интересует только сам процесс обмена и вывода информации.

Синхронизированный протокол

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

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

Как осуществляется запрос?

Процесс отправки запроса на сервер можно разбить на несколько составных частей:

  1. В первую очередь осуществляется DNS-запрос, который должен преобразовать адрес сайта из URI формата в IP (числовая форма URI-адреса). Именно такой формат адреса используется в Всемирной сети.
  2. После определения IP устанавливается связь между сервером и HTTP клиентом.
  3. Пересылка запроса.
  4. Задержка, в которую входит пересылка информации на сервер, ее обработка и отправка ответа на запрос. Программисты называют этот временной промежуток ожиданием ответа.
  5. Получение ответа на запрос.

Отследить все эти этапы можно с помощью панели веб-разработчика в браузере.

Из перечня всех этапов достаточно длительным является первый. В начале развития протокол HTTP использовал устаревшую схему обработки данных, которая предусматривала разрыв связи после того, как будет получен ответ на требуемый запрос. Это очень тормозило процесс работы в интернет-пространстве. Однако, после того как вышла новая стандартизация работы протокола HTTP версии 1.1, стал доступным новый режим работы соединения — keep-alive, согласно которому связь стала неразрывной. Вследствие этого после обработки первого запроса не требуется заново проходить первый этап, а сразу переходить ко второму.

Заметка

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

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

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

Параллельное HTTP соединение

Чтобы решить проблему большого времени ожидания и прерывания связи с хостом, была создана параллельная схема связи между клиентом и сервером. Другими словами можно одновременно установить соединение с несколькими хостами. Разработчики стандарта HTTP 1.1 советуют подключать не более 2 каналов соединения одновременно. Но следует учитывать, что спецификация вышла на свет еще во времена древних динозавров. Сейчас браузеры легко поддерживают связь с 4 каналами одновременно по умолчанию, а если порыться в настройках клиента, то этот показатель можно увеличить до 8.

Каждый канал работает по старой схеме соединения, но рост их количества привел к существенным изменениям в плане времени загрузки ресурса.

Конвейерное HTTP соединение

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

Благодаря этому нововведению стало также возможным сокращение количества TCP/IP-пакетов. Таким образом, можно в один такой пакет поместить несколько HTTP-запросов. Вследствие этого улучшится не только работа протокола, но и повысится эффективность функционирования сети Интернет в целом.

Подводя итог

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

Что такое протокол сайта? Как работает HTTP и HTTPS

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

Основные протоколы сайта

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

  • • HTTP (Hyper Text Transfer Protocol)
  • • HTTPS (HyperText Transfer Protocol Secure)
  • • FTP (File Transfer Protocol)
  • • POP3 (Post Office Protocol)
  • • SMTP (Simple Mail Transfer Protocol)
  • • TELNET

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

Как работает HTTP протокол сайта

HTTP является прикладным протоколом передачи данных. Принцип его работы сложен, если разбираться в нем досконально, и крайне прост, если вникнуть в его суть. Работа через данный протокол осуществляется по схеме client-server. Существует сервер, который в пассивном режиме постоянно ожидает, когда с ним будет установлено соединение. Это соединение с ним рано или поздно установит клиент, то есть машинный интерфейс пользователя интернетом. Клиент хочет что-то получить от сервера: получить страницу, открыть картинку, скачать песню. Чтобы сообщить о том, что именно хочет клиент, пользователь отправляет запросы, которые сервер умело обрабатывает. Сервер умеет обрабатывать запросы юзера благодаря инструкции, которой его снабдил HTTP протокол. Если запрос обработать невозможно, сервер знает, какую ошибку он должен выдать.

Как работает HTTPS протокол сайта

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

Илон Маск рекомендует:  Что такое код updatecolors

HTTP или HTTPS: какой протокол лучше использовать

Ответ на этот вопрос очевиден. HTTP протокол устарел. Когда он был создан, это было сродни технической революции, а его использование подняло удобство коммуникации пользователя с серверами на необычайно высокий уровень. Но времена меняются и теперь он уязвим. HTTPS протокол является самым безопасным способом общения устройств на сегодняшний день. Его невозможно взломать, обойти, скомпрометировать, сегодня данный протокол передачи данных неуязвим. Невозможно определить, будет ли так всегда, но на данный момент большинство поисковых систем помечают сайты, которые все еще работают через HTTP протокол, как ненадежных, и сообщают пользователям о том, что на этом сайте им может угрожать опасность. И это происходит не просто так, это необходимо, чтобы обеспечить безопасность пользователей. Если вы еще не перевели свой сайт на HTTPS протокол передачи данных, то вам следует это сделать как можно скорее. Так, вы повысите доверие со стороны поисковых систем при продвижении сайта естественными ссылками, сможете пользоваться большим числом сервисов и сделаете использование своего сайта безопасным и удобным.

HTTP — HTTPS

HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) — протокол прикладного уровня, с помощью которого происходит передача данных (сначала — в виде гипертекстовых документов). Технология «клиент-сервер» — основа HTTP. Это означает, что предполагается наличие потребителей (клиентов), инициирующих соединение и отправляющих запрос, и поставщиков (серверов), ожидающих соединения с целью получения запроса. Эти поставщики производят требуемые действия и возвращают сообщение с результатом. На сегодняшний день протокол HTTP используется в Интернете практически везде с целью получения информации с веб-сайтов.

Содержание

HTTP может также использоваться в роли «транспорта» для таких протоколов прикладного уровня как SOAP, WebDAV.

HTTPS (HyperText Transfer Protocol Secure) — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, инкапсулируются в криптографический протокол SSL или TLS. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.

В 1994 году это расширение создала компания Netscape Communications для своего браузера Netscape Navigator. HTTPS используется и поддерживается всеми популярными браузерами.


Принцип работы

Действие протокола HTTP происходит по следующему принципу: программа-клиент осуществляет TCP-соединение с сервером (стандартный номер порта-80) и выводит ему HTTP-запрос. Сервер прорабатывает данный запрос и выдает HTTP-ответ клиенту.

Google придумала, как заставить сайты перейти на HTTPS

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

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

Тем не менее, в последнее время компании Google и Mozilla, каждая по своему, активно продвигают HTTPS. Mozilla и ее партнеры запустили сервис Let’s Encrypt, предоставляющий бесплатные, простые в развертывании TLS-сертификаты. В свою очередь, Google Chrome стал обозначать загружаемые по HTTP сайты как небезопасные (Not Secure).

Теперь же Google намерена пойти еще дальше и заставить сайты полностью перейти на HTTPS. Начиная с версии Chrome 79, в браузер постепенно будут вноситься изменения, которые в итоге приведут к полной блокировке «смешанного контента» по умолчанию. Уже в Chrome 80 «смешанные» аудио и видео будут автоматически обновляться до HTTPS. В случае невозможности загрузки контента по HTTPS, он будет блокироваться. В Chrome 81 этот подход будет также применяться к «смешанным» изображениям. [1]

Власти Казахстана перехватывают трафик Facebook, Google и «ВКонтакте»

Спустя неделю после того, как правительство Казахстана начало перехватывать весь HTTPS-трафик, стали известны некоторые подробности о происходящем в стране. Подробнее здесь.

Правительство Казахстана начало перехватывать весь HTTPS-трафик в стране

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

После установки сертификата правительственные органы Казахстана смогут расшифровывать HTTPS-трафик пользователей, просматривать его содержимое, снова шифровать его с помощью своего сертификата и отправлять по назначению. Это позволяет правительству Казахстана легко отслеживать действия своих граждан в Интернете.

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

Без установки сертификата зайти на сайты с HTTPS (а таких большинство) нельзя — интернет-провайдер блокирует доступ и выдаёт страницу-заглушку, подобную той, которая представлена ниже.

На этой странице выведено следующее сообщение:

Целью применения сертификата безопасности является ограничение распространения по сети телекоммуникаций запрещенной законодательством информации.

Пользователям предлагает перейти по ссылке для установки сертификата. Некоторым абонентам поступили SMS с напоминанием «в соответствии с Законом «О связи» ст. 26″ установить сертификат на все выходящие в интернет устройства.

Операторы Kcell и Activ заявили, что сертификат был внедрен из-за участившихся случаев хищения персональных данных казахстанцев и кражи денег с их банковских карт. Он защитит абонентов «от хакерских атак и просмотра противоправного контента». У сертификата не будет доступа к персональным данным абонента, утверждают Kcell. [2]

2020: 20% крупнейших сайтов не используют HTTPS

В апреле 2020 года стало известно о том, что 20% крупнейших в мире сайтов не используют протокол HTTPS с поддержкой шифрования, несмотря на ограничения, которые с которыми они сталкиваются в связи с этим.

По данным Google, 79 из 100 наиболее популярных веб-ресурсов, не связанных с компанией, не используют сертификат для защищенных HTTPS-соединений. Такую безопасность игнорируют, в частности, крупнейшая в мире база данных и интернет-портал о кинематографе IMDB и газета The New York Times. Правда, HTTP применяется не на всех страницах сайтов указанных и других крупных компаний.

Авторы рейтинга Alexa, собирающие статистику о посещаемости сайтов, составили список ресурсов, которые автоматически не перенаправляют небезопасные запросы в ответ на безопасные. Данные Google подтверждаются: 20% из наиболее посещаемых сайтов относятся к разряду небезопасных.

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

Раньше внедрение HTTPS было весьма дорогостоящим для сайтов, особенно небольших, но к апрелю 2020 года работает множество компаний, предлагающих бесплатную и очень быструю установку SSL-сертификатов. Например, можно отметить сервис Lets’s Encrypt, обеспечивающий автоматическую выдачу бесплатных сертификатов для TLS-шифрования и поддерживаемый Google на правах платинового члена.

Однако крупные сайты не спешат полностью переходить на HTTPS, считая эту миграцию технически сложной и зачастую невыгодной. Планируя такой переход, компании, как правило, задают себе несколько вопросов: «Не станет ли сеть доставки дороже в случае с HTTPS?», «Будет ли сторонний контент на сайте учитывать переход на HTTPS?» и др. Компании приходится проводить множество тестирований и исправлять многочисленные ошибки перед тем, как протокол начнет нормально функционировать.

Если HTML-ресурсы, которые предоставляет компания, имеют ссылки (картинки, скрипты…) на разные хосты и не используются относительные URL, то переход на HTTPS осложняется.

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

Кроме того, по словам эксперта в области информационной безопасности Malwarebytes Жерома Сегуры (Jérôme Segura), HTTPS не гарантирует 100-процентную безопасность. Например, некоторые сайты могут задействовать протокол на главной странице, но не включить его в другие страницы и сервисы. [3]

Проверка 10 000 ведущих сайтов из рейтинга Alexa показала следующее: многие из них подвержены критическим уязвимостям протоколов SSL/TLS, обычно через поддомены или зависимости. Уязвимые криптографические конфигурации выявлены на 5574 хостах, то есть примерно на 5,5% от общего количества.

По словам авторов исследования, сложность современных веб-приложений многократно увеличивает поверхность атаки. Проблему усугубляет отсутствие официально одобренного и согласованного списка рекомендуемых настроек HTTPS. Так, Mozilla SSL Configuration Generator предлагает несколько вариантов конфигурации в зависимости от требуемого уровня защиты.

Россия: число сайтов с SSL-сертификатами за год выросло в четыре раза

По данным аналитического сервиса StatOnline, в российских национальных доменных зонах количество сайтов, использующих SSL-сертификаты, за год выросло в четыре раза. В июле 2015 года в зоне .RU количество таких ресурсов составляло 109 тыс., в том же месяце 2020 года — 189 тыс., а в июле 2020 года — 531 тыс. Для сравнения, показатели зоны .РФ составляли 18 тыс., 21 тыс. и 65 тыс. соответственно. По состоянию на август 2020 года, всего в зоне .RU насчитывается 5,5 млн сайтов, в зоне.РФ — 900 тыс., передают «Известия». [4]

HTTPS-протокол призван защитить данные пользователей от перехвата. Согласно обещаниям Google, ссылки на ресурсы, которые всё еще не перешли на HTTPS, с начала 2020 года будут отображаться в результатах поиска с предупреждением об их небезопасности. С похожей инициативой выступила и компания Mozilla, выпускающая браузер Firefox.

SSL-сертификаты — уникальная цифровая подпись сайта, необходимая для организации защищенного соединения между браузером интернет-пользователя и сервером. Обычные сайты используют для обмена данными протокол HTTP, ресурсы с сертификатом — защищенный HTTPS. SSL-сертификаты выпускаются на разные сроки. По данным StatOnline, наиболее распространенный период действия SSL-сертификата — менее 1 года. В зоне .RU число таких сертификатов составляет 82% от общего числа, а в зоне .РФ — 95%.

Антивирусы влияют на безопасность HTTPS

13 февраля 2020 года группа исследователей опубликовала отчет о влиянии антивирусного ПО на безопасность HTTPS-трафика, в котором подтвердились предположения экспертов о небезопасном влиянии антивирусных средств на зашифрованный трафик.

В составе группы действовали специалисты Mozilla, Google, CloudFlare, представители университета Мичигана, иллинойсского университета в Урбан-Шампейне, калифорнийского университета в Беркли и Международного института информатики [5] .

Эксперты подозревали о влиянии инструментов защиты на защищенные соединения, в результате чего зашифрованный трафик подвергается риску и безопасность ослабевает. Они оказались правы в своих подозрениях. Исследователи проанализировали подтверждения сессий связи (handshakes), связанных с браузерами, антивирусными продуктами и вредоносными программами, и на основе этого создали эвристические методы контроля перехвата и вмешательства в HTTPS, определения субъекта перехвата трафика.

Созданные для тестов инструменты разместили на серверах Mozilla Firefox, CloudFlare CDN и сайтах электронной коммерции. Анализ показал: 4% соединений Firefox, 6,2% соединений e-commerce сайтов и 11% соединений CloudFlare перехвачены. После чего большинство этих соединений стали менее безопасны (97% применительно к Firefox, 54% для CloudFlare и 32% для e-commerce ресурсов). Безопасность более 62% процентов соединений ослабла до относительно приемлемого уровня, а 58% соединений стали подвержены критическим уязвимостям.

По мнению экспертов, беспокойство вызывает не только то, что перехватчики соединений использовали более слабые криптографические алгоритмы, но и то, что 10-40% из них объявили о поддержке давно взломанных шифров, что позволяет атакующему в позиции Man in the middle (MITM) перехватить соединение, произвести downgrade и расшифровать его.

Исследователи изучили работу продуктов A10 Networks, Blue Coat, Barracuda, Check Point, Cisco, Forcepoint, Fortinet, Juniper Networks, Microsoft, Sophos, Untangle и WebTitan. Из этого списка только технологии Blue Coat, по мнению исследователей, обращались с TLS-соединениями корректно. Остальные продукты получили 2-3 балла по пятибалльной шкале из-за уязвимостей и потенциальных MitM-атак.

2020: Только 5% HTTPS-серверов используют корректно настроенный HSTS

По данным компании Netcraft, 95% от всех использующихся в мире HTTPS-серверов уязвимы к хакерским атакам из-за неправильно настроенного механизма HSTS или его отсутствия. Как показали результаты исследования, только 5% изученных экспертами HTTPS-серверов используют корректно настроенный HSTS. Подобное исследование также проводилось три года назад, и с тех пор практически ничего не изменилось. По мнению исследователей, администраторы либо не знают о проблеме, либо относятся к ней недостаточно серьезно.

HSTS активирует форсированное защищенное соединение через HTTPS вместо HTTP. В настоящее время данный механизм поддерживается браузерами Internet Explorer 11, Microsoft Edge, Firefox, Chrome, Safari и Opera. С его помощью администраторы web-ресурсов могут предотвращать атаки «человек посередине», манипуляции с файлами cookie и т.д.

Как сообщают эксперты, простейший сценарий атаки выглядит следующим образом: пользователь вводит в строку поиска адрес сайта, указывая http:// вместо https://. Ресурс без поддержки HSTS открывается через HTTP, и у злоумышленников появляется возможность осуществить фишинговую атаку или атаку «человек посередине».

Браузеры способствуют существованию фальшивых сайтов


Браузеры Google (Chrome), Microsoft (Internet Explorer), Apple (Safari) и Mozilla (Firefox) позволяют нарушать режим безопасного использования информации программам вроде Superfish, PrivDog, Gogo и аналогичным. Они делают это путем бездействия [6] .

Безопасные веб-страницы (HTTPS) требуют от веб-браузеров наличия файла, именуемого цифровым сертификатом, который необходим, помимо прочего, чтобы убедиться, что пользователь именно там, на том сайте, на котором он думает, что он там.

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

Один из способов защиты против этого — файл цифрового сертификата. Так же, как почтовый штемпель показывает — где и когда письмо было отправлено по почте, файл сертификата должен доказать идентичность сайта.

Для использования защищенного веб-сайта HTTPS, необходимо вначале получить файл сертификата у любой из компаний в бизнесе по их продаже. Эти компании называют Центрами Сертификации (Certificate Authorities). Они берут на себя хлопоты по проверке идентичности субъекта, делающего запрос.

Технари упоминают файл сертификата, как «сертификат» или, чаще всего, просто «cert». Иногда его называют «сертификат HTTPS» или «сертификат шифрования». Google называет его «сертификат безопасности».

Чтобы подтвердить свою идентичность, сайты, использующие SSL-сертификаты, предоставляют сертификаты безопасности для Chrome, например. Любой желающий может создать веб-сайт, притворяющийся другим сайтом, но только реальный сайт имеет действительный сертификат безопасности для конкретного URL. Недействительные сертификаты могут означать: кто-то пытается манипулировать подключением к сайту.

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

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

Помимо этого, никто не знает эти компании. GeoTrust, Entrust, USERTrust, GTE CyberTrust, Starfield, CertPlus, DigiCert и Thawte не являются общеизвестными. Почтамт Гонконга, например, является доверенным Центром Сертификации. Кто будет доверять веб-узлу, идентичность которого удостоверена почтамтом Гонконга? Браузеры в пользовательских системах доверяют.

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

Нет сомнения, что Microsoft, Apple, Google и Mozilla будет указывать на то, что имя поручающегося Certificate Authority легко доступно. Технически, это так. Реально это не так, по крайней мере, не для не-технарей, которые нуждаются в этом больше всего.

Чтобы увидеть имя Certificate Authority, потребуется совершить несколько манипуляций, а маршрут передвижения никто никогда не объясняет новичкам. И эти манипуляции отличны для каждого браузера.

Рассмотрим действия на платформе Windows. Существует несколько путей по раскрытию имени CA.

В Firefox 36 (и выше), необходимо нажать на замок, слева от адреса сайта в адресной строке. Во всплывающем окне появится «Подтверждено» и имя Центра Сертификации.

В Chrome 41 название компании темно-зеленое в светло-зеленом прямоугольнике. Нужно нажать на название компании или на замок рядом с адресом, затем на слово «Соединения». Это не сразу понятно, в появившемся окне есть две вкладки — одна для Разрешений, другая для Соединений.

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

В Internet Explorer 11 надо щелкнуть на замке с правой стороны адресной строки. В появившемся окне видно информацию об идентификации веб-сайта. Внизу окна щелкнуть Просмотр сертификатов и видно подробную информацию о Центре Сертификации, кому он выдан и сроках действия.

В Opera 27 требуется нажать на название компании, отображаемое зеленым цветом рядом с черным названием сайта, или на замок слева от адреса. Затем, нажать на слово «Подробнее». Название Центра Сертификации показывается, но он не идентифицирован, как таковой.

Браузер Vivaldi technical preview 2 предлагает секретный намек. Если навести курсор мыши на название компании, отображаемое зеленым цветом, слева от имени сайта, всплывающее окно покажет «информацию о сайте». После нажатия, цвет фона меняется со светло-зеленого до темно-зеленого. Нажатие на название компании вызовет окно, которое выглядит так же, как в Chrome — с вкладками Разрешения и Соединения.

В Safari на OS X необходимо нажать на маленький зеленый замок слева от названия компании.

Два браузера iOS 8 работают как Джекил и Хайд. Chrome не показывает название компании, только адрес. Safari, напротив, показывает только название компании и скрывает URL.

Хуже всего в Safari на iOS 8 то, что независимо от того, где ни щелкай, ни нажимай или наводи, он не выдаст название Центра Сертификации для безопасных веб-сайтов. Он не показывает даже полные URL-адреса. Chrome на Android также не в состоянии идентифицировать поручительства Центра Сертификации для защищенного веб-сайта.

Странное совпадение, что в наиболее популярных браузерах на iOS и Android отсутствует важная функция безопасности.

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

В Windows, Firefox, Chrome и Vivaldi используется слово «подтверждено», Internet Explorer использует «определил веб-сайт как», а Opera просто показывает имя.

Лучшее объяснение в Safari на OS X: Компания X определила сайт Y, как принадлежащий компании Z. Довольно просто. Но даже это объяснение не определяет Certificate Authority как Certificate Authority (Центр Сертификации), что делает ситуацию гораздо сложнее для не-технарей.

Добавляет путаницы название Центров Сертификации. В приведенных выше примерах Bank Of America, видно четыре различных названия: VeriSign Inc, VeriSign (без Inc), Symantec Corporation и Symantec Class 3 EV SSL CA — G3.

Как Центр Сертификации может использовать четыре названия?

Отчасти это происходит из файла сертификата, имеющего несколько встроенных имен для каждого Центра Сертификации. Chrome отображает «общее название», а Firefox выводит «Название организации». Ни один из браузеров не показывает название «Организационной единицы», которое, в данном случае, «Symantec Trust Network».

Несколько имен возникают из-за использования субподрядчиков (технари используют другой термин, но он лучше представляет концепцию) Центров Сертификации.

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

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

И все становится еще хуже.

В случае с Bank of America, технари знают, что Symantec купила VeriSign, так что эти два названия, по сути, одно и то же.

Но действительно ли Bank of America использует VeriSign? Может быть, они используют DigiCert или GeoTrust или Thawte. Как узнать? Единственный способ — если родственник работает в этом банке.

Кто еще думает, что определение «мошенничество» слишком сурово?

При этом вполне понятно, как работал Superfish.

Человек посередине (Man in the middle)

Superfish размещает себя между жертвой и остальным миром. Когда клиенты Lenovo думали, что у них установлено безопасное соединение с somebankingsite.com, его на самом деле не было. У них было безопасное соединение с программным обеспечением Superfish на их ПК с Windows 8.

Кроме того, банк тоже обманули, заставляя думать, что он общается непосредственно с клиентом. На самом деле, банк также общался с Superfish. Это классическая атака посредника, атака «человек посередине», MitM-атака [7] .

В старые времена, только плохие парни и шпионы проводили атаки посредника. Теперь рекламные компании делают это.

Классическая атака «человека посередине» использовала незащищенное соединение HTTP между веб-браузером и мошенником. Если происходит замена HTTPS на HTTP, то должен отсутствовать значок замка. С тех времен многие вещи изменились.

Superfish может скрыть свое присутствие представлением веб-браузеру файла сертификата — не настоящего файла-сертификата, а того, который Superfish создает «на лету». Независимо от того, какой защищенный веб-сайт HTTPS клиент Lenovo посещал, Superfish динамически создавал сертификат для него.

Другая часть атаки заставляет веб-браузеры доверять сертификатам от Superfish. Нормальные компьютеры так не делают.

Долгие месяцы клиенты Lenovo не замечали, что Superfish ручается за каждый защищенный веб-сайт в мире. Это свидетельствует о том, что найти название Certificate Authority довольно трудно. Gogo долго выпускал мошеннические сертификаты YouTube, пока этого не заметил сотрудник Google.

Илон Маск рекомендует:  Что такое код iscntrl isxdigit


Веб-браузеры должны четко показывать Certificate Authority на видном месте — лучше заставить пользователя «щелкать», для сокрытия названия, а не для его показа. Браузеры должны пролить свет на систему, функционирующую в темноте.

Существовавшая некогда компания розничной торговли Sy Syms использовала слоган для рекламы: «Образованный потребитель — наш лучший клиент». В мире технологий все не так. Возникает стойкое чувство, что есть цель — удержание в неведении технически неграмотных пользователей.

Если имя Центра сертификации (Certificate Authority) будет на видном месте в окне браузера, конечные пользователи могут получить некоторые преимущества:

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

Спецслужбы не любят образованных потребителей. Нынешняя система служит им хорошо. Они могут предложить мошенническую копию веб-сайта и поручиться за него сертификатом от скомпрометированного Центра Сертификации. Компрометация одного CA, позволяет им поручиться за любой веб-сайт, пока скрыто название CA. Если бы мы могли видеть, что Центр Сертификации Harveys ручается за Bank of America, афера бы не сработала.

Все зависит от Google, Apple, Mozilla и Microsoft. Им стоит показать своим потребителям название Центров Сертификации, подтверждающих подлинность, якобы, безопасных веб-сайтов.

Идентичность Certificate Authority очень важный аспект во взаимном доверии между потребителями и поставщиками данных.

Спецификации HTTP/2

18 февраля 2015 года стало известно о предстоящих усовершенствованиях протокола HTTP. Цель модернизации — значительное ускорение загрузки страниц.

Разработкой спецификаций протокола занималась рабочая группа IETF HTTP.

HTTP2 – первый значимый апдейт протокола с 1999 года, когда на свет вышла версия HTTP под номером 1.1. Обновление ускорит загрузку интернет-страниц, улучшит качество интернет-соединений с удалёнными серверами, оптимизирует работу кэша на компьютере, чтобы браузеру не приходилось загружать одни и те же данные по нескольку раз, нагружая интернет-канал.

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

Корпорация Google официально заявила, что постарается перейти на протокол HTTP/2 максимально оперативно, чтобы ускорить загрузку данных для пользователей Интернета. Разработчики, заинтересованные в обновлённом протоколе, могут получить доступ к его спецификациям.

Основные особенности цифрового протокола HTTP2:

  • Повышение эффективности использования сетевых ресурсов за счёт мультиплексирования запросов, расстановки приоритетов для запросов и сжатия заголовков HTTP, проактивных push-ответов со стороны сервера.
  • Серьёзное увеличение производительности для современных браузеров и мобильных устройств.
  • Возможность развёртывания в современном интернете, используя IPv4 и IPv6 и не забывая о NAT.
  • Упрощение развёртывания решений на основе HTTP.
  • Обеспечение современных требований к безопасности.

В основе HTTP/2 протокол SPDY [8] .

2014: Сайты с доступом по HTTP перейдут в разряд «опасных»

17 декабря 2014 года стало известно о предстоящей в 2015 году изменении в системе предупреждений браузера о небезопасных соединениях.

Chrome Security Team заявила, что все веб-страницы, доступ к которым осуществляется по протоколу HTTP, будут считаться опасными по умолчанию. По мнению разработчиков, подобная мера должна способствовать популяризации использования безопасных каналов связи и стимулировать владельцев сайтов переходит на применение HTTPS.

На 17 декабря 2014 года предупреждение появляется только в случае HTTPS-соединения, сертификат которого устарел или считается недопустимым (невалидным) и в то же самое время незащищённые каналы считаются браузером заслуживающими доверия, что не соответствует реалиям.

Согласно планам Chrome Security Team, будут определены три уровня безопасности:

  • безопасное соединение с доступом по валидному HTTPS;
  • сомнительное соединение, где в основном применяется доступ по HTTPS, но некоторые ресурсы используют обычный HTTP или имеются несущественные ошибки TLS;
  • небезопасное соединение, где применяется обычный HTTP или некорректный HTTPS.

Первое время HTTP-сайты будут относиться к сомнительной категории. Когда доля защищённых сайтов вырастет до 75%, их будут маркировать как опасные. Когда доступ по HTTPS начнут практиковать более 85% сайтов, оповещение о безопасном доступе предлагается убрать, считая, что сеанс безопасен по умолчанию.

Работа с HTTP в 1С 8.2 и 8.3

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

Общая информация

Для работы с протоколом HTTP в 1С существуют три основных объекта — HTTPСоединение, HTTPЗапрос и HTTPОтвет, кроме этого для создания HTTPS-соединения используется объект ЗащищенноеСоединениеOpenSSL, а для соединения через прокси-сервер объект ИнтернетПрокси. Существует еще несколько объектов, которые могут использоваться при работе с протоколом HTTP, но используются они достаточно редко и не так важны.

Назначение основных объектов следует из названия.

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

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

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

ИнтернетПрокси позволяет указать настройки прокси-сервера — с помощью метода Установить() можно указать параметры для подключения к прокси-серверу, отмечу, что свойства «Пароль» и «Пользователь» являются устаревшими, использовать их не рекомендуется.

ЗащищенноеСоединениеOpenSSL создает защищенное соединение OpenSSL — имеется возможность указать сертификат клиента и/или сертификат удостоверяющего центра, в большинстве случаев (для доступа к обычным сайтам по протоколу HTTPS) указывать какие либо сертификаты не требуется.

Заканчиваем с теорией и переходим к практике.

Практические задачи при работе с HTTP

В качестве практической части рассмотрим задачи, которые чаще всего встречаются при работе с протоколом HTTP в 1С

Краткое описание протокола HTTP

HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) был разработан как основа World Wide Web.

Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту.

Структура HTTP-запроса

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

Заголовок запроса состоит из главной (первой) строки запроса и последующих строк, уточняющих запрос в главной строке. Последующие строки также могут отсутствовать.

Запрос в главной строке состоит из трех частей, разделенных пробелами:


Метод (иначе говоря, команда HTTP):

GET — запрос документа. Наиболее часто употребляемый метод; в HTTP/0.9, говорят, он был единственным.

HEAD — запрос заголовка документа. Отличается от GET тем, что выдается только заголовок запроса с информацией о документе. Сам документ не выдается.

POST — этот метод применяется для передачи данных CGI-скриптам. Сами данные следуют в последующих строках запроса в виде параметров.

PUT — разместить документ на сервере. Насколько я знаю, используется редко. Запрос с этим методом имеет тело, в котором передается сам документ.

Ресурс — это путь к определенному файлу на сервере, который клиент хочет получить (или разместить — для метода PUT). Если ресурс — просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.

Версия протокола-версия протокола HTTP, с которой работает клиентская программа.

Таким образом, простейший HTTP-запрос может выглядеть следующим образом:

Здесь запрашивается корневой файл из корневой директории web-сервера.

Строки после главной строки запроса имеют следующий формат:

Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Keep-Alive).

Перечислю некоторые наиболее употребительные параметры HTTP-запроса:

Connection (соединение)- может принимать значения Keep-Alive и close. Keep-Alive («оставить в живых») означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером «скачать» html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close.
close («закрыть») — соединение закрывается после ответа на данный запрос.

User-Agent — значением является «кодовое обозначение» браузера, например:

Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

Accept — список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например для моего IE5:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Это, очевидно, нужно для случая, когда сервер может выдавать один и тот же документ в разных форматах.

Значение этого параметра используется в основном CGI-скриптами для формирования ответа, адаптированного для данного браузера.

Referer — URL, с которого перешли на этот ресурс.

Host — имя хоста, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP-адресом. В этом случае имя виртуального сервера определяется по этому полю.

Accept-Language — поддерживаемый язык. Имеет значение для сервера, который может выдавать один и тот же документ в разных языковых версиях.

Формат HTTP-ответа

Формат ответа очень похож на формат запроса: он также имеет заголовок и тело, разделенное пустой строкой.

Заголовок также состоит из основной строки и строк параметров, но формат основной строки отличается от таковой в заголовке запроса.

Основная строка запроса состоит из 3-х полей, разделенных пробелами:

Версия протокола — аналогичен соответствующему параметру запроса.

Код ошибки — кодовое обозначение «успешности» выполнения запроса. Код 200 означает «все нормально» (OK).

Словесное описание ошибки — «расшифровка» предыдущего кода. Например для 200 это OK, для 500 — Internal Server Error.

Наиболее употребительные параметры http-ответа:

Connection — аналогичен соответствующему параметру запроса.
Если сервер не поддерживает Keep-Alive (есть и такие), то значение Connection в ответе всегда close.

Поэтому, на мой взгляд, правильной тактикой браузера является следующая:
1. выдать в запросе Connection: Keep-Alive;
2. о состоянии соединения судить по полю Connection в ответе.

Content-Type («тип содержимого») — содержит обозначение типа содержимого ответа.

В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Значение Content-Type для браузера аналогично значению расширения файла для Windows.

Некоторые типы содержимого:

text/html — текст в формате HTML (веб-страница);
text/plain — простой текст (аналогичен «блокнотовскому»);
image/jpeg — картинка в формате JPEG;
image/gif — то же, в формате GIF;
application/octet-stream — поток «октетов» (т.е. просто байт) для записи на диск.

На самом деле типов содержимого гораздо больше.

Content-Length («длина содержимого») — длина содержимого ответа в байтах.

Last-Modified («Модифицирован в последний раз») — дата последнего изменения документа.

Что такое протокол сайта? Как работает HTTP и HTTPS

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

Основные протоколы сайта

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

  • • HTTP (Hyper Text Transfer Protocol)
  • • HTTPS (HyperText Transfer Protocol Secure)
  • • FTP (File Transfer Protocol)
  • • POP3 (Post Office Protocol)
  • • SMTP (Simple Mail Transfer Protocol)
  • • TELNET

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


Как работает HTTP протокол сайта

HTTP является прикладным протоколом передачи данных. Принцип его работы сложен, если разбираться в нем досконально, и крайне прост, если вникнуть в его суть. Работа через данный протокол осуществляется по схеме client-server. Существует сервер, который в пассивном режиме постоянно ожидает, когда с ним будет установлено соединение. Это соединение с ним рано или поздно установит клиент, то есть машинный интерфейс пользователя интернетом. Клиент хочет что-то получить от сервера: получить страницу, открыть картинку, скачать песню. Чтобы сообщить о том, что именно хочет клиент, пользователь отправляет запросы, которые сервер умело обрабатывает. Сервер умеет обрабатывать запросы юзера благодаря инструкции, которой его снабдил HTTP протокол. Если запрос обработать невозможно, сервер знает, какую ошибку он должен выдать.

Как работает HTTPS протокол сайта

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

HTTP или HTTPS: какой протокол лучше использовать

Ответ на этот вопрос очевиден. HTTP протокол устарел. Когда он был создан, это было сродни технической революции, а его использование подняло удобство коммуникации пользователя с серверами на необычайно высокий уровень. Но времена меняются и теперь он уязвим. HTTPS протокол является самым безопасным способом общения устройств на сегодняшний день. Его невозможно взломать, обойти, скомпрометировать, сегодня данный протокол передачи данных неуязвим. Невозможно определить, будет ли так всегда, но на данный момент большинство поисковых систем помечают сайты, которые все еще работают через HTTP протокол, как ненадежных, и сообщают пользователям о том, что на этом сайте им может угрожать опасность. И это происходит не просто так, это необходимо, чтобы обеспечить безопасность пользователей. Если вы еще не перевели свой сайт на HTTPS протокол передачи данных, то вам следует это сделать как можно скорее. Так, вы повысите доверие со стороны поисковых систем при продвижении сайта естественными ссылками, сможете пользоваться большим числом сервисов и сделаете использование своего сайта безопасным и удобным.

HTTPS

HTTPS – протокол передачи данных, поддерживающий шифрование.

HTTP и HTTPS – в чем разница

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

Поэтому все больше сайтов переходят на защищенный протокол HTTPS. В протоколе безопасности HTTPS используется асимметричная схема шифрования за счет использования гибридной системы TLS (усовершенствованный SSL) – благодаря этому все данные надежно защищены от перехвата.

Используемая в протоколе HTTPS система TLS предполагает защиту на трех уровнях:

  • Все данные шифруются. Так злоумышленники не смогут узнать, какая информация передается, и отследить действия пользователей на сайте. Для шифрования используется общий секретный ключ, который при установке безопасного соединения выбирают сервер и компьютер. Все ключи одноразовые, перехватить и подобрать очень сложно – длина ключа превышает 100 знаков.
  • Фиксация всех изменений или искажений данных, даже если это было сделано случайно.
  • Аутентификация гарантирует, что посетители попадут именно на тот сайт, который им нужен, и защищает от атаки посредника. Для этого у сайта должен быть специальный цифровой сертификат.

Сертификат безопасности

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

Сертификат безопасности можно получить в центре сертификации. При выборе сертификата следует обратить внимание на следующее:

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

o Одиночный сертификат для одного защищенного источника (например, www.example.com).
o Многодоменный сертификат для нескольких известных защищенных источников (например, www.example.com, cdn.example.com, example.co.uk).

o Сертификат-шаблон для защищенного источника с несколькими динамическими субдоменами. (например, a.example.com, b.example.com).

o Domain Validation – подтверждение домена (стоимость 10-30 долларов в год),

o Organization Validation – подтверждение домена и организации (стоимость 40-200 долларов в год),

o Extended Validation – подтверждение домена и организации с расширенной проверкой (стоимость 120-300 долларов в год). Именно этот сертификат дает зеленую строку в адресной строке браузера.

Использование протокола HTTPS

Все современные браузеры поддерживают защищенный протокол HTTPS. И все больше сайтов переходят на его использование – особенно после того как Google объявил использование зашифрованного протокола фактором ранжирования.

Примеры сервисов и веб-страниц, где использование интернет-протокола HTTPS является необходимостью:

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

Рекомендации по работе с протоколом HTTPS от Google

Google активно выступает за распространение защищенного протокола – сайты с HTTPS получают небольшое преимущество в результатах поиска. А чтобы работа с интернет-протоколом HTTPS не вызывала сложностей Google советует придерживаться следующих рекомендаций:

  • Использовать надежный сертификат безопасности,
  • При необходимости использовать 301 редирект,
  • Не закрывать HTTPS-страницы от сканирования и индексации файлом robots.txt,
  • Не использовать на HTTPS-страницах теги noindex,
  • Использовать технологию HSTS, которая снизит вероятность показа пользователям незащищенного содержания. В этом случае браузер будет запрашивать страницы HTTPS, даже если пользователь введет HTTPS в адресной строке.

Как перенести сайт с протокола HTTP на HTTPS

Рекомендации Google

  • Изменение протокола сайта с HTTP на HTTPS расценивается Google как перенос сайта с изменением URL.
  • Обязательно следует добавить ресурс с HTTPS-протоколом в Google Search Console.
  • На HTTPS-протокол лучше переносить сайт по частям.
  • Если новые URL пока не нужно индексировать, вместо переадресации следует использовать атрибут rel=canonical, поскольку страницы с переадресацией невозможно проверить. В других случаях нужно сделать переадресацию по сопоставлению URL для пользователей и поисковых систем,
  • Сделать отдельный файл robots.txt для сайта с HTTPS.
  • Для перенесенных на HTTPS страниц можно сделать отдельную Sitemap.
  • После переноса сайта Google также рекомендует обновить внешние ссылки и ссылки в рекламных кампаниях.

Рекомендации Яндекса

Технически для Яндекса смена протокола сайта с HTTP на HTTPS – это просто объединение ресурсов в группу зеркал либо изменение главного зеркала. Чтобы этот процесс прошел корректно, важно, чтобы у ресурсов был идентичный контент, а у владельца сайта – сертификат безопасности, выданный в надежном центре.

После этого следует:

  • Добавить сайт с HTTPS-протоколом в список сайтов в сервисе Яндекс.Вебмастер, тем самым сообщив о нем поисковому роботу,
  • Сообщить роботу об изменениях в отношении главного зеркала на странице «Настройки индексирования — Переезд сайта» сервиса Яндекс.Вебмастер для HTTP-версии сайта.

В течении нескольких недель главное зеркало в группе зеркал изменится, что сразу отразится в панели сервиса Яндекс.Вебмастер.

Как повлияет переход на протокол безопасности HTTPS на позиции и трафик

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

Через некоторое время все показатели приходят в норму. А в случае с Google позиции должны немного увеличиваться, т.к. поисковая система учитывает использование HTTPS-протокола при ранжировании сайтов. Но не стоит думать, что смены протокола достаточно, чтобы сразу выйти в ТОП-10 – данный фактор имеет меньший вес по сравнению с качеством материалов сайта.

Синонимы: нет
Все термины на букву «H»
Все термины в глоссарии

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL