CVE-2026-23552 - قبول التوكنات عبر العوالم (Realms) في camel-keycloak

نظرة عامة

لا يتحقق KeycloakSecurityPolicy في Apache Camel من مطالبة iss (المُصدِر) في توكنات JWT مقابل العالم (Realm) المهيأ. وهذا يعني أن توكنًا صادرًا عن عالم Keycloak واحد يُقبل بصمت من قِبل سياسة مهيأة لعالم مختلف تمامًا، مما يكسر عزل المستأجرين.

الإصدارات المتأثرة: 4.15.0، 4.16.0، 4.17.0

مُتتبَّع في: https://issues.apache.org/jira/browse/CAMEL-22854

السبب الجذري

في KeycloakSecurityHelper.parseAccessToken()، عندما لا يُوفَّر مفتاح عام صراحةً (وهو التكوين الافتراضي)، يتم فقط فك تشفير التوكن من Base64 — دون أي تحقق منه:

public static AccessToken parseAccessToken(String tokenString, PublicKey publicKey)
        throws VerificationException {
    if (publicKey != null) {
        return TokenVerifier.create(tokenString, AccessToken.class)
                .publicKey(publicKey)
                .verify()
                .getToken();
    } else {
        // no signature verification, no issuer check
        return TokenVerifier.create(tokenString, AccessToken.class).getToken();
    }
}

وبما أن مسار الكود الافتراضي يصل إلى فرع else، تبقى ثلاثة أمور دون فحص:

1. توقيع التوكن لا يُتحقق منه أبدًا
2. مطالبة iss لا تُقارن أبدًا بالقيمة المتوقعة {serverUrl}/realms/{realm}
3. لا يُجلب أي مفتاح عام من JWKS من Keycloak

ويظل فحص الدور ناجحًا لأنه ينظر فقط إلى أسماء الأدوار داخل حمولة التوكن. إذا صادف أن اسم الدور (tenant-user) متطابق عبر العوالم — وهو أمر شائع في الإعدادات متعددة المستأجرين — يمر الطلب.

التأثير

في تطبيق متعدد المستأجرين حيث يُرتبط كل مستأجر بعالم Keycloak منفصل، يمكن لمستخدم من المستأجر A الوصول إلى مسارات محمية للمستأجر B. على وجه التحديد:

• الوصول إلى البيانات عبر المستأجرين في تطبيقات SaaS متعددة المستأجرين
• تصعيد الامتيازات عندما تكون للعوالم المختلفة تكوينات أدوار مختلفة
• تجاوز كامل لعزل الحماية القائم على العوالم

إعادة الإنتاج

يُظهر هذا المشروع الثغرة باستخدام Apache Camel 4.17.0 ومثيل Keycloak محلي.

المتطلبات الأساسية

• Java 17+
• Maven 3.9+
• أداة سطر الأوامر Camel JBang CLI (jbang app install camel@apache/camel)
• Docker أو Podman (يستخدمها camel infra داخليًا)

الإعداد

شغّل Keycloak محليًا:

camel infra run keycloak

يبدأ هذا تشغيل Keycloak على localhost:8080 ببيانات اعتماد المدير admin/admin.

التشغيل

mvn verify

ما الذي يحدث

يقوم اختبار التكامل (CrossRealmTokenBypassIT) بما يلي:

1. يتصل بمثيل Keycloak المحلي وينشئ عالمين: acme وglobex
2. ينشئ عميلًا سريًا في كل عالم مع تفعيل منح الوصول المباشر
3. ينشئ دور العالم tenant-user في كلا العالمين
4. ينشئ المستخدم alice (كلمة المرور alice123) في عالم acme ويمنحها دور tenant-user
5. يهيئ مسار Camel (direct:globex-protected) محميًا بسياسة KeycloakSecurityPolicy مرتبطة بعالم globex
6. يحصل على توكن JWT للمستخدم alice من عالم acme (المُصدِر: http://localhost:8080/realms/acme)
7. يرسل ذلك التوكن إلى المسار المحمي لعالم

ينجح الطلب. يمر توكن acme من سياسة globex دون أي خطأ.

نتائج الاختبار المتوقعة على الإصدار 4.17.0

على إصدار مُصحَّح (4.18.0+)، سيفشل الاختبار الثاني وينجح الثالث.

التنظيف

camel infra stop keycloak

كما يزيل الاختبار عالمي acme وglobex في @AfterAll.

الإصلاح

يجب على KeycloakSecurityPolicy رفض التوكنات التي لا تتطابق فيها مطالبة iss مع {serverUrl}/realms/{realm}. الإصلاح مُتتبَّع في CAMEL-22854 وسيُطرح مع الإصدار Camel 4.18.0 (الإصدار التالي طويل الدعم LTS).