ترجمه قوقل ؟ جد ؟
فهرس ثغره الـ Business logic والمواضيع المشروحه فيها
1. شرح ثغره الـ Business logic وكيف بحصل الهجوم
2. تأثير الثغره وكيف نحمي حالنا منها
3. أمثلة على ثغرات Business logic
4. شرح ثغرة عدم التعامل مع المدخلات الغير التقليدية
حل الابات الخاصه بالـ Business logic
1. Excessive trust in client-side controls
2. High-level logic vulnerability
3. Inconsistent security controls
4. Flawed enforcement of business rules
5. Low-level logic flaw
6. Inconsistent handling of exceptional input
7. Weak isolation on dual-use endpoint
8. Insufficient workflow validation
9. Authentication bypass via flawed state machine
10. Infinite money logic flaw
11. Bypassing access controls using email address parsing discrepancies
شرح ثغره الـ Business logic وكيف بحصل الهجوم
هي أخطاء بتصميم وبتنفيذ التطبيق بتظهر الثغره لما نعمل افتراضات خاطئة عن سلوك المستخدم او ما نحسب حسابات معينه ...
الثغرة هاي بتكون بسبب عدم التحقق من المدخلات أو تجاهل سيناريوهات غير متوقعة
كيف بحدث الهجوم:
الخلل بظهر لما ما ندرس التطبيق بشكل شامل أو نترك فجوات بعملية التحقق
كيف بحصل الهجوم:
مثلاً بمتجر معين بحمّل صورة المنتج باستخدام رابط زي هاد :
https://example.com/image.jpg
هون التطبيق بقرأ الصورة لكن لو ما كان مأمن كويس
مثلاً لو كتبنا:
جار التحميل…
example.com
فالنتيجة ممكن تكون استقبال بيانات مش متوقعة واستغلال الخطأ بمنطق التطبيق
تأثير الثغرات وكيف نحمي حالنا منها:
بسبب الأخطاء هاي ممكن نوصل لوظائف أو بيانات حساسة وببعض الحالات بنقدر نعدل على الملفات أو نغير قيم حرجة بالتطبيق وطبعا التأثير بتراوح بين مشاكل بسيطة لمشاكل أمنية خطيرة حسب طبيعة التطبيق والبيانات
الوقاية والحماية:
1. لازم نفهم logic التطبيق بشكل كامل ونتجنب الافتراضات الغير دقيقة
2. بنوثق كل خطوة بسير العمل بساعد باكتشاف الثغرات مبكراً
3. بنتحقق من صحة البيانات على مستوى السيرفر مش بس مستوى على العميل
4. بنشغل أدوات فحص الثغرات بانتظام عشان نتأكد انه مافي نقاط ضعف
أمثلة على ثغرات الـ Business logic
بتظهر حسب السياق الخاص بكل تطبيق ورغم اختلاف كل حالة عن الثانية إلا إنه بنلاقي أنه في أنماط مشتركة بتربط بينها
بنقدر نصنفها بناءً على الأخطاء الأساسية اللي أدت لظهورها راح نستعرض أمثلة عن الأخطاء اللي ممكن ترتكبها فرق التصميم والتطوير
واللي بتأدي مباشرة لظهور ثغرات Business logic هاي الأخطاء غالباً بتكون نتيجة افتراضات خاطئة عن سلوك المستخدم أو تجاهل حالات استثنائية غير متوقعة سواء كنت بتطور تطبيق جديد أو بتراجع تطبيق قائم الدروس هاي بتساعدنا نطبق نفس التفكير النقدي على باقي التطبيقات
أمثلة على أخطاء الـ logic: (لابات سيتم حلها)
1. الثقة المفرطة بالتحكمات على جانب العميل
2. عدم التعامل مع المدخلات الغير تقليدية
3. الافتراضات الخاطئة عن سلوك المستخدم
4. الثغرات الخاصة بـ Domain معين
5. توفير encryption oracle
6. اختلافات بتحليل عناوين البريد الإلكتروني
الثقة المفرطة بالتحكمات على جانب العميل:
افتراض خاطئ إن المستخدمين بتعاملوا بس من خلال الواجهة المعتمدة للتطبيق هاد الشيء خطر لأنه بفرض التحقق من جانب العميل انه بمنعوا يرسل مدخلات خبيثة
لكن المهاجم بقدر يستخدم أدوات مثل Burp Proxy وبعدل البيانات بعد ما تنرسل من المتصفح وقبل ما تدخل على السيرفر
Lab: 2FA broken logic
ثغرة في منطق التحقق بخطوتين Two-Factor Authentication - 2FA
ببعض الأحيان بكون في خلل بمنطق التحقق بخطوتين بتسبب بأنه الموقع ما بقوم بالتحقق بشكل كافٍ من أنه المستخدم اللي كمل الخطوة الأولى هو نفسه اللي كمل الخطوة الثانية
مثلا
المستخدم بسجل دخول باستخدام اسم المستخدم وكلمة المرور بالخطوة الأولى :
هاد هو طلب تسجيل دخول بسيط بمعلومات بنعرفها
هون بتم تعيين كوكي (Cookie) خاص بحساب المستخدم بنغيره لاسم المستخدم اللي بدنا اياه :
بعدها راح يطلب إدخال رمز التحقق بندخله من الايميل وبنلقط الطلب وبنغير الكوكي اللي هي باسم المستخدم لاسم الحساب اللي بدنا نفوت عليه :
بنخليه هيك
بعدها بنبعث الطلب للـ intruder عشان نعمل هجوم على رمز التحقق الخاص بالمستخدم اللي بدنا نفوت عليه وبنحدد البايلود ارقام لحد 9999
[]
الاغلب وقع هون وحكالك هيو شامل كل الارقام
طيب يا عزيزي خلينا نفكر شوي
رمز التحقق 4 خانات ليش نحط من 0 هيك صار خانه وحده
جد يعني ما فكرت وحكيت حلك يا عبود غلط
خلص هالمره سماح نرجع نركز بدال ما نختار ارقام وتطلع غلط بنختار Brute forcer وبنقيم الاحرف لانه بس ارقام بدنا وحجمهم يكون 4 خانات وبنخلي الحد الادنى والاعلى هو 4 خانات
راح نشرحها بالاب اللي جاي
راح تواجهنا مشكله الا وهي الـ session بنجرب نبعث الاسم مع رمز التحقق بدون الـ session بنلاحظ انه بحولنا على المسار طبيعي my-account
بامكاننا نسجل دخول باستخدام بياناتنا بعدها بنغير قيمة الكوكي لأي اسم مستخدم ثاني عند إرسال رمز التحقق :
فيديو توضيحي
Lab: Excessive trust in client-side controls
التحدي هاد متعلق بثغرة بتظهر لما التطبيق ما يتحقق من المدخلات على مستوى العميل بشكل كافي فـ الثغرة هاي بتسمحلنا إننا نستغل logic عملية الشراء لشراء منتجات بسعر غير مقصود
التطبيق ما بتحقق من صحة البيانات بالشكل الكافي وبالتالي بنقدر نعدل المتغير الخاص بالسعر بالطلب الخاص فينا مهمتنا هي نشتري Lightweight l33t leather jacket بسعر أقل من السعر الأصلي
بنقدر نسجل دخول باستخدام البيانات
wiener | peter
قدرنا نعدل على السعر قبل ما نضيفه على السله وبعدها بس ارسلنا الطلب بعد تعديل القيمه واشتريناه باقل من سعره
نفهم كيف قدرنا نعدل سعر اي منتج قبل ما نضيفه على السله
شرح ثغرة عدم التعامل مع المدخلات الغير التقليدية
الثغرة هاي بتظهر لما منطق التطبيق ما يقيد المدخلات بحيث تتماشى مع قواعد العمل مثلاً التطبيق ممكن يسمح بإدخال أي قيمة رقمية لكن المفروض يكون في تحقق يمنع إدخال قيم غير منطقية مثل الأرقام السالبة أو القيم الخارجة عن النطاق المسموح فيه (زي كمية طلب أكبر من المخزون المتوفر)
كيف بيحصل الهجوم:
مثلاً بمتجر إلكتروني المستخدم عنده خيار تحديد كمية المنتج المطلوب مع إنه أي عدد صحيح ممكن يدخل المفروض logic التطبيق يمنع إدخال قيمة سالبة أو قيمة تفوق المخزون إذا ما تم التحقق بشكل كافي من المدخلات ممكن المهاجم يدخل قيمة غير متوقعة (زي -1000) وهاد بسبب سلوك غير متوقع
خلينا نشوف مثال عملي على عملية تحويل الأموال بين حسابين:
كود:
$transferAmount = $_POST['amount'];
$currentBalance = $user->getBalance();
if ($transferAmount <= $currentBalance) {
// تنفيذ التحويل
} else {
// رفض العملية بسبب نقص الرصيد
}لو المهاجم دخل قيمة سالبة (مثلاً -1000) الشرط بتحقق غلط لأن الـ -1000 دائماً أقل من الرصيد الحالي وبالتالي بتم تنفيذ التحويل بطريقة غير مقصودة وهاد بخلينا نستفيد من الثغرة عشان نحول مبالغ بشكل عكسي
تأثير الثغرة:
عدم التعامل الصحيح مع المدخلات غير التقليدية ممكن يؤدي إلى:
- تجاوز القيود المنطقية المحددة للتطبيق
- تنفيذ عمليات تحويل أو شراء بطرق خاطئة
- استغلال موارد التطبيق لتحقيق أهداف غير مشروعة
التأثير بعتمد على وظيفة التطبيق وطبيعة العملية لكن بشكل عام بزيد من فرص الاستغلال وهجوم المهاجم
الوقاية والحماية:
1. لازم نتأكد من التحقق من المدخلات على مستوى السيرفر مش بس على العميل
2. نحدد حدود منطقية واضحة لكل نوع من المدخلات سواء كانت رقمية أو نصية
3. بنستخدم أدوات فحص مثل Burp Proxy وRepeater لتجربة إدخال قيم غير متوقعة (أرقام سالبة، قيم عالية، سلاسل طويلة أو أنواع بيانات غير معتادة)
4. بنراجع كل النماذج بالتطبيق عشان نضمن إنه ما في أي استثناءات بتسمح بظهور ثغرة
5. توثيق السيناريوهات المحتملة والحدود المنطقية بساعد باكتشاف الثغرات مبكراً
High-level logic vulnerability
التطبيق ما بتحقق من صحة مدخلات المستخدم بشكل كافي وهاد الاشي بسمحلنا نستغل ثغرة بـ logic عملية الشراء لشراء منتجات بسعر غير الموجود
مهمتنا هي شراء Lightweight l33t leather jacket بسعر أقل من السعر الطبيعي
بنقدر نسجل دخول باستخدام البيانات
wiener | peter
بنضيف منتج للسلة وبنراقب الطلبات من خلال الـ Burp وبنحلل الطلبات وبنلاحظ إنه المتغير اللي بحدد الكمية موجودة بطلب POST /cart
بنبعث طلب POST /cart للـ REPEATER
يعني بنكرر التحدي السابق لكن هاي المره بنحط كمية سالبة
بنتأكد إنه القيمة السالبة بتنقص من الكمية اللي بالسلة
بنتأكد إن السلة صارت بتحتوي على منتج معين قيمته هي كمية سالبة وبالتالي السعر الإجمالي صار قيمة سالبة
بنضيف الـ ...Lightweight للسلة وبنستخدم كمية سالبة مناسبة من المنتج اللي حطيناه مسبقا وخليناه سالب عشان نخفض السعر الإجمالي بحيث يكون أقل من الرصيد اللي معنا بالمتجر
بالفيديو عملت العمليه اكثر من مره ولاحظ كيف قعدت اقيس كل مره عشان يطلع الاوردر بسعر رخيص وما يطلع بالسالب هيك اكيد بنثير الانتباه بالمقابل خليت سعر الدفع اقل من اللي معي عشان يمشي الاوردر
نفهم كيف قدرنا نعدل عدد اي منتج قبل ما نضيفه على السله وخليناه بالسالب
لاحظ السعر مش موجود زي التحدي السابق...
Low-level logic flaw
التحدي هاد متعلق بثغرة بمنطق الشراء بتسمحلنا نشتري منتجات بسعر غير الموجود
التطبيق ما بتحقق من صحة مدخلات المستخدم بشكل كافي، وبنستغل الثغرة لشراء Lightweight l33t leather jacket بسعر أقل من السعر الطبيعي
بنقدر نسجل دخول باستخدام البيانات
wiener | peter
بنرسل الطلب POST /cart للـ Repeater وبنفحص كم بنقدر نضيف كميات بنلاحظ انه ما بنقدر بكل مره الا نضيف بس قيمه مكونه من رقمين يعني اكبر قيمه هي 99
بنحول الطلب للـ Intruder بنروح للـ Intruder وبنحدد الكمية وبنخليها لـ 99
بالـ Payloads بنختار نوع البايلود Null payloads لانه ما بدنا يعدل اشي فقط يرسل نفس الطلب بكل مره بنفس القيمه 99
ومن إعدادات الـ payload بنحدد Continue indefinitely وبنبدأ الهجوم
أثناء تشغيل الهجوم بنتابع صفحة السلة مع التحديث المستمر وبنراقب إجمالي السعر بنلاحظ إنه السعر فجأة تحول لقيمة سالبة كبيرة وبيبدأ يرتفع باتجاه 0
السبب إنه السعر تجاوز القيمة القصوى المسموح بها (2,147,483,647) وبالتالي اتلفت وصارت أدنى قيمة ممكنة (-2,147,483,648)
هسا بدنا نعمل هجوم يضيف بعدد كبير حتى نخلي القيمه اقل من 100$ ونقدر نشتري هاي الكميه كلها
طبعا هاد اكثر لاب حسيته غلبني يمكن لاني نعسان ومش مصحصح واجا وقت نومي
الهدف من التحدي
نفهم كيف قدرنا نعدل نغير السعر الكامل للسله عن طريق اضافه كميات هائله من المنتجات حتى وصل السعر عدد اكبر من الرينج المحطوط ف صار بالسالب كله
ولاحظ بس بنقدر بكل مره اننا نضيف 99 منتج ك حد اقصى فقط ف عملنا بروت فورس يضل يرسل منتجات على السله عددهم 99
ف ضليت طول الفيديو احاول بس القيمه السالبه اوصلها للصفر واخليها تزيد شوي بس عشان اقدر ادفعها لانه كان معي فقط 100$
Inconsistent handling of exceptional input
التحدي هاد متعلق بثغرة بالتحقق من صحة المدخلات أثناء تسجيل الحسابات, بتسمحلنا نسجل حساب بخولنا نوصل لصلاحيات الإدارة
الهدف هو نوصل للوحة الإدارة ونحذف المستخدم carlos
بنروح لـ Target بعدها Site map، بنضغط بالزر اليمين على نطاق الموقع، وبنختار Discover content عشان نبحث عن محتوى مخفي
او ممكن نستخدم ادوات ثانيه عشان نستخرج المسارات اللي موجوده بالموقع (مثل gobuster) بهاي الطريقه استخدامها
gobuster dir -u http://(ip) -w (wordlest)
بنضغط على Session is not running عشان نشغل البحث، وبعد فترة بنراجع الـ Site map بنلاقي المسار admin/
بنحاول ندخل على admin/، لكن بنواجه رسالة خطأ بتشير إنه المستخدمين من DontWannaCry عندهم صلاحية الدخول
بنروح لصفحة تسجيل الحسابات وبنلاحظ إنه الموقع بطلب من موظفي DontWannaCry يستخدموا الإيميل الرسمي تبعهم
من زر البريد الإلكتروني في شريط المختبر، بنفتح البريد الإلكتروني وبنسجل البريد اللي معنا @YOUR-EMAIL-ID.web-security-academy.net
بوصلنا على الايميل رابط عشان نفعل الحساب
بنرجع للمختبر وبنجرب نسجل حساب جديد باستخدام إيميل طويل بالشكل التالي (عشان نشوف اذا في اي مشاكل بتصير بلوجك الموقع ) :
[email protected]
(بحيث يكون long-string طويل)
بنفتح البريد الإلكتروني بنلاقي رسالة تأكيد للحساب بنضغط على الرابط لتأكيد التسجيل
بعد ما نسجل دخول بنروح لصفحة الـ My account وبنلاحظ إنه الإيميل تبعنا انقص لـ 255 حرف فقط
بنسجل خروج وبنرجع لصفحة تسجيل الحسابات
بنسجل حساب جديد بنفس الطريقة لكن هاي المرة بنضيف dontwannacry.com كـ subdomain بالشكل التالي:
long-string@dontwannacry.com.YOUR-EMAIL-ID.web-security-academy.net
(بنالتأكد إنه الحرف m بـ dontwannacry.com@ هو الحرف رقم 255 بالضبط)
عشان يقرأ اخر الايميل الدومين الخاص بالادمنز
بنفتح البريد الإلكتروني وبنضغط على رابط التأكيد وبنسجل الدخول بالحساب الجديد
بنلاحظ إنه صار عننا صلاحيات الدخول للوحة الإدارة admin/ لأنه السيرفر قرأ العنوان عند الحرف 255 فقط واعتبر إيميلنا تابع لـ dontwannacry.com
الهدف من التحدي
نفهم كيف قدرنا نسجل كـ حساب لدومين ثاني جربنا نسجل ايميل طويل كثيير ولاحظنا انه احنا تعدينا الرينج وهو قرأ فقط 255 ف ضفنا السب دومين دومين الـ dontwannacry حتى السيرفر يقرأه كانه الهم ويوصلنا الايميل على بريدنا
Inconsistent security controls
أحد الأسباب الرئيسية لظهور ثغرات الـ logic هو الافتراضات الخاطئة عن سلوك المستخدم, كتير بنفترض إنه المستخدمين بكونو جديرين بالثقة بعد ما يمرّوا بإجراءات التحقق الأولية
النتيجة؟ بنلاقي تطبيقات بتطبّق إجراءات أمان ضعيفة بالمراحل الاحقة وطبعا بفتحلنا مجال نستغل اي ثغرة
مثلا
تطبيق ظاهر إنه آمن لأنه بفرض قواعد صارمة بالبداية لكن بعدين بترك المجال مفتوح لتعديل المعطيات دون التحقق الكافي
هاد بوصل لثغرات خطيرة مثل تمكين المستخدمين العاديين من الوصول لصلاحيات الإدارة
التحدي هاد بوضح إنه الثغرة بتسمح لأي مستخدم عادي إنه يوصل لصلاحيات إدارية كان مفروض تكون خاصة بموظفي الشركة
الهدف اننا ندخل على لوحة الإدارة ونحذف المستخدم carlos
بنبدا زي ما بدينا بالتحدي الماضي
بنحاول ندخل على admin/ ورغم إنه ما عننا صلاحية مباشرة رسالة الخطأ بتوضح إنه المستخدمين من DontWannaCry عندهم صلاحية
بنروح لصفحة تسجيل الحسابات وبنلاحظ إنه الموقع بنبه موظفي الـ DontWannaCry يستخدموا الإيميل الرسمي
بنسجل حساب باستخدام إيميل تاعنا [email protected]
بنفتح البريد الإلكتروني وبنضغط على رابط التأكيد عشان نفعل الحساب
بعد التسجيل الدخول بنروح لصفحة الـ My account وبنلاحظ إنه بإمكاننا نغيير الإيميل
بنغير الإيميل لحساب بدومين dontwannacry.com@
بعد ما نغيره بنلاحظ انه ما بطلب مننا اي تاكيد او اثبات انه النا وهيك بنقدر نكون ادمن ونمسح اي حساب
الهدف من التحدي
نفهم كيف قدرنا نسجل كـ حساب dontwannacry بعد ما سجلنا طبيعي وغيرنا الايميل ف السيرفر بقرأه كانه الهم
Weak isolation on dual-use endpoint
أحياناً بنفترض إنه المستخدم رح يدخل كل البيانات المطلوبة بالحقول الإلزامية لكن بالحقيقة بأمكاننا نحذف أو نعدل المعطيات أثناء النقل
المشكلة بتكون أكتر بالحالات اللي نفس السكريبت اللي السيرفر بطبّق وظائف متعددة اعتماداً على وجود أو عدم وجود معلمة معينة
إذا حذفنا متغير أو حتى غيرنا اسمها التطبيق ممكن يمرّ بطريقة غير متوقعة ويكشف لنا مسارات أو وظائف كانت مفروض تكون محمية
التحدي هاد بوضح إنه التطبيق بفترض صلاحيات المستخدم بناءً على المدخلات بدون تحقق كافي والنتيجة هي اننا بنقدر نستغل logic إدارة الحسابات لنصل لحسابات مستخدمين عشوائية
الهدف اننا ندخل على لوحة الإدارة ونحذف المستخدم carlos
بنقدر نسجل دخول باستخدام البيانات
wiener | peter
بنروح لصفحة My account وبنغير كلمة المرور
بنراجع طلب POST /my-account/change-password بنلاحظ إنه إذا حذفنا المتغير current-password بالكامل بنقدر نغير كلمة السر بدون ما ندخلها بكل بساطه
كمان اسم المستخدم بحدد الحساب اللي بتغير الباسورد الخاصه فيه فـ بنخلي الـ username هيك username=administrator وبنرسل الطلب مرة ثانية
بنسجل خروج وبعدين بنجرب ندخل باستخدام حساب الـ administrator مع كلمة المرور الجديده
وهيك بنقدر نحذف المستخدم carlos وبنحل التحدي
الهدف من التحدي
نفهم كيف قدرنا نسجل كـ حساب administrator بعد ما غيرنا كلمه السر بدون ما نعرفها اصلا وقدرنا نغير اسم المستخدم لما عملنا اعاده تعيين كلمه السر
Insufficient workflow validation
في كتير من عمليات بتعتمد على تسلسل محدد للخطوات والواجهة عادة بترشد المستخدمين لهاد التسلسل لكن احنا ما بنلتزم بهاد التسلسل بل بنقدر نعيد إرسال الطلبات أو نتخطى خطوات معينة
هاد بفتحلنا مجال لثغرات زي تجاوز خطوة التحقق الثنائي (2FA) أو تعديل خطوات الشراء
التحدي هاد متعلق بثغرة بتظهر بسبب افتراضات خاطئة حول تسلسل خطوات عملية الشراء
الهدف اننا استغلال الثغرة لشراء Lightweight l33t leather jacket دون خصم التكلفة من رصيد المتجر
بنقدر نسجل دخول باستخدام البيانات
wiener | peter
بعد ما نسجل دخول بنشتري أي منتج بنقدر نتحمله برصيدنا
بنراجع سجل الطلبات من proxy history وبنلاحظ إنه الطلب POST /cart/checkout بوجهنا لصفحة تأكيد الطلب
يعني بس يكون بدو ياكد الطلب ببعث هاد الطلب ف احنا ممكن نبعثه عن طريق الـ Repeater
بنرسل طلب GET /cart/order-confirmation?order-confirmation=true للـ Repeater وبنراقب الاستجابة
بنضيف السترة الجلدية للسلة وبالـ Repeater بنعيد إرسال طلب تأكيد الطلب وبنلاحظ إنه الطلب بكمل العملية بدون خصم التكلفة من رصيدنا
هيك بنكون حلينا التحدي
الهدف من التحدي
نفهم كيف عمليه الشراء بتتم وكيف ممكن نستغل اي ثغره موجوده باي خطوه من عمليه الشراء
Authentication bypass via flawed state machine
التحدي هاد متعلق بثغرة بتظهر بسبب افتراضات خاطئة حول تسلسل عملية تسجيل الدخول
الهدف نستغل الثغرة عشان نتجاوز عملية التحقق ونوصل للوحة الإدارة وحذف المستخدم carlos
بنقدر نسجل دخول باستخدام البيانات
wiener | peter
بعد ما نسجل دخول بنلاحظ إنه مطلوب نحدد دور قبل ما نوصل للصفحة الرئيسية ... بنستخدم أداة اكتشاف المحتوى مثل gobuster او من خلال الـ burp suite زي ما عملنا قبل عشان نحدد مسار admin/
لما نجرب ندخل مباشرة من صفحة اختيار الدور ما بزبط فـ بنسجل خروج وبنلقط طلب تسجيل الدخول على الـ Burp بنمرر طلب الـ POST /login الطلب اللي بعده بكون GET /role-selector بنعمل Drop لهاد الطلب وبننتقل للصفحة الرئيسية للمختبر
بنلاحظ إنه بدون تحديد الدور بشكل صحيح الدور الافتراضي صار المدير وبالتالي صار عننا وصول للوحة الإدارة
من هناك بنحذف المستخدم carlos وبنحل التحدي
الهدف من التحدي
نفهم كيف عمليه تسجيل الدخول بتتم وشو هي خطواتها وكيف ممكن نستغل اي ثغره موجوده باي خطوه من عمليه تسجيل الدخول او انشاء حساب
Flawed enforcement of business rules
في كتير ثغرات بتكون مرتبطة بمجال معين أو بالغرض من الموقع
مثلا متجر إلكتروني ممكن نلاقي ثغرات بالـ logic بتأثر على آلية الخصومات أو سياسات التسعير
إذا التطبيق ما بتحقق بشكل كافٍ من تغيرات الأسعار أو المعايير اللي بتنطبق عليها الخصومات بنقدر نستغل هالشي ونتلاعب بالسعر قبل تنفيذ الطلب
بشكل عام لازم ننتبه لأي وظيفة بتعدل على أسعار أو قيم مهمة بناءً على مدخلات المستخدم أو تفاعلاته مثل تطبيق الخصومات أو نقاط المكافآت
الفكرة إن المطورين ممكن يفترضوا إنه المستخدم رح يتبع السيناريو الطبيعي للتطبيق وما بفكروا إنو ممكن يعدل على الخطوات أو يستغلها بترتيب غير متوقع
بالنهاية فهم الـ Domain بساعدنا نستوعب كيف ممكن أي خطأ بسيط يتحول لثغرة خطيرة فـ أحياناً بنحتاج معرفة عميقة بمجال التطبيق حتى نعرف شو الأمور اللي بتعطي منفعة للمهاجم أو القيمة اللي ممكن يتلاعب فيها بمجرد فهمنا لـ logic التطبيق بنقدر نستغل أو نكتشف الثغرات اللي ما بتكون واضحة لغيرنا
التحدي هاد بوضح ثغرة بـ logic الشراء بسمحلنا نشتري Lightweight l33t leather jacket بسعر أقل من السعر الأصلي بسبب وجود خلل بتطبيق الخصومات
بعد ما نسجل دخول بنلاحظ إنه في كوبون اسمه NEWCUST5 بأسفل الصفحة بنسجل بالنشرة البريدية وبنوخذ كوبون ثاني اسمه SIGNUP30 بنضيف السترة الجلدية للسلة وبنروح لصفحة الدفع وبنطبق الكوبونين عشان ناخذ خصم على الطلب بعدها بنحاول نستخدم نفس الكوبون أكثر من مرة لو دخلنا الكود نفسه مرتين متتاليتين برفضه التطبيق لأنه مطبَّق مسبقاً لكن إذا بدّلنا بين الكوبونين بنقدر نتجاوز هالتحقق بنكرر العملية بحيث ينخفض السعر النهائي لأقل من رصيدنا اللي بالمتجر وبنكمل الطلب وبنشتري السترة بسعر أقل من قيمتها الحقيقية وهيك بنحل التحدي
الهدف من التحدينفهم كيف ممكن نستغل اي خطأ او اي اضافه حاطينها الموقع مثلا خصومات او اي طريقه توصلنا لهدفنا
Infinite money logic flaw
التحدي هاد بوضح ثغرة بـ logic الشراء بتخلينا نولد رصيد إضافي بالمتجر بشكل غير محدود ومن خلاله بنقدر نشتري Lightweight l33t leather jacket بسعر أقل من الطبيعي أو حتى مجاناً
بنسجل دخول وبنشترك بالنشرة البريدية لنحصل على كوبون SIGNUP30 بنلاحظ إنه بنقدر نشتري بطاقات هدية بقيمة $10 من المتجر ونستردها من صفحة My account بنضيف بطاقة هدية للسلة وبنكمل الدفع مع تطبيق الكوبون SIGNUP30 عشان نحصل على خصم 30% بعد الدفع
بنحصل على كود البطاقة الهدية وبنستخدمه عشان نسترده من حسابنا فـ بزيد رصيدنا بمقدار $3
بنراجع سجل الطلبات بالـ proxy history وبنلاحظ أنه استرداد البطاقة بتم عبر طلب POST /gift-card ومتغير gift-card
بنضبط الـ Session handling rules بـ Burp وبننشئ ماكرو Macro عشان يكرر هاي الخطوات
1. يشتري البطاقة
2. يدفع
3. يتسخلص الكود ويسترده
ف بنحط الطلبات هاي
كود:
/cart
/cart/copon
/cart/checkout
/cart/order-con....
/gift-cardوبنختبر الماكرو وبنتأكد من نجاحه انه بجيب كود وبستخدمه بطلب الاسترداد
بنرسل طلب GET /my-account للـ Intruder وبنحدد البايلود Null payloads بعدد كبير (500 مثلاً) مع ضبط الطلبات بحيث يكون Maximum concurrent requests = 1 لضمان تسلسل الطلبات الصحيح
بعد ما ينتهي الهجوم بنحصل على رصيد كبير بالمتجر فـ بنشتري السترة الجلدية وبنحل التحدي
نفهم اكثر من طريقه عشان نستغل لوجك الموقع ونقدر نوخذ ونحصل على مصاري داخل المتجر بدون ما ننشتري غير كارد
Authentication bypass via encryption oracle
بتظهر حالات خطيرة لما التطبيق بسمح للمستخدمين انهم يتحكمو بمدخلات تدخل ضمن عملية التشفير
وبعدها يرجعلنا النص المُشفر
بهيك حالة بنقدر نستخدم التطبيق كـ Encryption Oracle عشان يشفر بياناتنا بنفس الخوارزمية والمفاتيح المستخدمة داخلياً
الخطر بيصير أكبر إذا كانت بالتطبيق وظائف ثانية بتعتمد على بيانات لازم تكون مشفرة
وبالتالي بنقدر نولد بيانات مشفرة صالحة ونمررها لوظائف حساسة
التحدي هاد بحتوي على ثغرة بالـ logic بتكشف تشفير الكوكيز للمستخدمين Encryption Oracle وبنستغلها عشان ندخل كمسؤول ونحذف المستخدم carlos
بنسجل دخول مع تفعيل خيار Stay logged in وبنراقب الكوكي stay-logged-in اللي بكون مُشفر, بنلاحظ إنه لما نحاول نرسل كومنت بإيميل غير صالح السيرفر بضيف كوكي notification مُشفر وبعيد توجيهنا مع رسالة خطأ بتوضح الإيميل المدخل بصيغة واضحة
من هاد بنكتشف إمكانية استخدام التطبيق لتشفير وفك تشفير بياناتنا Encryption Oracle
بنفك تشفير كوكي stay-logged-in عشان نعرف الصيغة wiener:timestamp بننشئ قيمة جديدة بصيغة administrator:timestamp وبدنا نرسلها لكن نقيم القيمه اللي بالبدايه اللي عددها 23 حرف Invalid email address باستخدام تقنيات الـ Padding
بعد ما نحذف البادئه بعطينا خطا لازم تكون القيمه من مضاعفات الـ 16 ف بنضيف قيمه عشوائيه x مثلا عشان نخلي القيمه تصير 32 بعدها بنمحي من الهاش اول 32 بايت وبنبعث قيمه الـ administrator:timestamp فقط وهيك بتطلعلنا كوكي الادمن
بنستبدل الكوكي القديم بالكوكي الجديد بكل حركه بنعملها وبنزور الصفحة الرئيسية وبنلاحظ دخولنا كمسؤول وبنقدر نحذف المستخدم carlos
نجرب اي اضافات للموقع ودايما نراقب المحتو المخفي من الواجهه الرسوميه للموقع
Bypassing access controls using email address parsing discrepancies
أحياناً المواقع بتستخدم عملية Parsing للإيميل عشان تحدد النطاق الـ Domain وتنسب المستخدم للمؤسسة الصحيحة لكن عملية الـ Parsing معقدة والاختلافات بين طرق التحقق ممكن تعمل ثغرات
بإمكاننا نستخدم تقنيات الـ Encoding عشان نخفي أجزاء من الإيميل وبالتالي التسجيل باستخدام الإيميل بكون صحيح ولكنه السيرفر بقرأه بطريقه ثانيه
الثغره بتمكننا نسجل بحساب وكأنه من نطاق مقيد وهو بسمحلنا نوصل لوظائف حساسة مثل لوحات الإدارة...
التحدي هاد بكشف ثغرة بسبب اختلاف طرق التحقق من نطاق الإيميل, بنستغل هاي الثغرة عشان نتجاوز القيود ونتجاوز " منع التسجيل بإيميلات غير مصرح فيها " ، وبنسجل حساب وبنحذف المستخدم carlosبنحاول نسجل بإيميل عادي لكن السيرفر برفض لو مش من الـ ginandjuice.shop بنستخدم تقنيات Encoding مثل UTF-7 عشان نخدع السيرفر عشان يقبل الإيميل كأنه من ginandjuice.shop مع أنه عنوان البريد فعلياً مختلف, بعد ما نسجل بنفعل الحساب من رابط التفعيل المرسل لبريدنا، وبننجح بتجاوز التحقق بنسجل دخول وبنروح للوحة الإدارة وبنحذف المستخدم carlos وبهيك بنحل اخر تحدي
هاد بنقدر نحكي من التحديات اللي شوي صعبه شرحتلكم فوق كيف تحلوه
جربو واعطوني النتيجه اذا قدرتو تحلوه او لا
نستكشف طرق التحقق ونبحث عن اي ثغره فيها ونتعرف على احدى الطرق اللي بتمكننا نسجل بحساب غير مصرح فيه
التعديل الأخير:
