JWT Biztonság: a nem biztosított tokenek és a hiányzó követelés érvényesítésének kockázatai

Támadó hatás

A nem megfelelő JWT érvényesítés lehetővé teszi a támadók számára, hogy megkerüljék a hitelesítési mechanizmusokat követelések hamisításával vagy lejárt tokenek [S1] újrafelhasználásával. Ha egy kiszolgáló elfogadja a jogkivonatokat érvényes aláírás nélkül, a támadó módosíthatja a hasznos terhelést a jogosultságok kiszélesítése érdekében, vagy bármely felhasználónak kiadhatja magát. [S1]. Továbbá a lejárati (exp) követelés érvényesítésének elmulasztása lehetővé teszi a támadó számára, hogy korlátlan ideig használja a feltört tokent. [S1].

Kiváltó ok

A JSON webes token (JWT) egy JSON-alapú struktúra, amely digitálisan aláírt vagy integritásvédett [S1] követelések megjelenítésére szolgál. A biztonsági hibák általában két elsődleges megvalósítási hiányosságból erednek:

• Nem biztonságos JWT-k elfogadása: Ha egy szolgáltatás nem kényszeríti ki szigorúan az aláírás-ellenőrzést, akkor feldolgozhatja a "nem biztonságos JWT-ket", ha az aláírás hiányzik, és az algoritmus "nincs" értékre van állítva. [S1]. Ebben a forgatókönyvben a kiszolgáló megbízik a hasznos adatban lévő követelésekben anélkül, hogy ellenőrizné azok integritását. [S1].
• Hiányzó igényérvényesítés: A exp (lejárati idő) igény azonosítja azt az időpontot, amelyen vagy utána a JWT nem fogadható el a [S1] feldolgozására. A aud (közönség) követelés azonosítja a [S1] token tervezett címzettjeit. Ha ezek nincsenek bejelölve, a szerver elfogadhat olyan tokeneket, amelyek lejártak, vagy más alkalmazáshoz készültek. [S1].

Konkrét javítások

• Rejtjelezési aláírások kényszerítése: Konfigurálja az alkalmazást minden olyan JWT elutasítására, amely nem használ előre jóváhagyott, erős aláírási algoritmust (például RS256).
• Lejárat érvényesítése: Végezzen kötelező ellenőrzést, hogy megbizonyosodjon arról, hogy az aktuális dátum és idő a exp [S1] követelésben meghatározott időpont előtt van.
• Közönség ellenőrzése: Győződjön meg arról, hogy a aud igény tartalmazza a helyi szolgáltatást azonosító értéket; ha a szolgáltatás nincs azonosítva a aud igényben, akkor a tokent el kell utasítani [S1].
• A visszajátszás megakadályozása: Használja a jti (JWT ID) igényt, hogy minden tokenhez egyedi azonosítót rendeljen, lehetővé téve a szerver számára, hogy nyomon kövesse és elutasítsa az újrafelhasznált tokenek [S1].

Észlelési stratégia

A JWT kezelésének sérülékenységei a token szerkezetének és a szerver válasz viselkedésének elemzésével azonosíthatók:

• Fejléc-ellenőrzés: A alg (algoritmus) fejléc ellenőrzése, hogy megbizonyosodjon arról, hogy nincs-e „nincs” értékre állítva, és a [S1] elvárt kriptográfiai szabványokat használja.
• Követelések ellenőrzése: A exp (lejárat) és aud (közönség) követelések meglétének és érvényességének megerősítése a [S1] JSON hasznos adatban.
• Érvényesítési tesztelés: Annak tesztelése, hogy a szerver helyesen utasítja-e el a exp követelés szerint lejárt, vagy a aud [S1] követelésben meghatározott más közönségnek szánt tokeneket.