أفضل الممارسات لتأمين REST API / خدمة الويب [مغلق]

https://stackoverflow.com/questions/7551

08-06-2019
|

سؤال

عند تصميم واجهة برمجة تطبيقات أو خدمة REST، هل هناك أي ممارسات أفضل للتعامل مع الأمان (المصادقة، التفويض، إدارة الهوية)؟

عند إنشاء SOAP API، يكون لديك WS-Security كدليل ويوجد الكثير من المؤلفات حول هذا الموضوع.لقد وجدت معلومات أقل حول تأمين نقاط نهاية REST.

على الرغم من أنني أفهم أن REST لا يحتوي عن قصد على مواصفات مشابهة لـ WS-*، إلا أنني آمل أن تظهر أفضل الممارسات أو الأنماط الموصى بها.

أي مناقشة أو روابط للوثائق ذات الصلة ستكون موضع تقدير كبير.إذا كان الأمر مهمًا، فسنستخدم WCF مع رسائل POX/JSON المتسلسلة لواجهات/خدمات REST API الخاصة بنا والتي تم إنشاؤها باستخدام الإصدار 3.5 من .NET Framework.

المحلول

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

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

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

نصائح أخرى

لا توجد معايير لـ REST بخلاف HTTP.توجد خدمات REST موجودة هناك.أقترح عليك إلقاء نظرة خاطفة عليهم والتعرف على كيفية عملهم.

على سبيل المثال، استعرنا الكثير من الأفكار من خدمة Amazon S3 REST عند تطوير خدماتنا الخاصة.لكننا اخترنا عدم استخدام نموذج الأمان الأكثر تقدمًا استنادًا إلى توقيعات الطلب.الطريقة الأبسط هي مصادقة HTTP الأساسية عبر SSL.عليك أن تقرر ما هو الأفضل في حالتك.

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

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

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

توجد قائمة مرجعية رائعة موجودة في جيثب:

المصادقة

لا تعيد اختراع العجلة في المصادقة، وإنشاء الرمز المميز، وتخزين كلمات المرور.استخدم المعايير.
يستخدم Max Retry وميزات السجن في تسجيل الدخول.
استخدم التشفير على جميع البيانات الحساسة.

JWT (رمز الويب JSON)

استخدم مفتاحًا عشوائيًا معقدًا (JWT Secret) لجعل القوة الغاشمة للرمز المميز صعبة للغاية.
لا تستخرج الخوارزمية من الحمولة.فرض الخوارزمية في الواجهة الخلفية (HS256 أو RS256).
انتهاء صلاحية الرمز المميز (TTL, RTTL) أقصرما يمكن.
لا تقم بتخزين البيانات الحساسة في JWT الحمولة، ويمكن فك تشفيرها بسهولة.

OAuth

التحقق من صحة دائما redirect_uri من جانب الخادم للسماح فقط بعناوين URL المدرجة في القائمة البيضاء.
حاول دائمًا استبدال الرموز وليس الرموز المميزة (لا تسمح response_type=token).
استخدم معلمة الحالة مع تجزئة عشوائية لمنعها CSRF على ال OAuth عملية المصادقة.
تحديد النطاق الافتراضي، والتحقق من صحة معلمات النطاق لكل تطبيق.

وصول

الحد من الطلبات (الاختناق) لتجنب هجمات DDoS/القوة الغاشمة.
استخدم HTTPS على جانب الخادم لتجنب MITM (هجوم الرجل في الوسط)
يستخدم HSTS رأس مع SSL لتجنب هجوم SSL Strip.

مدخل

استخدم طريقة HTTP المناسبة وفقًا للعملية: GET (يقرأ)، POST (يخلق)، PUT/PATCH (استبدال/تحديث)، و DELETE (لحذف سجل)، والرد مع 405 Method Not Allowed إذا كانت الطريقة المطلوبة غير مناسبة للمورد المطلوب.
التحقق من صحة نوع المحتوى عند الطلب Accept الرأس (التفاوض على المحتوى) للسماح فقط بالتنسيق المدعوم (على سبيل المثال. application/xml, application/json, الخ) والرد عليها 406 Not Acceptable الاستجابة إذا لم تكن متطابقة.
التحقق من صحة content-type من البيانات المنشورة كما تقبلها (على سبيل المثال. application/x-www-form-urlencoded, multipart/form-data, application/json, ، إلخ).
التحقق من صحة إدخال المستخدم لتجنب الثغرات الأمنية الشائعة (على سبيل المثال.XSS، وحقن SQL، وتنفيذ التعليمات البرمجية عن بعد، وما إلى ذلك).
لا تستخدم أي بيانات حساسة (بيانات الاعتماد أو كلمات المرور أو رموز الأمان أو مفاتيح واجهة برمجة التطبيقات) في عنوان URL، ولكن استخدم المعيار Authorization header.
استخدم خدمة بوابة API لتمكين التخزين المؤقت، Rate Limit السياسات (على سبيل المثالالحصة، والاعتقال المفاجئ، وحد المعدل المتزامن) ونشر موارد واجهات برمجة التطبيقات ديناميكيًا.

يعالج

تحقق مما إذا كانت كافة نقاط النهاية محمية خلف المصادقة لتجنب عملية المصادقة المعطلة.
يجب تجنب معرف المورد الخاص بالمستخدم.استخدم /me/orders بدلاً من /user/654321/orders.
لا تقم بزيادة المعرفات تلقائيًا.استخدم UUID بدلاً من ذلك.
إذا كنت تقوم بتحليل ملفات XML، فتأكد من عدم تمكين تحليل الكيان لتجنب XXE (هجوم كيان XML الخارجي).
إذا كنت تقوم بتحليل ملفات XML، فتأكد من عدم تمكين توسيع الكيان لتجنب قنبلة Billion Laughs/XML عبر هجوم توسيع الكيان الأسي.
استخدم CDN لتحميل الملفات.
إذا كنت تتعامل مع كمية هائلة من البيانات، فاستخدم العمال وقوائم الانتظار لمعالجة أكبر قدر ممكن في الخلفية وإرجاع الاستجابة بسرعة لتجنب حظر HTTP.
لا تنسى أن تقلب تصحيح وضع إيقاف التشغيل.

انتاج |

يرسل X-Content-Type-Options: nosniff header.
يرسل X-Frame-Options: deny header.
يرسل Content-Security-Policy: default-src 'none' header.
إزالة رؤوس البصمات - X-Powered-By, Server, X-AspNet-Version إلخ.
قوة content-type لردك إذا رجعت application/json ثم نوع محتوى ردك هو application/json.
لا تُرجع بيانات حساسة مثل بيانات الاعتماد وكلمات المرور ورموز الأمان.
قم بإرجاع رمز الحالة المناسب وفقًا للعملية المكتملة.(على سبيل المثال 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, ، إلخ).

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

لقد تجاهل الجميع في هذه الإجابات التحكم/التفويض الحقيقي في الوصول.

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

يمكن للأطباء الحصول على السجل الطبي للمريض الذي لديهم علاقة رعاية معه
لا يمكن لأحد نشر البيانات الطبية خارج ساعات التدريب (على سبيل المثال.9-5)
يمكن للمستخدمين النهائيين الحصول على السجلات الطبية التي يمتلكونها أو السجلات الطبية للمرضى الذين هم الوصي عليهم
يمكن للممرضات تحديث السجل الطبي للمريض الذي ينتمي إلى نفس الوحدة التي تنتمي إليها الممرضة.

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

المعايير الأخرى هنا هي لما يلي:

مصادقة:بطاقة تعريف.الاتحاد وتفويض التفويض على سبيل المثال.السماح لخدمة ما بالتصرف نيابةً عني في خدمة أخرى (يمكن لـ Facebook النشر على Twitter الخاص بي)
SAML:اتحاد الهوية / SSO على شبكة الإنترنت.SAML يتعلق كثيرًا بهوية المستخدم.
معايير WS-Security / WS-*:تركز هذه على التواصل بين خدمات SOAP.وهي خاصة بتنسيق المراسلة على مستوى التطبيق (SOAP) وتتعامل مع جوانب المراسلة على سبيل المثال.الموثوقية، الأمن، السرية، النزاهة، الذرية، الأحداث...لا شيء يغطي التحكم في الوصول وكلها خاصة بـ SOAP.

XACML لا يعتمد على التكنولوجيا.يمكن تطبيقه على تطبيقات Java و.NET وPython وRuby...خدمات الويب وواجهات برمجة تطبيقات REST والمزيد.

فيما يلي موارد مثيرة للاهتمام:

الواحة XACML موقع إلكتروني
ال معيار نيست أباك

لقد استخدمت OAuth عدة مرات، واستخدمت أيضًا بعض الطرق الأخرى (BASIC/DIGEST).أقترح بكل إخلاص OAuth.الرابط التالي هو أفضل برنامج تعليمي رأيته حول استخدام OAuth:

http://hueniverse.com/oauth/guide/

انتهت إحدى أفضل المنشورات التي صادفتها فيما يتعلق بالأمان فيما يتعلق بـ REST 1 قطرة مطر.تستخدم واجهة MySpace API بروتوكول OAuth أيضًا للأمان، ولديك حق الوصول الكامل إلى قنواتها المخصصة في رمز RestChess، والذي قمت بالكثير من الاستكشاف باستخدامه.تم عرض هذا في Mix ويمكنك العثور على المنشور هنا.

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

يحتوي OWASP (مشروع أمان تطبيقات الويب المفتوحة) على بعض أوراق الغش التي تغطي جميع جوانب تطوير تطبيقات الويب.يعد هذا المشروع مصدرًا قيمًا وموثوقًا للغاية للمعلومات.فيما يتعلق بخدمات REST يمكنك التحقق من هذا: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

أوصي بـ OAuth 2/3.يمكنك العثور على مزيد من المعلومات في http://oauth.net/2/

لقد بحثت كثيرًا عن أمان ws المريح وانتهى بنا الأمر أيضًا باستخدام الرمز المميز عبر ملف تعريف الارتباط من العميل إلى الخادم لمصادقة الطلبات.لقد استخدمت Spring Security لترخيص الطلبات في الخدمة لأنه كان عليّ مصادقة كل طلب والترخيص به بناءً على سياسات الأمان المحددة الموجودة بالفعل في قاعدة البيانات.

حقيقة أن عالم SOAP مغطى جيدًا بمعايير الأمان لا تعني أنه آمن افتراضيًا.في المقام الأول، المعايير هي جداً معقد.التعقيد ليس صديقًا جيدًا جدًا للأمان ونقاط الضعف في التنفيذ مثل هجمات التفاف توقيع XML مستوطنة هنا.

أما بالنسبة لبيئة .NET فلن أساعدها كثيرًا، ولكن "بناء خدمات الويب باستخدام جافا" (لبنة بها حوالي 10 مؤلفين) ساعدتني كثيراً في فهم بنية أمان WS-*، وعلى وجه الخصوص، مراوغاتها.

لا تقدم REST نفسها أي معايير أمنية، ولكن أشياء مثل OAuth وSAML أصبحت بسرعة هي المعايير في هذا المجال.ومع ذلك، فإن المصادقة والترخيص ليست سوى جزء صغير مما تحتاج إلى أخذه في الاعتبار.تنطبق العديد من نقاط الضعف المعروفة المتعلقة بتطبيقات الويب بشكل كبير على REST apis.عليك أن تأخذ في الاعتبار التحقق من صحة الإدخال، وكسر الجلسة، ورسائل الخطأ غير المناسبة، ونقاط الضعف الداخلية للموظفين، وما إلى ذلك.إنه موضوع كبير.

أريد أن أضيف (بما يتماشى مع stinkeymatt)، الحل الأبسط هو إضافة شهادات SSL إلى موقعك.بمعنى آخر، تأكد من أن عنوان URL الخاص بك هو HTTPS://.سيغطي ذلك أمن النقل الخاص بك (مقابل المال).باستخدام عنوان URL RESTful، تتمثل الفكرة في إبقاء الأمر بسيطًا (على عكس أمان WS*/SAML)، يمكنك استخدامه اتصال oAuth2/openID أو حتى المصادقة الأساسية (في الحالات البسيطة).ولكنك ستظل بحاجة إلى SSL/HTTPS.يرجى التحقق من أمان ASP.NET Web API 2 هنا: http://www.asp.net/web-api/overview/security (مقالات وفيديوهات)

كما انتهى @Nathan برأس HTTP بسيط، وقد قال البعض شهادات OAuth2 وSSL من جانب العميل.جوهر الأمر هو هذا ...لا ينبغي أن تتعامل واجهة REST API الخاصة بك مع الأمان لأن ذلك يجب أن يكون خارج نطاق واجهة برمجة التطبيقات.

بدلاً من ذلك، يجب وضع طبقة أمان فوقها، سواء كان رأس HTTP خلف وكيل ويب (أسلوب شائع مثل SiteMinder أو Zermatt أو حتى Apache HTTPd)، أو معقد مثل OAuth 2.

الشيء الأساسي هو أن الطلبات يجب أن تعمل دون أي تفاعل من قبل المستخدم النهائي.كل ما هو مطلوب هو التأكد من مصادقة الاتصال بـ REST API.في Java EE لدينا فكرة أ userPrincipal التي يمكن الحصول عليها على HttpServletRequest.تمت إدارة أيضًا في واصف النشر أن نمط URL يمكن أن يكون آمنًا لذلك لا يحتاج رمز REST API إلى التحقق بعد الآن.

في عالم WCF، سأستخدم ServiceSecurityContext.Current للحصول على سياق الأمان الحالي.تحتاج إلى تكوين التطبيق الخاص بك ليطلب المصادقة.

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

بالنسبة لأمن تطبيقات الويب، يجب عليك إلقاء نظرة على OWASP (https://www.owasp.org/index.php/Main_Page) الذي يوفر أوراق الغش لمختلف الهجمات الأمنية.يمكنك دمج أكبر عدد ممكن من التدابير لتأمين طلبك.فيما يتعلق بأمان واجهة برمجة التطبيقات (الترخيص والمصادقة وإدارة الهوية)، هناك طرق متعددة كما ذكرنا سابقًا (Basic وDigest وOAuth).توجد ثقوب في OAuth1.0، لذا يمكنك استخدام OAuth1.0a (لم يتم اعتماد OAuth2.0 على نطاق واسع بسبب المخاوف المتعلقة بالمواصفات)

لقد مر وقت طويل ولكن السؤال لا يزال ذا صلة، على الرغم من أن الإجابة ربما تغيرت قليلاً.

ستكون بوابة API حلاً مرنًا وقابلاً للتكوين بدرجة كبيرة.لقد اختبرت واستخدمت كونغ قليلا جدا وأعجبني حقا ما رأيته.توفر KONG واجهة REST API إدارية خاصة بها والتي يمكنك استخدامها لإدارة المستخدمين.

Express-gateway.io هو الأحدث وهو أيضًا بوابة API.

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

لا تنتمي إلى StackOverflow