اختبار منطق الأعمال ورفع الملفات

لماذا يهم

نادراً ما تكشف ماسحات الثغرات الآلية هذه العيوب، لأنه لا شيء فيها مشوَّه تقنياً: فالطلب JSON صالح، والملف المرفوع صالح. وحده المختبِر الذي يفهم ما تقصده قواعد العمل يرى أن discount: 100 أو تأكيداً ثانياً كان يجب رفضه. وتذكر OWASP هذه الفئة مرتين: التصميم غير الآمن (A06:2025) في قائمة Top 10، والوصول غير المقيَّد إلى تدفقات الأعمال الحساسة (API6:2023) في قائمة API Security Top 10، حيث الخطر المذكور هو الإساءة الآلية لتدفق شراء أو حجز أو تسجيل.

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

إساءة استخدام المسار: خطوات متخطّاة وحقول معدَّلة

كل تدفق متعدد الخطوات آلة حالات: السلة، وكوبون مطبَّق، وبانتظار الدفع، ومدفوع، ومؤكَّد. يعرض المتصفح الخطوات بالترتيب، لكن الخادم يستقبل طلبات منفصلة ويجب أن يتحقق في كل منها أن طلب الشراء في الحالة الصحيحة. يبدأ الاختبار بكتابة الحالات والطلبات التي تنقل بينها، كما في درس اختبار انتقالات الحالة، ثم تجربة الانتقالات التي لا يسمح بها التصميم: استدعاء طلب التأكيد قبل الدفع، أو إعادة ترتيب الخطوات (اختيار الشحن بعد الدفع)، أو تكرار خطوة يجب أن تحدث مرة واحدة.

والمجموعة الثانية من الاختبارات تغيّر قيماً يجب أن يملكها الخادم. فحقول السعر والخصم والإجمالي والعملة والدور وis_admin لا ينبغي أن تصل من العميل أصلاً؛ فإن وصلت، غيّرها وانظر هل يعيد الخادم الحساب أم يصدّقها. وأضف القيم السالبة والمتطرفة التي تعرفها من تحليل القيم الحدّية: كمية -1 (استرداد متنكر في صورة شراء)، و0، و999999، وخصم 101 بالمئة، وسعر 0.001.

• التخطي: أرسل الخطوة الأخيرة أولاً. المتوقع: خطأ 4xx وعدم تغيّر الحالة.
• إعادة الترتيب والتكرار: ادفع مرتين، وأكّد مرتين، وطبّق كوبوناً على سلة فارغة. المتوقع: رفض الاستدعاء الثاني أو جعله بلا أثر.
• التلاعب: غيّر price أو total أو discount أو role في الطلب، كما في طلب الدفع أدناه لطلب شراء قيمته 1,899.00. المتوقع: 400 أو 422، أو تجاهل الحقل؛ وفي الحالتين يستخدم الخادم قيمه الخاصة ويعرضها الرد. أما رد 200 يحصّل 1.00 فقط فهو العيب.
• الحدود وإعادة الاستخدام: كوبون واحد لكل عميل، وثلاث محاولات في الساعة، وخمسة عناصر في الطلب. المتوقع: يعدّ الخادم كل استخدام، فيصمد الحد عبر الجلسات والأجهزة وإعادة تحميل الصفحة، والكود المخصص لاستخدام واحد إجمالاً يُرفض أيضاً من حساب ثانٍ.

POST /orders/8841/pay HTTP/1.1
Host: shop.example
Content-Type: application/json
Cookie: session=...

{ "payment_token": "tok_test_123", "total": 1.00, "currency": "SAR" }

جرّبها: مولّد انتقالات الحالات جرّبها: منشئ طلبات API

حالات التسابق: الطلب نفسه مرتين في اللحظة نفسها

حالة التسابق (Race Condition) عيب لا يظهر إلا عندما يلمس طلبان أو أكثر السجل نفسه في اللحظة نفسها تقريباً. والمثال الكلاسيكي هو الإنفاق المزدوج (Double Spend): محفظة فيها 100 ريال، يصل سحبان بقيمة 100 ريال معاً، فيقرأ كلاهما الرصيد قبل أن يكتب أيٌّ منهما، وينجح كلاهما. والشكل نفسه ينتج طلبين من نقرة مزدوجة على «إتمام الطلب»، أو كوبوناً للاستخدام الواحد يُستخدم مرتين، أو حداً من خمس محاولات يسمح بمرور ست.

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

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

جرّبها: مولّد الحالات الحدّية

رفع الملفات: الاسم والنوع والحجم والمحتوى ومكان الحفظ

يعطي الرفع التطبيقَ ثلاثة أشياء قد تتعارض: اسم ملف بامتداده، ونوعاً مُعلَناً للوسائط (MIME Type) في ترويسة Content-Type لجزء الطلب متعدد الأجزاء (Multipart)، والبايتات نفسها. والعميل يختار الأولين بحرية تامة. فملف اسمه report.pdf بنوع application/pdf قد يحتوي صفحة HTML. والمعالجة الآمنة، كما تصفها ورقة OWASP الإرشادية لرفع الملفات (File Upload Cheat Sheet)، هي قائمة سماح بالامتدادات، وفحص للمحتوى الفعلي (توقيع الملف، أي البايتات الأولى التي تحدد صيغته، وللصور: إعادة كتابتها)، وحد للحجم، واسم ملف يولّده الخادم، وتخزين على خادم منفصل أو خارج جذر الويب (المجلد الذي يقدّم منه خادم الويب الملفات)، حيث لن يشغّل الخادم الملف بوصفه شيفرة.

والنصف الثاني من الاختبار هو ما يحدث حين يقدّم التطبيق الملف المخزَّن إلى المتصفح. فملف HTML أو SVG مخزَّن يُفتح من عنوان على أصل التطبيق نفسه يشغّل سكربتاً بجلسة المستخدم: XSS مخزَّن مُسلَّم عبر الرفع. والردود الآمنة ترسل Content-Type الذي قرره الخادم بالضبط، وX-Content-Type-Options: nosniff، وContent-Disposition: attachment (فينزّل المتصفح الملف بدل عرضه) لكل ما ليس صورة نقطية (Raster) مثل PNG أو JPEG تحقّق الخادم من محتواها، أو تقدّم ملفات المستخدمين من نطاق منفصل. وملف SVG صورة أيضاً، لكنه قد يحمل سكربتاً، فيُعامَل معاملة HTML.

• النوع: ملف نصي غير ضار أُعيدت تسميته .jpg؛ وصورة مرسلة بنوع text/html؛ وامتداد مزدوج photo.jpg.html؛ وامتداد بأحرف كبيرة .PHP. المتوقع: يكون الامتداد الأخير، بغض النظر عن حالة الأحرف، ضمن قائمة السماح ويطابقه المحتوى؛ ولا يحسم النوع المُعلَن وحده القرار أبداً.
• الحجم: الحد بالضبط، وبايت واحد فوقه، وملف فارغ. المتوقع: قبول؛ ورفض برسالة واضحة؛ ورفض أو معالجة كملف فارغ.
• الاسم: ../../qa-traversal-test.png، وهو محاولة اجتياز مسار (Path Traversal): فإن بنى الخادم مسار الحفظ من الاسم الأصلي، صعد كل ../ مجلداً واحداً إلى أعلى وخرج من مجلد الرفع (والاسم فريد، فإن وُجد العيب أنشأ ملفاً جديداً بدل الكتابة فوق ملف قائم)؛ واسم من 300 حرف، ومسافات، وحروف عربية، و%00 (بايت صفري مرمَّز)، واسم ليس إلا امتداداً. المتوقع: الحفظ باسم يولّده الخادم، والاسم الأصلي للعرض فقط ومرمَّزاً.
• تقديم الملف المخزَّن: افتح العنوان المُعاد. المتوقع: Content-Type صحيح، وnosniff، وattachment أو أصل منفصل؛ ولا شيء يُنفَّذ.
• التخزين والتنفيذ: اسأل أين تُخزَّن الملفات وهل ذلك المسار قابل للتنفيذ؛ فإن قُبل ملف نصي باسم .php أو .aspx أصلاً، فيجب أن يُنزَّل نصاً ولا يُنفَّذ أبداً.

جرّبها: مرجع أنواع MIME جرّبها: مدقّق Content-Type جرّبها: مولّد مجموعات الأحرف الخاصة

مثال تطبيقي: إتمام شراء مع كوبون للاستخدام الواحد

المتطلب: «يضيف العميل عناصر إلى السلة، وله أن يطبّق كوبوناً واحداً (استخدام واحد لكل عميل، والحد الأدنى للطلب 200 ريال)، ويدفع عبر مزوّد الدفع، ويستلم تأكيداً. ويُخصم المخزون عند تأكيد الطلب». والطلبات هي POST /cart/items وPOST /cart/coupon وPOST /orders (ينشئ الطلب ويعيد الإجمالي) وPOST /orders/{id}/pay وPOST /orders/{id}/confirm.

ابدأ بنمذجته حالاتٍ: السلة، وكوبون مطبَّق، وبانتظار الدفع، ومدفوع، ومؤكَّد، ثم اشتق اختباراً لكل انتقال ممنوع، واختباراً لكل حقل يجب أن يملكه الخادم، والقيم الحدّية لكل قاعدة (199.99 و200.00 للحد الأدنى للطلب، مع فحصه مجدداً عند حذف عناصر بعد تطبيق الكوبون). ولكل اختبار مرجع اختبار (Test Oracle) واضح: حالة الطلب وإجماليه بعد الاستدعاء، يُقرآن بـGET /orders/{id}، وعدد المخزون.

#  Test                                         Expected
1  POST /orders/{id}/confirm before /pay        4xx; stays Awaiting payment
2  /pay with "total": 1.00 in the body          4xx or ignored; server total kept
3  /cart/coupon twice with the same code        second call 4xx; discount once
4  coupon on a 199.99 cart (minimum 200.00)     4xx; no discount
5  coupon on a 200.00 cart                      accepted; discount applied
6  coupon at 200.00, then an item removed       discount dropped, or /orders 4xx
7  /cart/items with "quantity": -1              4xx; cart unchanged
8  /confirm sent twice in parallel              one confirmation; stock reduced once
9  /pay on another customer's order             403 or 404 (access control)
10 coupon already used on an earlier order      4xx; no discount

جرّبها: مولّد انتقالات الحالات جرّبها: منشئ طلبات API

أسئلة شائعة

المراجع

• OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
• OWASP Cheat Sheet Series: File UploadOWASP Foundationالتحقق من الملفات المرفوعة: فحص الامتداد ونوع المحتوى، وحدود الحجم، والتخزين خارج جذر الويب، والفحص.
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023أكثر عشر نقاط ضعف شيوعاً في واجهات API: خلل التفويض على مستوى الكائن، وخلل التوثيق، والاستهلاك غير المقيد للموارد، وغيرها.
• OWASP Top 10:2025OWASP Foundation · 2025أخطر عشرة مخاطر أمنية لتطبيقات الويب، مع كيفية اختبار كل منها والوقاية منه.