🏊 🦄 💇🏻 सुरक्षा क्रिब: JWT 😭 📎 🙆🏾

प्रमाणीकरण के बाद अधिक जानकारी के आदान-प्रदान के लिए ग्राहक को स्वयं की पहचान करने की अनुमति देने के लिए कई एप्लिकेशन JSON वेब टोकन (JWT) का उपयोग करते हैं।

JSON वेब टोकन एक खुला मानक (RFC 7519) है जो JSON ऑब्जेक्ट के रूप में पार्टियों के बीच जानकारी को सुरक्षित रूप से स्थानांतरित करने के लिए एक कॉम्पैक्ट और स्टैंडअलोन तरीका परिभाषित करता है।

यह जानकारी सत्यापित और विश्वसनीय है क्योंकि यह डिजिटल रूप से हस्ताक्षरित है।
JWTs एक रहस्य (HMAC एल्गोरिथ्म का उपयोग करके) या सार्वजनिक / निजी कुंजी जोड़े का उपयोग करके RSA या ECDSA का उपयोग करके हस्ताक्षर किए जा सकते हैं।

JSON वेब टोकन क्लाइंट की पहचान और विशेषताओं के बारे में जानकारी प्रसारित करने के लिए उपयोग किया जाता है। इस "कंटेनर" को सर्वर द्वारा हस्ताक्षरित किया जाता है ताकि ग्राहक इसमें हस्तक्षेप न करे और इसे बदल न सके, उदाहरण के लिए, पहचान डेटा या कोई विशेषता (उदाहरण के लिए, एक साधारण उपयोगकर्ता से व्यवस्थापक की भूमिका या ग्राहक का लॉगिन बदलना)।

यह टोकन सफल प्रमाणीकरण के मामले में बनाया गया है और प्रत्येक क्लाइंट अनुरोध को शुरू करने से पहले सर्वर द्वारा जाँच की जाती है। टोकन का उपयोग ग्राहक के "पहचान पत्र" (उसके बारे में सभी जानकारी वाला एक कंटेनर) के रूप में किया जाता है। सर्वर में टोकन की वैधता और अखंडता को सुरक्षित तरीके से सत्यापित करने की क्षमता है। यह एप्लिकेशन को स्टेटलेस होने की अनुमति देता है (एक स्टेटलेस एप्लिकेशन इस क्लाइंट के साथ अगले सत्र में उपयोग के लिए एक सत्र में उत्पन्न क्लाइंट डेटा को सहेजता नहीं है (प्रत्येक सत्र स्वतंत्र है)), और प्रमाणीकरण प्रक्रिया उपयोग की जाने वाली सेवाओं से स्वतंत्र है (इस अर्थ में कि क्लाइंट और सर्वर प्रौद्योगिकियां ट्रांसपोर्ट चैनल, भले ही HTTP का सबसे अधिक उपयोग किया जाता है, सहित भिन्न हो सकते हैं)।

JWT का उपयोग करने के लिए विचार

यहां तक कि अगर JWT टोकन का उपयोग करना आसान है और आपको राज्यस्तरीय (स्टेटलेस) बिना सेवाएं (मुख्य रूप से REST) प्रदान करने की अनुमति देता है, तो यह समाधान सभी अनुप्रयोगों के लिए उपयुक्त नहीं है क्योंकि यह कुछ कैविएट के साथ आता है, जैसे कि टोकन के भंडारण का मुद्दा।

यदि एप्लिकेशन को पूरी तरह से स्टेटलेस नहीं होना है, तो आप सभी वेब प्लेटफार्मों द्वारा प्रदान किए गए पारंपरिक सत्र प्रणाली का उपयोग करने पर विचार कर सकते हैं। हालांकि, स्टेटलेस एप्लिकेशन के लिए, JWT एक अच्छा विकल्प है अगर इसे सही तरीके से लागू किया जाए।

JWT मुद्दे और हमलों

None Hash Algorithm का उपयोग करना

एक समान हमला तब होता है जब कोई हमलावर टोकन बदलता है और किसी भी कीवर्ड के माध्यम से इंगित करने के लिए हैशिंग एल्गोरिथ्म ("एल्ग" फ़ील्ड) में भी बदलाव करता है कि टोकन अखंडता पहले ही सत्यापित हो चुकी है। कुछ पुस्तकालयों ने सत्यापित एल्गोरिदम के साथ एक वैध टोकन के रूप में कोई भी एल्गोरिथ्म का उपयोग करते हुए टोकन पर हस्ताक्षर किए, इसलिए एक हमलावर टोकन के पेलोड को बदल सकता है और आवेदन टोकन पर भरोसा करेगा।

किसी हमले को रोकने के लिए, आपको JWT लाइब्रेरी का उपयोग करना चाहिए, जो इस भेद्यता से प्रभावित नहीं है। इसके अलावा, टोकन के सत्यापन के दौरान, आपको स्पष्ट रूप से अपेक्षित एल्गोरिदम के उपयोग का अनुरोध करना चाहिए।

कार्यान्वयन उदाहरण:

//  HMAC   String   JVM private transient byte[] keyHMAC = ...; ... //        //    HMAC-256 - JWTVerifier verifier = JWT.require(Algorithm.HMAC256(keyHMAC)).build(); //   DecodedJWT decodedToken = verifier.verify(token);

टोकन अवरोधन

यह हमला तब होता है जब किसी हमलावर द्वारा किसी टोकन को इंटरसेप्ट या चोरी किया गया हो और वह किसी विशिष्ट उपयोगकर्ता के क्रेडेंशियल्स का उपयोग करके सिस्टम तक पहुंच प्राप्त करने के लिए इसका उपयोग करता है।

टोकन में "उपयोगकर्ता संदर्भ" जोड़ने में सुरक्षा शामिल है। उपयोगकर्ता संदर्भ में निम्नलिखित जानकारी शामिल होगी:

एक यादृच्छिक स्ट्रिंग जो प्रमाणीकरण चरण में उत्पन्न होती है और इसे टोकन में शामिल किया जाता है, और क्लाइंट को एक अधिक सुरक्षित कुकी (झंडे: HttpOnly + Secure + SameSite + कुकी उपसर्ग) के रूप में भी भेजा जाता है।
यादृच्छिक स्ट्रिंग से SHA256 हैश को टोकन में संग्रहीत किया जाएगा ताकि किसी भी XSS समस्या हमलावर को यादृच्छिक स्ट्रिंग के मूल्य को पढ़ने और अपेक्षित कुकी सेट करने की अनुमति न दे।

आईपी पते का उपयोग संदर्भ में नहीं किया जाएगा, क्योंकि ऐसी परिस्थितियां हैं जिनमें एक सत्र के दौरान आईपी पता बदल सकता है, उदाहरण के लिए, जब कोई उपयोगकर्ता अपने मोबाइल फोन के माध्यम से एप्लिकेशन का उपयोग करता है। फिर आईपी एड्रेस लगातार वैध रूप से बदल रहा है। इसके अलावा, IP पते का उपयोग करने से यूरोपीय GDPR के अनुपालन के स्तर पर समस्याएँ पैदा हो सकती हैं।

यदि टोकन सत्यापन के दौरान प्राप्त टोकन में सही संदर्भ नहीं है, तो इसे अस्वीकार कर दिया जाना चाहिए।
कार्यान्वयन उदाहरण:

सफल प्रमाणीकरण के बाद टोकन बनाने के लिए कोड:

 //  HMAC   String   JVM private transient byte[] keyHMAC = ...; //    private SecureRandom secureRandom = new SecureRandom(); ... //   ,     byte[] randomFgp = new byte[50]; secureRandom.nextBytes(randomFgp); String userFingerprint = DatatypeConverter.printHexBinary(randomFgp); //    cookie String fingerprintCookie = "__Secure-Fgp=" + userFingerprint + "; SameSite=Strict; HttpOnly; Secure"; response.addHeader("Set-Cookie", fingerprintCookie); // SHA256          // (  )  XSS      //     cookie MessageDigest digest = MessageDigest.getInstance("SHA-256"); byte[] userFingerprintDigest = digest.digest(userFingerprint.getBytes("utf-8")); String userFingerprintHash = DatatypeConverter.printHexBinary(userFingerprintDigest); //      15     Calendar c = Calendar.getInstance(); Date now = c.getTime(); c.add(Calendar.MINUTE, 15); Date expirationDate = c.getTime(); Map<String, Object> headerClaims = new HashMap<>(); headerClaims.put("typ", "JWT"); String token = JWT.create().withSubject(login) .withExpiresAt(expirationDate) .withIssuer(this.issuerID) .withIssuedAt(now) .withNotBefore(now) .withClaim("userFingerprint", userFingerprintHash) .withHeader(headerClaims) .sign(Algorithm.HMAC256(this.keyHMAC));

टोकन की वैधता को सत्यापित करने के लिए कोड:

 //  HMAC   String   JVM private transient byte[] keyHMAC = ...; ... //     cookie String userFingerprint = null; if (request.getCookies() != null && request.getCookies().length > 0) { List<Cookie> cookies = Arrays.stream(request.getCookies()).collect(Collectors.toList()); Optional<Cookie> cookie = cookies.stream().filter(c -> "__Secure-Fgp" .equals(c.getName())).findFirst(); if (cookie.isPresent()) { userFingerprint = cookie.get().getValue(); } } //  SHA256      cookie  //       MessageDigest digest = MessageDigest.getInstance("SHA-256"); byte[] userFingerprintDigest = digest.digest(userFingerprint.getBytes("utf-8")); String userFingerprintHash = DatatypeConverter.printHexBinary(userFingerprintDigest); //      JWTVerifier verifier = JWT.require(Algorithm.HMAC256(keyHMAC)) .withIssuer(issuerID) .withClaim("userFingerprint", userFingerprintHash) .build(); //   DecodedJWT decodedToken = verifier.verify(token);

उपयोगकर्ता द्वारा टोकन का स्पष्ट निरसन

चूंकि टोकन समाप्ति के बाद ही अमान्य हो जाता है, इसलिए उपयोगकर्ता के पास एक अंतर्निहित फ़ंक्शन नहीं है जो आपको टोकन को स्पष्ट रूप से रद्द करने की अनुमति देता है। इस प्रकार, चोरी के मामले में, उपयोगकर्ता स्वयं टोकन वापस नहीं ले सकता है और फिर हमलावर को ब्लॉक कर सकता है।

सुरक्षा विधियों में से एक टोकन की एक ब्लैकलिस्ट की शुरूआत है, जो पारंपरिक सत्र प्रणाली में मौजूद "लॉग आउट" फ़ंक्शन के अनुकरण के लिए उपयुक्त होगा।

रद्द करने की तारीख के साथ टोकन का संग्रह (SHA-256 एन्कोडिंग HEX में), जो जारी किए गए टोकन की वैधता अवधि से अधिक होना चाहिए, काली सूची में संग्रहीत किया जाएगा।

जब उपयोगकर्ता "लॉग आउट" करना चाहता है, तो वह एक विशेष सेवा को कॉल करता है जो प्रदान किए गए उपयोगकर्ता टोकन को काली सूची में जोड़ता है, जिससे आवेदन में आगे उपयोग के लिए टोकन को तत्काल रद्द कर दिया जाता है।

कार्यान्वयन उदाहरण:

ब्लैकलिस्ट रिपॉजिटरी:
काली सूची के केंद्रीकृत भंडारण के लिए, निम्नलिखित संरचना वाले डेटाबेस का उपयोग किया जाएगा:

 create table if not exists revoked_token(jwt_token_digest varchar(255) primary key, revokation_date timestamp default now());

टोकन निरस्तीकरण प्रबंधन:

 //    (logout). //  ,      //         . public class TokenRevoker { //    @Resource("jdbc/storeDS") private DataSource storeDS; //      public boolean isTokenRevoked(String jwtInHex) throws Exception { boolean tokenIsPresent = false; if (jwtInHex != null && !jwtInHex.trim().isEmpty()) { //   byte[] cipheredToken = DatatypeConverter.parseHexBinary(jwtInHex); //  SHA256   MessageDigest digest = MessageDigest.getInstance("SHA-256"); byte[] cipheredTokenDigest = digest.digest(cipheredToken); String jwtTokenDigestInHex = DatatypeConverter.printHexBinary(cipheredTokenDigest); //     try (Connection con = this.storeDS.getConnection()) { String query = "select jwt_token_digest from revoked_token where jwt_token_digest = ?"; try (PreparedStatement pStatement = con.prepareStatement(query)) { pStatement.setString(1, jwtTokenDigestInHex); try (ResultSet rSet = pStatement.executeQuery()) { tokenIsPresent = rSet.next(); } } } } return tokenIsPresent; } //    HEX      public void revokeToken(String jwtInHex) throws Exception { if (jwtInHex != null && !jwtInHex.trim().isEmpty()) { //   byte[] cipheredToken = DatatypeConverter.parseHexBinary(jwtInHex); //  SHA256   MessageDigest digest = MessageDigest.getInstance("SHA-256"); byte[] cipheredTokenDigest = digest.digest(cipheredToken); String jwtTokenDigestInHex = DatatypeConverter.printHexBinary(cipheredTokenDigest); //             //   if (!this.isTokenRevoked(jwtInHex)) { try (Connection con = this.storeDS.getConnection()) { String query = "insert into revoked_token(jwt_token_digest) values(?)"; int insertedRecordCount; try (PreparedStatement pStatement = con.prepareStatement(query)) { pStatement.setString(1, jwtTokenDigestInHex); insertedRecordCount = pStatement.executeUpdate(); } if (insertedRecordCount != 1) { throw new IllegalStateException("Number of inserted record is invalid," + " 1 expected but is " + insertedRecordCount); } } } } }

टोकन प्रकटीकरण

यह हमला तब होता है जब एक हमलावर टोकन (या टोकन का एक सेट) तक पहुंच प्राप्त करता है और सिस्टम के बारे में जानकारी प्राप्त करने के लिए इसमें संग्रहीत जानकारी को निकालता है (JWT टोकन के बारे में जानकारी base64 का उपयोग करके इनकोड किया गया है)। उदाहरण के लिए, सुरक्षा भूमिकाएं, लॉगिन प्रारूप इत्यादि जैसी जानकारी हो सकती है।

संरक्षण विधि काफी स्पष्ट है और टोकन को एन्क्रिप्ट करने में शामिल है। एन्क्रिप्टेड डेटा को क्रिप्टोनालिसिस का उपयोग करके हमलों से बचाने के लिए भी महत्वपूर्ण है। इन सभी लक्ष्यों को प्राप्त करने के लिए, एईएस-जीसीएम एल्गोरिथ्म का उपयोग किया जाता है, जो एसोसिएटेड डेटा (AEAD) के साथ प्रमाणित एन्क्रिप्शन प्रदान करता है। AEAD आदिम सममित प्रमाणित एन्क्रिप्शन कार्यक्षमता प्रदान करता है। इस आदिम के कार्यान्वयन को चयनित सिफरटेक्ट के आधार पर अनुकूली हमलों से बचाया जाता है। प्लेनटेक्स्ट को एन्क्रिप्ट करते समय, आप वैकल्पिक रूप से संबंधित डेटा को निर्दिष्ट कर सकते हैं जिसे प्रमाणित किया जाना चाहिए लेकिन एन्क्रिप्ट नहीं किया गया है।

यही है, प्रासंगिक डेटा के साथ एन्क्रिप्शन डेटा की प्रामाणिकता और अखंडता सुनिश्चित करता है, लेकिन उनकी गोपनीयता नहीं।

हालांकि, यह ध्यान दिया जाना चाहिए कि एन्क्रिप्शन मुख्य रूप से आंतरिक जानकारी को छिपाने के लिए जोड़ा जाता है, लेकिन यह याद रखना बहुत महत्वपूर्ण है कि जेडडब्ल्यूटी टोकन के जालसाजी के खिलाफ प्रारंभिक सुरक्षा हस्ताक्षर है, इसलिए, टोकन के हस्ताक्षर और इसके सत्यापन का हमेशा उपयोग किया जाना चाहिए।

क्लाइंट साइड टोकन स्टोरेज

यदि अनुप्रयोग टोकन को संग्रहीत करता है ताकि निम्न में से एक या अधिक परिस्थितियाँ उत्पन्न हों:

टोकन स्वचालित रूप से ब्राउज़र (कुकी भंडारण) द्वारा भेजा जाता है;
यदि ब्राउज़र को पुनरारंभ किया जाता है, तब भी टोकन प्राप्त किया जाता है (ब्राउज़र लोकलस्टोरेज कंटेनर का उपयोग करके);
टोकन XSS हमले (जावास्क्रिप्ट कोड के लिए उपलब्ध कुकी या लोकलस्टोरेज या सेशनस्टोर में संग्रहीत टोकन) के मामले में प्राप्त किया जाता है।

किसी हमले को रोकने के लिए:

सेशनस्टोरेज कंटेनर का उपयोग करके ब्राउज़र में टोकन स्टोर करें।
इसे बियरर स्कीम का उपयोग करके प्राधिकरण हेडर में जोड़ें। शीर्षक इस तरह दिखना चाहिए:
```
 Authorization: Bearer <token> 
```
टोकन में फिंगरप्रिंट जानकारी जोड़ें।

सेशनस्टोरेज कंटेनर में टोकन स्टोर करके, यह XSS के मामले में चोरी के लिए टोकन प्रदान करता है। हालांकि, टोकन में जोड़ा गया एक फिंगरप्रिंट किसी हमलावर को उसके कंप्यूटर पर चोरी किए गए टोकन का पुन: उपयोग करने से रोकता है। एक हमलावर के लिए अधिकतम उपयोग क्षेत्रों को बंद करने के लिए, निष्पादन संदर्भ को सीमित करने के लिए एक सामग्री सुरक्षा नीति जोड़ें।

एक मामला बना हुआ है जहां एक हमलावर उपयोगकर्ता के ब्राउज़िंग संदर्भ को एक वैध उपयोगकर्ता के माध्यम से लक्ष्य एप्लिकेशन का उपयोग करने के लिए प्रॉक्सी सर्वर के रूप में उपयोग करता है, लेकिन सामग्री सुरक्षा नीति अप्रत्याशित डोमेन के साथ संचार को रोक सकती है।

प्रमाणीकरण सेवा को लागू करना भी संभव है ताकि टोकन एक सुरक्षित कुकी के अंदर जारी किया जाए, लेकिन इस मामले में, सीएसआरएफ के खिलाफ सुरक्षा को लागू किया जाना चाहिए।

टोकन बनाने के लिए एक कमजोर कुंजी का उपयोग करना

यदि टोकन पर हस्ताक्षर करने के लिए आवश्यक HMAC-SHA256 एल्गोरिथ्म के मामले में उपयोग किया जाने वाला रहस्य कमजोर है, तो इसे हैक किया जा सकता है (जानवर बल के हमले का उपयोग करके उठाया गया)। नतीजतन, एक हमलावर हस्ताक्षर के मामले में एक मनमाना वैध टोकन नकली कर सकता है।

इस समस्या को रोकने के लिए, आपको एक जटिल गुप्त कुंजी का उपयोग करना चाहिए: अल्फ़ान्यूमेरिक (मिश्रित मामला) + विशेष वर्ण।

चूँकि केवल कंप्यूटर गणना के लिए कुंजी की आवश्यकता होती है, इसलिए गुप्त कुंजी का आकार 50 स्थिति से अधिक हो सकता है।

उदाहरण के लिए:

 A&'/}Z57M(2hNg=;LE?~]YtRMS5(yZ<vcZTA3N-($>2j:ZeX-BGftaVk`)jKP~q?,jk)EMbgt*kW'

अपने टोकन हस्ताक्षर के लिए उपयोग की जाने वाली गुप्त कुंजी की जटिलता का आकलन करने के लिए, आप JWT API के साथ संयोजन में एक पासवर्ड शब्दकोश हमले को टोकन पर लागू कर सकते हैं।

सुरक्षा क्रिब: JWT