- •Отзывы и пожелания
- •Список опечаток
- •Нарушение авторских прав
- •Предисловие
- •Кому адресована эта книга
- •О чем идет речь в книге
- •Как извлечь максимум из книги?
- •Загрузка примеров
- •Загрузка цветных изображений
- •Условные обозначения
- •Атаки на веб-приложения. Введение
- •Правила применения оружия
- •Вопросы конфиденциальности данных
- •Очистка
- •Инструментарий тестировщика
- •Kali Linux
- •Альтернативы Kali Linux
- •Прокси-сервер
- •Burp Suite
- •Zed Attack Proxy
- •Облачная инфраструктура
- •Дополнительные источники
- •Упражнения
- •Резюме
- •Глава 2
- •Эффективное обнаружение
- •Типы тестирования
- •Построение карты сети
- •Masscan
- •hatWeb
- •Nikto
- •CMS-сканеры
- •Эффективная атака методом полного перебора
- •Средства сканирования
- •Постоянное картирование контента
- •Обработка полезной нагрузки
- •«Полиглот»
- •Запутывание (обфускация) кода
- •Дополнительные источники
- •Упражнения
- •Резюме
- •Глава 3
- •Легкая добыча
- •Анализ сети
- •Ищем вход
- •Определение учетных данных
- •Есть способ получше
- •Очистка
- •Дополнительные ресурсы
- •Резюме
- •Глава 4
- •Продвинутые способы атаки с использованием метода полного перебора
- •Распыление подбора пароля
- •Спросим LinkedIn
- •Метаданные
- •Кассетная бомба
- •За семью прокси-серверами
- •ProxyCannon
- •Резюме
- •Глава 5
- •Внедрение файлов
- •Удаленное внедрение файлов
- •Локальное внедрение файлов
- •Внедрение файла для удаленного выполнения кода
- •Резюме
- •Обнаружение и эксплуатация уязвимостей в приложениях с помощью внешних сервисов
- •Распространенный сценарий
- •Командно-контрольный сервер
- •Центр сертификации Let’s Encrypt
- •INetSim
- •Подтверждение
- •Асинхронное извлечение данных
- •Построение выводов на основе анализа данных
- •Резюме
- •Расширение функциональных возможностей Burp Suite
- •Нелегальная аутентификация и злоупотребление учетными записями
- •Швейцарский нож
- •Запутывание кода
- •Collaborator
- •Открытый сервер
- •Выделенный сервер Collaborator
- •Резюме
- •Глава 8
- •Вредоносная сериализация
- •Использование десериализации
- •Атака на пользовательские протоколы
- •Анализ протокола
- •Эксплойт для осуществления атаки
- •Резюме
- •Практические атаки на стороне клиента
- •Правила ограничения домена
- •Совместное использование ресурсов разными источниками
- •Межсайтовый скриптинг
- •Постоянный XSS
- •DOM-модели
- •Межсайтовая подделка запроса
- •BeEF
- •Перехват
- •Атаки с применением методов социальной инженерии
- •Кейлоггер
- •Закрепление в системе
- •Автоматическая эксплуатация
- •Туннелирование трафика
- •Резюме
- •Практические атаки на стороне сервера
- •Внутренние и внешние ссылки
- •Атаки XXE
- •Атака billion laughs
- •Подделка запроса
- •Сканер портов
- •Утечка информации
- •«Слепой» XXE
- •Удаленное выполнение кода
- •Резюме
- •Глава 11
- •Атака на API
- •Протоколы передачи данных
- •SOAP
- •REST
- •Аутентификация с помощью API
- •Базовая аутентификация
- •Ключи API
- •Токены на предъявителя
- •Postman
- •Установка
- •Вышестоящий прокси-сервер
- •Среда выполнения
- •Коллекции
- •Запуск коллекции
- •Факторы атаки
- •Резюме
- •Глава 12
- •Атака на CMS
- •Оценка приложения
- •WPScan
- •sqlmap
- •Droopescan
- •Arachni
- •Взлом кода с помощью бэкдора
- •Закрепление в системе
- •Утечка учетных данных
- •Резюме
- •Глава 13
- •Взлом контейнеров
- •Сценарий уязвимости в Docker
- •Осведомленность о ситуации
- •Взлом контейнера
- •Резюме
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
NOW! |
o |
||||
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
||||
w Click |
to |
BUY 286 Глава 11.Атака на API |
||||||||
|
|
|
|
|
|
m |
||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
Аутентификация с помощью API |
|||||
|
|
|
|
|
|
g |
|
|
||
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Разъединение вызывает еще ряд проблем, когда речь заходит об аутентификации и авторизации. Нередко встречаются API, не требующие аутентификации, но есть вероятность, что некоторые веб-сервисы будут требовать, чтобы их клиенты так или иначе проходили аутентификацию.
Так как же нам добиться аутентификации с помощью API? Этот процесс ничем не отличается оттипичного приложения. По сути, аутентификация требует, чтобы вы предоставили что-то, что вы знаете, и при необходимости нечто, что у вас есть, что соответствует записи в базе данных API. Если это секретная информация и только владелец этой информации, по-видимому, имеет к ней доступ,API можетбытьдостаточно уверен,что клиент,предоставляющийданную информацию,получитдоступ.APIтеперьнужнотолько отслеживатьэтого конкретного клиента, поскольку HTTP в данном случае не поможет.
Традиционные веб-приложения будут принимать данные аутентификации (нечто, что вы знаете, вместе с комбинацией имени пользователя и пароля) и могутпотребовать наличия второго фактора (одноразовый пароль,номер SMS или мобильное push-уведомление). Как только вы будете верифицированы, вам выдадут идентификатор сеанса,который ваш браузер передастдля последующих запросов аутентификации через куки-файлы.
API-интерфейсы похожитем,что онитребуют,чтобы какой-либо секретный ключ или токен передавался обратно при каждом запросе, требующем аутентификации.Этоттокен обычно генерируется API и предоставляется пользователю после успешной аутентификации с помощью других средств. В то время как типичное веб-приложение почти всегда использует заголовок Cookie для отслеживания сеанса, у API есть несколько вариантов.
Базовая аутентификация
Да, она также распространена в веб-приложениях, но обычно не используется в современных приложениях из-за проблем, связанных с безопасностью. При базовой аутентификации имя пользователя и парольпередаются в открытом виде через заголовок Authorization.
GET /users?name=admin HTTP/1.1
Host: api.ecorp.local:8081
Content-Type: application/json
Accept: application/json
Authorization: Basic YWRtaW46c2VjcmV0
Cache-Control: no-cache
Очевидные проблемы, связанные с этим, заключаются в том, что учетные данныепередаютсяпопроводамввиденезашифрованноготекстаизлоумыш-
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
||
|
|
|
C |
|
E |
|
|
|
|
|
|
C |
E |
|
|
|
|||||||
|
|
X |
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
||||||
|
- |
|
|
|
|
|
d |
|
|
- |
|
|
|
|
|
d |
|
||||||
|
F |
|
|
|
|
|
|
|
t |
|
|
F |
|
|
|
|
|
|
|
t |
|
||
|
D |
|
|
|
|
|
|
|
|
i |
|
|
D |
|
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
|
|
|
|
|
|
|
|
|
r |
||||
P |
|
|
|
|
|
NOW! |
o |
P |
|
|
|
|
|
NOW! |
o |
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|
|
|
|
BUY |
|
|
Аутентификация с помощью API 287 BUY |
|
|
|||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||
w Click |
to |
|
|
|
|
|
|
|
|
|
|
|
to |
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
m |
w Click |
|
|
|
|
|
|
|
m |
|||||||
w |
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
|
|
|
||
|
w |
|
|
|
|
|
|
|
|
o |
|
|
w |
|
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
g |
.c |
|
|
. |
|
|
|
|
g |
.c |
|
||||||
|
|
p |
|
|
|
|
|
|
|
|
|
p |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
ленникам нужно перехватить только один запрос, чтобы скомпрометировать |
|
|
e |
|
|||||||||||||
|
|
|
df |
|
|
n |
e |
|
|
|
|
df |
|
|
n |
|
|||||||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
-x cha |
|
|
|
|
|
пользователя. Идентификаторы сеансов и токены по-прежнему предоставляютзлоумышленникамдоступ,носрокихдействияможетистечьионипопадут в черный список.
При базовой аутентификации следует использовать протокол HTTPS, поскольку учетныеданные пользователя передаются в виде незашифрованного текста. Современные API склонны избегать данного типа аутентификации, потому что учетные данные могут кешироваться прокси-серверами, могут быть перехвачены с помощью атак типа «человек посередине» (MITM) или извлечены из дампов памяти.Если API использует протокол LDAP для аутен тификации пользователей в домене Active Directory, не рекомендуется передавать учетные данные домена пользователя по проводам при каждом APIзапросе.
Ключи API
Более распространенный способ аутентификации – предоставление ключа или токена с API-запросом. Ключ является уникальным для учетной записи с доступомквеб-службеидолженхранитьсявтайне,равнокакипароль.Однако, в отличие от пароля, он (обычно) не генерируется пользователем и, следовательно,сменьшейвероятностьюповторноиспользуетсявдругихприложениях.
Для передачи этого значения API-интерфейсам не существует отраслевого стандарта, хотя Open Authorization (OAuth) и SOAP имеют некоторые требования, определенные протоколом.
Пользовательские заголовки, заголовок Cookie и даже параметр GET – одни из распространенных способов отправки токенов или ключей вместе с запросом.
Использование параметра GET для передачи ключа – как правило, плохая идея,поскольку это значение может кешироваться браузерами,прокси-серве- рами и попадать в файлы журналов веб-сервера.
GET /users?name=admin&api_key=aG93IGFib3V0IGEgbmljZSBnYW1lIG9mIGNoZXNz
HTTP/1.1
Host: api.ecorp.local:8081 Content-Type: application/json Accept: application/json Cache-Control: no-cache
Еще один вариант – использовать пользовательский заголовок для отправки API-ключа вместе с запросом. Эта более приемлемая альтернатива, но попрежнемутребуетсяиспользоватьпротоколHTTPS,чтобыэтозначениенельзя было перехватить с помощью MITM-атак.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|
|||
|
|
X |
|
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
|
||
|
F |
|
|
|
|
|
|
t |
|
||
|
D |
|
|
|
|
|
|
|
i |
r |
|
P |
|
|
|
|
NOW! |
o |
|||||
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
||||
w Click |
to |
BUY 288 Глава 11.Атака на API |
|||||||||
|
|
|
|
|
|
|
m |
||||
w |
|
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
GET /users?name=admin HTTP/1.1 |
|||
|
|
|
|
|
|
|
|||||
|
|
|
|
-xcha |
|
|
|
|
|
Host: api.ecorp.local:8081 Content-Type: application/json Accept: application/json
X-Auth-Token: aG93IGFib3V0IGEgbmljZSBnYW1lIG9mIGNoZXNz
Cache-Control: no-cache
Токены на предъявителя
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Как и ключи,токены на предъявителя представляютсобой секретные значения,которые обычно также передаются через HTTP-заголовок Authorization, новместотипаBasic используетсятипBearer.ВслучаесRESTAPI,покаклиент исервердоговариваютсяотом,какобмениватьсяэтимтокеном,несуществует стандарта, определяющего этот процесс, и поэтому на практике можно встретить его вариации.
GET /users?name=admin HTTP/1.1 Host: api.ecorp.local:8081 Content-Type: application/json Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjEiLCJ1c2VyIjoiYWRtaW4i LCJpc19hZG1pbiI6dHJ1ZSwidHMiOjEwNDUwNzc1MH0.TstDSAEDcXFE2Q5SJMWWKIsXV 3_krfE4EshejZXnnZw
Cache-Control: no-cache
Предыдущий токен на предъявителя является примером JWT. Он немного длиннее традиционного скрытого токена, но у него есть ряд преимуществ.
JWT
JWT – это относительно новый механизм аутентификации, который завоевываетсвоюдолю на рынке веб-сервисов.Это компактный автономный метод безопасной передачи информации между двумя сторонами.
Токены JWT универсальны,и ихлегко реализоватьв протоколах аутентификации. SOAP и OAuth могут без проблем реализовывать токен JWT в качестве токена на предъявителя.
Информацию об OAuth можно найти на странице https:// oauth.net/2/.
Токены JWT, по сути,утверждают,что они подписаны с использованием ко-
да аутентификации сообщений, применяющего хеш-функции (HMAC), и
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
||
|
|
|
C |
|
E |
|
|
|
|
|
|
C |
E |
|
|
|
|||||||
|
|
X |
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
||||||
|
- |
|
|
|
|
|
d |
|
|
- |
|
|
|
|
|
d |
|
||||||
|
F |
|
|
|
|
|
|
|
t |
|
|
F |
|
|
|
|
|
|
|
t |
|
||
|
D |
|
|
|
|
|
|
|
|
i |
|
|
D |
|
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
|
|
|
|
|
|
|
|
|
r |
||||
P |
|
|
|
|
|
NOW! |
o |
P |
|
|
|
|
|
NOW! |
o |
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|
|
|
|
BUY |
|
|
Аутентификация с помощью API 289 BUY |
|
|
|||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||
w Click |
to |
|
|
|
|
|
|
|
|
|
|
|
to |
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
m |
w Click |
|
|
|
|
|
|
|
m |
|||||||
w |
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
|
|
|
||
|
w |
|
|
|
|
|
|
|
|
o |
|
|
w |
|
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
g |
.c |
|
|
. |
|
|
|
|
g |
.c |
|
||||||
|
|
p |
|
|
|
|
|
|
|
|
|
p |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
секретного ключалибо пары ключей RSA.HMAC–это алгоритм,который мож- |
|
|
e |
|
|||||||||||||
|
|
|
df |
|
|
n |
e |
|
|
|
|
df |
|
|
n |
|
|||||||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
-x cha |
|
|
|
|
|
но использоватьдля проверки как целостностиданных,так и аутентификации сообщения, что хорошо подходит для токенов JWT. Токены JWT представляют собой сочетание заголовка, полезной нагрузки и соответствующей подписи в кодировке base64url:
base64url(header) . base64url(payload) . base64url(signature)
В заголовкетокена будетуказан алгоритм,используемыйдля подписи,а полезная нагрузка будеттребованием (например,я–user1,а я–администратор), в то время как третья часть– это сама подпись.
Если проверим предыдущий токен на предъявителя, то увидим структуру типичноготокена JWT.Естьтри фрагмента информации,разделенныхточкой, в кодировке base64url.
В этой кодировке используется тотже алфавит,что и в традиционном формате Base64, за исключением замены символов + на – и / на _.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJpZCI6IjEiLCJ1c2VyIjoiYWRtaW4iLCJpc19hZG1pbiI6dHJ1ZSwidHMiOjEwND
UwNzc1MH0
.
TstDSAEDcXFE2Q5SJMWWKIsXV3_krfE4EshejZXnnZw
Первый фрагмент – заголовок, описывающий алгоритм подписи. В данном случае это HMAC с SHA-256. Тип определяется как токен JWT.
Можно использовать функцию JavaScript atob() в консоли браузера для декодирования этого фрагмента в удобочитаемый текст.
> atob('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9') "{"alg":"HS256","typ":"JWT"}"
Второй фрагмент обычно представляет собой произвольные данные, которые что-либо утверждают. Они также известны как полезная нагрузка. В этом случае они сообщают серверу, что я являюсь пользователем с правами администратора admin с идентификатором пользователя 1 и временной отметкой 104507750. Временные отметки – хорошая идея, поскольку они могут предотвратить атаки повторного воспроизведения.
> atob('eyJpZCI6IjEiLCJ1c2VyIjoiYWRtaW4iLCJpc19hZG1pbiI6dHJ1ZSwidH MiOjEwNDUwNzc1MH0') "{"id":"1","user":"admin","is_admin":true,"ts":104507750}"
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
||
|
|
|
C |
|
E |
|
|
|
|
|
|
|
C |
|
E |
|
|
|
||||||
|
|
X |
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
||||||
|
- |
|
|
|
|
|
d |
|
|
|
- |
|
|
|
|
|
d |
|
||||||
|
F |
|
|
|
|
|
|
|
t |
|
|
F |
|
|
|
|
|
|
|
t |
|
|||
|
D |
|
|
|
|
|
|
|
|
i |
|
|
D |
|
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
|
|
r |
|
|
|
|
|
|
|
|
|
r |
||||
P |
|
|
|
|
NOW! |
|
o |
P |
|
|
|
|
|
NOW! |
o |
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
BUY |
|
|
|||||||||
w Click |
to |
BUY 290 Глава 11.Атака на API |
w Click |
to |
|
|
|
|
|
|
||||||||||||||
|
|
|
|
|
|
|
|
m |
|
|
|
|
|
|
|
m |
||||||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
|
|
|
||
|
w |
|
|
|
|
|
|
|
|
|
o |
|
|
w |
|
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
g |
.c |
|
|
. |
|
|
|
|
g |
.c |
|
|||||||
|
|
p |
|
|
|
|
|
|
|
|
|
|
p |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
e |
Последний фрагмент представляет собой 32-байтовую подпись SHA-256 |
|
|
|
e |
|
||||||||||
|
|
|
df |
|
|
n |
|
|
|
|
|
|
|
|
df |
|
|
n |
|
|
|
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
|
-x cha |
|
|
|
|
|
HMAC в кодировке base64url.
Когда API-сервер получит этот токен, состоящий из трех частей, он сделает следующее:
выполнит синтаксический анализ заголовка, чтобы определить алгоритм: в данном случае это HMAC SHA-256;
рассчитает значение HMAC SHA-256 для первых двух фрагментов, закодированных в base64url, объединенных точкой:
HMAC-SHA256(base64url(header) + "." + base64url(payload),"secret_key");
если подпись подтверждается, можно считать полезную нагрузку также валидной.
Причуды JWT
Хотя в настоящее время этот процесс криптографически безопасен,есть несколько способов, которые мы можем использовать, чтобы поэкспериментировать с этим токеном и попытаться обмануть слабые реализации API.
Прежде всего, хотя заголовок и полезная нагрузка подписаны, их можно модифицировать. Данные токена находятся под нашим контролем. Единст венное, что нам не известно, – это секретный ключ. Если мы модифицируем полезную нагрузку, подпись не пройдет проверку и, скорее всего, сервер отклонит наш запрос.
Помните, однако, что фрагмент заголовка анализируется до того, как будет выполнена верификация подписи. Это связано с тем, что в заголовке содержатся инструкции относительно того,как API проверяет сообщение.Это означает,что мы могли бы потенциально изменить данные и что-либо нарушить в реализации.
Интересно, что рабочее предложение (RFC) указывает поддерживаемый алгоритм подписи под названием none, который может использоваться реализацией для предположения,что токен был проверен другими способами
(рис. 11.2).
Полное определение токена JWT в открытом стандарте RFC 7519
можно найти на странице https://tools.ietf.org/html/rfc7519.
Некоторые библиотеки JWT следуют стандарту и также поддерживают этот алгоритм. Итак, что происходит, когда мы используем алгоритм none с нашей предыдущей полезной нагрузкой?
|
|
|
|
hang |
e |
|
|
|
|
||
|
|
|
C |
|
E |
|
|
||||
|
|
X |
|
|
|
|
|
|
|||
|
- |
|
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
||||
|
|
|
|
|
|
|
|||||
|
|
|
|
|
BUY |
|
|
||||
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
|
g |
|
|
|
|
|
|
df |
-xcha |
n |
e |
|
||||
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
Аутентификация с помощью API
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
C |
E |
|
|
|||
|
|
X |
|
|
|
|
|||
|
- |
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
||||
291 BUY |
|
|
|||||||
|
|
|
|
|
|||||
w Click |
to |
|
|
|
|
m |
|||
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
g |
|
|
|
|
|
|
df |
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Рис.11.2. В RFC упоминается о незащищенных токенах JWT, использующих алгоритм «none»
Вот как будет выглядеть наш токен без подписи,добавленной после последней точки.
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0
.
eyJpZCI6IjEiLCJ1c2VyIjoiYWRtaW4iLCJpc19hZG1pbiI6dHJ1ZSwidHMiOjEwND
UwNzc1MH0
.
[blank]
Токен будет проверен и считаться действительным, если серверная библиотека придерживается стандарта JWT RFC. Мы можем протестировать этот модифицированный токен, используя расширение JSON Web Tokens (рис. 11.3) из Burson Suite, которое можно загрузить из BApp Store.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
NOW! |
o |
||||
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
||||
w Click |
to |
BUY 292 |
||||||||
|
|
|
|
|
|
m |
||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
Глава 11.Атака на API
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Рис.11.3. Расширение JSON Web Tokens
МожноввестизначениеJWTвпервоеполеипредоставитьфиктивныйключ. ПосколькумыбольшенеиспользуемHMAC,этозначениебудетигнорироваться. Расширение должно подтвердить,что подпись и токен JWT действительны.
Рис.11.4. Токен JWT без подписи считается действительным
Более подробную информацию об этом типе атаки можно найти на странице https://auth0.com/blog/critical-vulnerabilities-
injson-web-token-libraries/.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
||
|
|
|
C |
|
E |
|
|
|
|
|
|
|
C |
E |
|
|
|
|||||||
|
|
X |
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
||||||
|
- |
|
|
|
|
|
d |
|
|
|
- |
|
|
|
|
|
d |
|
||||||
|
F |
|
|
|
|
|
|
|
t |
|
|
F |
|
|
|
|
|
|
|
t |
|
|||
|
D |
|
|
|
|
|
|
|
|
i |
|
|
D |
|
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
|
|
r |
|
|
|
|
|
|
|
|
|
r |
||||
P |
|
|
|
|
|
NOW! |
|
o |
P |
|
|
|
|
|
NOW! |
o |
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|
|
|
|
BUY |
|
|
|
Аутентификация с помощью API 293 BUY |
|
|
|||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||
w Click |
to |
|
|
|
|
|
|
|
|
|
|
|
|
to |
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
m |
w Click |
|
|
|
|
|
|
|
m |
|||||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
|
|
|
||
|
w |
|
|
|
|
|
|
|
|
|
o |
|
|
w |
|
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
g |
.c |
|
|
. |
|
|
|
|
g |
.c |
|
|||||||
|
|
p |
|
|
|
|
|
|
|
|
|
|
p |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
e |
Эта простая атака может иметь разрушительные последствия для API, ко- |
|
|
e |
|
|||||||||||
|
|
|
df |
|
|
n |
|
|
|
|
|
|
|
|
df |
|
|
n |
|
|
|
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
|
-x cha |
|
|
|
|
|
торый использует библиотеку с небезопасной реализацией JWT. Возможность подделывать тикеты аутентификации может быть очень полезной для нас как для злоумышленников.
JWT4B
Разделять вручную заголовок, полезную нагрузку и подписи немного утомительно.Хорошобыавтоматизироватьэтотпроцесс.Еслимыориентируемся на реализацию JWT на сервере, нам также может потребоваться изменить некоторые параметры. Это трудно, особенно если приходится каждый раз пересчитывать подпись.
Расширение JWT4B было создано для проверки запросов для данных JWT, их анализа и проверки подписи–и все это в пользовательском прокси-сервере
Burp Suite.
JWT4B доступен для загрузки на GitHub на странице https:// github.com/mvetsch/JWT4B.
Как только загрузим JAR-файл JWT4B на диск,можно загрузить его вручную в Burp. На вкладке Extender (Расширитель) в разделе Extenions (Расширения) нажмите кнопку Add (Добавить).
Рис.11.5. Вкладка Extensions
Во всплывающем окне Load Burp Extension (Загрузить расширение Burp) мы можем дать указание Burp загрузить JAR-файл JWT4B из расположения на диске.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
NOW! |
o |
||||
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
||||
w Click |
to |
BUY 294 |
||||||||
|
|
|
|
|
|
m |
||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
Глава 11.Атака на API
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Рис.11.6. Загрузка файла JWT4B
JWT4Bпозволитнамперехватыватьзапросысзаголовкамиавторизации,содержащими токен JWT,заменять полезную нагрузку и подписывать повторно, используя тот же ключ (если он у нас есть) либо случайный ключ или даже изменять алгоритм подписи.
Рис.11.7. Модификация токенов JWT на лету