FixVibe
Covered by FixVibehigh

JWT Сигурност: Рискове от незащитени токени и липсващо валидиране на искове

JSON уеб токените (JWT) предоставят стандарт за прехвърляне на искове, но сигурността разчита на стриктно валидиране. Неуспешната проверка на подписи, времена на изтичане или предвидени аудитории позволява на атакуващите да заобиколят удостоверяването или да възпроизвеждат токени.

CWE-347CWE-287CWE-613

Въздействие на нападателя

Неправилното валидиране на JWT позволява на атакуващите да заобиколят механизмите за удостоверяване чрез подправяне на искове или повторно използване на изтекли токени [S1]. Ако сървър приеме токени без валиден подпис, атакуващият може да промени полезния товар, за да ескалира привилегиите или да имитира всеки потребител [S1]. Освен това, неуспешното прилагане на искането за изтичане (exp) позволява на атакуващия да използва компрометиран токен за неопределено време [S1].

Първопричина

JSON уеб токен (JWT) е базирана на JSON структура, използвана за представяне на искове, които са цифрово подписани или защитени с целостта [S1]. Провалите в сигурността обикновено произтичат от две основни пропуски в изпълнението:

  • Приемане на незащитени JWT: Ако дадена услуга не налага стриктно проверка на подписа, тя може да обработва „Незащитени JWT“, където подписът липсва и алгоритъмът е настроен на „няма“ [S1]. В този сценарий сървърът се доверява на твърденията в полезния товар, без да проверява тяхната цялост [S1].
  • Липсващо валидиране на искове: Искът exp (време на изтичане) идентифицира времето, на или след което JWT не трябва да бъде приет за обработка [S1]. Искът aud (аудитория) идентифицира предвидените получатели на токена [S1]. Ако те не са отметнати, сървърът може да приеме токени, които са с изтекъл срок или са предназначени за друго приложение [S1].

Конкретни поправки

  • Прилагане на криптографски подписи: Конфигурирайте приложението да отхвърля всеки JWT, който не използва предварително одобрен, силен алгоритъм за подписване (като RS256).
  • Потвърдете изтичане: Приложете задължителна проверка, за да се уверите, че текущата дата и час са преди времето, посочено в искането exp [S1].
  • Проверете аудиторията: Уверете се, че искът aud съдържа стойност, идентифицираща локалната услуга; ако услугата не е идентифицирана в искането aud, токенът трябва да бъде отхвърлен [S1].
  • Предотвратяване на повторение: Използвайте искането jti (JWT ID), за да присвоите уникален идентификатор на всеки токен, което позволява на сървъра да проследява и отхвърля повторно използваните токени [S1].

Стратегия за откриване

Уязвимостите при обработката на JWT могат да бъдат идентифицирани чрез анализиране на структурата на токена и поведението на реакция на сървъра:

  • Проверка на заглавката: Проверка на заглавката alg (алгоритъм), за да се уверите, че не е зададена на „няма“ и използва очакваните криптографски стандарти [S1].
  • Проверка на искове: Потвърждаване на наличието и валидността на претенциите exp (изтичане) и aud (аудитория) в JSON полезния товар [S1].
  • Тестване за потвърждаване: Тества се дали сървърът правилно отхвърля токени, които са изтекли съгласно претенцията exp или са предназначени за различна аудитория, както е дефинирано от претенцията aud [S1].