تخطي إلى المحتوى

حالة استخدام

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

الأهداف

بعد استكمال هذا الموضوع الفرعي، يجب أن يكون الممارسون قادرين على القيام بما يلي:

  • فهم مفهوم الثغرات المنطقية في التطبيقات
  • تحديد وفهم الفئات الفرعية الشائعة لثغرات منطق التطبيق بما في ذلك:
    • الضوابط من جانب العميل
    • عدم وجود حد لمعدل/تقديم طلبات متعددة
    • تضاربات التقريب
    • تجاوز خطوات العملية
    • تزييف الطلبات عبر المواقع

العرض

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

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

الضوابط من جانب العميل

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

حجم الإدخال

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

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

تعمل تقنيات التحويل هذه بشكل عام مع جميع الضوابط من جانب العميل، ويجب أن تراعيها أثناء تغطيتنا لعناصر التحكم الأخرى.

التحقق من صحة محتوى البيانات

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

تتعلق إحدى الفئات الفرعية الشائعة لهذا النوع من الثغرات الأمنية بتغيير حجم الصورة، وفي بعض الأحيان سيكون لدى المطورين ميزة على موقع ويب تقوم بتغيير حجم الصور من جانب الخادم للعرض الأمثل بدقة معينة. بشكل عام سيبدو عنوان موقع الويب مثل http://example.com/image?imgname=file.gif&width=640&height=480 تتمثل طريقة عمل هذه البرامج النصية دائمًا تقريبًا في تخصيص تخزين ضمن الذاكرة لإبقاء الصورة التي تم تغيير حجمها وتوسيع نطاق الملف المحدد ليصل إلى الحجم الجديد ثم إعادة بيانات الصورة إلى المتصفح. في المثال أعلاه، عادة ما تكون الذاكرة المخصصة 1.2 بحد ميغابايت متواضعة، ولكن إذا أرسل المستخدم طلبًا بعرض وارتفاع 100000 فسيحاول الخادم تخصيص 10 غيغابايت. من خلال إرسال مثل هذه الطلبات بشكل متكرر يمكن للمهاجم التغلب بسهولة حتى على خادم الويب القوي. يجب على المطورين على الأقل فرض حد أقصى للحجم على جانب الخادم ومراعاة نقل عملية تغيير الحجم إلى خادم معزول بحيث لا يؤثر غمر هذا الخادم على الخادم الأساسي.

تعطيل عناصر التحكم

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

البيانات الحساسة المخزنة على جانب العميل

في بعض الأحيان يقوم المطورون بتضمين بيانات حساسة في صفحة ويب إما سرية أو يتحكمون في شيء لا ينبغي أن يكون تحت سيطرة المستخدم. قد يكون أحد الأمثلة على ذلك محاولة تقييد البيانات التي يراها المستخدم عن طريق إخفاء البيانات السرية باستخدام سمة أوراق الأنماط المتتالية (CSS) display=none، أو إرفاقها في تعليقات لغة تمييز النص التشعبي أو آليات أخرى. يمكن للمستخدم مشاهدة هذه البيانات ببساطة عن طريق عرض شفرة مصدر لغة تمييز النص التشعبي لصفحة الويب. مثال على الضوابط من جانب العميل هي تضمين البيانات التي لا ينبغي تحريرها في حقول النموذج المخفية. على سبيل المثال، في الأيام الأولى للتجارة الإلكترونية غالبًا ما شملت متاجر الويب سعر العنصر في إدخال نموذج مخفي بلغة تمييز النص التشعبي تم إرساله بعد ذلك إلى عربة تسوق تابعة لجهة خارجية. باستخدام التقنيات التي تمت مناقشتها في “حجم الإدخال”، يمكن للمستخدمين بسهولة تعديل القيمة في هذا الحقل المخفي وشرائه بأي سعر يريدونه. (قد تتذكر أنه تمت مناقشة مثال آخر لهذا النوع من الثغرات الأمنية تحت عنوان “تصعيد الصلاحيات الأفقي” أعلاه.)

الوقاية من ثغرات الضوابط من جانب العميل

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

عدم وجود حد لمعدل/تقديم طلبات متعددة

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

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

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

تناقضات التقريب

تتعلق إحدى فئات الثغرات المثيرة للاهتمام بكيفية تعامل العمليات المختلفة مع الفئات، وسلُط الضوء على هذه الفئة من الثغرات في فلمي سوبرمان 3 (Superman 3) وأوفيس سبيس (Office Space) ومع ذلك لا تزال تحدث في العديد من التطبيقات المالية. إذا كان هناك تطبيقان يدعمان تحويل الأموال بين بعضهما البعض فكيفية تعاملهما مع السنتات الجزئية أمر مهم. فإذا قام أحد التطبيقات بتقريب السنتات الجزئية وقام تطبيق آخر باقتطاعها فيمكن للمهاجم نقل 1.9 سنتًا بشكل متكرر من تطبيق الاقتطاع إلى تطبيق التقريب، حيث سيكلف كل تحويل المستخدم 1 سنت (1.9 مقتطعة) ويحصل على 2 سنت (1.9 مقربة).

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

تجاوز خطوات العملية

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

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

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

على سبيل المثال فكر في موقع تكون فيه آلية إعادة تعيين كلمة المرور هي قيام الموقع بإرسال رابط لك يسمح بتغيير كلمة المرور الخاصة بك، وهذا أمر طبيعي إلى حد ما. تخيل أن الموقع نفسه يحتوي على صفحة تسمح لك بتغيير عنوان بريدك الإلكتروني وإذا قمت ببساطة بزيارة example.com/[email protected] فسيتم تغيير عنوان بريدك الإلكتروني إلى العنوان المحدد. أخيرًا تخيل أن موقع attacker.com قد تم إعداده لعرض صفحة بعد صفحة من صور الحيوانات الرائعة، لكن توجد مشكلة لأن زر “التالي” في أسفل الصفحة هو في الواقع الرابط أعلاه. إذا قام مستخدم مسجل الدخول في example.com بزيارة attacker.com ونقر على زر “التالي” فسيتم تغيير عنوان بريده الإلكتروني ويمكن للمهاجم إعادة تعيين كلمة مرور المستخدم على الفور والتحكم في حسابه.

جرب بنفسك!

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

الوقاية من تزييف طلب المواقع المشتركة

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

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

لأجل استكشاف متعمّق لكل من تزييف طلب مواقع مشتركة والثغرات الأخرى في منطق التطبيق، راجع مسار تعلّم تقييم أمان تطبيقات الويب..

اختبار مهارة

بالنسبة لهذا القسم قررنا تخطي اختبار المهارات لسبب واحد بسيط للغاية وهو أن متصفحات الويب تقوم حاليًا بتغيير سياساتها بحيث تكون سياسات ملفات تعريف SameSite الآن Lax افترضيًا مما يتسبب تلقائيًا بإيقاف الكثير من هجمات تزييف طلب المواقع المشتركة من العمل. ولهذا السبب فإن أي تمارين نقترحها قد لا تعمل في المستقبل.

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

موارد التعلّم

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

مجانًا

دليل مشروع أمان تطبيق الويب المفتوح حول الثغرة وكيفية عمله والتدابير الوقائية التي تعمل ولا تعمل

اللغات: الإنجليزية
زيارة الموقع

ورقة معلومات مرجعية للوقاية من تزييف طلب المواقع المشتركة

مجانًا

قائمة بالتخفيفات المحتملة لتزييف طلب مواقع مشتركة التي يُنصح بها أو ويُنصح بعدم استخدامها

اللغات: الإنجليزية
زيارة الموقع