استخدام Burp Suite في اختبار حقيقي: من فهم الطلب إلى إثبات النتيجة

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

جهز بيئة اختبار منفصلة وحدد النطاق

Burp Suite

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

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

تصفح الميزة كما يستخدمها صاحبها

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

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

أعد الطلب لاختبار فرضية واحدة

Repeater

هذه الأداة تسمح بتعديل رسالة وإرسالها مجددًا، وهي مناسبة للتحقق اليدوي ومقارنة السلوك. أرسل إليها طلبًا مهمًا، وسمّ التجربة بما يصف السؤال. مثلًا: «حساب تجريبي ثانٍ يطلب ملف الحساب الأول». لا تجعل أسماء التبويبات أرقامًا لا تتذكر معناها بعد ساعة.

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

الاستجابة ليست مجرد رقم وحجم

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

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

متى تستخدم الأتمتة؟

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

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

حوّل الجلسة إلى نتيجة قابلة للتسليم

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

توثيق الأداة الرسمي ومرجع إعادة إرسال الطلبات:
https://portswigger.net/burp/documentation/desktop
https://portswigger.net/burp/documentation/desktop/tools/repeater

ولفهم كيف تختار الفرضية قبل استخدام الأداة، اقرأ:
https://courses.cyberpts.com/community/10/kyf-tfkr-kmkhtbr-akhtraq-and-rwyh-hdf-jdyd