По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
@media screen and (max-width: 736px){
.video-container {
position: relative;
padding-bottom: 56.25%;
padding-top: 30px;
height: 0;
overflow: hidden;
}
.video-container iframe {
position: absolute;
top:0;
left: 0;
width: 100%;
height: 100%;
}}
Мы живем в мире, в котором побеждают быстрые и общительные. Если говорить о приложениях, то достичь двух этих целей можно через WebSocket.
WebSocket часто называют высокопроизводительным протоколом передачи данных, и он необходим для создания канала связи между клиентом и сервером.
Так что же это значит, и какую роль WebSocket играет в безопасности API? Обо всем этом поговорим в статье.
Что такое WebSocket?
Исходя из общепринятого названия, WebSocket – это дуплексный протокол, который часто используется в клиент-серверном канале связи. Он считается двунаправленным, т.е. передача данных выполняется от клиента к серверу и наоборот.
Соединение, установленное с помощью WebSocket, сохраняется до тех пор, пока его не прервет любой из участников. Если одна сторона разрывает соединение, то другая не сможет продолжить коммуникацию, поскольку соединение автоматически разрывается для обоих участников.
Чтобы инициировать соединение, WebSocket нужна поддержка со стороны HTTP. Это основа современной разработки веб-приложений, с непрерывным потоком данных и несинхронизированным трафиком.
Для чего нужен WebSocket и в каких случаях от него лучше отказаться?
WebSocket – это необходимый инструмент для клиент-серверного взаимодействия. Поэтому важно четко понимать его возможности и варианты использования.
WebSocket подходит, если вы:
Разрабатываете веб-приложения реального времени
Самый популярный вариант использования WebSocket – это разработка приложений реального времени с постоянным отображением данных на стороне клиента. Внутренний сервер постоянно отправляет эти данные, а WebSocket реализует их бесперебойную передачу или отправку через уже открытое соединение. Использование WebSocket ускоряет передачу данных и улучшает производительность приложения.
Реальным примером использования такой возможности WebSocket является сайт по торговле биткоинами. WebSocket помогает обрабатывать данные, которые внутренний сервер отправляет клиенту.
Создаете чат-приложения
Разработчики чат-приложений выбирают WebSocket для выполнения таких операций, как одноразовый обмен и публикация/трансляция сообщений. Для отправки/получения сообщений используется одно и то же WebSocket соединение, поэтому такая коммуникация считается простой и быстрой.
Работаете над игровым приложением
При разработке игрового приложения крайне важно, чтобы сервер постоянно получал данные, не запрашивая обновления пользовательского интерфейса. WebSocket позволяет достичь этой цели без вмешательства в интерфейс приложения.
Теперь, когда стало ясно, для каких целей можно использовать WebSocket, стоит поговорить о том, когда стоит присмотреться к другим решениям.
WebSocket – далеко не самый лучший вариант, когда вам нужно получить старые данные, либо же данные требуются только для разовой обработки. В таких случаях лучше ограничиться HTTP-протоколами.
WebSocket или HTTP?
Поскольку для связи между приложениями используется и HTTP, и WebSocket, люди часто путаются и не могут определиться. Ниже приведено подробное описание каждого из вариантов.
Как уже говорилось, WebSocket является двунаправленным и фреймовым протоколом. HTTP – это, наоборот, однонаправленный протокол, работающий над TCP-протоколом.
Протокол WebSocket поддерживает непрерывную передачу данных, поэтому часто используется в разработке приложений реального времени. HTTP не зависит от состояния и используется для создания RESTful-приложений.
Передача данных в WebSocket происходит в обе стороны, так что он считается довольно быстрым протоколом. HTTP проигрывает по скорости WebSocket, поскольку в этом протоколе соединение устанавливается с одной стороны.
WebSocket использует унифицированное TCP-соединение. Пока один из участников не разорвет это соединение, оно будет активным. HTTP создает разные соединения для разных запросов. После выполнения запроса соединение разрывается автоматически.
Как устанавливается WebSocket-соединение
Процесс начинается с «рукопожатия» (handshake), в котором используется новая схема ws или wss. Если проводить параллель, то это примерно то же, что HTTP и защищенный протокол HTTP (HTTPS).
В этой схеме клиенты и серверы следуют стандартному протоколу подключения WebSocket. Установка WebSocket-соединения начинается с дополнения HTTP-запроса несколькими заголовками: Connection: Upgrade, Upgrade: WebSocket, Sec-WebSocket- Key и т.д..
Соединение устанавливается в следующие этапы:
1. Запрос
Заголовок Connection: Upgrade указывает на WebSocket-рукопожатие, а в Sec-WebSocket-Key содержится случайное значение в кодировке Base64. Это значение произвольно генерируется во время каждого WebSocket-рукопожатия. Частью запроса также является и заголовок ключа.
Все вышеперечисленные заголовки образуют GET HTTP-запрос. Он выглядит примерно так:
GET ws://websocketexample.com:8181/ HTTP/1.1
Host: localhost:8181
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: b6gjhT32u488lpuRwKaOWs==
В Sec-WebSocket-Version отмечается версия WebSocket-протокола, которой может пользоваться клиент.
2.Ответ
В заголовок ответа Sec-WebSocket-Accept попадает значение, отправленное в заголовке запроса Sec-WebSocket-Key. Ответ привязан к спецификации протокола и активно используется для устранения вводящей в заблуждение информации. Другими словами, такая структура улучшает безопасность API и блокирует некорректно настроенные сервера от создания ошибок при разработке приложения.
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: rG8wsswmHTJ85lJgAE3M5RTmcCE=
WebSocket-протокол
Протокол WebSocket – это тип фреймового протокола, который включает в себя различные дискретные блоки с данными. Для корректного функционирования в нем развертывается информационная часть пакета, тип фрейма и длина полезной нагрузки. Чтобы понять принципы работы WebSocket, необходимо разобраться, из чего он состоит. Ключевые элементы перечислены ниже.
Бит FIN – это основная часть WebSocket. Он генерируется автоматически при создании подключения.
Биты RSV1, RSV2, RSV3 – эти биты зарезервированы для дополнительных возможностей.
Opcode – это часть каждого фрейма; объясняет процесс интерпретации данных полезной нагрузки для отдельного фрейма. Примеры распространенных значений: 0x00, 0x0, 0x02, 0x0a, 0x08 и т.д.
БитMask активируется, когда один бит задан как 1.
Для всех данных полезной нагрузки в WebSocket используется случайный ключ, выбранный клиентом. Ключ маски в сочетании с данными полезной нагрузки помогает обмениваться этими данными через операцию XOR. Это очень важно для безопасности API приложения, поскольку маскирование предотвращает неправильную интерпретацию кэша и т.н. «отравленный кэш».
Разберем эти ключевые элементы подробнее.
Длина полезной нагрузки
Используется для кодирования общей длины данных полезной нагрузки в WebSocket. Отображается, когда закодированная длина данных меньше 126 битов. Если длина данных больше 126 битов, то для описания длины полезной нагрузки используются дополнительные поля.
Ключ маски
Каждый фрейм, который клиент отправляет на сервер, маскируется 32-битным значением. Отображается, когда бит маски равен 1. Если бит маски равен 0, то ключ маски также будет нулевым.
Данные полезной нагрузки
Все случайные данные приложения и расширения считаются данными полезной нагрузки. Эти данные используются клиентом и серверами для согласования и в процессе первых рукопожатий.
Заключение
WebSocket – это обновленный, быстрый и простой протокол для установки постоянной клиент-серверной связи. WebSocket гарантирует неразрывность подключения и высокую безопасность данных, даже при непрерывной передаче данных. Использование WebSocket предельно упрощает разработку приложений в режиме реального времени. В ряде случаев WebSocket проявляет себя лучше, чем HTTP, поскольку поддерживает дуплексную связь (например: сайты фондовой биржи, онлайн-игры, приложения для биткоинов, службы обмена сообщениями).
WebSocket стал настоящим кладезем полезных возможностей при разработке. Он улучшает безопасность API и поддерживает множество ресурсов (после подключения к внешним библиотекам). Попробуйте заменить свои обычные протоколы обмена данными на WebSocket и оцените его преимущества.
Почитайте предыдущую статью про криптографический обмен ключами.
Предположим, вы хотите отправить большой текстовый файл или даже изображение, и позволить получателям подтвердить, что он исходит именно от вас. Что делать, если рассматриваемые данные очень большие? Или что, если данные нужно сжать для эффективной передачи? Существует естественный конфликт между криптографическими алгоритмами и сжатием. Криптографические алгоритмы пытаются произвести максимально случайный вывод, а алгоритмы сжатия пытаются воспользоваться преимуществом неслучайности данных для сжатия данных до меньшего размера. Или, возможно, вы хотите, чтобы информация была прочитана кем-либо, кто хочет ее прочитать, что означает, что не нужно ее шифровать, но вы хотите, чтобы получатели могли проверить, что вы ее передали.
Криптографические хэши предназначены для решения этих проблем. Возможно, вы уже заметили по крайней мере одно сходство между идеей хеширования и криптографического алгоритма. В частности, хэш предназначен для получения очень большого фрагмента данных и создания представления фиксированной длины, поэтому на выходе для широкого диапазона входных данных очень мало конфликтов. Это очень похоже на концепцию максимально близкого к случайному выходу для любого ввода, необходимого для криптографического алгоритма. Еще одно сходство, о котором стоит упомянуть, заключается в том, что хэш-алгоритмы и криптографические алгоритмы работают лучше с очень редко заполненным входным пространством.
Криптографический хеш просто заменяет обычную хеш-функцию криптографической функцией. В этом случае хэш может быть вычислен и отправлен вместе с данными.
Криптографические хэши могут использоваться либо с системами с симметричными ключами, либо с системами с открытым ключом, но обычно они используются с системами с открытым ключом.
Сокрытие информации о пользователе
Возвращаясь к начальным статьям, еще одна проблема безопасности - это исчерпание данных. В случае отдельных пользователей исчерпание данных можно использовать для отслеживания того, что пользователи делают, пока они находятся в сети (а не только для процессов). Например:
Если вы всегда носите с собой сотовый телефон, можно отслеживать перемещение Media Access Control (MAC), когда он перемещается между точками беспроводного подключения, чтобы отслеживать ваши физические перемещения.
Поскольку большинство потоков данных не симметричны - данные проходят через большие пакеты, а подтверждения передаются через небольшие пакеты, наблюдатель может обнаружить, когда вы выгружаете и скачиваете данные, и, возможно, даже когда вы выполняете небольшие транзакции. В сочетании с целевым сервером эта информация может дать хорошую информацию о вашем поведении как пользователя в конкретной ситуации или с течением времени. Этот и многие другие виды анализа трафика могут выполняться даже для зашифрованного трафика.
Когда вы переходите с веб-сайта на веб-сайт, наблюдатель может отслеживать, сколько времени вы тратите на каждый из них, что вы нажимаете, как вы перешли на следующий сайт, что вы искали, какие сайты вы открываете в любое время и т. д. информация может многое рассказать о вас как о личности, о том, чего вы пытаетесь достичь, и о других личных факторах.
Рандомизация MAC-адресов
Institute of Electrical and Electronic Engineers (IEEE) первоначально разработал адресное пространство MAC-48 для назначения производителями сетевых интерфейсов. Эти адреса затем будут использоваться "как есть" производителями сетевого оборудования, поэтому каждая часть оборудования будет иметь фиксированный, неизменный аппаратный адрес. Этот процесс был разработан задолго до того, как сотовые телефоны появились на горизонте, и до того, как конфиденциальность стала проблемой.
В современном мире это означает, что за одним устройством можно следить независимо от того, где оно подключено к сети. Многие пользователи считают это неприемлемым, особенно потому, что не только провайдер может отслеживать эту информацию, но и любой, кто имеет возможность прослушивать беспроводной сигнал. Один из способов решить эту проблему-позволить устройству регулярно менять свой MAC-адрес, даже, возможно, используя другой MAC-адрес в каждом пакете. Поскольку сторонний пользователь (прослушиватель) вне сети провайдера не может "угадать" следующий MAC-адрес, который будет использоваться любым устройством, он не может отслеживать конкретное устройство. Устройство, использующее рандомизацию MAC-адресов, также будет использовать другой MAC-адрес в каждой сети, к которой оно присоединяется, поэтому оно не будет отслеживаться в нескольких сетях.
Существуют атаки на рандомизацию MAC-адресов, в основном сосредоточенные вокруг аутентификации пользователя для использования сети. Большинство систем аутентификации полагаются на MAC-адрес, поскольку он запрограммирован в устройстве, чтобы идентифицировать устройство и, в свою очередь, пользователя. Как только MAC-адрес больше не является неизменным идентификатором, должно быть какое-то другое решение. Места, где рандомизация MAC-адресов может быть атакована, - это
Время (timing): если устройство собирается изменить свой MAC-адрес, оно должно каким-то образом сообщить другому абоненту беспроводного соединения об этих изменениях, чтобы канал между подключенным устройством и базовой станцией мог оставаться жизнеспособным. Должна быть какая-то согласованная система синхронизации, чтобы изменяющийся MAC-адрес мог продолжать обмен данными при изменении. Если злоумышленник может определить, когда произойдет это изменение, он сможет посмотреть в нужное время и обнаружить новый MAC-адрес, который принимает устройство.
Порядковые номера (Sequence numbers): как и во всех транспортных системах, должен быть какой-то способ определить, все ли пакеты были получены или отброшены. Злоумышленник может отслеживать порядковые номера, используемые для отслеживания доставки и подтверждения пакетов. В сочетании с только что отмеченной атакой по времени это может обеспечить довольно точную идентификацию конкретного устройства при изменении MAC-адреса.
Отпечатки информационных элементов (Information element fingerprints): каждое мобильное устройство имеет набор поддерживаемых функций, таких как установленные браузеры, расширения, приложения и дополнительное оборудование. Поскольку каждый пользователь уникален, набор приложений, которые он использует, также, вероятно, будет довольно уникальным, создавая "отпечаток" возможностей, которые будут сообщаться через информационный элемент в ответ на зонды от базовой станции.
Отпечатки идентификатора набора услуг (SSID): каждое устройство хранит список сетей, к которым оно может подключиться в настоящее время, и (потенциально) сетей, которые оно могло достичь в какой-то момент в прошлом. Этот список, вероятно, будет довольно уникальным и, следовательно, может выступать в качестве идентификатора устройства.
Хотя каждый из этих элементов может обеспечить определенный уровень уникальности на уровне устройства, комбинация этих элементов может быть очень близка к идентификации конкретного устройства достаточно часто, чтобы быть практически полезной при отслеживании любого конкретного пользователя, подключающегося к беспроводной сети.
Это не означает, что рандомизация MAC-адресов бесполезна, это скорее один шаг в сохранении конфиденциальности пользователя при подключении к беспроводной сети.
Луковая маршрутизация
Луковая маршрутизация - это механизм, используемый для маскировки пути, а также шифрования пользовательского трафика, проходящего через сеть. Рисунок 1 используется для демонстрации.
На рисунке 1 хост А хочет безопасно отправить некоторый трафик на K, чтобы ни один другой узел в сети не мог видеть соединение между хостом и сервером, и чтобы ни один злоумышленник не мог видеть открытый текст. Чтобы выполнить это с помощью луковой маршрутизации, A выполняет следующие действия:
Он использует службу для поиска набора узлов, которые могут соединяться между собой, и предоставления пути к серверу K. Предположим, что этот набор узлов включает [B, D, G], хотя на рисунке они показаны как маршрутизаторы, скорее всего, это программные маршрутизаторы, работающие на хостах, а не выделенные сетевые устройства. Хост A сначала найдет открытый ключ B и использует эту информацию для создания сеанса с шифрованием с симметричным ключом B.
Как только этот сеанс установлен, A затем найдет открытый ключ D и использует эту информацию для обмена набором симметричных ключей с D, наконец, построит сеанс с D, используя этот симметричный секретный ключ для шифрования защищенного канала. Важно отметить, что с точки зрения D, это сеанс с B, а не с A. Хост A просто инструктирует B выполнить эти действия от его имени, а не выполнять их напрямую. Это означает, что D не знает, что A является отправителем трафика, он знает только, что трафик исходит от B и передается оттуда по зашифрованному каналу.
Как только этот сеанс будет установлен, A затем проинструктирует D настроить сеанс с G таким же образом, как он проинструктировал B настроить сеанс с D. D теперь знает, что пункт назначения-G, но не знает, куда будет направлен трафик G.
У хоста A теперь есть безопасный путь к K со следующими свойствами:
Трафик между каждой парой узлов на пути шифруется с помощью другого симметричного закрытого ключа. Злоумышленник, который разрывает соединение между одной парой узлов на пути, по-прежнему не может наблюдать трафик, передаваемый между узлами в другом месте на пути.
Выходной узел, которым является G, знает пункт назначения, но не знает источник трафика.
Входной узел, которым является B, знает источник трафика, но не пункт назначения.
В такой сети только А знает полный путь между собой и местом назначения. Промежуточные узлы даже не знают, сколько узлов находится в пути-они знают о предыдущем и следующем узлах. Основная форма атаки на такую систему состоит в том, чтобы захватить как можно больше выходных узлов, чтобы вы могли наблюдать трафик, выходящий из всей сети, и соотносить его обратно в полный поток информации.
Атака "Человек посередине" (Man-in-the-Middle)
Любой вид безопасности должен не только изучать, как вы можете защитить информацию, но также учитывать различные способы, которыми вы можете вызвать сбой защиты данных. Поскольку ни одна система не является идеальной, всегда найдется способ успешно атаковать систему. Если вам известны виды атак, которые могут быть успешно запущены против системы безопасной передачи данных, вы можете попытаться спроектировать сеть и среду таким образом, чтобы предотвратить использование этих атак. Атаки "человек посередине" (MitM) достаточно распространены, и их стоит рассмотреть более подробно. Рисунок 2 демонстрирует это.
Рисунок 2-б аналогичен рисунку 2-а с одним дополнением: между хостом A и сервером C расположен хост B, который хочет начать зашифрованный сеанс. Некоторыми способами, либо подменяя IP-адрес C, либо изменяя записи службы доменных имен (DNS), чтобы имя C преобразовывалось в адрес B, или, возможно, даже изменяя систему маршрутизации, чтобы трафик, который должен быть доставлен в C, вместо этого доставлялся в B, злоумышленник заставил B принять трафик, исходящий из A и предназначенный для C. На рисунке 2-б:
Хост A отправляет полуслучайное число, называемое одноразовым номером, в C. Эту информацию получает B.
Хост B, который злоумышленник использует в качестве MitM, передает этот одноразовый номер на узел C таким образом, что создается впечатление, что пакет действительно исходит от узла A. В этот момент злоумышленник знает одноразовый идентификатор, зашифрованный A. Злоумышленник не знает закрытый ключ A, но имеет доступ ко всему, что A отправляет зашифрованным с помощью закрытого ключа A.
Сервер C также отправляет ответ с зашифрованным одноразовым случайным числом. B получает это и записывает.
Хост B передает одноразовое случайное число, полученное от C, на A. Хост A по-прежнему будет считать, что этот пакет пришел непосредственно от C.
Хост B вычисляет закрытый ключ с помощью A, как если бы это был C.
Хост B вычисляет закрытый ключ с помощью C, как если бы это был A.
Любой трафик, который A отправляет в C, будет получен B, что:
Расшифруйте данные, которые A передал, используя закрытый ключ, вычисленный на шаге 5 на рисунке 2-б.
Зашифруйте данные, которые A передал, используя закрытый ключ, вычисленный на шаге 6 на рисунке 2-б, и передайте их C.
Во время этого процесса злоумышленник на B имеет доступ ко всему потоку в виде открытого текста между A и C. Ни A, ни C не осознают, что они оба построили зашифрованный сеанс с B, а не друг с другом. Такого рода атаки MitM очень сложно предотвратить и обнаружить.
Сложная терминология в некоторых темах, касающихся IT, иногда заводит в тупик. Простой и понятный процесс может быть описан очень комплексным языком, из-за чего, даже после изучения темы, могут остаться вопросы. Это касается и контейнеризации. В рамках этой темы ответим на вопрос - в чем разница между LXC, LXD и LXCFS.
О LXC
LXC (Linux Containers) представляет собой интерфейс в пользовательской среде, функция которого - сдерживать ядро Linux. Имея в активе эффективный API и набор простых инструментов, LXC дает пользователю возможность администрировать любые использующиеся контейнеры.
Важные характеристики
Текущая версия LXC задействует ряд функций ядра, чтобы обеспечить контейнеризацию следующих процессов:
namespaces (ipc, uts, mount, pid);
профиль AppArmor (та же SELinux);
правила Seccomp;
Chroots (задействуя pivot _root);
потенциал ядра;
группы контроля (CGroups).
Как правило, контейнеры LXC обычно воспринимаются пользователями как нечто усредненное между Chroot и VM. Эта технология нацелена на то, чтобы создать среду, аналогичную стандартно установленной Linux, но сделать это без необходимости в дополнительном ядре.
Компоненты
Ниже в списке, несколько актуальных компонентов LXC:
liblxc;
языковые привязки для AP (Python (2 и 3 ), Lua, Go, Ruby, Haskell);
стандартные инструменты администрирования контейнеров;
готовые варианты контейнеров;
LXD - решение для LXC
LXD (Linux Container Daemon) является базирующимся на LXC гипервизором контейнеров.
Основные части LXD:
системный daemon (lxd);
клиент LXC;
плагин (nova-compute-lxd);
REST API предоставляется демоном в локальном или сетевом режиме. Эффективная утилита управления, клиент командной строки, отличается своей интуитивностью и простотой. Именно с помощью него реализовано управление каждым контейнером. Клиент обрабатывает подключение одновременно к разному количеству контейнеров, отображает уже созданные и создает новые. Есть возможность их перемещения в процессе функционирования.
Упомянутый плагин “превращает” все LXD-host в вычислительные узлы, которые работают для поддержки контейнеров, а не VM.
Преимущества
Основные преимущества LXD:
обеспечение безопасности (контейнеры не обладают привилегированностью, ресурсы ограничиваются и так далее.)
любой масштаб использования;
интуитивность (простое управление через ввод в командной строке);
образ-ориентированность (использование надежных образов, вместо шаблонов);
возможность активной миграции;
Связь с LXC
LXD не является новой версией LXC, скорее, он использует ее как базу. Чтобы администрирование контейнеров стало еще проще, LXD задействует LXC, влияя на библиотеку последней. Также во взаимодействии участвует прослойка, написанная на Go. Таким образом, LXD является, по сути, альтернативой LXC с расширенными возможностями (отличный пример - управление через сеть).
LXCFS: настройка контейнеризации
LXCFS - это небольшая архитектура файлов в среде пользователя, которая способна оптимизировать работу ядра Linux.
LXCFS включает в себя:
файлы, которые монтируются над оригинальными аналогами и предоставляют CGroup-совместимые значения;
дерево cgroupfs, функционирующее в независимости от контейнеров.
Архитектура представляет из себя простой код, созданный в C. Задача, которую необходимо было решить - запуск контейнера systemdпод базовым пользователем с параллельным запуском systemd внутри контейнера, с целью взаимодействовать с cgroups.
Если говорить простым языком, цель создания этой архитектуры - ощущение активного контейнера, как независимой системы.
Так в чем же разница?
Сравнивать LXC, LXD, LXCFS не имеет смысла, так как они не представляют из себя 3 разных продукта с одинаковым функционалом. Грубо можно описать их как программу, дополнение к ней и патч, который позволяет среде пользователя адаптироваться под ее нужды.