По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Стандарт 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 для определения прав доступа пользователя или для использования лицензированных функций, должны будут получать новый токен с сервера каждый раз, когда что-то из этого меняется.
В этой статье рассказываем, как быстро и просто сбросить и восстановить пароль в Cisco ASA Firewall. Про сброс пароля на маршрутизаторах и коммутаторах Cisco можно прочесть в этой статье. Поехали!
Процедура сброса пароля
Шаг 1: Подключитесь к Cisco ASA с помощью консольного кабеля и перезагрузите устройство.
Шаг 2: Нажмите клавишу «ESC» или «BREAK» на клавиатуре, чтобы прервать процесс загрузки. Нужно начинать нажимать клавишу, как только устройство запустится до тех пор, пока устройство не перейдет в режим ROMMON. Приглашение будет выглядеть так:
Evaluating BIOS Options ...
Invalid Key: 0000
Launch BIOS Extension to setup ROMMON
Cisco Systems ROMMON Version (1.0(12)13) #0: Thu Aug 28 15:55:27 PDT 2008
Platform ASA5505
Use BREAK or ESC to interrupt boot.
Use SPACE to begin boot immediately.
Boot interrupted.
Use ? for help.
rommon #0>
rommon #0>
Шаг 3: Теперь введите команду confreg 0x41, чтобы изменить значение регистра конфигурации на 0x41. Это значение указывает устройству игнорировать конфигурацию запуска при загрузке.
rommon #0> confreg 0x41
Update Config Register (0x41) in NVRAM...
rommon #1>
Шаг 4: Перезагрузите устройство. Введите команду boot, чтобы сделать это.
rommon #1> boot
Шаг 5: После перезагрузки устройство не будет запрашивать пароль. Перед приглашением ciscoasa> вы увидите сообщение о том, что startup config с потерянным паролем был проигнорирован. Введите команду enable, чтобы войти в привилегированный режим. В запросе пароля нажмите Enter, чтобы оставить его пустым.
Ignoring startup configuration as instructed by configuration register.
INFO: Power-On Self-Test in process.
...........................................................
INFO: Power-On Self-Test complete.
Type help or '?' for a list of available commands.
ciscoasa> enable
Password:
ciscoasa#
Шаг 6: Копируем нашstartup config в running config командой copy startup-config running-config .
ciscoasa# copy startup-config running-config
Destination filename [running-config]?
.
Cryptochecksum (unchanged): b10dcb10 12202944 fee241b5 47ee01e9
3071 bytes copied in 4.920 secs (767 bytes/sec)
Шаг 7: Теперь войдите в режим конфигурации черезconf t и настройте новый пароль при помощи команды enable password привилегированного уровня (вместо password123 в примере), а заетм сбросьте значение конфигурации до его исходного значения 0x01 при помощи команды config-register и сохраните конфиг при помощи wr.
ASA# conf t
ASA(config)# enable password password123
ASA(config)# config-register 0x01
ASA(config)# wr
Building configuration...
Cryptochecksum: 4fd2bcb3 8dfb9bd5 886babde 9aff8c3d
3527 bytes copied in 1.270 secs (3527 bytes/sec)
[OK]
Шаг 8: Теперь перезагрузите устройство командой reload.
ASA(config)# reload
Proceed with reload? [confirm]
ASA(config)#
Сброс пароля был успешно завершен и после перезагрузки вам нужно будет ввести ваш новый пароль.
Также, как и системы электронной почты, системы VoIP телефонии есть практически у каждой компании. Это могут быть простые облачные АТС, арендуемые у провайдера или собственные выделенные под IP-АТС серверные мощности, но среда, по которой передаётся сигнализация и пользовательский трафик данных систем один – Интернет. Это делает систему VoIP телефонии одной из самых востребованных злоумышленниками целей, ведь получив к ней доступ, открывается масса возможностей для извлечения прибыли или нанесения другого ущерба. Если Вы банально откроете логи своего межсетевого экрана и поищите запросы, поступающие извне, то наверняка увидите, что тысячи сканеров каждую секунду пробуют узнать какие сервисы работают на вашем внешнем адресе. И даже если этот адрес никак не связан с IP-телефонией, то вы всё равно там увидите запросы, связанные с VoIP. Это говорит о том, что злоумышленники очень хотят найти уязвимые системы телефонии и знают как проэксплуатировать выявленную брешь. В этой статье разберём какой профит получают хакеры, взломавшие VoIP систему, основные методы атак и протоколы, на которые они направлены. Чего хотят плохие парни? Как только Ваша систему IP-телефонии будет зарегистрирована в сети VoIP провайдера – вы сможете позвонить в любой уголок мира - на мобильный телефон в Тайване, на такософон в одной из красных будок Лондона и даже на декадно-шаговую АТС в музее Франкфурта-на-Майне! Что сделает злоумышленник, получивший такую возможность? – Воспользуется ею за Ваш счёт! В большинстве плачевно известных случаев, получая доступ к системе по средствам какой-либо уязвимости, злоумышленники делают следующее: совершают дорогостоящие звонки на дальние расстояния (long-distance calls); перепродают возможность звонка третьим лицам, не подозревающим, что услуга предоставляется на украденных мощностях звонят на номера с премиум обслуживанием, зарабатывая кэшбэк на свой счёт Существует провайдеры телефонных номеров с премиум обслуживанием (international premium rate number - IPRN). Это такие номера, звонки на которые, происходят очень часто и со всего мира. Например, номера для технической поддержки, прогноза погоды, сервисы для взрослых. Провайдеры таких номеров платят часть прибыли тому, кто гонит на них трафик - генератору звонков (call generator). В некоторых случаях провайдер осознанно участвует в мошеннической схеме, а иногда и вовсе не подозревает, что платит кэшбэк злоумышленникам за трафик, сгенерированный на "угнанных" мощностях. В конечном итоге и провайдеры и call generator'ы остаются в выигрыше, а платить приходится тому кого взломали. Всё вышеописанное подпадает под одно определение, которому в английской литературе дали название - toll fraud. На русский язык это можно перевести как неправомочные действия и несанкционированное пользование чужими ресурсами телефонной связи. Злоумышленникам также может быть интересно вывести вашу систему телефонии из строя, устроив атаку типа DoS (Denial of service) - отказ в обслуживании, хотя это случается реже toll fraud'а. Нам известны случаи, когда целый ботнет из серверов FreePBX начинал забрасывать IP-АТС заказчика "мусорными" вызовами, в результате чего на какое-то время, пользоваться системой стало просто невозможно. Техническая реализация Согласно исследованию IBM наиболее атакуемыми VoIP протоколами являются SIP, SCCP и H.255. Самым распространённым VoIP протоколом на сегодняшний день является SIP, поэтому и большинство атак осуществляется именно на этот протокол. Всё начинается с поиска сервера для проведения атаки. Протокол SIP использует стандартный порт 5060, поэтому первое, что сделает потенциальный злоумышленник – это отправит SIP-запрос на данный порт, чтобы посмотреть какой придет ответ. Как правило, для поиска SIP-сервиса используются стандартные запросы INVITE, REGISTER или OPTIONS. Хорошей практикой является перенос SIP-сервиса со стандартного порта на какой-нибудь другой. Таким образом мы можем увести сервис из-под удара. Ещё лучше – ограничить доступ к этому порту только для доверенного списка IP-адресов. Однако, иногда такой возможности просто нет. Для изначального установления соединения в SIP используется метод “тройного рукопожатия” , начинающийся с запроса INVITE, который подтверждается ответом 200 OK. Однако, если этот ответ от вызывающей стороны не получен, то соединение не устанавливается. Если наблюдается много таких незаконченных соединений за коротких промежуток времени, то это может быть признаком того, что против сервера идёт DoS-атака. Кстати, точно таким же образом, злоумышленник может провести атаку против легитимного устройства пользователя, чтобы сбросить его регистрацию на сервере и зарегистрироваться самому. Существует также метод “флуда” запросами REGISTER. Для этого злоумышленник должен знать параметры зарегистрированного устройства, регистрацию которого он хочет сбросить, подделать заголовок Contact в SIP пакете и отправить много (достаточно раз в 15 секунд) запросов REGISTER на сервер. Такой метод называется Registration-hijacking. Эти атаки возможны благодаря тому, что протокол SIP передает информацию в открытом виде, а значит атакующий может её собрать, модифицировать и воспроизвести. Помимо этого, в протоколе SIP не предусмотрено проверки целостности сообщений, поэтому атаки с модифицированной информацией и воспроизведенными пакетами не детектируются. Злоумышленникам совсем не обязательно перехватывать ваш трафик, чтобы вытащить запросы регистраций легитимных пользователей, потом модифицировать их и подсовывать обратно серверу. После обнаружения открытого SIP-порта, можно просто устроить перебор зарегистрированных внутренних номеров, например, от 10 до 9999. Ответ от сервера на запрос регистрации по такой схеме будет однозначно свидетельствовать о том, какие номера есть на IP-АТС, а каких там нет. Например, я могу отправить запрос на регистрацию с номера 2526 с неправильным паролем. Если на сервере зарегистрирован такой номер, то я получу ответ, что пароль неверен (Wrong Password), а если нет – то сообщение о том, что номер не найден (Not Found). Собрав список зарегистрированных номеров можно потом применить против них метод перебора паролей и получить доступ к внутреннему номеру легитимного пользователя. Другой неприятные метод атаки на VoIP позволяет прослушивать ваши телефонные разговоры. Для этого необходимо перехватить сигнальную информацию и соответствующие медиа потоки определенного соединения. Медиа потоки, которые как раз и содержат пакеты с голосом, обычно передаются по UDP с использованием протокола RTP. Захватив достаточное количество пакетов, можно декодировать RTP поток, а затем сделать из них простой аудио файл, который и будет содержать голос. Сделать это можно с помощью программы Wireshark. Мы рассказали про базовые методы проведения атак на VoIP системы. В следующих статьях, мы обязательно расскажем как защититься от каждого типа атаки, как выявить признаки атак и какие инструменты можно для этого использовать.