مطلوب مختص اختبار اختراق تطبيق Android

مطلوب مختص اختبار اختراق (Penetration Testing Team) لتطبيق Salla EG – Android فقط – بميزانية 3,000 دولار

نبذة عن المشروع

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

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

أولًا: نطاق العمل

الاختبار في المرحلة الحالية يشمل:

1. تطبيق Salla EG على Android.

2. واجهات الـ API التي يستخدمها التطبيق، بما فيها اختبار الصلاحيات والتحقق من البيانات التي يعالجها السيرفر.

3. المصادقة وتسجيل الدخول وإدارة الجلسات.

4. حماية بيانات المستخدمين وعناوينهم وأرقام هواتفهم.

5. المحفظة والاشتراكات والمدفوعات المرتبطة بالتطبيق.

6. دورة حياة الطلبات من عرض المخلفات إلى الحجز والاستلام والإكمال.

7. رفع الصور والموقع والكمية وصور الميزان.

8. واجهات الـ API الخاصة بتكامل QR والجلسات والمكافآت، إذا كانت متاحة للاختبار.

9. اختبار التفاعل بين أدوار المستخدمين المختلفة.

خارج النطاق الحالي: الموقع الإلكتروني كواجهة مستقلة، ولوحة الإدارة كواجهة مستقلة، واختبار iOS، والماكينة الفعلية، والـ Firmware. ومع ذلك، يمكن اختبار الـ APIs المشتركة مع الموقع أو لوحة الإدارة عندما تكون ضرورية لتقييم أمان تطبيق Android، مع عدم اعتبار الواجهات المستبعدة مختبرة.

ثانيًا: تفاصيل نظام Salla EG

1. حسابات المستخدمين

تتيح المنصة إنشاء الحسابات وتسجيل الدخول واستخدام الخدمات وفقًا لصلاحيات كل مستخدم.

2. مقدمو المخلفات

يستطيع المستخدم رفع صور المخلفات وتحديد موقعها وإضافة بيانات الطلب.

3. المشترون

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

4. الاشتراكات

لدينا اشتراك يومي بقيمة 200 جنيه مصري، يتيح للمشتري الوصول إلى مجموعة من الطلبات وفقًا لقواعد الاشتراك، وعددها المستهدف تقريبًا من 8 إلى 10 طلبات.

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

5. حجز الطلبات

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

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

6. إكمال الاستلام

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

7. واجهات QR والمكافآت

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

ثالثًا: قائمة مهام الاختبار المطلوبة

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

المرحلة الأولى: تجهيز الاختبار وفهم التطبيق – 5 مهام

1. تحديد نطاق التطبيق والنسخة المطلوب اختبارها.

2. رسم خريطة للشاشات والوظائف الأساسية.

3. حصر واجهات API التي يستخدمها التطبيق.

4. تحديد أدوار المستخدمين والصلاحيات المتوقعة لكل دور.

5. إعداد خطة الاختبار وقواعد العمل المسموح بها قبل البدء.

المرحلة الثانية: التسجيل وتسجيل الدخول – 10 مهام

6. اختبار التسجيل وإنشاء الحسابات.

7. اختبار تسجيل الدخول والتحقق من بيانات الاعتماد.

8. اختبار استعادة كلمة المرور.

9. اختبار التحقق من البريد الإلكتروني أو رقم الهاتف، إذا كان متاحًا.

10. اختبار آلية OTP وحدود المحاولات، إذا كانت مطبقة.

11. اختبار تسجيل الخروج وإبطال الجلسات.

12. اختبار انتهاء صلاحية الجلسات والرموز.

13. اختبار التعامل مع الحسابات غير المفعلة أو الموقوفة.

14. اختبار حماية واجهات المصادقة من المحاولات المتكررة.

15. اختبار تسريب المعلومات من رسائل الخطأ والاستجابات.

المرحلة الثالثة: صلاحيات المستخدمين والتحكم في الوصول – 10 مهام

16. التحقق من ملكية الطلبات والحسابات على مستوى السيرفر.

17. اختبار منع الوصول إلى بيانات مستخدم آخر.

18. اختبار صلاحيات قراءة بيانات الطلبات.

19. اختبار صلاحيات تعديل الطلبات.

20. اختبار صلاحيات حذف الطلبات.

21. اختبار الوصول إلى وظائف غير متاحة لدور المستخدم.

22. اختبار إمكانية تغيير معرّفات الطلبات للوصول إلى بيانات غير مصرح بها.

23. اختبار التحقق من صلاحيات كل عملية على مستوى الـ API.

24. اختبار الحقول الحساسة التي قد يمكن تعديلها من خلال الطلبات.

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

المرحلة الرابعة: خصوصية البيانات والمعلومات الحساسة – 8 مهام

26. التحقق من إخفاء العناوين التفصيلية قبل الحصول على صلاحية الوصول.

27. التحقق من إخفاء أرقام الهواتف غير المصرح بعرضها.

28. فحص استجابات الـ API بحثًا عن بيانات إضافية غير مطلوبة.

29. اختبار تسريب بيانات المستخدمين بين الحسابات.

30. اختبار الوصول إلى الصور والملفات المقيدة.

31. التحقق من عدم تسريب البيانات عبر السجلات أو رسائل الأخطاء.

32. اختبار البيانات المخزنة مؤقتًا داخل التطبيق.

33. التحقق من حماية الموقع الجغرافي والبيانات الشخصية.

المرحلة الخامسة: عرض المخلفات والبحث – 7 مهام

34. اختبار البحث عن الطلبات حسب المحافظة والمركز.

35. اختبار صحة التحقق من معايير البحث والفلترة.

36. اختبار الوصول إلى الطلبات غير المنشورة أو المنتهية.

37. اختبار التحقق من ملكية بيانات المخلفات.

38. اختبار التلاعب بمعرّفات الطلبات في طلبات البحث والتفاصيل.

39. اختبار صلاحيات الوصول إلى الصور ومعلومات المخلفات.

40. التحقق من اتساق بيانات الطلب بين التطبيق والسيرفر.

المرحلة السادسة: الاشتراكات وحدود الوصول – 8 مهام

41. اختبار تفعيل الاشتراك بعد تأكيد الدفع الصحيح.

42. التحقق من منع تفعيل الاشتراك دون استحقاق صحيح.

43. اختبار صحة سعر الاشتراك ومدته.

44. اختبار الالتزام بحدود عدد الطلبات المسموح بها.

45. اختبار منع استخدام الاشتراك بعد انتهاء صلاحيته.

46. اختبار قواعد الاشتراك اليومي والشهري.

47. اختبار الطلبات المتزامنة وتأثيرها على عدد الطلبات المتاحة.

48. التحقق من تطابق حالة الاشتراك مع سجل المعاملات.

المرحلة السابعة: المحفظة والمدفوعات – 10 مهام

49. اختبار سلامة رصيد المحفظة.

50. التحقق من منع تعديل الرصيد من جهة العميل.

51. اختبار سلامة تسجيل عمليات الإضافة والخصم.

52. اختبار منع تسجيل المعاملة المالية نفسها أكثر من مرة.

53. اختبار معالجة الطلبات المالية المتزامنة.

54. اختبار التحقق من مبلغ المعاملة وعملتها.

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

56. اختبار التعامل مع حالات الدفع الناجح والمرفوض والمعلق.

57. التحقق من صحة سجل العمليات المالية.

58. التحقق من اتساق المحفظة والاشتراك والطلب بعد فشل المعاملات أو تكرارها.

المرحلة الثامنة: حجز الطلبات ومهلة اليومين – 10 مهام

59. اختبار حجز الطلب وفقًا لصلاحيات المشتري.

60. اختبار منع حجز الطلب نفسه لأكثر من مشترٍ في الوقت نفسه.

61. اختبار التزامن عند إرسال طلبات الحجز المتقاربة.

62. التحقق من حصرية تفاصيل الطلب للمشتري المستحق.

63. اختبار انتهاء الحجز بعد يومين.

64. التحقق من إعادة الطلب إلى قائمة الطلبات المتاحة بعد انتهاء المهلة.

65. اختبار منع تمديد مدة الحجز دون صلاحية.

66. اختبار منع إلغاء حجز مستخدم آخر.

67. اختبار منع استمرار الوصول إلى التفاصيل بعد انتهاء الاستحقاق.

68. التحقق من اتساق حالة الحجز بين التطبيق والسيرفر.

المرحلة التاسعة: الاستلام وإكمال الطلب – 7 مهام

69. اختبار منع إكمال طلب لا يخص المشتري.

70. اختبار التحقق من صور الميزان.

71. اختبار التحقق من الكمية المسجلة.

72. اختبار التحقق من موقع الاستلام.

73. اختبار منع تسجيل عملية الإكمال أكثر من مرة.

74. اختبار منع تعديل طلب مكتمل دون صلاحية.

75. التحقق من اتساق صور الإثبات والكمية وحالة الطلب.

المرحلة العاشرة: رفع الصور والملفات – 6 مهام

76. اختبار التحقق من نوع الملفات المسموح برفعها.

77. اختبار التحقق من حجم الصور وحدود الرفع.

78. اختبار حماية الملفات من الوصول غير المصرح به.

79. التحقق من عدم الثقة في امتداد الملف أو نوعه المرسل من العميل وحده.

80. اختبار صلاحيات حذف الصور أو استبدالها.

81. التحقق من عدم كشف معلومات حساسة من بيانات الصور الوصفية، متى كان ذلك منطبقًا.

المرحلة الحادية عشرة: أمان Android والتخزين المحلي – 8 مهام

82. فحص إعدادات Android وملف Manifest.

83. اختبار تخزين الرموز وبيانات الجلسات.

84. التحقق من عدم وجود أسرار أو بيانات اعتماد ثابتة داخل التطبيق.

85. اختبار إعدادات الاتصال المشفر والتحقق من الشهادات.

86. فحص السجلات بحثًا عن بيانات حساسة.

87. اختبار النسخ الاحتياطي ومخاطر استخراج بيانات التطبيق.

88. فحص المكونات المكشوفة والروابط العميقة والصلاحيات.

89. اختبار مخاطر العبث بالتطبيق أو تشغيله في بيئة معدلة، بحسب الحاجة والمخاطر.

المرحلة الثانية عشرة: واجهات QR والجلسات والمكافآت – 5 مهام

90. اختبار التحقق من صحة بيانات جلسة QR.

91. اختبار منع إعادة استخدام الجلسة لصرف مكافأة إضافية.

92. اختبار التحقق من ارتباط الجلسة بالمستخدم الصحيح.

93. اختبار سلامة حساب المكافأة ومنع التلاعب بقيمتها من جهة العميل.

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

المرحلة الثالثة عشرة: التقرير وإعادة الاختبار – 6 مهام

95. إعداد قائمة موحدة بالثغرات المؤكدة.

96. تصنيف الثغرات حسب الخطورة والأثر الفعلي.

97. توثيق خطوات إعادة إنتاج كل ثغرة والأدلة المرتبطة بها.

98. تقديم توصيات إصلاح واضحة وقابلة للتنفيذ.

99. تسليم تقرير تنفيذي وفني نهائي باللغة العربية، مع إبقاء المصطلحات التقنية الإنجليزية عند الحاجة.

100. تنفيذ جولة إعادة اختبار واحدة للثغرات التي تم إصلاحها، ضمن الحدود المتفق عليها، وتسليم تقرير يوضح نتيجة الإصلاح.

إجمالي القائمة: 100 مهمة اختبار موزعة على 13 مرحلة.

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

رابعًا: متطلبات المختص

يشترط أن يكون المتقدم متخصصًا، وأن يوضح في عرضه:

- خبرة في اختبار تطبيقات Android.

- خبرة عملية في اختبار الـ APIs وصلاحيات الوصول.

- خبرة في اختبار منطق الأعمال والمحافظ والمدفوعات.

- خبرة في إعداد تقارير احترافية.

- نموذج تقرير سابق بعد إزالة بيانات العملاء.

- منهجية الاختبار والأدوات المستخدمة.

- الجدول الزمني المتوقع لكل مرحلة.

يفضل وجود مختبر متخصص في Android، ومختبر متخصص في API وBusiness Logic،

لا يكفي تقديم تقرير آلي من أدوات الفحص دون تحقق يدوي من النتائج.

خامسًا: المخرجات المطلوبة

يجب تسليم الآتي:

1. خطة الاختبار ونطاق العمل المعتمد.

2. قائمة المهام المائة مع حالة كل مهمة.

3. تقرير فني مفصل بالثغرات المؤكدة.

4. ملخص تنفيذي للإدارة.

5. أدلة فنية منقحة لا تحتوي على أسرار أو بيانات مستخدمين حقيقية.

6. تصنيف الخطورة باستخدام CVSS عند ملاءمته، مع توضيح الأثر التجاري.

7. توصيات إصلاح لكل ثغرة.

8. قائمة بالمكونات أو المهام التي تعذر اختبارها وأسباب ذلك.

9. تقرير إعادة الاختبار بعد الإصلاح.

10. اجتماع ختامي لمناقشة النتائج والإجابة عن أسئلة فريق التطوير.

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

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

سابعًا: الاستثناءات

الاختبار الحالي لا يشمل:

- اختبار الموقع الإلكتروني كواجهة مستقلة.

- اختبار لوحة الإدارة كواجهة مستقلة.

- تطبيق iOS.

- الاختبار المادي لماكينة إعادة التدوير.

- اختبار Firmware أو Hardware.

- هجمات حجب الخدمة أو الاختبارات التدميرية.

- الهندسة الاجتماعية والتصيد.

- الأنظمة الخارجية غير المصرح باختبارها.

- إجراء معاملات مالية حقيقية غير معتمدة.

- تنفيذ الإصلاحات البرمجية بدلًا من فريق التطوير.

- إعادة اختبار غير محدودة بعد الجولة المتفق عليها.

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

ثامنًا: ضوابط الاختبار

سيتم تنفيذ العمل ضمن نطاق مصرح به وبيئة متفق عليها.

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

تاسعًا: أسئلة يجب الإجابة عنها في العرض

1. كيف سيختبر صلاحيات المستخدمين وخصوصية العناوين وأرقام الهواتف؟

2. كيف سيتحقق من عدم إمكانية حجز الطلب نفسه من أكثر من مستخدم؟

3. كيف سيختبر المحفظة والمدفوعات دون المخاطرة بأموال حقيقية؟

4. كيف سيختبر حدود الاشتراكات ومهلة اليومين؟

5. كيف سينفذ اختبار Android اليدوي بجانب اختبار الـ APIs؟

6. كيف سيتعامل مع واجهات QR في غياب الماكينة الفعلية؟

8. ما المدة المتوقعة لتنفيذ المهام المائة؟

9. هل تشمل الميزانية التقرير الفني وجولة إعادة الاختبار؟

10. ما المنهجية التي ستسخدمها لضمان جودة النتائج وعدم تكرار الثغرات؟

نبحث عن مختص احترافي يقدم نتائج قابلة للتحقق، وتوصيات عملية، وتقريرًا واضحًا يساعدنا على تحسين أمان Salla EG قبل التوسع في الاستخدام.

يرجى تقديم عرض محدد يشمل خطة العمل والمدة والمخرجات و الاستثناءات، مع الالتزام بميزانية المشروع.