Apache APISIX يعزز أمان API من خلال إضافة CSRF Plugin

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

تقدم هذه المقالة csrf، وهو مكون أمان CSRF لـ Apache APISIX، وتفصل كيفية تأمين معلومات API الخاصة بك في Apache APISIX بمساعدة مكون csrf.

مقدمة المكون

تم تنفيذ مكون csrf بناءً على مخطط Double Submit Cookie. كما تم تعريفه في RFC 7231#section-4.2.1، نعتبر طرق GET و HEAD و OPTIONS كـ طرق آمنة. وفقًا لهذه الاتفاقية، سيسمح مكون csrf لهذه الطرق الثلاث بالمرور مباشرة، ولكن سيتحقق من الطرق الأخرى ويعترض أي طلبات غير آمنة.

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

عند تمكين مكون csrf في مسار، ستتضمن جميع استجابات الطلبات لهذا المسار ملف تعريف ارتباط يحمل رمز csrf.

يحتاج المستخدم إلى حمل هذا الملف في طلب غير آمن لهذا المسار وإضافة حقل إضافي في رأس الطلب لحمل محتوى الملف. الحقل هو قيمة name في تكوين المكون بحيث يمر الطلب عبر فحوصات مكون CSRF.

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

كيفية استخدام المكون

تمكين مكون CSRF في مسار

قم بإنشاء مسار في APISIX باستخدام واجهة برمجة التطبيقات الإدارية وتمكين مكون csrf.

curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
  "uri": "/hello",
  "plugins": {
    "csrf": {
      "key": "edd1c9f034335f136f87ad84b625c8f1"
    }
  },
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "127.0.0.1:9001": 1
    }
  }
}'

هناك ثلاثة معلمات تكوين للمكون.

• key: حقل مطلوب، قيمة المفتاح السري العشوائي. يحتاج المستخدم إلى توفير مفتاح عشوائي.
• expires: اختياري، وقت انتهاء صلاحية المفتاح السري العشوائي، القيمة الافتراضية هي 7200 ثانية. نظرًا لأن رمز CSRF يتم إرساله إلى العميل باستخدام ملف تعريف ارتباط، يتم وضع هذا التكوين في تكوين الملف للتحكم في وقت انتهاء صلاحية الملف. بالإضافة إلى ذلك، سيحسب المكون أيضًا الوقت لتحديد ما إذا كان الرمز قد انتهت صلاحيته.
• name: اختياري، اسم رمز CSRF، القيمة الافتراضية هي apisix-csrf-token.

إرسال طلب

يتم الوصول إلى المسار أولاً باستخدام طلب POST.

curl -i http://127.0.0.1:9080/hello -X POST

سيقوم Apache APISIX باعتراض الطلب وإرجاع خطأ 401. في الرأس المرتجع ستجد ملف تعريف ارتباط تم تعيينه، والذي يجب أن يكون القيمة الافتراضية apisix-csrf-token=.... داخل الملف إذا لم يتم تكوين حقل name للمكون. هذا هو رمز CSRF الذي تم إنشاؤه بواسطة مكون CSRF. في الطلب، تحتاج إلى التأكد من أن الطلب يحمل هذا الملف وأن الرمز مكتوب في رأس الطلب.

HTTP/1.1 401 Unauthorized
Set-Cookie: apisix-csrf-token= ${apisix-csrf-token};path=/;Expires=Mon, 13-Dec-21 09:33:55 GMT
{"error_msg":"no csrf token in headers"}

مثال على استخدام JavaScript على جانب العميل: قراءة ملفات تعريف الارتباط باستخدام js-cookie وإرسال الطلبات باستخدام axios.

const token = Cookie.get('apisix-csrf-token');

const instance = axios.create({
  headers: {'apisix-csrf-token': token}
});

إذا كان الرمز في ملف تعريف الارتباط لا يتطابق مع الرمز في رأس الطلب، سيتم اعتراض الطلب بواسطة مكون csrf، كما هو موضح في المثال التالي.

curl -i http://127.0.0.1:9080/hello -X POST -H 'apisix-csrf-token: ${apisix-csrf-token}' -b 'apisix-csrf-token= ${apisix-csrf-token}'

HTTP/1.1 401 Unauthorized
Set-Cookie: apisix-csrf-token= ${apisix-csrf-token};path=/;Expires=Mon, 13-Dec-21 09:33:55 GMT
{"error_msg":"csrf token mismatch"}

أخيرًا، استخدم curl للتحقق من الوصول العادي.

curl -i http://127.0.0.1:9080/hello -X POST -H 'apisix-csrf-token: ${apisix-csrf-token}' -b 'apisix-csrf-token= ${apisix-csrf-token}'

HTTP/1.1 200 OK

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

تعطيل المكون

قم بإزالة معلومات التكوين ذات الصلة لمكون csrf ثم أرسل طلبًا لتحديث المسار لتعطيل المكون.

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
  "uri": "/hello",
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "127.0.0.1:1980": 1
    }
  }
}'

الخلاصة

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

يعمل Apache APISIX أيضًا حاليًا على إضافة مكونات إضافية لدعم تكامل خدمات إضافية، لذا إذا كنت مهتمًا، فلا تتردد في بدء مناقشة في GitHub Discussion، أو عبر قائمة البريد للتواصل.