PKCE: تأمين العملاء العامين

من دون PKCE، تكون تطبيقات الهاتف المحمول عرضة لهجمات اعتراض رمز التفويض. فعندما يعيد خادم التفويض توجيه رمز التفويض إلى مخطط URI المخصص المسجل للتطبيق، مثل myapp://callback، يمكن لأي تطبيق ضار على الجهاز نفسه يسجل مخطط URI نفسه اعتراض إعادة التوجيه وسرقة الرمز.

تتمثل الهجمة في أن يسجل تطبيق ضار مخطط URI المخصص نفسه الذي يستخدمه التطبيق الشرعي. وعندما يعيد خادم التفويض توجيه الرمز إلى myapp://callback، قد يعرض نظام التشغيل التطبيقين بوصفهما معالِجين لهذا العنوان. إذا اختار المستخدم التطبيق الضار أو جعله نظام التشغيل التطبيق الافتراضي، يحصل المهاجم على رمز التفويض ويمكنه استبداله بالرموز من دون معرفة سر العميل.

يضيف PKCE (RFC 7636) سرًا يُنشأ ديناميكيًا إلى تدفق رمز التفويض. وقبل بدء التدفق، ينشئ العميل سلسلة عشوائية تشفيريًا يتراوح طولها بين 43 و128 محرفًا، تُسمى متحقق الرمز. وتكون هذه السلسلة فريدة لكل طلب تفويض، ولا تُنقل حتى خطوة تبادل الرموز.

يحسب العميل تحدي الرمز من متحقق الرمز: code_challenge = BASE64URL(SHA256(code_verifier)). ويُعد استخدام SHA256 الطريقة المطلوبة في RFC 7636؛ أما طريقة "plain"، التي ترسل متحقق الرمز مباشرةً، فلا يُنصح بها. وتحدي الرمز هو تحويل أحادي الاتجاه لمتحقق الرمز، ما يعني أن معرفة التحدي لا تكشف متحقق الرمز.

يتضمن طلب التفويض معاملين إضافيين: "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256". يخزّن خادم التفويض تحدي الرمز المرتبط برمز التفويض المُصدر. ولا يُنقل في هذه المرحلة أي سر إلى الخادم يمكن اعتراضه.

أثناء تبادل الرموز، أي عند إرسال POST إلى نقطة نهاية الرموز، يتضمن العميل "code_verifier=ORIGINAL_RANDOM_STRING" إلى جانب رمز التفويض. يحسب خادم التفويض BASE64URL(SHA256(code_verifier)) ويتحقق من مطابقته لقيمة code_challenge المخزنة. ولا يستطيع اجتياز هذا التحقق إلا العميل الشرعي الذي أنشأ متحقق الرمز.

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

يمنع PKCE أيضًا هجمات حقن رمز التفويض، حيث يستبدل المهاجم رمزًا صالحًا برمز مسروق في إعادة التوجيه. لا يتطابق تحدي الرمز المسروق مع متحقق الرمز الذي سيقدمه عميل الضحية، مما يؤدي إلى فشل تبادل الرموز. يوفر PKCE دفاعًا متعدد الطبقات ضد عدة مسارات للهجوم في الوقت نفسه.

على الرغم من أن RFC 7636 وُصف في البداية بأنه حل للعملاء العامين (الذين لا يملكون أسرار عملاء)، فإن OAuth Security BCP وOAuth 2.1 يفرضان استخدام PKCE مع جميع العملاء، بما في ذلك العملاء السريون الذين يملكون أسرار عملاء. يوفر PKCE حماية مستقلة عن مصادقة العميل، مما يجعله مفيدًا للجميع.

يجمع OAuth 2.1 (draft-ietf-oauth-v2-1) أفضل الممارسات الأمنية من OAuth 2.0 Security BCP في مستند واحد. ويفرض PKCE على جميع تدفقات رمز التفويض، ويُهمل التدفق الضمني، ويتطلب تدوير رموز التحديث. وأصبح PKCE عمليًا خط الأساس المطلوب لأي تطبيق OAuth 2.0 جديد.

يتطلب تنفيذ PKCE بشكل صحيح ما يلي: استخدام مولد عشوائي آمن تشفيريًا لمتحقق الرمز (32 بايت عشوائيًا على الأقل، ثم ترميزها باستخدام base64url)، وتخزين متحقق الرمز بأمان في العميل (وليس في عنوان URL أو السجلات)، واستخدام طريقة S256 (وليس plain)، والتأكد من التخلص من متحقق الرمز بعد تبادل الرموز. تتولى معظم مكتبات OAuth الحديثة معالجة PKCE تلقائيًا.

في PKCE، ما العلاقة بين متحقق الرمز وتحدي الرمز؟

يمنع PKCE (RFC 7636) اعتراض رمز التفويض من خلال ربط كل رمز بمتحقق رمز يُنشأ ديناميكيًا ولا يعرفه سوى العميل الشرعي. يُجزّأ متحقق الرمز لإنتاج تحدي الرمز (الذي يُرسل علنًا). ويتطلب تبادل الرموز متحقق الرمز الأصلي. يمنع PKCE هجمات الاعتراض والحقن معًا. ويفرض OAuth 2.1 استخدام PKCE في جميع تدفقات رمز التفويض.