FixVibe
Covered by FixVibehigh

JWT Security: Mga Panganib ng Mga Hindi Secure na Token at Nawawalang Pagpapatunay ng Claim

Nagbibigay ang JSON Web Tokens (JWTs) ng pamantayan para sa paglilipat ng mga claim, ngunit umaasa ang seguridad sa mahigpit na pagpapatunay. Ang hindi pag-verify ng mga lagda, mga oras ng pag-expire, o mga nilalayong madla ay nagbibigay-daan sa mga umaatake na i-bypass ang pagpapatotoo o pag-replay ng mga token.

CWE-347CWE-287CWE-613

Epekto ng Attacker

Ang hindi wastong pagpapatunay ng JWT ay nagbibigay-daan sa mga umaatake na i-bypass ang mga mekanismo ng pagpapatunay sa pamamagitan ng pamemeke ng mga claim o muling paggamit ng mga nag-expire na token na [S1]. Kung ang isang server ay tumatanggap ng mga token nang walang wastong lagda, maaaring baguhin ng isang umaatake ang payload upang palakihin ang mga pribilehiyo o gayahin ang sinumang user na [S1]. Higit pa rito, ang pagkabigong ipatupad ang expiration (exp) na claim ay nagbibigay-daan sa isang attacker na gumamit ng isang nakompromisong token nang walang katiyakan [S1].

Root Cause

Ang JSON Web Token (JWT) ay isang istrukturang nakabatay sa JSON na ginagamit upang kumatawan sa mga claim na nilagdaan ng digital o pinoprotektahan ng integridad na [S1]. Ang mga pagkabigo sa seguridad ay karaniwang nagmumula sa dalawang pangunahing gaps sa pagpapatupad:

  • Pagtanggap ng Mga Hindi Secure na JWT: Kung ang isang serbisyo ay hindi mahigpit na nagpapatupad ng pag-verify ng lagda, maaari itong magproseso ng "Mga Hindi Secure na JWT" kung saan wala ang lagda at ang algorithm ay nakatakda sa "wala" [S1]. Sa sitwasyong ito, pinagkakatiwalaan ng server ang mga claim sa payload nang hindi bini-verify ang integridad ng mga ito [S1].
  • Nawawalang Pagpapatunay ng Claim: Ang exp (oras ng expiration) na claim ay tumutukoy sa oras kung kailan o pagkatapos nito ay hindi dapat tanggapin ang JWT para sa pagproseso ng [S1]. Tinutukoy ng claim ng aud (audience) ang mga nilalayong tatanggap ng token na [S1]. Kung hindi ito nasuri, maaaring tumanggap ang server ng mga token na nag-expire na o nilayon para sa ibang application [S1].

Mga Konkretong Pag-aayos

  • Ipatupad ang Cryptographic Signatures: I-configure ang application para tanggihan ang anumang JWT na hindi gumagamit ng pre-approved, malakas na signing algorithm (gaya ng RS256).
  • Patunayan ang Expiration: Magpatupad ng mandatoryong pagsusuri upang matiyak na ang kasalukuyang petsa at oras ay bago ang oras na tinukoy sa exp claim [S1].
  • I-verify ang Audience: Tiyaking naglalaman ang claim ng aud ng halaga na nagpapakilala sa lokal na serbisyo; kung ang serbisyo ay hindi natukoy sa aud claim, ang token ay dapat tanggihan [S1].
  • Prevent Replay: Gamitin ang jti (JWT ID) na claim upang magtalaga ng natatanging identifier sa bawat token, na nagpapahintulot sa server na subaybayan at tanggihan ang mga muling ginamit na token na [S1].

Diskarte sa Pagtuklas

Ang mga kahinaan sa paghawak ng JWT ay maaaring matukoy sa pamamagitan ng pagsusuri sa istraktura ng token at pag-uugali ng pagtugon ng server:

  • Header Inspection: Sinusuri ang alg (algorithm) header upang matiyak na hindi ito nakatakda sa "wala" at gumagamit ng inaasahang cryptographic na pamantayan [S1].
  • Pag-verify ng Claim: Kinukumpirma ang presensya at validity ng mga claim na exp (expire) at aud (audience) sa loob ng JSON payload na [S1].
  • Pagsusuri sa Pagpapatunay: Pagsubok kung tama na tinatanggihan ng server ang mga token na nag-expire na ayon sa exp claim o nilayon para sa ibang audience gaya ng tinukoy ng aud claim [S1].