أمن أنظمة مصادقة REST

https://stackoverflow.com/questions/454355

19-08-2019
|

سؤال

خلفية:

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

كانت أسئلة SO هذه مفيدة بشكل خاص لمساعدتي في البدء:

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

للوصول إلى السؤال:

يعتمد كل من S3 وOAuth على توقيع عنوان URL للطلب بالإضافة إلى عدد قليل من الرؤوس المحددة. ولم يوقع أي منهما على نص الطلب لطلبات POST أو PUT.أليس هذا عرضة لهجوم رجل في الوسط، الذي يحتفظ بعنوان URL والرؤوس ويستبدل نص الطلب بأي بيانات يريدها المهاجم؟

يبدو أنه يمكنني الوقاية من ذلك من خلال تضمين تجزئة نص الطلب في السلسلة التي يتم التوقيع عليها.هل هذا آمن؟

المحلول

ذكرت الإجابة السابقة فقط SSL في سياق نقل البيانات ولم تغطي المصادقة فعليًا.

أنت تتساءل حقًا عن المصادقة الآمنة لعملاء REST API.ما لم تكن تستخدم مصادقة عميل TLS، فإن SSL وحيد ليست آلية مصادقة قابلة للتطبيق لـ REST API.يقوم SSL بدون مصادقة العميل فقط بمصادقة الخادم, ، وهو أمر غير ذي صلة بمعظم واجهات برمجة تطبيقات REST لأنك تريد حقًا مصادقة ملف عميل.

إذا كنت لا تستخدم مصادقة عميل TLS، فستحتاج إلى استخدام شيء مثل نظام المصادقة المستند إلى الملخص (مثل النظام المخصص لـ Amazon Web Service) أو OAuth 1.0a أو حتى مصادقة HTTP الأساسية (ولكن عبر SSL فقط).

تتحقق هذه المخططات من أن الطلب قد تم إرساله بواسطة شخص متوقع.يضمن TLS (SSL) (بدون مصادقة العميل) بقاء البيانات المرسلة عبر السلك دون التلاعب بها.وهي اهتمامات منفصلة ولكنها متكاملة.

بالنسبة للمهتمين، لقد توسعت في سؤال SO حول أنظمة مصادقة HTTP وكيفية عملها.

نصائح أخرى

REST يعني العمل مع معايير الويب، ومعيار النقل "الآمن" على الويب هو SSL.أي شيء آخر سيكون غير تقليدي نوعًا ما ويتطلب جهدًا إضافيًا للنشر للعملاء، الذين يجب أن تتوفر لديهم مكتبات تشفير.

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

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

لاحظ أنه مع واجهات برمجة التطبيقات، من الأفضل للعميل أن يقوم بتمرير الرموز المميزة - سلاسل يتم إنشاؤها عشوائيًا - بدلاً من كلمة المرور التي يسجل المطور الدخول إلى موقع الويب بها.لذلك يجب أن يكون المطور قادرًا على تسجيل الدخول إلى موقعك وإنشاء رموز مميزة جديدة يمكن استخدامها للتحقق من واجهة برمجة التطبيقات (API).

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

(تم التحديث لتغطية الآثار المترتبة على جعل الاتصال SSL فقط.)

أو يمكنك استخدام الحل المعروف لهذه المشكلة واستخدام SSL.الشهادات الموقعة ذاتيًا مجانية وهي مشروع شخصي، أليس كذلك؟

إذا كنت تطلب تجزئة النص كأحد المعلمات في عنوان URL وتم توقيع عنوان URL هذا عبر مفتاح خاص، فلن يتمكن هجوم الرجل في الوسط إلا من استبدال النص بالمحتوى الذي من شأنه إنشاء نفس التجزئة.من السهل الآن التعامل مع قيم تجزئة MD5 على الأقل، وعندما يتم كسر SHA-1، حسنًا، ستحصل على الصورة.

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

في الواقع، مصادقة S3 الأصلية يفعل السماح بتوقيع المحتوى، وإن كان بتوقيع MD5 ضعيف.يمكنك ببساطة فرض ممارستهم الاختيارية المتمثلة في تضمين رأس Content-MD5 في HMAC (السلسلة المراد توقيعها).

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

يعد نظام المصادقة v4 الجديد الخاص بهم أكثر أمانًا.

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

تذكر أن اقتراحاتك تجعل من الصعب على العملاء التواصل مع الخادم.إنهم بحاجة إلى فهم الحل المبتكر الخاص بك وتشفير البيانات وفقًا لذلك، هذا النموذج ليس جيدًا لواجهة برمجة التطبيقات العامة (إلا إذا كنت Amazon\yahoo\google..).

على أي حال، إذا كان يجب عليك تشفير محتوى الجسم، فأنا أقترح عليك التحقق من المعايير والحلول الحالية مثل:

تشفير XML (معيار W3C)

أمان XML

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow