أسرة السلامة: JWT

تستخدم العديد من التطبيقات JSON Web Tokens (JWT) للسماح للعميل بتعريف نفسه لمزيد من تبادل المعلومات بعد المصادقة.

JSON Web Token هو معيار مفتوح (RFC 7519) يحدد طريقة مدمجة ومستقلة لنقل المعلومات بشكل آمن بين الأطراف ككائن JSON.


يتم التحقق من هذه المعلومات وموثوقيتها لأنها موقعة رقمياً.
يمكن توقيع JWTs باستخدام سر (باستخدام خوارزمية HMAC) أو أزواج المفاتيح العامة / الخاصة باستخدام RSA أو ECDSA.

يستخدم JSON Web Token لنقل المعلومات المتعلقة بهوية وخصائص العميل. يتم توقيع هذه "الحاوية" من قبل الخادم بحيث لا يتداخل العميل معها ولا يمكنه تغييرها ، على سبيل المثال ، بيانات التعريف أو أي خصائص (على سبيل المثال ، الدور من مستخدم بسيط إلى مسؤول أو تغيير تسجيل دخول العميل).

يتم إنشاء هذا الرمز المميز في حالة المصادقة الناجحة ويتم فحصه بواسطة الخادم قبل البدء في تنفيذ كل طلب عميل. يتم استخدام الرمز المميز بواسطة التطبيق باعتباره "بطاقة هوية" للعميل (حاوية تحتوي على جميع المعلومات عنه). الخادم لديه القدرة على التحقق من صحة وسلامة الرمز بطريقة آمنة. يسمح هذا للتطبيق بأن يكون بلا جنسية (لا يحفظ التطبيق عديم الجنسية بيانات العميل التي تم إنشاؤها في جلسة واحدة للاستخدام في الجلسة التالية مع هذا العميل (كل جلسة مستقلة)) ، وعملية المصادقة مستقلة عن الخدمات المستخدمة (بمعنى أن تقنيات العميل والخادم قد يختلف ، بما في ذلك قناة النقل ، على الرغم من أن HTTP هو الأكثر استخدامًا).

اعتبارات لاستخدام JWT

حتى إذا كان رمز JWT سهل الاستخدام ويسمح لك بتقديم خدمات (بشكل أساسي REST) ​​بدون حالة (بدون الحالة) ، فإن هذا الحل غير مناسب لجميع التطبيقات ، لأنه يأتي مع بعض المحاذير ، مثل مشكلة تخزين الرمز المميز.

إذا لم يكن التطبيق عديم الجنسية تمامًا ، فيمكنك التفكير في استخدام نظام الجلسة التقليدية الذي توفره جميع منصات الويب. ومع ذلك ، بالنسبة للتطبيقات عديمي الجنسية ، JWT يعد خيارًا جيدًا إذا تم تنفيذه بشكل صحيح.

القضايا والهجمات JWT

باستخدام خوارزمية تجزئة NONE

يحدث هجوم مشابه عندما يغير المهاجم الرمز المميز وأيضًا يغير خوارزمية التجزئة (حقل "alg") للإشارة من خلال أي كلمة رئيسية إلى أنه تم التحقق من تكامل الرمز المميز بالفعل. استعرضت بعض المكتبات الرموز المميزة الموقعة باستخدام خوارزمية لا شيء كعلامة مميزة صالحة مع توقيع تم التحقق منه ، لذلك يمكن للمهاجمين تغيير حمولة الرمز المميز ويثق التطبيق بالرمز المميز.

لمنع حدوث هجوم ، يجب عليك استخدام مكتبة JWT ، التي لا تتأثر بهذه الثغرة الأمنية. أيضًا ، أثناء التحقق من صحة الرمز المميز ، يجب أن تطلب بوضوح استخدام الخوارزمية المتوقعة.

مثال التنفيذ:

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

اعتراض الرمز

يحدث الهجوم عندما يتم اعتراض الرمز المميز أو سرقته بواسطة أحد المهاجمين ويستخدمه للوصول إلى النظام باستخدام بيانات اعتماد مستخدم معين.

تتكون الحماية من إضافة "سياق المستخدم" إلى الرمز المميز. يتكون سياق المستخدم من المعلومات التالية:

1. سلسلة عشوائية يتم إنشاؤها في مرحلة المصادقة ويتم تضمينها في الرمز المميز ، كما يتم إرسالها إلى العميل كملف تعريف ارتباط أكثر أمانًا (الإشارات: HttpOnly + Secure + SameSite + بادئة ملفات تعريف الارتباط).
2. سيتم تخزين تجزئة SHA256 من السلسلة العشوائية في الرمز المميز بحيث لا تسمح أي مشكلة XSS للمهاجم بقراءة قيمة السلسلة العشوائية وتعيين ملف تعريف الارتباط المتوقع.

لن يتم استخدام عنوان IP في السياق ، لأن هناك حالات يمكن فيها تغيير عنوان IP خلال جلسة واحدة ، على سبيل المثال ، عندما يصل المستخدم إلى التطبيق من خلال هاتفه المحمول. ثم عنوان IP يتغير باستمرار شرعي. علاوة على ذلك ، قد يؤدي استخدام عنوان IP إلى حدوث مشكلات على مستوى الامتثال للناتج المحلي الإجمالي الأوروبي.

إذا كان الرمز المميز المستلم أثناء التحقق من الرمز المميز لا يحتوي على السياق الصحيح ، فيجب رفضه.
مثال التنفيذ:

رمز لإنشاء رمز مميز بعد المصادقة الناجحة:

 //  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) للحصول على معلومات حول النظام. قد تكون المعلومات ، على سبيل المثال ، أدوار الأمان وتنسيق تسجيل الدخول وما إلى ذلك.

طريقة الحماية واضحة تمامًا وتتألف من تشفير الرمز المميز. من المهم أيضًا حماية البيانات المشفرة من الهجمات باستخدام تحليل التشفير. لتحقيق كل هذه الأهداف ، يتم استخدام خوارزمية AES-GCM ، والتي توفر تشفير مصادق مع البيانات المرتبطة (AEAD). يوفر AEAD البدائي وظيفة تشفير مصادقة متماثلة. تطبيقات هذا البدائية محمية من الهجمات التكيفية القائمة على نص مشفر محدد. عند تشفير النص العادي ، يمكنك تحديد البيانات ذات الصلة التي يجب أن تتم المصادقة عليها ولكن لا يتم تشفيرها.

وهذا يعني أن التشفير مع البيانات ذات الصلة يضمن صحة وسلامة البيانات ، ولكن ليس سريتها.

ومع ذلك ، تجدر الإشارة إلى أن التشفير يضاف بشكل رئيسي لإخفاء المعلومات الداخلية ، ولكن من المهم للغاية أن نتذكر أن الحماية الأولية ضد التزييف في الرمز المميز JWT هي التوقيع ، وبالتالي ، يجب استخدام توقيع الرمز المميز والتحقق منه دائمًا.

العميل رمزية التخزين

إذا كان التطبيق يخزن الرمز المميز بحيث يحدث واحد أو أكثر من الحالات التالية:

• يتم إرسال الرمز المميز تلقائيًا بواسطة المستعرض (تخزين ملفات تعريف الارتباط) ؛
• يتم الحصول على الرمز المميز حتى إذا تم إعادة تشغيل المستعرض (باستخدام حاوية localStorage في المستعرض) ؛
• يتم الحصول على الرمز المميز في حالة حدوث هجوم XSS (يتوفر ملف تعريف الارتباط لرمز JavaScript أو رمز مميز يتم تخزينه في localStorage أو sessionStorage).

لمنع وقوع هجوم:

1. تخزين الرمز المميز في المستعرض باستخدام حاوية sessionStorage.
2. قم بإضافته إلى رأس التخويل باستخدام مخطط Bearer. يجب أن يبدو العنوان كالتالي:
   
   

    Authorization: Bearer <token> 

3. أضف معلومات البصمة إلى الرمز المميز.

عن طريق تخزين الرمز المميز في حاوية sessionStorage ، فإنه يوفر رمزًا مميزًا للسرقة في حالة XSS. ومع ذلك ، فإن بصمة الإضافة المضافة إلى الرمز المميز تمنع المهاجم من إعادة استخدام الرمز المسروق على جهاز الكمبيوتر الخاص به. لإغلاق مناطق الاستخدام القصوى للمهاجمين ، أضف سياسة أمان المحتوى للحد من سياق التنفيذ.

تظل هناك حالة حيث يستخدم المهاجم سياق استعراض المستخدم كخادم وكيل لاستخدام التطبيق الهدف من خلال مستخدم شرعي ، ولكن يمكن لسياسة أمان المحتوى منع التواصل مع المجالات غير المتوقعة.

من الممكن أيضًا تطبيق خدمة مصادقة بحيث يتم إصدار الرمز المميز داخل ملف تعريف ارتباط آمن ، ولكن في هذه الحالة ، يجب تطبيق الحماية ضد CSRF.

استخدام مفتاح ضعيف لإنشاء رمز مميز

إذا كان السر المستخدم في حالة خوارزمية HMAC-SHA256 ، ضروري لتوقيع الرمز ، ضعيفًا ، فيمكن اختراقه (يتم التقاطه باستخدام هجوم القوة الغاشمة). نتيجة لذلك ، يمكن للمهاجم مزيف رمز تعسفي صالح من حيث التوقيع.

لمنع هذه المشكلة ، يجب عليك استخدام مفتاح سري معقد: الأحرف الأبجدية الرقمية (حالة مختلطة) + أحرف خاصة.

نظرًا لأن المفتاح ضروري فقط لحسابات الكمبيوتر ، يمكن أن يتجاوز حجم المفتاح السري 50 موقعًا.

على سبيل المثال:

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

لتقييم مدى تعقيد المفتاح السري المستخدم في توقيع الرمز المميز ، يمكنك تطبيق هجوم قاموس كلمة المرور على الرمز المميز مع واجهة برمجة تطبيقات JWT.