اختبار الاختراق
ما قد يفعله المهاجم، نفعله نحن أولًا.
اختبار اختراق يدوي يستند إلى OWASP وPTES وNIST في منهجيته. يختبر فريق معتمد من مختبِري الاختراق تطبيق الويب وواجهات API وتطبيق الجوال والبيئة السحابية والشبكة الخارجية والداخلية لديك كما يفعل مهاجم حقيقي. نكتشف يدويًا ثغرات منطق الأعمال وسلاسل الاستغلال وتصعيد الصلاحيات التي لا تلتقطها أدوات الفحص الآلي أبدًا، ونسلّمها في تقرير مدعوم بالأدلة.
ليست خدمة تكتفي بتشغيل أداة فحص وإخراج ملف PDF، بل هي منهجية تحاكي مهاجمًا يقضي أيامًا داخل نظامك، بنتائج قابلة للإثبات وإعادة اختبار بعد المعالجة.
280+
مشروع اختبار اختراق
CVSS3.1
تقييم المخاطر
OSCP/CEH
الشهادات
nmap -sV -p- target.partnerfy.co
443/tcp open https nginx 1.18.0 — TLS 1.2
22/tcp open ssh OpenSSH 7.4 (legacy)
gobuster dir -u https://target -w common.txt
/admin (Status: 200) [Size: 4821]
/api/v1/users (Status: 401) [Size: 38]
/.git/config (Status: 200) [Size: 263]
sqlmap -u 'target/login' --data 'u=a&p=b'
[INFO] testing 'AND boolean-based blind'
[INFO] parameter 'u' is vulnerable
[CRITICAL] SQL Injection — CVE-2024-XXXX — CVSS 9.8
سلسلة الهجوم
MITRE ATT&CK
تقرير اختبار الاختراق: النتائج
RPT-2026-0541
حقن SQL في نموذج تسجيل الدخول
CVSS 9.8
CRIT
سر JWT ضعيف: هجوم القوة الغاشمة
CVSS 9.1
CRIT
ثغرة IDOR في المسار /api/v1/users/{id}
CVSS 8.2
HIGH
ثغرة XSS مخزّنة في التعليقات
CVSS 7.4
HIGH
إعداد CORS غير صحيح
CVSS 6.1
MED
ترويسة HSTS مفقودة
CVSS 3.7
LOW
FIXED
المشكلة
لماذا لا تكفي أدوات الفحص الآلي؟
تفيد أدوات الفحص مثل Nessus وAcunetix وOWASP ZAP، لكنها لا تحل محل المهاجم. فالمهاجم يربط الثغرات في سلسلة استغلال، ويقرأ قواعد عملك ويحوّلها إلى سلاح ضدك، ويتجاهل الضوضاء ويصل إلى مدخل الاختراق الحقيقي. تعمل أداة الفحص وفق قائمة تحقق، أما مختبِر الاختراق فيضع فرضيات خاصة بنظامك.
لا تكشف سلاسل الاستغلال
تعرض أداة الفحص كل نتيجة على حدة، بينما يجمع المهاجم ثلاث نقاط منخفضة الخطورة في سلسلة هجوم حرجة.
لا ترى منطق الأعمال
لن تكتشف أداة الفحص أبدًا خطأً منطقيًا مثل «ضرب قيمة الطلب في -1».
تفتقر إلى الإبداع
يضع مختبِر الاختراق فرضيات خاصة بتطبيقك، أما أداة الفحص فتبحث عن التواقيع فقط.
كمّ هائل من الإنذارات الكاذبة
70% من تقرير أداة الفحص المؤلف من 500 صفحة مجرد ضوضاء. يتحقق مختبِر الاختراق يدويًا من كل نتيجة.
لا تعرف حدود الصلاحيات
لا يمكن اختبار قاعدة «يجب ألا يرى هذا المستخدم هذا السجل» إلا على يد من يعرف مجال عملك.
لا تتجاوز CAPTCHA وWAF
يتجاوز المهاجم جدار WAF، أما أداة الفحص فتتوقف عند أول رمز 403 تتلقاه.
لا تشمل الهندسة الاجتماعية
قد يكون المدخل الحقيقي أحيانًا رسالة بريد إلكتروني، ولا تستطيع أداة الفحص تنفيذ محاكاة تصيّد احتيالي.
لا تختبر محو الآثار
يخفي المهاجمون آثارهم، ولا يقيس مدى انتباه مركز عمليات الأمن (SOC) لديك إلا الفريق الأحمر (Red Team).
عرض مرئي للهجوم
أين الثغرات وما مدى خطورتها؟
نلخّص النتائج في كل مهمة عبر ثلاثة عناصر مرئية: خريطة حرارية حسب الفئة، وقائمة تحقق OWASP Top 10، ومخطط زمني يبدأ بالفحص ثم الاكتشاف ثم المعالجة ثم إعادة الاختبار وصولًا إلى النتيجة النظيفة.
خريطة حرارية لفئات الثغرات
Critical
High
Med
Low
XSS
SQLi
Auth
CORS
Crypto
Logic
IDOR
CSRF
SSRF
Upload
Headers
Deps
كل خلية تمثل فئة، وتوضح النقاط عدد النتائج ودرجة خطورتها، فيرى مديرك المنطقة الأعلى خطرًا بنظرة واحدة.
قائمة OWASP Top 10 لعام 2021
قائمة تحقق
- A01 Broken Access Control
- A02 Cryptographic Failures
- A03 Injection (SQL/XSS/Cmd)
- A04 Insecure Design
- A05 Security Misconfiguration
- A06 Vulnerable Components
- A07 Identification & Auth Failures
- A08 Software & Data Integrity
- A09 Logging & Monitoring Failures
- A10 SSRF
قبل وبعد
مسار اختبار الاختراق: الفحص ثم الاكتشاف ثم المعالجة ثم إعادة الاختبار ثم النتيجة النظيفة
كل مرحلة موثقة، وكل ثغرة تُغلق يُتحقق منها بإعادة اختبار مجانية بعد المعالجة.
01
الفحص
استطلاع آلي ويدوي
02
الاكتشاف
نتائج مؤكدة
03
المعالجة
توصيات المعالجة مع أمثلة برمجية
04
إعادة الاختبار
التحقق من الإغلاق
05
نظيف
تقرير نظيف وشهادة
لمن هذه الخدمة؟
من يحتاج فعلًا إلى اختبار الاختراق هذا؟
ليس اختبار الاختراق إلزاميًا لكل شركة، لكن إذا كنت ضمن إحدى هذه الفئات فعليك البدء اليوم لا في يوم ما. إليك 8 فئات نموذجية.
متاجر إلكترونية تستقبل المدفوعات
بيانات البطاقات، ومسارات 3DSecure، وإساءة استخدام القسائم، والتلاعب بالأسعار.
منصات SaaS ببيانات العملاء
عزل البيئات متعددة المستأجرين (Multi-Tenant)، وحدود صلاحيات المستخدمين، وخطر IDOR المرتفع.
شركات التقنية المالية الخاضعة للتنظيم
معايير PCI-DSS والجهات الرقابية المالية وGDPR: اختبار اختراق مستقل واحد على الأقل سنويًا.
قطاع صحي يعالج بيانات PHI
بيانات المرضى، وأنظمة المواعيد، وحماية بمستوى HIPAA للبيانات الصحية.
متعاقدو القطاع الحكومي
قبل عمليات التدقيق الحكومية، تُطلب شهادة مستقلة تثبت إجراء اختبار الاختراق.
شركات B2B ذات تكاملات API
واجهات API للشركاء، ومسارات OAuth، وسلاسل التحقق من الهوية.
تطبيقات جوال خاضعة لمراجعة App Store
تخزين الرموز المميزة (Tokens)، وامتثال MASVS، وكشف كسر الحماية (Jailbreak/Root)، وتثبيت شهادات SSL (SSL Pinning).
عملاء بعد وقوع حادث أمني
بعد الاختراق: إجابة مدعومة بالأدلة عن سؤال «هل هناك باب آخر مفتوح؟».
نطاق الخدمة
فريق واحد و10 قدرات مختلفة لاختبار الاختراق
من الويب إلى السحابة، ومن الجوال إلى الأمن المادي: فريق هندسي واحد يغطي سطح الهجوم بالكامل. إذا احتجت إلى اختبار تطبيق واحد فسننفذه، وإذا احتجت إلى عملية فريق أحمر (Red Team) كاملة فسننفذها أيضًا.
اختبار اختراق الشبكة الخارجية
جميع عناوين IP المتصلة بالإنترنت، والمنافذ المفتوحة، والخدمات القديمة.
اختبار اختراق الشبكة الداخلية
من الداخل بصفة موظف: مسار الوصول إلى صلاحيات مدير النطاق.
اختبار اختراق تطبيقات الويب
قائمة OWASP Top 10 ومنطق الأعمال وسيناريوهات المصادقة والتفويض.
اختبار اختراق واجهات API
بروتوكولات REST وGraphQL وgRPC، وقائمة OWASP API Top 10، وثغرات BOLA، وحدود معدل الطلبات.
اختبار اختراق تطبيقات الجوال
منصتا iOS وAndroid، ومعيار MASVS، وأداة Frida، والهندسة العكسية.
اختبار اختراق السحابة (AWS/Azure/GCP)
أخطاء إعداد IAM، وصلاحيات IAM في Lambda، وضوابط RBAC في K8s، والحاويات العامة (Buckets).
الهندسة الاجتماعية
حملات التصيّد الاحتيالي، والتصيّد الصوتي، وزرع وحدات USB لقياس وعي الموظفين.
اختبار الاختراق المادي
دخول المكاتب، واستنساخ بطاقات الدخول، والتسلل خلف الموظفين، والوصول إلى غرفة الخوادم.
مهمة الفريق الأحمر (Red Team)
سيناريو كامل من البريد الإلكتروني إلى مدير النطاق: هل سيكتشفه مركز عمليات الأمن (SOC) لديك؟
إعادة الاختبار بعد المعالجة
تحقق مجاني من أن الإصلاحات أغلقت الثغرات فعلًا.
آلية العمل
منهجيتنا لاختبار الاختراق في 6 خطوات
تخضع كل مهمة للمنهجية نفسها: وثيقة النطاق (RoE)، ثم الاستطلاع، فتقييم الثغرات، فالاستغلال الفعلي، فإعداد التقارير المدعومة بالأدلة، وأخيرًا إعادة اختبار مجانية.
01
النطاق وقواعد الاشتباك (Rules of Engagement)
نوثّق الأنظمة والسيناريوهات والساعات المسموح بها وحدود معدل الطلبات في وثيقة RoE رسمية موقّعة. وهل يجري الاختبار على بيئة الإنتاج أم بيئة التجهيز (Staging)، وهل تدخل الهندسة الاجتماعية في النطاق: كل ذلك يُحسم مسبقًا.
02
جمع المعلومات (الاستطلاع)
استخبارات المصادر المفتوحة (OSINT)، وحصر النطاقات الفرعية، ورسم خريطة المنافذ، وبصمة التقنيات، والبحث عن بيانات الاعتماد المسرّبة. نلتقط صورة لسطح الهجوم بعين المهاجم.
03
تقييم الثغرات
نفرز مخرجات أدوات الفحص يدويًا، ونصمم سيناريوهات لمنطق الأعمال، فتتحول كل نتيجة إلى فرضية.
04
الاستغلال
نثبت الفرضيات كما يفعل مهاجم حقيقي: سلاسل استغلال، وتصعيد للصلاحيات، واستخراج للبيانات، ضمن الحدود الأخلاقية ومع توثيق كامل.
05
إعداد التقارير
ملخص تنفيذي، وأدلة لكل نتيجة، ودرجة CVSS، وخارطة طريق للمعالجة مرتبة حسب الأولوية. ويستطيع فريق التطوير التعمق حتى أمثلة الشيفرة البرمجية.
06
المعالجة وإعادة الاختبار
بعد نشر الإصلاحات (خلال 4-8 أسابيع عادةً) نعيد اختبار جميع النتائج الحرجة والعالية (Critical/High) مجانًا ونتحقق من إغلاقها.
الأدوات
الأدوات التي نستخدمها في الميدان
الأدوات مهمة، لكن العقل الذي يستخدمها أهم. والاختبار اليدوي يتقدم دائمًا على أدوات الفحص.
Burp Suite Pro
OWASP ZAP
Metasploit
Nmap
Nessus
Acunetix
Nuclei
Wireshark
John the Ripper
Hashcat
Cobalt Strike
Postman
ffuf
BloodHound
SQLmap
Frida
MobSF
Kali Linux
Responder
CrackMapExec
من الميدان
بعض الثغرات الحقيقية التي اكتشفناها
نحافظ على سرية أسماء العملاء ونشارك التفاصيل التقنية. وقد أُغلقت كل ثغرة قبل الانتقال إلى بيئة الإنتاج أو قبل أي إساءة استخدام.
التجارة الإلكترونية
CRIT
حقن SQL قبل الإطلاق
حقن SQL أعمى في بحث المنتجات كان يتيح استخراج جدول الطلبات بالكامل. جرى الانتقال إلى ORM بعد اكتشافه قبل 4 أيام من الإطلاق.
برمجيات SaaS
CRIT
تجاوز المصادقة
كان رمز JWT يقبل القيمة «alg:none»، ما يتيح للمهاجم دخول أي مستأجر (Tenant) بصفة مدير.
تطبيق مصرفي للجوال
CRIT
تخزين غير آمن للرموز المميزة
كان رمز الجلسة يُكتب نصًا صريحًا في NSUserDefaults ويمكن قراءته على جهاز بصلاحيات الجذر. جرى الانتقال إلى Keychain مع المصادقة البيومترية.
واجهات API لقطاع B2B
HIGH
ثغرة IDOR: بيانات شركة أخرى
لم تكن نقطة النهاية /api/invoices/{id} تتحقق من الملكية، فأتاحت المعرّفات المتسلسلة الوصول إلى فواتير الشركات المنافسة.
بوابة صحية
HIGH
رابط إعادة التعيين غير عشوائي
كان رمز إعادة تعيين كلمة المرور يُولَّد من epoch + user_id، فكان هجوم القوة الغاشمة يتيح الاستيلاء على أي حساب.
بيئة AWS مؤسسية
MED
حاوية S3 عامة
كانت سجلات CI/CD تُكتب في حاوية عامة (Bucket) تحتوي على بيانات اعتماد مؤقتة لقاعدة البيانات.
الأسئلة الشائعة
الأسئلة الأكثر شيوعًا حول اختبار الاختراق
تعتمد أداة الفحص الآلي (مثل Nessus وZAP وAcunetix) على التواقيع: فهي تبحث عن أنماط معروفة، ومعظم نتائجها إنذارات كاذبة، ولا تكتشف أبدًا ثغرات منطق الأعمال. أما مختبِر الاختراق فيضع فرضيات خاصة بتطبيقك، ويربط ثلاث نقاط ضعف في هجوم حرج، ويحاول تصعيد الصلاحيات يدويًا، ويثبت كل نتيجة بخطوات قابلة لإعادة التنفيذ. وعمليًا، نصف «النتائج الحرجة العشر» في تقرير أداة الفحص مجرد ضوضاء، بينما جرى استغلال كل نتيجة في تقرير اختبار الاختراق وإثباتها، فيتجاوز فريق التطوير النقاش وينتقل مباشرة إلى الإصلاح.
الأنواع الثلاثة صالحة، ويقيس كل منها أمرًا مختلفًا. يبدأ اختبار الصندوق الأسود (Black-Box) من مهاجم لا يعرف عنك شيئًا، وهو الأقرب إلى المهاجم الحقيقي لكنه مكلف من حيث الوقت والنطاق. أما الصندوق الأبيض (White-Box) فيمنح المختبِر الشيفرة المصدرية ومخططات البنية وحسابات المدير، وهو أعمق اختبار قياسًا بكل ساعة عمل، والأنسب قبل الإطلاق. ويقع الصندوق الرمادي (Gray-Box) في المنتصف: حساب مستخدم عادي مع معرفة عامة بالبنية، وهو الحل الوسط الأكثر عملية لمعظم اختبارات الاختراق في المؤسسات الكبيرة لأنه يغطي نموذجَي المهاجم الخارجي والداخلي في مهمة واحدة. ويعتمد الخيار الصحيح على الهدف، ونقرره معك في الاجتماع الأول.
إذا أُديرت العملية بشكل صحيح فلا. تحدد وثيقة قواعد الاشتباك (RoE) الساعات المسموح بها، وحدود الاتصالات المتزامنة، وحسابات الاختبار المعزولة، والإجراءات المحظورة مثل هجمات حجب الخدمة (DoS) والحذف الدائم للبيانات. وفي معظم المهام تقتصر الفحوص التخريبية، مثل محاولات القوة الغاشمة التي تفعّل قفل الحسابات أو رفع الحمولات، على بيئة التجهيز (Staging)، أما في بيئة الإنتاج فنكتفي بجمع أدلة للقراءة فقط. وتوجد دائمًا خطة للتراجع: لقطات احتياطية قبل الاختبار، ومهندس مناوب يمكن الوصول إليه عند أي خلل. أكثر من 280 مهمة بلا أي انقطاع في الإنتاج، لأن هذا التخصص يتطلب هذا الانضباط.
يختلف ذلك باختلاف النطاق. يستغرق تطبيق ويب واحد عادةً من 5 إلى 10 أيام عمل، ومهمة API متوسطة الحجم من 7 إلى 12 يوم عمل، وتطبيق الجوال من 8 إلى 14 يوم عمل، وسيناريو الفريق الأحمر (Red Team) الكامل من 4 إلى 8 أسابيع. ويضاف إلى ذلك، بعد نشر الإصلاحات (خلال 4 إلى 8 أسابيع عادةً)، إعادة اختبار مجانية تستغرق نحو 2 إلى 3 أيام عمل. وتحدد المدة ثلاثة عوامل: اتساع النطاق، وعدد الأدوار والصلاحيات المطلوب فحصها، وإمكانية الوصول إلى بيئة الاختبار. وفي الاجتماع الأول نحدد النطاق ونقدم عدد أيام عمل ثابتًا وسعرًا ثابتًا، ولا يتغيران لاحقًا.
يتألف التقرير من ثلاثة مستويات. الأول ملخص تنفيذي من صفحة إلى صفحتين، يضم جدول مخاطر غير تقني وعدد النتائج والوضع الأمني العام. والثاني النتائج التقنية، ولكل نتيجة وصفها والمكوّن المتأثر وخطوات الاستغلال مع لقطات الشاشة ودرجة CVSS 3.1 والإصلاح الموصى به مع أمثلة برمجية. والثالث خطة عمل مرتبة حسب الأولوية تبيّن ما يجب إصلاحه أولًا وما يليه، بما يتوافق مع وتيرة دورات العمل (Sprints) لديك. ويُسلَّم التقرير كاملًا بصيغتي Markdown وPDF، ويُعاد إصداره بعد إعادة الاختبار مع ملاحظة «remediated». ويقدمه عملاؤنا مباشرة إلى مدققي ISO 27001 وSOC 2 وPCI-DSS عند التدقيق.
لا. إعادة اختبار جميع النتائج الحرجة والعالية (Critical وHigh) من المهمة الأساسية مشمولة في قيمة العقد. والشرط الوحيد هو نشر الإصلاحات خلال 4 إلى 8 أسابيع (ويمكن تمديدها إلى 12 أسبوعًا بالاتفاق) وتوفر بيئة جاهزة للاختبار. وتُوسم النتائج المغلقة بعبارة «remediated»، ويُعاد الإبلاغ عن النتائج التي ما زالت مفتوحة. هذه هي ضمانة الجودة لدينا: لا نسلّم التقرير ثم نختفي، بل نبقى معك حتى الإغلاق. أما إعادة اختبار النتائج المتوسطة والمنخفضة (Medium وLow) فاختيارية، وتكلّف نسبة صغيرة من قيمة المهمة الأساسية.
نستخدم الثلاثة معًا في المهمة نفسها، ونطبّق لكل هدف مرجعه: تطبيقات الويب (OWASP Top 10 لعام 2021 وOWASP ASVS Level 2)، وواجهات API (OWASP API Top 10)، وتطبيقات الجوال (OWASP MASVS). وتتبع المنهجية مراحل PTES (Penetration Testing Execution Standard): التحضير المسبق، وجمع المعلومات، ونمذجة التهديدات، وتحليل الثغرات، والاستغلال، وما بعد الاستغلال، وإعداد التقارير. ونعتمد CVSS 3.1 لتقييم المخاطر، ونرجع إلى NIST SP 800-115 في صياغة التقرير. والعمل متوافق مع ISO 27001 وSOC 2 وPCI-DSS، أي أن التقرير يأتي بالبنية التي يتوقعها المدقق لديك. والجمع بين المعايير الثلاثة يضمن العمق التقني والجاهزية للتدقيق معًا.
نعم، في كل مهمة يحمل المهندس القائد شهادة واحدة على الأقل معترفًا بها في القطاع: OSCP (Offensive Security Certified Professional)، أو OSWE (Offensive Security Web Expert)، أو CEH (Certified Ethical Hacker)، أو CRTP (Certified Red Team Professional)، أو GPEN (GIAC Penetration Tester). ونفضّل كذلك شهادة eMAPT لتطبيقات الجوال، وشهادة AWS Security Specialty أو AZ-500 للسحابة. وليست الشهادات إلزامية، لكن عندما يطلبها العميل، خصوصًا في مناقصات القطاعين المالي والحكومي، يمكننا إرفاقها بوثائق الشراء. والأهم أن يقدم الفريق نتائج قابلة لإعادة التنفيذ، فالشهادات مؤشر على ذلك وليست ضمانًا له، ونحن نقدم الأمرين معًا.
لنكتشف ثغراتك
قبل أن يكتشفها المهاجمون.
في اجتماع مجاني لمدة 30 دقيقة لتحديد النطاق، نضع معًا خطة اختبار الاختراق: الأنظمة المستهدفة، وقواعد الاشتباك (RoE)، والجدول الزمني، والسعر الثابت.