REST هي بنية تطبيق ويب شائعة للغاية. للاتصال بالوظائف على الخادم ، يتم استخدام طلبات HTTP العادية مع المعلمات المحددة (عادةً ما يتم استخدام JSON أو XML لبناء المعلمات) ، في حين لا يوجد معيار صارم لهندسة REST ، مما يضيف المرونة (وبطبيعة الحال ، قليل من الفوضى).
REST يسمح لك بمعالجة مسألة الأمان بمرونة أو ، من الخطيئة الكثيرة ، عدم التعامل مع السؤال على الإطلاق. استنادًا إلى
OWASP ، قمنا بإعداد قائمة من النصائح لمساعدتك في تحسين أمان تطبيق REST.
كنقطة انطلاق في تلك الحالات النادرة عندما تكون هناك حاجة هنا ، نستخدم بيثون وجانغو.
القاعدة 0
HTTPS
مجرد إعداده. من فضلك. حماية البيانات المنقولة لم تؤذي أحدا. حتى إذا كنت تعتقد أنه لا يوجد شيء للحماية في الوقت الحالي ، فلن يكون هذا هو الحال دائمًا ولا يزال يتعين عليك تكوين HTTPS. لذا قم بتكوينه بشكل أفضل على الفور ، وسيظل الجميع على ما يرام.
القاعدة 1
المصادقة
قد تبدو نصيحة واضحة ، ومع ذلك ، يفضل الكثيرون الإهمال. يجب أن يكون للتطبيق دائمًا مصادقة ، حتى إذا كنت تعتقد الآن أنك ستستخدمه فقط داخل الشركة ولا يوجد فرق بين الموظفين الذين يقومون بذلك. وإذا أضفت المزيد من المجلات ، فسيصبح التحقيق في الحوادث وتحليل النشاط أكثر بساطة.
نظرًا لأن الوصول إلى الرموز ، يعتبر من الممارسات الجيدة حاليًا استخدام
JWT (رموز الويب JSON). لا تستخدم الرموز المميزة ذات القيمة {"alg": "none"} للتحكم في النزاهة ، يجب أن تحتوي الرموز المميزة دائمًا على توقيع أو MAC! يُفضل التوقيع بسبب حقيقة أن مفاتيح الإنشاء والتحقق من مطابقة MAC (أو يمكن حسابها بسهولة من بعضها البعض) ، أي إذا كان الخادم قادرًا على التحقق من قيمة MAC ، فيمكنه أيضًا إنشاء قيمه. لا يؤكد التوقيع أيضًا سلامة الرسالة فحسب ، بل يؤكد أيضًا هوية المرسل.
المادة 2
رفض طرق HTTP التي لا تستخدمها
قم بتكوين الخادم ليضيف إلى القائمة تلك الأساليب التي تستخدمها (GET ، POST ، PUT ، إلخ) ورفض أي شيء لا يلائم هذه القائمة. من غير المحتمل أن يحتاج خادمك إلى معالجة طلبات TRACE أثناء الإنتاج (هذه الطريقة جزء من هجوم XST (التتبع عبر المواقع) ، والذي يتكون من هجوم XSS وطريقة TRACE أو TRACK. يسمح هذا الهجوم ، على سبيل المثال ، بسرقة ملفات تعريف ارتباط المستخدم ، حتى لو يتم تمييزها كـ HttpOnly). كلما قلت معلومات البنية التحتية المتاحة من الخارج ، كان ذلك أفضل.
المادة 3
تميز الوصول
هل يحتاج جميع المستخدمين لديك إلى جميع الطرق ، على سبيل المثال ، DELETE؟ إذا كنت لا تريد أن يكون بعض المستخدمين قادرين على تنفيذ عمليات معينة - قم بتكوين التحكم في الوصول في التطبيق الخاص بك. على سبيل المثال ، يمكن للمستخدم العادي الوصول إلى طريقة GET فقط لبعض الوظائف ، ويمكن للمدير استخدام GET و POST ، وما إلى ذلك. لذلك ، يستحق تعيين الأدوار في قاعدة البيانات التي يمكن تعيينها للمستخدمين للتحكم في الوصول المريح.
نتيجة لذلك ، سيكون لكل وظيفة كتلة فحص من هذا النوع تقريبًا:
if request.POST and user.is_manager: do_stuff()
المادة 4
فكر في الحد من عدد الاستعلامات
إذا كنت تعتقد أن المستخدمين يجب ألا يرسلوا مائة ألف طلب في الثانية ، فعليك تحديد هذا الرقم. استخدم مفاتيح API أو أي آلية أخرى ملائمة لك لتتبع وتقييد عدد الطلبات التي سيتم معالجتها في فترة زمنية معينة من مستخدم واحد. بالنسبة إلى Django ، على سبيل المثال ، توفر django-ratelimit هذه الوظيفة ، حيث يمكنك تعيين العديد من المعلمات كمعرّف للتقييد ، وليس بالضرورة مفاتيح API ، ولكن عنوان IP.
المادة 5
تأكد من التحقق من صحة / تطهير المدخلات
لا تثق في معلمات الإدخال المنقولة ، فقم دائمًا بإجراء التحقق من الصحة / الإصحاح:
- إذا كان ذلك ممكنًا (وحيثما أمكن ذلك) ، فضع حدًا لطول / نوع / تنسيق الإدخال والطلب نفسه. رفض جميع الطلبات / البيانات المرسلة التي تتجاوز الطول المحدد بواسطتك أو التي لا تتطابق مع النوع / التنسيق.
- عند معالجة السلاسل ، يمكنك دائمًا الهروب من جميع الأحرف الخاصة.
- إذا كنت تستخدم الإطار ، فمعظمها يحتوي على أدوات التحقق الخاصة بالصرف والصرف الصحي (مرفوعة عن تلك الشائعة - Django (python) و Yii2 (php)) ، لذلك من المهم دراسة إمكانياتها وإذا لم تتم تغطية بعض الجوانب التي تحتاجها - ابحث عن مكتبة تغلق هذا ، أو اكتب هذه الوظيفة بنفسك.
- تتبع أخطاء التحقق من الصحة. إذا فشلت طلبات بعض المستخدمين باستمرار في التحقق من الصحة - فكر في حظر هؤلاء المستخدمين تلقائيًا.
- تأكد من أن محلل الإدخال (أو نسخته الحالية) غير معرض لأي هجمات بحد ذاته.
المادة 6
لا تعطي معلومات أكثر من اللازم
إذا تسبب أي طلب في حدوث خطأ في التطبيق ، أو كان ببساطة غير متاح لسبب ما ، فلا تقدم تفاصيل في الرد ، فأرجع رسالة الخطأ الأكثر تجريدًا. تقوم بعض الخوادم بإرجاع stacktrace بعد حدوث خطأ افتراضيًا ، لذا تأكد من إعادة تكوين هذا المنطق.
المادة 7
احتفظ دائمًا بالسجلات
اسمح لكل حدث (المصادقة ، الخطأ ، الطلب ، إلخ) أن يتم تسجيله بالتفصيل قدر الإمكان. قم بتسجيلها بطريقة منطقية للبحث عنها بشكل أكثر ملاءمة إذا لزم الأمر. فقط في حالة ، قبل التسجيل في السجلات ، تعقيم البيانات المسجلة.
المادة 8
حدد نوع المحتوى بشكل صحيح - هذا مهم!
لكي يقرأ المستعرض (أو العميل) البيانات المقدمة بشكل صحيح ، من المهم نوع المحتوى المحدد بشكل صحيح والمطابق للبيانات المقدمة. في حالة المتصفحات ، يجدر أيضًا تعيين خيارات X-Content-Type-head في الرأس: nosniff ، لمنع المستعرض من محاولة اكتشاف نوع المحتوى الآخر إلى جانب الذي تم إرساله فعليًا (إجراء ضد هجمات XSS).
المادة 9
التحقق من صحة نوع المحتوى
- يجدر إعداد رفض الطلبات إذا كان نوع المحتوى الخاص بهم يختلف عن محتوياتها. سيؤدي ذلك إلى تقليل مخاطر معالجة البيانات غير الصحيحة ، مما قد يؤدي إلى الحقن أو تنفيذ التعليمات البرمجية في الخادم / العميل.
- يجدر أيضًا رفض الطلبات التي لا تدعم نوع المحتوى الخاص بها ، أو التي يتغيب عنها هذا الرأس عمومًا. تجنب أيضًا الإجابات المباشرة حول أي وظيفة من نوع Content تقبل / المشكلات ، إذا لم يكن ذلك ضروريًا (سيساعد ذلك في تجنب هجمات XXE).
- في خدمات REST ، من الشائع دعم عدة أنواع من الاستجابات (على سبيل المثال ، json و xml) ، ويشير العميل إلى نوع الاستجابة المفضل في رأس Accept عند الطلب. تجنب نسخ محتويات رأس قبول في نوع المحتوى من الاستجابة كآلية لتعيين هذا الرأس. أيضًا رفض الطلبات التي لا يحتوي رأس قبولها مباشرةً على واحد من الأنواع المدعومة.
المادة 10
لا تنسَ إعداد مشاركة الموارد المشتركة (CORS)
CORS هو معيار يصف العمل مع استعلامات المجال المشترك. إذا كان التطبيق الخاص بك لا يدعم CORS ، فقم بتعطيل العمل مع هذا النوع من الرؤوس. إذا كنت بحاجة إلى استخدامه ، فيجب أن تكون سياسة الوصول محددة وصارمة قدر الإمكان.
المادة 11
لا تقم بتوسيع المعلمات في URL
يجب أن تكون جميع البيانات المهمة (كلمات المرور والمفاتيح والرموز وتسجيلات الدخول ، ويفضل أيضًا) داخل نص الطلب أو في الرؤوس ، ولكن يجب ألا تظهر بأي حال في عنوان URL. إذا كنت بحاجة إلى تمرير بيانات حساسة من خلال طريقة GET ، فضعها في الرأس.
إنه مستحيل:مثال .com / controller / 123 / action؟ apiKey = a53f435643de32
يمكنك:مثال .com / controller / 123 / action
العناوين:المضيف: example.com
وكيل المستخدم: موزيلا ...
X-APIkey: a53f435643de32
المادة 12
فكر في الحماية ضد هجمات CSRF
يمكنك قراءة المزيد حول جميع أنواع الحماية
هنا ، وبالتالي ، يعتبر استخدام رموز CSRF الطريقة الأكثر شيوعًا لتقليل مخاطر الهجمات من هذا النوع.
المادة 13
استكشاف الإطار الخاص بك
إذا كنت تستخدم أي إطار لتنفيذ REST في التطبيق الخاص بك ، فعليك دراسته وعدم استخدامه عمياء ، كما يحدث في كثير من الأحيان. اقرأ الوثائق بعناية ، وخاصة الجزء الأمني. لا تتركها تعمل على الإعدادات الافتراضية! كل إطار له الفروق الدقيقة ، خاصة عندما يتعلق الأمر بالأمن ، لذا فإن معرفة هذه الأشياء مهمة جدًا.