أسرة السلامة: CSRF

على الرغم من حقيقة أنه في آخر قائمة منشورة من نقاط الضعف لهجمات OWASP Top 10 2017 CSRF تصنف على أنها "محذوفة ، ولكن لا تنسى" ، فقد قررنا أنه لن يكون من غير الضروري التذكير مرة أخرى بكيفية الدفاع ضد هجمات CSRF ، بالاعتماد على تلك نفس القواعد التي تقدمها OWASP.

باستخدام رمز CSRF

يعد استخدام الرمز المميز (كطريقة عديمة الحالة وطريقة الحالة) هو الطريقة الأساسية والأكثر شيوعًا للحماية. يجب أن يكون الرمز المميز فريدًا لكل جلسة مستخدم ، يتم إنشاؤه بواسطة مولد أرقام عشوائي زائف قوي مشفر. توصي OWASP أيضًا باستخدام خوارزميات AES256-GCM و SHA256 / 512 للتشفير عند استخدام HMAC.

هناك عدة طرق للعمل مع الرموز المميزة: رمز التزامن ، نمط الرمز القائم على التشفير ، رمز HMAC

رمز المزامن

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

<form action="/post.php" method="post"> <input type="hidden" name="CSRFToken" value="l5824xNMAYFesBxing975yR8HPJlHZ"> ... </form> 

في الرؤوس:

 POST /page HTTP/1.1 Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36 Content-Type: application/json Host: example.com X-CSRF-TOKEN: l5824xNMAYFesBxing975yR8HPJlHZ 

أو في ملفات تعريف الارتباط

 POST /page HTTP/1.1 Host: example.com Set-Cookie: CSRFToken=l5824xNMAYFesBxing975yR8HPJlHZ; Content-Type: application/x-www-form-urlencoded 

يوصي OWASP بتخزين الرمز المميز في الرؤوس ، موضحًا أنه حتى في حالة فتح الرمز المميز أو انتهاء صلاحيته ، فإن المهاجم لا يزال غير قادر على تزوير الطلب بسبب المستعرضات.

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

لا يُنصح بإرسال رمز مميز باستخدام طلب GET ، حيث أنه من خلال هذا النهج ، يمكن الكشف عن الرمز المميز: في سجل المتصفح ، وملفات السجل ، ورؤوس الإحالة.

التشفير القائم على رمزية

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

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

HMAC مقرها الرمز

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

أتمتة الرمز

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

• اكتب ملفًا يضيف رمزًا تلقائيًا للطلبات عبر علامة النموذج أو عند استخدام ajax. على سبيل المثال ، يتبع Spring Security مقاربة مماثلة في كل مرة يتم فيها استخدام العلامة <form: form>.

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

• إضافة رمز رمزي تلقائيًا عند تقديم الصفحة. يستخدم CSRF Guard هذا النهج: تضاف الرموز المميزة إلى كل سمات href و src ، الحقول المخفية وفي جميع الأشكال

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


تسجيل الدخول CSRF

باستخدام CSRF في نموذج تسجيل الدخول ، يمكن للمهاجم تسجيل الدخول ،
متنكرا كضحية. واجهت نقاط الضعف هذه عمالقة مثل PayPal و Google.
يمكنك التعامل مع CSRF في نموذج تسجيل الدخول عن طريق إنشاء جلسات ما قبل الإعداد التي يتم إنشاؤها قبل مصادقة المستخدم ، ومن خلال تضمين الرموز المميزة في نموذج تسجيل الدخول.


Samesite ملف تعريف الارتباط

SameSite Cookie هي سمة موصوفة في RFC6265bis تهدف إلى مواجهة هجمات CSRF. وهي تعمل على النحو التالي. تتمثل إحدى طرق الحماية في التحقق من رؤوس المصدر والإحالة ، والتي يمكنك من خلالها فهم مصدر الطلب ، لكن هذا النهج يتطلب تطبيق آلية التحقق. باستخدام سمة SameSite ، نقيّد إرسال ملفات تعريف الارتباط بطلب من موارد غريبة. تحتوي هذه السمة على العديد من القيم المحتملة: Strict و Lax و None.
يعني استخدام القيمة الصارمة أن المستعرض لن يرسل ملفات تعريف الارتباط من أي مصادر لا تتطابق مع اسم المجال للمورد الحالي.
يجعل التراخي في القيمة من الممكن عدم حظر ملفات تعريف الارتباط من الموارد الخارجية ، حيث تم تنفيذ الانتقال بطريقة آمنة - باستخدام بروتوكول HTTPS. لاكس يحقق توازنًا بين قابلية الاستخدام والأمان.

إعداد سمة بسيط جدًا:

 Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax 

في وقت كتابة هذا التقرير ، يبدو دعم السمة بواسطة المتصفحات كما يلي:




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

التحقق من الرؤوس

كما ذكر أعلاه ، إحدى طرق الحماية هي التحقق من قيم الإحالة والأصل لرأس الطلب.
يتمثل جوهر هذا الاختيار في التحقق من قيم الرؤوس على جانب الخادم. إذا كانت تطابق المورد ، فيُعتبر الطلب صحيحًا ، وإلا فسيتم رفضه. إذا كان رأس الأصل مفقودًا ، فستحتاج إلى التأكد من أن قيمة المرجع تتطابق مع المورد الحالي. توصي OWASP برفض الطلبات التي لا تحتوي على رؤوس Origin أو Referrer. يمكنك أيضًا تسجيل جميع هذه الطلبات لتحليلها لاحقًا وتحديد كيفية التعامل معها.

ومع ذلك ، تزداد الأمور تعقيدًا إذا كان تطبيقك وراء خادم وكيل ، لأن عنوان URL في الرأس سيكون مختلفًا. في هذه الحالة ، هناك العديد من الخيارات:
• قم بتكوين التطبيق الخاص بك حتى تعرف دائمًا أصل الطلب. تكمن المشكلة في هذا الأسلوب في تحديد القيمة الصحيحة إذا تم نشر التطبيق الخاص بك في العديد من البيئات (على سبيل المثال ، dev ، QA ، الإنتاج) ، مما يؤدي إلى وجود مشكلة في الدعم
• استخدم رأس المضيف. سيسمح لك هذا الرأس بتحديد مصدر الطلب بغض النظر عن البيئة
• استخدم رأس X-Forwarded-Host ، والغرض منه هو تخزين الرؤوس الأصلية التي يتلقاها الخادم الوكيل

تعمل جميع الطرق الموضحة فقط عند وجود رؤوس المصدر والإشارة. ولكن هناك حالات عندما تكون هذه الرؤوس مفقودة. فيما يلي بعض الحالات التي لم يتم فيها تضمين هذه الرؤوس في الطلب:
• لا يتضمن الإصدار IE 11 رأس الأصل للمواقع الموثوق بها. يبقى الاعتماد فقط على رأس المرجع.
• في حالة إعادة التوجيه ، لا يتم تضمين Origin في الطلب ، حيث يُعتقد أنه قد يحتوي على معلومات سرية لا ينبغي إرسالها إلى مصدر آخر
• يتم تمكين رأس الأصل لجميع طلبات المواقع المشتركة ، ولكن معظم المتصفحات تضيفه فقط لطلبات POST / DELETE / PUT

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

تقديم مزدوج ملف تعريف الارتباط

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