الثغرة مش في اسمها: افهم الـ Impact الأول

x32x01
  • بواسطة x32x01 ||
واحد مرة دخل قالي: عندك 6 ثغرات في موقعك، وفيهم 3 ثغرات خطيرة. وكالعادة بشوف الرسايل دي وببتسم 🙂
ممكن ببساطة أطنشه، وعارف نهاية القصة هتكون فين. أنا اشتغلت في الحماية زمان، أيام منتديات ترياق العرب وكويت ناين، والعقلية بتاعة اللي لسه داخل المجال متغيرتش كتير.

لكن المرة دي دخلت معاه في نقاش، ووريته إن معظم الحاجات اللي بيتكلم عنها مفيهاش مشكلة فعلية، ومش بس كده، علمته مبدأ جديد خاص بالـ Directory Listing ووريته الموضوع عمليًا.



هل Directory Listing تعتبر ثغرة؟​

خلينا ناخد مثال بسيط.
حضرتك عندك موقع بيقدم مقالات، وكل مقال فيه صورة. الصور دي أصلًا Public ومفتوحة للعامّة، وعندك Folder موجود فيه الصور دي ومتاح إنك تتصفحه.
هو كان شايف إن مجرد إنك تقدر تتصفح الـ Folder يبقى دي ثغرة.
لكن أنا قلت له: لأ، مش في العموم.
لو الـ Directory Listing مفتوح على البحري وبيكشف ملفات أو مجلدات حساسة، أكيد ممكن يكون عندك مشكلة أمنية.
لكن لو الـ Folder ده تحديدًا مفيهوش أي حاجة حساسة، وكل اللي جواه صور Public أصلًا، فمجرد إمكانية تصفحه مش معناها تلقائيًا إن عندك ثغرة خطيرة.
خصوصًا إن الصور نفسها ممكن تكون متاحة لمحركات البحث ومتأرشفة وظهرت بالفعل في نتائج البحث.
وكان فيه مواقع قديمة قايمة أصلًا على فكرة الـ Directory Listing. لو حد فاكر موقع Netsurf.ru من حوالي 2004 🙂، مكنش فيه تصميم موقع بالشكل المعروف دلوقتي؛ كانت عبارة عن Folders تدخل تتصفحها وتحمل منها اللي إنت عاوزه وخلاص.

وده بالضبط بيوضح الفكرة:
المشكلة مش في إنك شايف الـ Folder، المشكلة في المحتوى اللي الـ Directory Listing كشفهولك.



الخلاصة​

🔎 الخطورة مش في الـ Directory Listing نفسه، لكن في إيه اللي الـ Directory Listing كشفهولك.
لو الملفات Public أصلًا ومفيهاش بيانات حساسة، فوجود Listing لوحده مش كفاية عشان تسميه Critical Vulnerability.



متقفش عند اسم الثغرة​

في واحدة من "الثغرات" اللي قال عليها اختلفنا فيها برضه.
طلبت منه يستغلها عشان يوضح الـ Impact بنفسه، لكنه معرفش يعمل ده، وكان مصمم إنها مشكلة.
وبعد النقاش قدرنا نوصل لنفس النقطة:
وجود سلوك غريب أو Misconfiguration مش معناه تلقائيًا إن عندك ثغرة خطيرة.
المهم هو: What is the Impact?
و:
What Can An Attacker Do?
دول أهم سؤالين لازم تسألهم قبل ما تحدد خطورة أي مشكلة أمنية.



مثال أخطر: Dashboard بدون Authentication​

على النقيض بقى، شوية كلمني شاب جميل ومش شغال في مجال الـ Security أصلًا 🙂
بعتلي صورة من الـ Dashboard بتاعة موقعي الشخصي، وبكل أمانة استغربت شوية:
إزاي قدر يوصل للـ Dashboard؟
بعد ما راجعت الموضوع واتكلمت معاه، اكتشفت إنه مدخلش لوحة التحكم أصلًا.
هو عمل حاجة ذكية جدًا: شيك على الـ Network وشاف الـ Requests اللي بتحصل، وبعد كده رسم الـ Dashboard بنفسه بناءً على البيانات اللي قدر يوصل لها.
المشكلة إن محتوى الـ Dashboard كان ممكن يتعرض من غير ما يعدي الأول على Authentication.
وده مثال مهم جدًا على واحدة من مشاكل الاعتماد على الـ AI من غير مراجعة.
الـ AI ممكن ينفذ المطلوب منك، لكن ده مش معناه إنه نفذ الـ Flow الأمني الصح.
ببساطة، الـ AI محتاجك تراجعه، خصوصًا في الحاجات المتعلقة بالـ Authentication والـ Authorization وتدفق البيانات.
وفي نفس الوقت، لازم نقيس حجم الـ Impact الحقيقي.

في الحالة دي، الشاب قدر يشوف الـ Data الموجودة في الـ Dashboard، لكنه:
  • مقدرش يضيف أي بيانات.
  • مقدرش يعدل البيانات.
  • مقدرش يعمل عمليات إدارية.
  • مقدرش يشوف كلمات المرور.
  • مقدرش يتصرف كـ Admin.
يعني المشكلة الأمنية موجودة فعلًا، لكن تأثيرها محدود مقارنة بالسيناريو اللي كان ممكن يحصل لو كان قادر ينفذ عمليات إدارية أو يغير البيانات.



إيه الـ Flow الأمني الصحيح؟​

في الحالة دي، الـ Flow المفروض يكون واضح:
  1. Authentication - اتأكد الأول إن المستخدم عنده صلاحية الدخول للـ Dashboard.
  2. Render Dashboard - بعد التأكد من الصلاحيات، اعرض الـ Dashboard ومحتوياتها.
لكن اللي حصل إن الـ Dashboard نفسها كانت ممكن تتعرض قبل تنفيذ خطوة التحقق.
واللي عجبني في الشاب إنه بلغ عن الموضوع بهدوء ومن غير تهويل.
والأجمل إنه بنفسه قال إنه عارف السقطات اللي ممكن يعملها الـ AI وعنده خبرة فيها.
ودي نقطة مهمة جدًا لأي حد بيستخدم AI في البرمجة:
🤖 كون الكود شغال لا يعني بالضرورة إنه آمن.



Dunning-Kruger Effect في مجال Security​

وده بيوصلنا لنقطة أكبر.
في بداية تعلمك لمجال جديد، ممكن يبقى عندك ثقة كبيرة جدًا في المعلومات القليلة اللي عرفتها.
وده مرتبط بمفهوم اسمه Dunning-Kruger Effect.
وبعد ما تتعلم أكتر وتدخل في التفاصيل، تبدأ تكتشف إن الموضوع أعقد مما كنت متخيل، وإن حاجات كتير كنت متأكد منها محتاجة فهم أعمق.
وده طبيعي جدًا.
والأهم إن التجربة دي تخليك تراجع نفسك أكتر المرة اللي بعدها بدل ما تستعجل في الحكم.

وده مهم جدًا في الـ Cybersecurity، لأن نفس السلوك ممكن يكون:
  • مشكلة بسيطة.
  • Misconfiguration.
  • Information Disclosure محدود.
  • Vulnerability لها Impact حقيقي.
  • أو مشكلة أخطر حسب البيانات والعمليات اللي ممكن المهاجم يوصل لها.
الاسم لوحده مش كفاية.



قبل ما تقول "دي ثغرة خطيرة"​

قبل ما تصنف أي مشكلة أمنية، اسأل نفسك سؤالين:
  1. What is the Impact?
  2. What Can An Attacker Do?
بعدها اسأل عن حدود الوصول:
  • هل المهاجم يقدر يشوف بيانات فقط؟
  • هل يقدر يعدل البيانات؟
  • هل يقدر يحذفها؟
  • هل يقدر ينفذ أوامر أو عمليات؟
  • هل يقدر يتجاوز Authentication؟
  • هل يقدر ينتقل لصلاحيات أعلى؟
  • هل البيانات اللي وصل لها حساسة أصلًا؟
لأن الفرق بين "السلوك ده غريب" و"عندي Critical Vulnerability" ممكن يكون كبير جدًا.
🔐 في الـ Security، الـ Impact هو اللي بيفرق.
وأنا مش بتريق على الشاب الأول خالص.
بالعكس، هو استمتع بالكلام جدًا، وفضل يدعيلي، وأنا فرحت إنه اقتنع واتعلم حاجة جديدة.
وفي النهاية دعيتله ربنا يوفقه ويكرمه، وييجي في يوم يقولي:
"موقعك فيه ثغرة خطيرة واستغليتها أهي." 😄
وساعتها هكون مبسوط، لأن أكيد عندي مشاكل في الحماية فعلًا، وأفضل طريقة لتحسين الأمان إنك تفضل تتعلم وتراجع افتراضاتك وتسمع للناس اللي بتختبر أنظمتك بعقلية صحيحة.



الأسئلة الشائعة​

--------------

هل Directory Listing تعتبر ثغرة أمنية؟​

مش بالضرورة. وجود Directory Listing وحده لا يحدد خطورة المشكلة. المهم هو الملفات والمعلومات التي أصبحت متاحة من خلاله، وهل تحتوي على بيانات حساسة أو يمكن استغلالها بطريقة تؤثر على أمان الموقع.

هل أي Misconfiguration تعتبر Vulnerability؟​

لا. الـ Misconfiguration ممكن تكون مشكلة أمنية، لكن تحديد خطورتها يحتاج إلى معرفة الـ Impact وما الذي يستطيع المهاجم فعله فعليًا نتيجة لها.

ليه الـ Impact مهم في تقييم الثغرات؟​

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

هل ممكن AI يكتب كود شغال لكنه غير آمن؟​

أيوه. الكود ممكن يعمل الوظيفة المطلوبة بشكل صحيح، وفي نفس الوقت يكون فيه Flow أمني غير صحيح، مثل عرض بيانات حساسة قبل التحقق من Authentication أو Authorization. لذلك مراجعة الكود والـ Security Flow مهمة حتى عند استخدام AI.
 
مواضيع مشابهة
x32x01
الردود
0
المشاهدات
21
x32x01
x32x01
x32x01
الردود
0
المشاهدات
17
x32x01
x32x01
x32x01
الردود
0
المشاهدات
25
x32x01
x32x01
x32x01
الردود
0
المشاهدات
22
x32x01
x32x01
x32x01
الردود
0
المشاهدات
29
x32x01
x32x01
x32x01
الردود
0
المشاهدات
28
x32x01
x32x01
إحصائيات المنتدى
المواضيع
2,298
المشاركات
2,363
الأعضاء
16
آخر عضو مسجل
HcN57
عودة
أعلى