По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В первой части этого материала мы изучили базовую веб-архитектуру, а во второй разобрали структуру веб-приложения. Настало время более детально рассмотреть HTTP и REST.
Понимание HTTP имеет решающее значение для веб-разработчиков, поскольку оно облегчает поток информации в веб-приложении, позволяя улучшить взаимодействие с пользователями и повысить производительность сайта.
Что такое HTTP?
В клиент-серверной модели клиенты и серверы обмениваются сообщениями по принципу «запрос-ответ»: клиент отправляет запрос, а сервер возвращает ответ.
Хранить трек из этих сообщений сложнее, чем звучит, поэтому клиент и сервер придерживаются общего языка и набора правил. Этот «язык», или протокол, называется HTTP.
Протокол HTTP определяет синтаксис (формат и кодировку данных), семантику (значение, связанное с синтаксисом) и тайминг (скорость и последовательность). Каждый HTTP-запрос и ответ, которыми обмениваются клиент и сервер, рассматривается как одна HTTP-транзакция.
HTTP: Общая информация
Есть несколько вещей, которые стоит отметить про HTTP, прежде чем погрузиться в детали.
Во-первых, HTTP текстовый протокол, что означает, что сообщения, которыми обмениваются клиент и сервер, являются битами текста. Каждое сообщение содержит две части: заголовок и тело.
Во-вторых, HTTP - это протокол прикладного уровня, то есть это просто абстракционный уровень, который стандартизирует взаимодействие хостов. Сам HTTP не передает данные. Получение запроса и ответа от одной машины к другой по-прежнему зависит от базового протокола TCP/IP.
Напоминаем, что TCP/IP - это двухкомпонентная система, которая функционирует как фундаментальная «система управления» Интернета.
Наконец, возможно, вы видели протокол «HTTPS» в адресной строке браузера и интересовались, является ли HTTP тем же самым, что HTTP + «S». Если коротко, то HTTPS разновидность HTTP, с небольшой разницей.
Простой HTTP-запрос или ответ не зашифрован и уязвим для различных типов атак. HTTPS, напротив, является более безопасной протоколом связи, которая использует TLS/SSL шифрование для обеспечения безопасности.
SSL - это протокол безопасности, который позволяет клиенту и серверу взаимодействовать по сети безопасным способом - чтобы предотвратить сниффинг и подмену во время передачи сообщений по сети.
Клиент обычно указывает, требуется ли ему подключение TLS/SSL, используя специальный номер порта 443. Как только клиент и сервер соглашаются использовать TLS/SSL для обмена данными, они согласовывают соединение с отслеживанием состояния, выполняя так называемое «квитирование TLS». Затем клиент и сервер устанавливают секретные сеансовые ключи, которые они могут использовать для шифрования и дешифрования сообщений, когда они разговаривают друг с другом.
Многие крупные веб-сайты, такие как Google и Facebook, используют HTTPS - в конце концов, это то, что сохраняет ваши пароли, личную информацию и данные кредитных карт в безопасности.
Что такое API
HTTP: Углубляясь в детали
Теперь, вооружившись базовыми знаниями, погрузимся глубже в структуру HTTP.
Мы можем начать с посещения https://www.github.com, чтобы связаться с сервером GitHub. Если вы используете Chrome или Firefox с установленным расширением Firebug, вы можете подробно изучить HTTP-запрос, перейдя на вкладку «Сеть» или «Network». С открытой кладкой «Сеть», перейдите на сайт www.github.com, введя его в адресную строку, и вы должны увидеть что-то подобное:
Затем на левой панели щелкните по первому пути, «github.com.» Теперь вы должны увидеть следующее:
Заголовок запроса HTTP
Заголовки HTTP обычно содержат метаданные (данные о данных). Метаданные включают тип запроса (GET, POST, PUT или DELETE), путь, код состояния, тип содержимого, используемый браузер, cookie, текст сообщения (иногда) и многое другое.
Рассмотрим наиболее важные части заголовка на примере GitHub, начиная с раздела «Заголовки ответа»:
Request URL: https://github.com/ - Запрошенный URL-адрес
Request Method: GET - Тип используемого метода HTTP. В нашем случае наш браузер сказал: «Эй, сервер GitHub, я хочу ПОЛУЧИТЬ (GET) домашнюю страницу».
Status Code:200 OK - Стандартизированный способ информирования клиента о результате запроса. Код состояния 200 означает, что сервер успешно нашел ресурс и отправляет его вам.
Remote Address:192.30.252.129:443 - IP-адрес и номер порта веб-сайта GitHub, который мы посетили. Обратите внимание, что это порт номер 443 (это означает, что мы используем HTTPS вместо HTTP).
Content-Encoding: gzip - Кодировка ресурса, который мы получили обратно. В нашем случае сервер GitHub сообщает нам, что содержимое, которое он отправляет назад, сжато. Возможно, Github сжимает файлы, чтобы страница быстрее загружалась.
Content-Type: text/HTML; charset = utf-8 - Задает представление данных в теле ответа, включая тип и подтип. Тип описывает тип данных, в то время как подтип указывает конкретный формат для этого типа данных. В нашем случае, мы имеем текст, в формате HTML. Во второй части указывается кодировка символов для HTML-документа. Чаще всего это будет UTF-8, как и выше.
Есть также куча информации заголовка, которую клиент должен был отправить, чтобы сервер мог знать, как ответить. Посмотрите на раздел «Заголовки запросов» или «Headers»:
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36 - Программное обеспечение, которым пользуется пользователь. Иногда веб-сайт должен знать, с какого устройства он просматривается. Поэтому браузер отправляет эту последовательность User-Agent, которую сервер может использовать для определения того, что используется для доступа к веб-сайту
Accept-Encoding: gzip, deflate, sdch - Указывает кодировку содержимого, которую может обработать браузер. Мы видим, что указан gzip, и поэтому сервер Github смог отправить нам содержимое в формате gzip.
Accept-Language: en-US, en; q = 0.8 - Описывает язык, на котором должна отобразиться веб-страница. В нашем случае «en» означает английский.
Host: github.com - Описывает хост, на который мы идем
Cookie:_octo=GH1.1.491617779.1446477115; logged_in=yes; dotcom_user=iam-peekay; _gh_sess=somethingFakesomething FakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFakesomethingFake; user_session=FakesomethingFake somethingFakesomethingFakesomethingFake; _ga=9389479283749823749; tz = America% 2FLos_Angeles _ - Фрагмент текста, который веб-сервер может хранить на компьютере пользователя и впоследствии извлекать. Информация сохраняется как пара имя-значение. Например, одна из пар имя-значение, сохраненных GitHub для моего запроса, является «dotcom_user=iam-peekay,», которая сообщает GitHub, что мой userid – Iam-peekay.
Что теперь со всеми этими парами имя-значение?
Итак, у нас есть много пар имя-значение. Но как создаются эти пары имя-значение?
Каждый раз, когда браузер будет открывать веб-сайт, он будет искать на компьютере файл cookie, установленный веб-сайтом ранее.
Так что, при посещении www.github.com, браузер будет искать файл cookie, который GitHub сохранил на жестком диске компьютера пользователя. Если он найдет файл cookie, он отправит все пары имя-значение в заголовке запроса.
Веб-сервер GitHub теперь может использовать данные cookie различными способами, такими как рендеринг контента на основе сохраненных пользовательских предпочтений, подсчет количества времени, проведённого на сайте.
Если браузер не находит файл cookie - либо потому, что сайт никогда не посещался, либо пользователь заблокировал или удалил его - браузер не отправляет данные cookie.
В этом случае сервер GitHub создает новый идентификатор в качестве пары имя-значение, вместе с любыми другими необходимыми ему парами имя-значение, и отправляет его пользователю через заголовок HTTP. Получив данные, устройство хранит их на своем жестком диске.
Тело HTTP
Выше мы узнали, что сервер содержит большинство важных «метаданных» (данные о данных), которые необходимы для связи с клиентом.
Теперь поговорим о теле HTTP запроса.
Тело – это основная часть сообщения. В зависимости от типа запроса он может быть и пустым.
В нашем случае вы можете увидеть тело на вкладке «Response». Поскольку мы сделали запрос GET на www.github.com, тело содержит содержимое HTML-страницы для www.github.com.
Дополнительные упражнения
Надеюсь, такой разбор позволит вам лучше понять структуру HTTP. На практике вы можете просмотреть на другие ресурсы, запрашиваемые вашим браузером (изображения, файлы JavaScript и т.д.) при посещении www.github.com.
Теперь рассмотрим различные методы HTTP запросов, которые клиент может инициировать.
Методы HTTP
Команды или методы HTTP указывают серверу, что делать с данными, определенными по URL. URL-адреса всегда идентифицируют определенный ресурс. Когда клиент использует URL-адрес в сочетании с командой HTTP, это сообщает серверу, какое действие необходимо выполнить с указанным ресурсом.
Примеры URL-адресов:
GET http://www.example.com/users (получить всех пользователей)
POST http://www.example.com/users/a-unique-id (создание нового пользователя)
PUT http://www.example.com/comments/a-unique-id (обновить комментарий)
DELETE http://www.example.com/comments/a-unique-id (удалить комментарий)
Когда клиент делает запрос, он указывает тип запроса, используя одну из этих команд. Наиболее важными являются GET, POST, PUT и DELETE. Есть и другие методы, такие как HEAD и OPTIONS, но они используются редко, поэтому в данном материале мы пропустим их.
GET
GET является наиболее часто используемым методом. Он используется для чтения информации по данному URL-адресу с сервера.
Запросы GET доступны только для чтения, что означает, что данные никогда не должны быть изменены на сервере - сервер должен просто извлечь данные без изменений. Таким образом, запросы GET считаются безопасными операциями, поскольку сколько бы не вызывай его, ответ будет одинаковым.
Кроме того, запросы GET являются идемпотентными. Это означает, что отправка нескольких запросов GET на один и тот же URL-адрес должна привести к тому же эффекту, что и один запрос GET, поскольку запрос GET просто запрашивает данные с сервера, а не изменяет их.
Запросы GET отвечают кодом состояния 200 (ОК), если ресурс был успешно найден, и 404 (NOT FOUND), если ресурс не был найден. (Отсюда термин «404 page» для сообщений об ошибках при посещении несуществующих или неправильно набранных URL-адресов.)
POST
POST используется для создания нового ресурса, например, через форму регистрации. Функция POST используется при необходимости создания дочернего ресурса (например, нового пользователя) для какого-либо родительского ресурса (http://example.com/users). Родительский ресурс запроса на создание новой сущности определяется по URL-адресу, и сервер обрабатывает новый ресурс и связывает его с родительским ресурсом.
POST не является ни безопасным, ни идемпотентным. Это связано с тем, что выполнение двух или более идентичных запросов POST приведет к созданию двух новых идентичных ресурсов.
Запросы POST отвечают кодом состояния 201 (CREATED) вместе с заголовком местоположения со ссылкой на вновь созданный ресурс.
PUT
PUT используется для обновления ресурса, идентифицированного по URL, с использованием информации в теле запроса. PUT также может использоваться для создания нового ресурса. Запросы PUT не считаются безопасными операциями, поскольку они изменяют данные на сервере. Однако он является идемпотентным, поскольку несколько идентичных запросов PUT на обновление ресурса должны иметь тот же эффект, что и первый.
Запросы PUT отвечают кодом состояния 200 (OK), если ресурс был успешно обновлен, и 404 (NOT FOUND), если ресурс не был найден.
DELETE
DELETE используется для удаления ресурса, определенного по URL-адресу. Запросы DELETE являются идемпотентным, поскольку если УДАЛИТЬ ресурс, он будет удален, и даже если вы сделаете несколько идентичных запросов DELETE, результат будет одинаковым: удаленный ресурс.
Скорее всего, вы просто получите сообщение об ошибке 404, если отправить запрос DELETE для одного и того же ресурса несколько раз, поскольку сервер не сможет найти его после удаления.
Запросы DELETE отвечают кодом состояния 200 (OK) в случае успешного удаления или 404 (NOT FOUND), если не удалось найти удаляемый ресурс.
Все вышеуказанные запросы возвращают значение 500 (ВНУТРЕННЯЯ ОШИБКА СЕРВЕРА), если обработка завершается неуспешно и сервер выдаёт ошибку.
Что же такое REST?
Перейдем к последнему термину – REST.
Возможно, вы слышали термин RESTful application ранее. Важно понимать, что это означает, потому что, если вы используете HTTP для обмена данными между клиентом и сервером, полезно следовать рекомендациям REST. На самом деле, HTTP-методы, которые мы рассмотрели выше, не что иное, как часть REST.
REST расшифровывается как Representational State Transfer (Передача состояния представления). Это архитектурный стиль проектирования приложения.
Основная идея заключается в том, что для выполнения вызовов между машинами используется протокол «без состояния», «клиент-сервер», «кэшируемый» - и чаще всего этот протокол HTTP. В общем, REST это согласованный набор ограничений для проектирования приложения. Эти ограничения помогают сделать систему более производительной, масштабируемой, простой, изменяемой, видимой, портативной и надежной.
Полный список ограничений очень длинный, и вы можете прочитать об этом здесь. В этой статье остановимся на двух наиболее важных из них:
1. Унифицированный интерфейс - Uniform interface: это ограничение позволяет определить интерфейс между клиентом и сервером путь, чтобы упростить и разъединить архитектуру. Там написано, что:
Ресурсы должны быть идентифицируемыми в запросе (например, с помощью идентификаторов ресурсов в URI). Ресурс (например, данные в базе данных) - это данные, которые определяют представление ресурса (например, JSON, HTML). Ресурсы и представления ресурсов - это концептуально разные сущности - клиент взаимодействует только с представлением ресурсов.
Клиент должен иметь достаточно информации для управления ресурсами на сервере с помощью представления ресурса.
Каждое сообщение, которым обмениваются клиент и сервер, должно быть самоописательным и содержать информацию о том, как обрабатывать сообщение.
Клиенты должны отправлять данные о состоянии с использованием основного содержимого HTTP, заголовка HTTP-запроса, параметров запроса и URL-адреса. Серверы должны отправлять данные о состоянии с помощью тела HTTP, кодов ответов и заголовков ответов.
Примечание: Описанные выше команды HTTP составляют основную часть ограничения «унифицированного интерфейса», поскольку они представляют собой единообразные действия, которые происходят с ресурсами.
2. Отсутствие состояния - Stateless: это ограничение говорит о том, что все данные о состоянии, необходимые для обработки запроса клиента, должны содержаться в самом запросе (URL, параметры запроса, тело HTTP или заголовки HTTP), а сервер должен отправить все необходимые данные о состоянии клиенту через сам ответ (заголовки HTTP, код состояния и тело ответа HTTP).
Примечание: Состояние - или состояние приложения - это данные, необходимые серверу для выполнения запроса.
Это означает, что для каждого запроса мы пересылаем информацию о состоянии туда и обратно, так что сервер не должен поддерживать, обновлять и отправлять состояние.
Наличие системы без сохранения состояния делает приложения намного более масштабируемыми, потому что ни один сервер не должен беспокоиться о поддержании одного и того же состояния сеанса на протяжении нескольких запросов. Все необходимое для получения данных о состоянии доступно в самом запросе и ответе.
Заключение
HTTP далеко не прост. Но, как вы видите, это критически важный компонент отношений между клиентом и сервером.
Для создания RESTful приложений требуется по крайней мере базовое понимание HTTP. С таким багажом знаний, следующий проект для вас будет намного проще.
Если ты используешь модуль EndPoint Manager, о котором мы рассказывали в нашей предыдущей статье, или же другое решение auto-provisioning для автоматической настройки телефонных аппаратов на FreePBX, то эта статья для тебя!
В ней мы покажем универсальный способ для поиска и устранения проблем, которые могут возникнуть в процессе работы с решениями auto-provisioning, таких как EPM.
Как ты уже знаешь, принцип auto-provisioning заключается в том, что телефонный аппарат обращается на сервер, на котором для него уже подготовлен конфигурационный файл. Затем он скачивает его, применяет настройки и становится готовым к работе.
Сервер может работать по протоколам TFTP, FTP, HTTP и др. в зависимости от выбранного режима и протоколов, которые поддерживает аппарат.
Давайте рассмотрим типовую проблему, с которой мы можем столкнуться, при автоматической настройке телефонных аппаратов с помощью auto-provisioning на примере модуля EPM
Кейс
Допустим, мы сделали глобальные настройки для сервера TFTP и создали типовой шаблон для телефона Yealink SIP-T28P. Теперь мы пробуем назначить этот шаблон конкретному телефонному аппарату. Для этого, либо через модуль Extension, либо через Extension Mapping в самом EPM мы привязываем созданный шаблон к телефону по его MAC-адресу. Затем перезагружаем телефон и обнаруживаем что … он не получает настройки.
Для начала, проверим логи TFTP сервера и выясним, посылает ли телефонный аппарат какие-либо запросы. Для этого откроем CLI нашего сервера и дадим такую команду:
tail -f var/log/asterisk/messages | grep tftp
После того, как мы введём эту команду, мы будем в реальном времени получать записи из лога messages, относящиеся к сервису tftp.
Скорее всего, мы увидим там что-то типа:
Где:
192.168.2.57 - IP адрес телефонного аппарата;
1111ссссdddd.cfg - Конфигурационный файл, который телефонный аппарат запрашивает с сервера. 1111ссссdddd - MAC адрес телефонного аппарата;
Сообщение RRQ from 192.168.2.57 filename 1111ccccdddd.cfg означает, что телефон запрашивает с tftp сервера свой конфигурационный файл, а сообщение sending NAK (1, File not found) to 192.168.2.57 означает ответ сервера о том, что файл с таким именем не найден.
Давайте теперь проверим директорию tftpboot, где EPM хранит конфигурационный файлы для телефонов и проверим, есть ли там файл с именем 1111ccccdddd.cfg. Для этого в CLI даём такие команды:
cd /tftpboot
ls -la | grep 1111ccccdddd
Скорее всего, мы получим пустой вывод, а значит такого файла нет. В этом случае нужно ещё раз проверить, что телефон корректно привязан по MAC адресу к нужному шаблону через модуль Extension или Extension Mapping.
После чего, ещё раз проверьте директорию tftpboot на предмет конфигурационного файла своего телефонного аппарата по MAC адресу:
Атака MITM обычно выполняется во внутренней корпоративной сети. Злоумышленник использует этот тип атаки с целью перехвата конфиденциальной информации, которая передается между устройствами. Как вы понимаете, «человек посередине» (Man-in-the-middle) — это просто указание на то, где находится злоумышленник. Он располагается между устройством (устройствами) жертвы и получателем. Машина злоумышленника используется для перехвата всех сообщений между жертвой получателем.
Большинство пользователей не знают о незащищенных сетевых протоколах, которые используются для передачи их сообщений от источника к получателю. Эти незащищенные протоколы передают сообщения в виде обычного текста, позволяя злоумышленнику перехватить и просмотреть фактические данные.
Чтобы лучше понять, как работает MITM-атака, давайте посмотрим на следующий рисунок:
Как показано на предыдущем рисунке, если PC1 захочет отправить какие-либо данные через Интернет, они отправляются на шлюз по умолчанию, которым является R1. Кроме того, для всех коммуникаций, которые происходят в локальной сети, устройства пересылают сообщения, используя MAC-адрес назначения, найденный в кадре, а не IP-адрес назначения. IP-адрес назначения важен только тогда, когда сообщение должно быть переадресовано за пределы локальной сети, например, в другую подсеть или удаленную сеть. Следовательно, когда PC1 захочет отправить сообщение через Интернет, он пересылает сообщение на MAC-адрес назначения, известный как BBBB.BBBB.BBBB, который принадлежит R1. Когда R1 должен пересылать какие-либо сообщения (пакеты) на PC1, он будет использовать MAC-адрес назначения AAAA.AAAA.AAAA. Таким образом, изначально сообщения на машину злоумышленника не отправляются.
Злоумышленник может использовать уязвимость в протоколе разрешения адресов (Address Resolution Protocol - ARP), чтобы гарантировать, что все сообщения, которыми обмениваются между PC1 и R1, отправляются через его машину, как показано на следующем рисунке:
Протокол ARP работает между уровнем 2 (канальный уровень) и уровнем 3 (уровень Интернета) стека протоколов TCP/IP. Он предназначен для преобразования IP-адреса в MAC-адрес потому, что коммутаторы не могут считывать адресацию уровня 3, например IP-адресацию внутри пакета. Коммутаторы могут только читать MAC-адреса и пересылать кадры на основе MAC-адреса назначения, найденного в заголовке кадра уровня 2. По этой причине ARP необходим в любой сети.
Когда устройство, такое как PC1, не знает MAC-адрес целевого хоста, такого как R1, оно будет отправлять ARP-запрос в сеть, спрашивая, у кого есть MAC-адрес для конкретного пункта назначения, как показано на следующем рисунке:
Запрос ARP отправляется на все устройства. Только устройство, имеющее IP-адрес назначения, ответит ARP-ответом, содержащим его MAC-адрес, как показано на следующем рисунке:
Затем MAC-адрес временно сохраняется в кэше ARP исходного устройства, PC1. Исходное устройство затем вставляет MAC-адрес назначения в заголовок кадра уровня 2 перед размещением сообщения в сети. Коммутатор, который получает сообщение от PC1, проверяет MAC-адрес назначения, найденный в заголовке уровня 2, и пересылает сообщение на хост назначения.
Злоумышленник может обманом заставить PC1 поверить в то, что он — это R1, а также заставить R1 думать, что он — это PC1. Злоумышленник может притвориться PC1 для R1 и наоборот. С технической точки зрения злоумышленник выдает себя за другую машину в сети — это называется подменой MAC-адресов. Кроме того, злоумышленник отправит безвозмездное сообщение ARP, содержащее ложное сопоставление IP-адресов и MAC-адресов. Каждое сообщение создается специально для PC1 и R1. Безвозмездное сообщение ARP — это ответ, который не был инициирован запросом ARP.
Другими словами, это когда одно устройство отправляет обновление ARP без запроса. Это позволяет злоумышленнику выполнять атаку с подменой ARP и отправлять ложные сообщения ARP устройствам, заставляя их вставлять неверные сопоставления IP-адресов в MAC-адреса в их кэш ARP. Это известная уязвимость, обнаруженная в ARP и TCP/IP.
На следующем рисунке показано, как злоумышленник отправляет безвозмездное сообщения ARP на PC1 и R1:
Это приведет к тому, что весь трафик между PC1 и R1 будет отправлен на атакующую машину, что приведет к атаке MITM.
На следующем скриншоте показан пример инструмента тестирования на проникновение, известного как arpspoof, который используется для отправки бесплатных сообщений ARP на хост-устройства в сети для создания атак MITM:
Как показано на предыдущем скриншоте, инструмент постоянно заполняет компьютер жертвы (10.10.10.11) и шлюз по умолчанию (10.10.10.1) ложными сведениями о сопоставлении IP-адресов с MAC-адресами. На следующем рисунке показан захват Wireshark, отображающий ложные сообщения ARP, отправляемые по сети:
Обратите внимание, как Wireshark выделил сообщения желтым цветом как подозрительные для изучения. Существует множество функций безопасности уровня 2, которые уже предварительно загружены в коммутаторы Cisco IOS, и все они могут быть реализованы специалистом по безопасности. Вот некоторые из этих функций безопасности:
Port security: Port security используется для фильтрации неавторизованных MAC-адресов от входа в интерфейс коммутатора.
Dynamic ARP Inspection (DAI): DAI проверяет информацию об адресе IP-to-MAC, найденную в пакете, поступающем в коммутатор. Если будет найдено поддельное сообщение, коммутатор отклонит его, чтобы защитить сеть уровня 2.
IP Source Guard: это еще одна функция безопасности, которая позволяет устройствам Cisco разрешать в сети только IP-адреса доверенных источников, предотвращая атаки с подменой IP-адресов.