
fast-jwt लाइब्रेरी में JWT एल्गोरिथम भ्रम प्रदर्शित करने वाला प्रूफ-ऑफ-कॉन्सेप्ट। सुरक्षा शिक्षा के लिए कमजोर सर्वर, टोकन जालसाजी स्क्रिप्ट और सत्यापन सुधार शामिल है।
इस रिपॉजिटरी में fast-jwt में JWT algorithm confusion को दर्शाया गया है जब token verification allowed algorithms को lock नहीं करता।
प्रोजेक्ट रूट से निम्न चलाएँ:
npm install
ऐप इन फाइलों की अपेक्षा करता है:
keys/private.pemkeys/public.pemनिम्न command sets में से एक चलाएँ।
PowerShell (Windows):
New-Item -ItemType Directory -Path keys -Force | Out-Null
openssl genrsa -out keys/private.pem 2048
openssl rsa -in keys/private.pem -RSAPublicKey_out -out keys/public.pem
Linux/macOS/Git Bash:
mkdir -p keys
openssl genrsa -out keys/private.pem 2048
openssl rsa -in keys/private.pem -RSAPublicKey_out -out keys/public.pem
node server.js
अपेक्षित आउटपुट:
Server running at http://localhost:3000
curl http://localhost:3000/generateToken
node sign.js
Printed token को कॉपी करें।
node checkAdmin.js <JWT_TOKEN>
अगर हमला सफल होता है, तो प्रतिक्रिया में Welcome Admin! शामिल होता है।
server.js में, verifier algorithms को प्रतिबंधित नहीं करता:
const verifySync = createVerifier({
key: publicKey,
});
Algorithm allowlist के बिना, सर्वर public key को HMAC secret के रूप में उपयोग करके हस्ताक्षरित एक malicious HS256 token स्वीकार कर सकता है।
हमारे CVE demos में, vulnerable object library है (अकेले नहीं चल सकती)। इसलिए एक simulated app की आवश्यकता होती है जो यह अनुकरण करे कि वास्तविक सिस्टम library के API को कैसे कॉल करता है। इस रिपॉजिटरी में, server.js simulated application layer है।
Supporting PoC code flow:
संक्षेप में, हमने library के functions को rewrite नहीं किया। हमने केवल vulnerable library के original APIs (createSigner, createVerifier) को simulated app के अंदर उपयोग किया ताकि exploit स्थिति को सटीक रूप से reproduce किया जा सके।
Verification को RS256 तक सीमित करें:
const verifySync = createVerifier({
key: publicKey,
algorithms: ["RS256"],
});
यह प्रोजेक्ट केवल नियंत्रित प्रयोगशाला वातावरण में सुरक्षा सीखने के लिए है।