Ushbu bo'limda dizayn muammolari va JSON web token (JWT)larni noto'g'ri boshqarish saytlarni turli yuqori jiddiylikdagi hujumlarga qanday ochib qo'yishini ko'rib chiqamiz. JWT'lar asosan autentifikatsiya, sessiya boshqaruvi va access control mexanizmlarida ishlatilgani sababli, bu zaifliklar butun saytni va uning foydalanuvchilarini buzishi mumkin.
JSON web token (JWT) — tizimlar o'rtasida kriptografik imzolangan JSON ma'lumot yuborishning standartlashtirilgan formati. Ular istalgan ma'lumotni o'z ichiga olishi mumkin, lekin asosan foydalanuvchilar haqidagi ma'lumot ("claim"lar)ni autentifikatsiya, sessiya boshqaruvi va access control doirasida yuborish uchun ishlatiladi. Klassik sessiya tokenlaridan farqli, serverga kerak bo'lgan barcha ma'lumot JWT ichida client tomonda saqlanadi.
JWT 3 qismdan iborat: header, payload va signature — har biri nuqta bilan ajratilgan (header.payload.signature). Header va payload — base64url-kodlangan JSON obyektlari. Header token haqidagi metama'lumotni, payload esa foydalanuvchi haqidagi "claim"larni o'z ichiga oladi:
{
"iss": "portswigger",
"exp": 1648037164,
"name": "Carlos Montoya",
"sub": "carlos",
"role": "blog_author"
}Bu ma'lumotni tokenga kirishi bor har kim o'qishi yoki o'zgartirishi mumkin. Shuning uchun har qanday JWT mexanizmining xavfsizligi kriptografik imzoga qattiq tayanadi.
Tokenni chiqargan server odatda header va payloadni hashlab imzo generatsiya qiladi. Bu jarayon maxfiy imzolash kalitini o'z ichiga oladi. Imzo tokenning qolganidan bevosita kelib chiqqani uchun, header yoki payloadning bitta baytini o'zgartirish mos kelmaydigan imzoga olib keladi. Serverning maxfiy kalitini bilmasdan to'g'ri imzo generatsiya qilib bo'lmaydi.
JWT spetsifikatsiyasi JSON Web Signature (JWS) va JSON Web Encryption (JWE) bilan kengaytiriladi. Odamlar "JWT" desa, deyarli har doim JWS tokenini nazarda tutadi. JWE'da token mazmuni shifrlangan bo'ladi.
JWT hujumlari foydalanuvchining zararli maqsadga erishish uchun o'zgartirilgan JWT'larni serverga yuborishini o'z ichiga oladi. Odatda maqsad — allaqachon autentifikatsiya qilingan boshqa foydalanuvchi qiyofasiga kirib, autentifikatsiya va access control'ni chetlab o'tish. Ta'siri odatda og'ir: hujumchi ixtiyoriy qiymatli yaroqli token yarata olsa, imtiyozini oshirib yoki boshqalar qiyofasiga kirib, hisoblarini to'liq egallaydi.
JWT zaifliklari odatda ilova ichidagi buzuq JWT boshqaruvi sababli yuzaga keladi. Bu implementatsiya kamchiliklari odatda JWT imzosi to'g'ri tekshirilmasligini anglatadi — bu hujumchiga token payloadidagi qiymatlarni o'zgartirishga imkon beradi. Imzo mustahkam tekshirilsa ham, serverning maxfiy kaliti sir bo'lib qolishiga tayanadi — agar kalit sizsa yoki brute-force qilinsa, hujumchi istalgan token uchun yaroqli imzo yarata oladi.
Serverlar odatda o'zi chiqargan JWT haqida hech qanday ma'lumot saqlamaydi — har token o'zini o'zi ta'minlaydi. Shuning uchun agar server imzoni to'g'ri tekshirmasa, hujumchini tokenning qolgan qismiga ixtiyoriy o'zgartirish kiritishdan hech narsa to'xtata olmaydi. Masalan, "isAdmin": false claimini true ga o'zgartirib, imtiyozni oshirish mumkin.
JWT kutubxonalari odatda tokenni tekshiradigan (verify()) va faqat dekodlaydigan (decode()) metodlar beradi. Ba'zan dasturchilar bularni chalkashtirib, kelgan tokenni faqat decode() ga uzatadi — bu ilova imzoni umuman tekshirmasligini anglatadi.
JWT header'i alg parametrini o'z ichiga oladi — u qaysi algoritm ishlatilganini aytadi. JWT'ni imzosiz ham qoldirish mumkin — bunda alg none ga o'rnatiladi ("unsecured JWT"). Serverlar odatda bunday tokenlarni rad etadi, lekin bu filtrni klassik obfuskatsiya (aralash registr, kutilmagan kodlash) bilan chetlab o'tish mumkin.
HS256 (HMAC + SHA-256) kabi ba'zi algoritmlar ixtiyoriy standalone satrni maxfiy kalit sifatida ishlatadi. Parol kabi, bu kalit oson taxmin qilinmasligi kerak. Dasturchilar ba'zan standart yoki namuna kalitlarni o'zgartirishni unutadi. Bunda hujumchi serverning maxfiy kalitini mashhur kalitlar wordlist'i bilan brute-force qila oladi — masalan hashcat bilan:
hashcat -a 0 -m 16500 <jwt> <wordlist>Kalitni topgach, istalgan JWT header va payload uchun yaroqli imzo generatsiya qilish mumkin.
JWS spetsifikatsiyasiga ko'ra faqat alg header parametri majburiy. Amalda header (JOSE header) boshqa parametrlarni ham o'z ichiga oladi. Hujumchilar uchun qiziqlari: jwk (kalitni JSON obyekt sifatida ichiga joylaydi), jku (kalitlar to'plami URL'i), kid (kalit ID). Ular serverga imzoni tekshirishda qaysi kalitni ishlatishni aytadi.
JWS jwk header parametri serverlarga ochiq kalitni token ichiga to'g'ridan-to'g'ri JWK formatida joylashga imkon beradi. Ideal holatda serverlar faqat cheklangan oq ro'yxatdagi ochiq kalitlarni ishlatishi kerak, lekin noto'g'ri sozlangan serverlar ba'zan jwk parametridagi istalgan kalitni ishlatadi. Buni o'z RSA private kalitingiz bilan tokenni imzolab, mos ochiq kalitni jwk header'iga joylab ekspluatatsiya qilish mumkin.
Ba'zi serverlar jku (JWK Set URL) header parametri orqali kalitni o'z ichiga olgan JWK Set'ga ishora qilishga imkon beradi. Server imzoni tekshirganda shu URL'dan kalitni oladi. Xavfsizroq saytlar faqat ishonchli domenlardan kalit oladi, lekin URL tahlil nomuvofiqliklaridan foydalanib bu filtrni chetlab o'tish mumkin.
Serverlar turli ma'lumotni imzolash uchun bir nechta kalit ishlatishi mumkin, shuning uchun JWT header'i kid (Key ID) parametrini o'z ichiga olishi mumkin. JWS spetsifikatsiyasi bu ID uchun aniq struktura belgilamaydi — u shunchaki ixtiyoriy satr. Agar bu parametr path traversal'ga zaif bo'lsa, hujumchi serverni fayl tizimidagi ixtiyoriy faylni tekshiruv kaliti sifatida ishlatishga majbur qila oladi (masalan /dev/null — bo'sh fayl, uni bo'sh satr bilan imzolab yaroqli imzo olish mumkin).
{
"kid": "../../path/to/file",
"typ": "JWT",
"alg": "HS256"
}Server mustahkam maxfiy kalit ishlatsa ham, dasturchilar kutmagan algoritm bilan tokenni imzolab yaroqli JWT soxtalash mumkin. Bu algorithm confusion hujumi deb ataladi. Batafsil: JWT algorithm confusion hujumlari.
jku header uchun ruxsat etilgan hostlar qat'iy oq ro'yxatini majburlang.kid header orqali path traversal yoki SQL injection'ga zaif emasligingizni tekshiring.exp) o'rnating va aud (audience) claimini qo'shing.