Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы и средства передачи данных в автоматизированных системах. Учебное пособие
.pdf
4.6. Протоколы верхнего уровня
131
должны быть обновлены. В зависимости от выполненных действий могут
различаться и ответы от сервера, например если объект создан, то возвращается 201 Created, если обновлен, то 200 OK.
Обычно при написании сервера, в ответ посылается статус и JSON
пакет либо с идентификатором созданного/измененного объекта, либо статус и сам объект с уже измененными полями.
Фундаментальное различие методов POST и PUT заключается в по-
нимании предназначений URI ресурсов. Метод POST предполагает, что по
указанному URI будет производиться обработка «впервые» передаваемого
клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует существующему объекту, который
находится по данному URI ресурсу.
Сообщения ответов сервера на метод PUT также не кэшируются.
Метод PATCH
Аналогично PUT, но применяется только к фрагменту ресурса.
Метод DELETE
Удаляет указанный ресурс.
Метод TRACE
Возвращает полученный запрос так, что клиент может увидеть, какую
информацию промежуточные серверы добавляют или изменяют в запросе.
Метод CONNECT
Преобразует соединение запроса в прозрачный TCP/IP-туннель,
обычно чтобы содействовать установлению защищённого SSL-соединения
через нешифрованный прокси.
Рассмотрим далее классические коды состояний, которые может отправлять сервер в ответ на соответствующие запросы разных типов.
Напомним, что коды состояния – это просто трехзначное число,
например 200, 302, 404, 500 и так далее.
Множество этих чисел разделяется по первой (крайней левой) цифре
на пять основных классов (от 1хх до 5хх):
1) Информация.
2) Успешное завершение.
3) Перенаправление.
Глава 4. Основы применения компьютерных сетей в автоматизированных…
132
4) Ошибка клиента.
5) Ошибка сервера.
Код состояния всегда является частью первой строки ответа от сер-
вера. За ним часто следует пояснение произошедшего события в виде
строки текста. Например: 200 ОК или 201 Element Created.
Чаще всего так отправляются статусы ошибок, например:
404 Database element does not exists
По этим кодам клиент узнаёт о результатах выполнения его запроса
и решает, что же ему делать дальше.
Давайте рассмотрим основные коды и примеры их применения.
Таблица 1
Основные коды HTTP статусов
Коды
1xx
Информационные
сообщения
Информирование о процессе передачи.
Клиент должен принять ответ с таким статусом как
обычный ответ. Сообщения от сервера содержат
только стартовую строку ответа и, если требуется,
несколько специфичных для ответа полей заголовка.
Примеры популярных ответов:
100 Continue («продолжай»);
101 Switching Protocols («переключение
протоколов»);
102 Processing («идёт обработка»);
103 Early Hints («ранняя метаинформация»);
Коды
2xx
Успех
Информирование о случаях успешной обработки
запроса клиента.
Сервер может ещё передать заголовки и тело
сообщения вместе со статусом.
Примеры популярных ответов:
200 OK («хорошо»);
201 Created («создано»);
202 Accepted («принято»);
204 No Content («нет содержимого»);
Коды
3xx
Перенаправление
Сообщает клиенту, что для успешного выполнения
операции необходимо сделать другой запрос, по-другому URI.
Адрес, по которому клиенту следует произвести
запрос, сервер указывает в заголовке Location.
Примеры популярных ответов:
301 Moved Permanently («перемещено навсегда»);
4.6. Протоколы верхнего уровня
133
Продолжение табл. 1
302 Moved Temporarily («перемещено временно»);
304 Not Modified («не изменялось»)[2][7];
305 Use Proxy («использовать прокси»)[2][7];
307 Temporary Redirect («временное
перенаправление»);
308 Permanent Redirect («постоянное
перенаправление»).
Коды
4xx
Ошибка клиента
Указание ошибок со стороны клиента.
При использовании всех методов, кроме HEAD,
сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
Примеры популярных ответов:
400 Bad Request («неправильный, некорректный
запрос»);
401 Unauthorized («не авторизован»);
402 Payment Required («необходима оплата»);
403 Forbidden («запрещено»);
404 Not Found («не найдено»);
405 Method Not Allowed («метод не
поддерживается»);
406 Not Acceptable («неприемлемо»);
408 Request Timeout («истекло время ожидания»);
409 Conflict («конфликт»);
410 Gone («удалён»);
413 Payload Too Large («полезная нагрузка
слишком велика»);
415 Unsupported Media Type («неподдерживаемый
тип данных»);
422 Unprocessable Entity («необрабатываемый
экземпляр»);
423 Locked («заблокировано»);
429 Too Many Requests («слишком много
запросов»);
Коды
5xx
Ошибка сервера
Информирование о случаях неудачного
выполнения операции по вине сервера.
Для всех ситуаций, кроме использования метода
HEAD, сервер должен включать в тело сообщения
объяснение, которое клиент покажет пользователю.
Примеры популярных ответов:
500 Internal Server Error («внутренняя ошибка
сервера»);
501 Not Implemented («не реализовано»);
Глава 4. Основы применения компьютерных сетей в автоматизированных…
134
Окончание табл. 1
502 Bad Gateway («плохой, ошибочный шлюз»);
503 Service Unavailable («сервис недоступен»);
504 Gateway Timeout («шлюз не отвечает»);
507 Insufficient Storage («переполнение
хранилища»);
520 Unknown Error («неизвестная ошибка»);
522 Connection Timed Out («соединение не
отвечает»).
Конечно, мы перечислили не все существующие коды и статусы
HTTP, но привели самые популярные, которые часто используются на
практике при разработке веб-приложений.
Как уже говорилось выше, сам текст сообщения можно заменять
при формировании ответа от сервера, делая его более осмысленным (вербальным).
Теперь рассмотрим более подробно заголовки HTTP пакетов, в которых передается важная информация для сервера.
Заголовки HTTP или HTTP headers – это просто дополнительные
строки в HTTP-сообщении, которые представляют собой пару «ключзначение».
Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.
Рассмотрим пример заголовков:
GET /tutorials/other/top-20-mysql-best-practices/ HTTP/1.1
Host: code.tutsplus.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120
Pragma: no-cache
Cache-Control: no-cache
4.6. Протоколы верхнего уровня
135
В ответ на данный запрос клиент получает ответ, который также со-
провождается заголовком.
Эта пара информационных пакетов называется:
1) Request headers или «заголовок запроса» – передаётся только от
клиента на сервер.
2) Response headers или «заголовок ответа» – передаётся только от
сервера клиенту.
Также можно выделить два дополнительных типа заголовков:
1) General Headers или «основные заголовки» – могут включаться в
любое сообщение клиента и сервера.
2) Entity Headers «заголовки сущности» – сопровождают каждую
сущность сообщения.
Именно в таком порядке рекомендуется посылать заголовки по-
лучателю.
Все необходимые для функционирования HTTP заголовки описаны
в соответствующих разделах стандартов.
Следует помнить, что если не хватает существующих «стандарт-
ных» заголовков, то можно спокойно вводить свои.
К имени такого дополнительного заголовка следует добавить пре-
фикс «X-» для избежания конфликта имён с возможно существующими.
Некоторые разработчики используют свои индивидуальные пре-
фиксы, так как текст ключа заголовка будет обрабатываться не стандартными средствами сервера, а бизнес-логикой приложения. Например,
можно добавить в заголовки запроса или ответа такие поля как: MyCustomRequest и MyCustom-Response.
Рассмотрим далее тело HTTP сообщения.
Тело сообщения также является важным элементом обмена дан-
ными в клиент-серверной архитектуре автоматизированных и информационных систем.
Именно в теле сообщения передается вся информационная «нагрузка». Если тело HTTP-сообщения или message body присутствует в пакете, то оно используется для передачи некоторого информационного
объекта, прямо или косвенно связанного с запросом или ответом.
Глава 4. Основы применения компьютерных сетей в автоматизированных…
136
Присутствие тела сообщения в запросе определяется по добавленному полю заголовка Content-Length, Content-Type или Transfer-Encoding и
определяется стандартом и типом самого сообщения.
В данной главе мы рассмотрели базовый вариант обмена данными в
клиент-серверной архитектуре. Далее мы перейдем к другим аспектам организации обмена информацией в информационных системах – аспектам
безопасной передачи и защиты данных.
4.6. Протоколы верхнего уровня
137
ГЛАВА 5
ЗАЩИТА ПЕРЕДАЧИ ДАННЫХ
В КОМПЬЮТЕРНЫХ СЕТЯХ
В данной главе мы рассмотрим методы защиты информации в авто-
матизированных и информационных системах. В частности, мы проведем
анализ методов защиты данных на стороне клиента и на стороне сервера.
Дополнительно будет проведен анализ методов защиты соединения
для передачи информации в локальных и глобальных сетях и будут описаны основные криптографические протоколы безопасности.
5.1. Методы защиты данных на стороне клиента
Для начала определимся с задачей защиты данных на стороне клиента. Под такой защитой мы подразумеваем невозможность (ну или хотя
бы высокую сложность) для злоумышленника получить конфиденциальные данные клиента [7].
Как уже говорилось выше, в наши дни всё больше программ переводятся в так называемый «веб-ориентированный» вид, т.е. используется
принцип клиент-сервер, что позволяет хранить данные удалённо и получать к ним доступ через тонкий клиент или браузер.
Одновременно с удобством использования остро встаёт вопрос о защищённости этих данных. Конфиденциальная информация может стать
доступна другим людям несколькими путями.
Во-первых, к пользователю могут быть применены физические меры.
Во-вторых, при передаче данные могут быть перехвачены различ-
ными снифферами.
В-третьих, на сервер могут быть произведены хакерские атаки, что
позволит злоумышленникам похитить информацию, либо недобросовестный администратор сервера воспользуется ею в личных целях.
Первое, что приходит на ум для защиты данных клиента, это обеспечение невозможности эти данные перехватить или модифицировать.
А это можно сделать, например, при помощи шифрования.
В самом простом случае мы можем ориентироваться на три типа информации, которая переходит между клиентом и сервером:
Глава 5. Защита передачи данных в компьютерных сетях
138
1) Текстовая информация.
2) Файлы.
3) Изображения и другие файлы.
Для защиты текста достаточно его собрать на стороне клиента, за-
шифровать и отправить на сервер.
Обратный процесс происходит на стороне сервера: информация получается, расшифровывается, обрабатывается, затем сервер шифрует данные и отправляет ответ на клиент. Ответ будет дешифроваться уже на стороне клиента.
Работа с файлами и изображениями похожа на работу с текстом,
только шифрование и расшифровка должна выполняться не над текстом, а
над файловыми потоками. Кроме того, в этот процесс включается еще и
этап преобразования содержимого файлов в формат Base64.
Можно самому реализовывать такой процесс при помощи программ
(например, для работы в современных браузерах применяются HTML5, Ja-
vaScript и XmlHttpRequest Level 2) или при помощи фреймворков.
Например, клиентская библиотека службы хранилища Azure для
.NET поддерживает шифрование данных в клиентских приложениях перед
их отправкой в службу хранилища Azure и их расшифровку во время скачивания клиентом. Библиотека также поддерживает интеграцию с хранилищем ключей Azure для управления ключами учетной записи хранения.
Этот процесс называется «шифрование конвертным методом» и происходит следующим образом.
1) Клиентская библиотека хранилища Azure создает ключ шифрова-
ния содержимого (CEK), который является симметричным ключом для однократного использования.
2) Данные пользователя шифруются с помощью этого ключа CEK.
3) Ключ CEK, в свою очередь, шифруется с помощью ключа шифро-
вания ключа KEK. KEK определяется идентификатором ключа и может
быть парой асимметричных ключей или симметричным ключом. Им можно
управлять локально, а также хранить его в хранилище ключей Azure.
4) Сама клиентская библиотека хранилища не имеет доступа к ключу
KEK. Библиотека вызывает алгоритм шифрования ключа, который обеспечивается хранилищем ключей.
5.1. Методы защиты данных на стороне клиента
139
5) Пользователи могут при необходимости использовать настраивае-
мые поставщики для шифрования и расшифровки ключа.
6) Зашифрованные данные затем передаются в службу хранилища
Azure. Зашифрованный ключ вместе с дополнительными метаданными
шифрования хранится как метаданные (в большом двоичном объекте) или
вставляется в зашифрованные данные (сообщения в очереди и табличные
сущности).
Расшифрование серверных сообщений конвертным методом проис-
ходит следующим образом.
1) Клиентская библиотека предполагает, что пользователь управляет
ключом шифрования ключа KEK локально или через хранилище ключей
Azure. Пользователь может не знать, какой именно ключ использовался для
шифрования. Вместо этого достаточно настроить и использовать сопоставитель ключей, который будет распознавать разные идентификаторы ключей.
2) Клиентская библиотека скачивает зашифрованные данные вместе
с данными шифрования, которые хранятся в службе.
3) Зашифрованный ключ шифрования содержимого CEK расшифро-
вывается с помощью ключа шифрования ключа KEK. Клиентская библиотека не имеет доступа к ключу KEK. Она просто вызывает пользовательский алгоритм или алгоритм расшифровки поставщика хранилища ключей.
4) Затем ключ шифрования содержимого CEK используется для рас-
шифровки зашифрованных пользовательских данных.
Естественно, что этот процесс является примером и конвертный ме-
тод может быть реализован не только на базе технологии .NET. Целью данного примера было показать общий подход и продемонстрировать тот
факт, что проблема защиты данных на стороне клиента настолько важна,
что даже такие мировые лидеры в области разработки программного обеспечения как Microsoft, давно включили эти инструменты в стандартный
набор разработки веб-приложений.
Также существует чуть более простой метод защиты данных на сто-
роне клиента – это защита от CSRF.
CSRF – это межсайтовая подделка запроса, т.е. вид атаки на клиента,
при которой, если жертва заходит на сайт, созданный злоумышленником,
вместо оригинального ресурса, то от лица этой жертвы тайно отправляется
запрос на другой сервер (например, на сервер платёжной системы),
Глава 5. Защита передачи данных в компьютерных сетях
140
осуществляющий некую вредоносную операцию (например, перевод денег
на счёт злоумышленника).
Для осуществления данной атаки жертва должна быть аутентифици-
рована на том сервере, на который отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, которое не может быть проигнорировано или подделано атакующим скриптом.
Защита от CSRF выполняется следующим образом: в каждый запрос,
которым можно что-то поменять на сервере, вставляется специальный
ключ или токен.
Токен должен удовлетворять следующим требованиям:
1) для каждой операции должен генерироваться свой уникальный
токен;
2) токен работает только один раз, потом он становится недействи-
тельным;
3) токен должен иметь размер, устойчивый к простому подбору за ра-
зумное время;
4) токен должен быть сгенерирован криптографически стойким гене-
ратором псевдослучайных чисел;
5) токен должен иметь ограниченное время жизни.
По сути, сейчас существует всего три основных метода использования токенов в защите:
1) Synchronizer Tokens (Statefull).
2) Double Submit Cookie (Stateless).
3) Encrypted Token (Stateless).
Говоря простыми словами, Synchronizer Tokens – это самый простой
подход, использующийся повсеместно.
Он требует хранения токена на стороне сервера. Суть метода такова:
1) При старте сессии на стороне сервера генерируется токен.
2) Токен кладется в хранилище данных сессии (т.е. сохраняется на
стороне сервера для последующей проверки).
3) В ответ на запрос (который стартовал сессию) клиенту возвраща-
ется токен.
4) Если рендеринг происходит на сервере, то токен может возвра-
щаться внутри HTML, как, например, одно из полей формы, или внутри
<meta> тега.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]