По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Стандарт JSON Web Tokens (JWT) – это лаконичный метод передачи данных, поддающихся проверке. Каждый токен содержит подпись, с помощью которой эмитент может проверить целостность сообщения.
С помощью этой статьи вы можете узнать, что из себя представляет структура JWT и как можно создать свои собственные токены. JWT – это популярный способ защиты API и аутентификации сеансов пользователей, так как они достаточно просты и являются автономными.
Как работают JWT?
Одна из самых распространенных задач в любом API – это проверка того факта, что пользователи являются теми, за кого себя выдают. Как правило, аутентификация выполняется тогда, когда клиент использует ключ API для запросов, которые он отправляет на сервер. Этот ключ содержит информацию, которая подтверждает личность пользователя. Но все еще остается вопрос: как сервер проверяет, что пользователь сначала предоставил ключ?
JWT с легкостью решают эту проблему с помощью секретного ключа, который используется для подписи каждого токена. Сервер проверяет действительность токена, повторно пересчитывая подпись с помощью своего секретного ключа. Любое несанкционированное вмешательство приведет к тому, что проверка не будет выполнена.
Структура JWT
JWT состоят из трех отдельных компонентов:
Заголовок
(header) – содержит метаданные о токене, например, алгоритм подписи, который был использован.
Полезная нагрузка
(payload) – в качестве полезной нагрузки могут выступать любые случайные данные, которые так или иначе относятся к вашей системе. Полезная нагрузка может содержать ID пользователя и набор определенных функций, с которыми пользователь может взаимодействовать.
Подпись
(signature) – подпись позволяет в дальнейшем проверить целостность токена. Подпись создается путем подписания заголовка и полезной нагрузки с помощью секретного ключа, который знает только сервер.
Для того, чтобы сформировать JWT, все эти три компонента нужно записать через точку:
header.payload.signature
Каждый компонент кодируется с помощью стандарта Base-64. Готовый токен представляет собой строку текста, которую можно использовать в средах разработки программ и отправлять вместе с HTTP-запросами.
Создание JWT
Создать JWT можно на любом языке программирования. В данном случае мы будем использовать PHP, но вы можете использовать и другой язык, процесс будет аналогичным.
Начнем с создания заголовка. Как правило, он включает в себя два поля –
alg
и
typ
:
alg
– это алгоритм хеширования, который мы будем использовать для создания подписи. Как правило, используют HMAC SHA256 (
HS256
).
typ
– это тип токена, который мы создаем. Здесь мы должны указать
JWT
.
Вот так выглядит объект JSON, который определяет заголовок:
{
"alg": "HS256",
"typ": "JWT"
}
Заголовок необходимо закодировать с помощью Base-64:
$headerData = ["alg" => "HS256", "typ" => "JWT"];
$header = base64_encode(json_encode($headerData));
Затем нам необходимо определить еще один объект JSON - полезную нагрузку токена. Что из себя будет представлять полезная нагрузка зависит от приложения. В данном примере мы используем информацию об учетной записи аутентифицированного пользователя и информацию о самом токене.
exp
,
iat
и
nbf
– это условные поля, которые используются для того, чтобы указать время истечения срока действия токена, время его создания и момент времени (начальный), до которого он считается недействительным. Полезную нагрузку также необходимо закодировать с помощью Base-64.
$payloadData = [
"userId" => 1001,
"userName" => "demo",
"licensedFeatures" => ["todos", "calendar", "invoicing"],
"exp" => (time() + 900),
"iat" => time(),
"nbf" => time()
];
$payload = base64_encode(json_encode($payloadData));
Нам остается только создать подпись. Для этого сначала нужно объединить заголовок и полезную нагрузку в одну сроку, разделив их точкой:
$headerAndPayload = "$header.$payload";
Затем мы должны сгенерировать уникальный секретный ключ, который мы будем использовать в качестве секретного ключа подписи. Этот ключ должен надежно храниться на вашем сервере, и его ни в коем случае нельзя передавать клиентам. Если значение секретного ключа будет раскрыто, то любой пользователь сможет создавать действительные токены.
// PHP method to generate 32 random characters
$secret = bin2hex(openssl_random_pseudo_bytes(16));
И мы завершаем процесс с помощью подписи объединенной строки (заголовка и полезной нагрузки) с помощью секретного ключа. Для этого мы будем использовать алгоритм хеширования, который мы указали в заголовке. Получившаяся подпись также, как и другие компоненты, должна быть закодирована с помощью Base-64.
$signature = base64_encode(hash_hmac("sha256", $headerAndPayload, $secret, true));
Итак, у нас теперь есть заголовок, полезная нагрузка и подпись. Они представляют собой отдельные текстовые компоненты. Для того, чтобы создать JWT, мы должны объединить из с помощью точки. И теперь мы можем отправить его клиенту:
$jwt = "$header.$payload.$signature";
Проверка входящих JWT
Клиентское приложение может определить, какие функции доступны пользователю, если расшифрует полезную нагрузку токена. Вот пример, написанный на JavaScript:
const tokenComponents = jwt.split(".");
const payload = token[1];
const payloadDecoded = JSON.parse(atob(payload));
// ["todos", "calendar", "invoicing"]
console.log(payloadDecoded.licensedFeatures);
Злоумышленник может подумать, что эти данные представляют собой простой текст и его легко изменить. Он может попробовать убедить сервер в том, что у него есть некая дополнительная доступная ему функция, изменив полезную нагрузку токена в своем запросе:
// Create a new payload component
const modifiedPayload = btoa(JSON.stringify({
...payloadDecoded,
licensedFeatures: ["todos", "calendar", "invoicing", "extraPremiumFeature"]
}));
// Stitch the JWT back together with the original header and signature
const newJwt = `${token[0]}.${modifiedPayload}.${token[2]}`
Как же сервер защищается от подобных атак? Ответ заключается в процессе создания подписи. Значение подписи учитывает, как заголовок токена, так и его полезную нагрузку. В случае данного примера изменение полезной нагрузки ведет к тому, что подпись становится недействительной.
Серверная программа проверяет входящие JWT путем пересчета их подписей. Если подпись, отправленная клиентом, не совпадает с подписью, посчитанной на сервере, то можно сделать вывод о том, что токен был подделан.
$tamperedToken = $_POST["apiKey"];
list($header, $payload, $signature) = $tamperedToken;
// Determine the signature this token *should* have
// when the server's secret is used as the key
$expectedSignature = hash_hmac("sha256", "$header.$payload", $secret, true);
// The token has been tampered with because its
// signature is incorrect for the data it includes
if ($signature !== $expectedSignature) {
http_response_code(403);
}
// The signatures match - we generated this
// token and can safely trust its data
else {
$user = fetchUserById($payload["userId"]);
}
Злоумышленник не может создать действительный токен, если он не знает секретный ключ, который хранится на сервере. Также это означает, что случайная утеря или преднамеренная передача секретного ключа сразу же делает все ранее созданные токены недействительными.
В реальной ситуации ваш код аутентификации должен проверять срок действия токена, а также должен убедиться, что он уже является действительным (
nbf
в полезной нагрузке). Это все необходимо для того, чтобы определить, является ли сеанс пользователя действительным.
Когда нужно использовать JWT
JWT, как правило используют для аутентификации API, поскольку их достаточно просто реализовать на сервере, легко использовать на клиентской стороне и просто передавать через границы сети. Но несмотря на то, что они такие простые, они обеспечивают хороший уровень безопасности за счет того, что каждый токен подписывается с помощью секретного ключа, который хранится на сервере.
JWT – это механизм, который не фиксирует текущее состояние, поэтому нет необходимости фиксировать информацию о созданных токенах на вашем сервере. Информацию о клиенте, который предоставляет вам JWT, вы можете получить из полезной нагрузки, а не искать ее в базе данных. После того, как подпись будет проверена, эта информация будет считаться достоверной.
Если вам необходимо обмениваться информацией между двумя сторонами без какого-либо постороннего вмешательства, то использование JWT – это отличный вариант. Однако у этого механизма есть слабые места, о которых следует знать заранее. В случае, если произойдет утечка секретного ключа или если ваш код проверки подписи содержит ошибку, то будет скомпрометирована вся система. Именно поэтому для реализации процесса создания и проверки JWT многие разработчики используют библиотеку с открытым исходным кодом. Функции доступны для всех популярных языков программирования, и они исключают риск ошибок при проверке токена.
Заключение
Стандарт JWT – это формат обмена данными, который включает в себя проверку целостности. Как правило, JWT используют для защиты взаимодействия между серверами API и клиентскими приложениями. Сервер может доверять входящим токенам, если у него получается воспроизвести их подписи. С помощью информации, полученной из полезной нагрузки, можно обеспечить безопасность при выполнении каких-либо действий
JWT достаточно удобны, но при этом имеют некоторые недостатки. Текстовое представление JWT в кодировке Base-64 может быть слишком объемным, если в полезной нагрузке будет слишком много полей. Это будет недопустимым потреблением ресурсов, если ваш клиент собирается отправлять JWT с каждым запросом.
Еще одним возможным недостатком может оказаться то, что JWT не фиксирует текущее состояние. После того, как токен был создан, он является неизменяемым и должен использоваться как есть до истечения своего срока действия. Клиенты, которые используют полезные данные JWT для определения прав доступа пользователя или для использования лицензированных функций, должны будут получать новый токен с сервера каждый раз, когда что-то из этого меняется.
Все, кто так или иначе причастен к миру IT, точно слышал это слово из трех букв - DNS. Domain Name System это своего рода телефонный справочник, в котором указаны адреса всех веб-сайтов в интернете. Также DNS это довольно простой протокол, работающий, как правило, через 53 порт и который используется системными администраторами в буквально каждой сети - ну а куда без него? В данной статье мы не будем подробно разбирать схему работы DNS и типа DNS серверов - это мы оставим на потом.
Каждый раз когда приложение или человек пытается попасть на какой-нибудь веб-сайт, DNS запрашивает в образном "телефонном справочнике" IP-адрес этого ресурса и отправляет вас по нужному адресу.
Темой этой статьи будет некорректное использование службы злоумышленниками: в какой-то момент умные товарищи поняли, что DNS также является прекрасным вектором атаки и научились использовать DNS в целях передачи информации и команд на компьютер жертвы, и это, по сути является основным принципом DNS туннелирования.
Принцип работы DNS туннелирования на пальцах
Пять шагов DNS туннелирования:
Злоумышленник использует DNS для маскировки вредоносных действий, т.к DNS трафик в 99,99% разрешен и не проверяется;
Далее злодеи туннелирует другие протоколы (к примеру, http) через DNS
Далее они туннелируют IP-трафик и передают украденную информацию
Украденную информация снова преобразуют в удобный для восприятия вид
Установленный туннель используют для передачи вредоносного ПО
Обратите внимание на скриншот - я запросил IP-адрес gismeteo.ru. В терминах технологии DNS, вы сделали запрос типа А (от слова Address). Типов подобных запросов существует несколько, и чуть ниже я попробую это продемонстрировать.
В любом случае, под капотом у DNS работает простая схема клиентский запрос на сервер, который в свою очередь отвечает клиенту обратно. А что если можно было бы "зашить" сообщение внутрь запроса?
Представьте себе, что хакеры контролируют DNS сервер: в таком случае, они смогут просто собирать всю нужную информацию без риска оказаться замеченными. Опять же - как DNS запрос может быть нелегитимным? Все привыкли к тому, что эта служба работает всегда и не несет никакой угрозы. Но если служба оказалась скомпрометированной, злоумышленники могут фальсифицировать запросы и использовать информацию, скрытую в различных полях ответных пакетов для контроля вредоносного ПО на компьютере жертвы.
Самая интересная часть - это туннелирование, то есть маскировка информации и передаваемых команд. Делается это, очевидно для того, чтобы подобный трафик прошел незамеченным мимо защитных систем и ПО. Для маскировки используются base32, base 64, а порой и полноценное шифрование.
Base32 и Base64 - это способы кодировки информации используя 32 символа и 64 соответственно. Суть данного упражнении в передаче любой информации в текстовом виде.У обоих методов есть минусы - Base32 код оказывается в 1,6 раза больше оригинальной информации, а Base64 - регистрозависим.
Когда возник данный тип атак?
Впервые подобный вид атак был упомянут в рассылке Buqtraq неким Оскаром Пирсоном в апреле 1998 года.
Далее в 2004 на ежегодной конференции Black Hat была представлена подробная техника - то есть буквально руководство по использованию данной атаки. Шло время и данный тип атак становился все популярнее - сегодня этот механизм встроен буквально в каждый вирус-шифровальщик.
Попробуйте погуглить словосочетание Sea Turtle - это все еще активная кампания, целью которой является взлом легитимных DNS серверов для перенаправления запросов на свои собственные сервера. То есть злоумышленники смогут отвечать на эти запросы ложными сайтами. К примеру пользователь будет пытаться зайти на Facebook или свой аккаунт Ozon, но на самом деле это будут копии страниц, созданные для перехвата пользовательской информации. Честно говоря, такой тип атак не имеет ничего общего с туннелированием DNS, но вектор атаки остается тем же. И представьте себе последствия от украденных учетных данных - лично я бы не хотел, что злоумышленники получили доступ к моим аккаунт в онлайн банках и социальных сетях.
Основные опасности DNS туннелирования
Как вы уже могли понять из моей спутанной и слегка аутичной статьи, DNS туннелирование является механизмом, который является катализатором для различного вида неприятностей, а именно:
Утечка данных: злоумышленники используют DNS для банального вывода текстовой информации с помощью определенной маскировки. Объемы вывода небольшие, но порой много и не требуется - к примеру, данные паспорта улетят очень быстро;
Удаленный контроль: злоумышленники отправляют различные команды через DNS, к примеру для управления RAT-ами (троянами с удаленным управлением). К слову, большое количество шифровальщиков именно так получают свои инструкции и ключи шифрования;
IP-Over-DNS туннелирование: сейчас уже можно найти специальные утилиты, в которых IP стэк имплементирован в клиент-серверную модель работы DNS. То есть такие утилиты позволяют относительно просто передавать информацию используя стандартные штуки вроде FTP, Netcat, ssh и пр. То есть через DNS можно будет передать буквально любую информацию
Техники детектирования DNS - туннелирования
Существует два основных метода по обнаружения некорректного использования DNS службы: анализ трафика и анализ полезной нагрузки.
При анализе полезной нагрузке необходимо обращать внимание на странные и аномальные запросы, особенно если они содержат в себе странные доменные имена, странные символы и пр. Для выявления подобного используются различные статистические техники.
В свою очередь, при анализе трафика, нужно обращать внимание на общее количество запросов к домену и сравнивать это число со средними значениями. Хакеры, осуществляющие DNS туннелирование, будут создавать большой объем DNS трафика - что сразу должно вызвать подозрения, так как отличия в объемах будут буквально на порядки.
Утилиты для создания DNS туннеля:
Если вам хочется посмотреть, уязвима ли ваша инфраструктура к такому виду атак, то можете попробовать несколько утилит из списка ниже (только на свой страх и риск). Все эти утилиты реализуют IP-over-DNS механизм атак.
Iodine: данная утилита доступна на большинстве платформ (Linux, Mac OS, Windows, FreeBSD) и позволяет установить SSH туннель между целью и вашим компьютером. Утилита не самая простая, когда-нибудь мы напишем статью чс примером ее использования;
OzymanDNS: функционал схож с Iodine, то есть утилита также позволяет строить SSH туннель. Интересно то, что это проект целиком и полностью написан на Perl;
DNSCat2: многофункциональный комбайн, который создает зашифрованный канал для управления (C2) и позволяет скачивать/загружать файлы, запускать cmd/powershell и пр.
Утилиты для мониторинга DNS туннеля:
dnsHunter: модуль на питоне, написанный для Mercenary-Linux. Данный модуль читает .pcap файлы, выделяет из них DNS-запросы и осуществляет геолукапы, что также может помочь при расследовании;
reassemble_dns: также утилита, написанная на питоне, которая позволяет читать .pcap файлы и реконструировать DNS запросы;
На рынке телефонных станций, компания Cisco Systems представлена двумя основными продуктами: Cisco Unified Communications Manager (CUCM) и Cisco Unified Communications Manager Express (CME). О них сегодня и поговорим.
Cisco Unified Communication Manager
Cisco Unified Communication Manager – это система процессинга телефонных вызовов на базе ОС Linux. Поддерживает основные стандарты, такие как SIP, H.323, MGCP и проприетарный SCCP. CUCM – решение, которое предназначено для средних и крупных организаций. При кластеризации серверов, один кластер может обрабатывать 30 000 пользователей. В одном кластере может находиться до 20 серверов, причем лишь только 8 из них предназначены непосредственно для обработки телефонной сигнализации. Остальные, это TFTP, MOH (music on hold) сервер, CUC и другие. Среди 8 серверов, обычно выделяют один Publisher, а остальные Subscriber’ы. Основная роль Publisher’a заключается в репликации базы данных на все остальные сервера. CUCM - это программное обеспечение, удобное в администрировании и настройке.
Основной WEB GUI проиллюстрирован ниже:
Данный интерфейс называется Cisco Unified CM Administration. Всего их 5:
Cisco Unified CM Administration
Cisco Unified Reporting
Disaster Recovery System
Cisco Unified Serviceability
Cisco Unified OS Administration
Cisco UCM может быть развернут как в виртуальной среде, так и на физическом сервере. Интегрируется с другими продуктами компании Cisco, такими как: Cisco Unity Connection (CUC), Cisco Unified Presence (CUP, начиная с 9 версии IM and Presence), Unified Contact Center Express и другие. Так же поддерживается интеграция с решениями других вендоров.
Cisco Unified Communication Manager Express (CME)
CME отлично подходит для малого и среднего бизнеса, удаленных офисов и небольших площадок. Call Manager Express реализуется на ISR (integrated service router) маршрутизаторах, что обеспечивает консолидацию сервисов телефонии и интернета в одном устройстве. Данная платформа способна поддерживать около 500 телефонных аппаратов. Например, маршрутизатор Cisco 3945E ISR G2 может обеспечить работу 450 телефонов. В CME предусмотрена работа голосовой почты, автосекретаря и других функций, которые реализуются с помощью специальных модулей. Как правило, администрирование CME происходит через CLI (command line interface). Но разработчиками предусмотрено использование аппликации Cisco Configuration Professional (CCP), с помощью которого можно управлять dial – планом, администрировать телефоны, пользователей и многие другие опции. Cisco Call Manager Express поддерживает SRST, что обеспечивает отказоустойчивость в случае падения WAN. При планировании важную роль играет DSP, которая отвечает за транскодирование и преобразование традиционного телефонного трафика в IP.
CME может локально хранить данные об именах пользователей. Это позволяет отображать имя звонящего при входящем звонке.
Другая удобная опция это Call Forwarding. Она позволяет перенаправлять входящие вызовы на номер, указанный заранее, если получатель звонка занят, или не отвечает.
Пример реализации ниже:
merion_voice(config)#ephone-dn 15
merion_voice (config-ephone-dn)#call-forward busy 1111
Cisco Call Manager Express поддерживает такие опции как:
Call Transfer – перевод вызова. Бывает консультативный (англ. Consult - возможность разговора с адресатом до трансфера вызова) и слепой (англ. Blind – моментальный перевод вызова после набора номера получателя).
Call Park – возможность повесить вызов на «холд» на специально выделенном номере, а затем, набрать с любого другого ТА этот номер и продолжить разговор.
Call Pickup – возможность ответить на телефонный вызов, который пришел на другой телефонный аппарат. Обычно реализуется в рамках одного отдела.
Intercom – позволяет при нажатии одной клавиши отдать распоряжения. Например, интерком может быть настроен на кнопке телефона руководителя, для быстрой связи с секретарем.
Paging – тоже самое что и интерком, только в широковещательном формате. Удобно для экстренных оповещений большого количества людей.
Таким образом, мы рассказали о двух основных продуктах компании Cisco Systems в области телефонных станций. В следующих статьях мы подробно расскажем о каждой из телефонных станций.