FixVibe
Covered by FixVibehigh

JWT Безбедност: ризици од необезбедени токени и валидација на барањето што недостасува

JSON Web Tokens (JWTs) обезбедуваат стандард за пренос на побарувања, но безбедноста се потпира на ригорозна валидација. Неуспехот да се потврдат потписите, времето на истекување или наменетата публика им овозможува на напаѓачите да ги заобиколат токените за автентикација или репродукција.

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].