المصادقة

حالة استخدام

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

الأهداف

بعد استكمال هذا الموضوع الفرعي، يجب أن يكون الممارسون قادرين على القيام بما يلي:

• فهم الأنواع الشائعة من ثغرات المصادقة
• فهم الآثار المحتملة لهذه الأنواع من الثغرات
• فهم آليات عمل هذه الثغرات
• فهم كيفية منع ثغرات هذه بشكل عام

العرض

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

تخزين كلمة المرور بشكل غير آمن

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

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

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

شفرة التجزئة : كما اتضح لا يحتاج خادم الويب أبدًا إلى استرداد كلمة مرور المستخدم من التخزين بل يحتاج فقط إلى معرفة ما إذا كانت كلمة المرور التي أدخلها المستخدم هي نفس كلمة المرور الحقيقية للمستخدم، وهناك فئة من الخوارزميات يشار إليها باسم شفرة التجزئة التشفيرية التي تقوم بتحويل أحادي الاتجاه على البيانات. ومن الأمثلة على تلك الخوارزميات هي إم دي 5 (MD5) وSHA، ومن المستحيل فعليًا بالنظر إلى التجزئة تحديد بيانات المصدر التي ولدَّت التجزئة. لسوء الحظ تكون كلمات المرور عادةً قصيرة إلى حد ما وتميل دالات شفرة التجزئة التشفيرية إلى أن تكون سريعة للغاية، وبالنسبة لدالة تجزئة معينة من الممكن تجزئة كل كلمة مرور ممكنة بطول معين وتخزين كلمة المرور والتجزئة الناتجة. وبعد ذلك بالنظر إلى تجزئة كلمة مرور معينة يمكن للمرء ببساطة البحث عن كلمة المرور التي أنشأت هذه التجزئة. في منتصف العقد الأول من القرن الحادي والعشرين، كان من الممكن حساب وتخزين وتوزيع قواعد البيانات هذه التي تسمى جداول قوس قزح للاستخدام العام. أحد حلول مشكلة جداول قوس قزح هو إضافة القليل من البيانات (تسمى التمليح) إلى كلمة المرور قبل شفرة تجزئتها، ولا يجب أن تكون هذه البيانات سرية أو مرتفعة الانتروبيا بشكل خاص بل يجب أن تكون مختلفة لكل مستخدم. يتمثل النهج الشائع في استخدام شفرة تجزئة اسم المستخدم وكلمة المرور معًا، ويحتوي جدول قوس قزح لكلمة مرور مايكروسوفت ويندوز مدير لان نيو تكنولوجي على شفرات تجزئة يصل طولها إلى 9 أحرف وتستوعب 6.7 تيرابايت. عند تمليح شفرة تجزئة كلمة المرور هذه فقط باستخدام 5 أحرف أبجدية رقمية سيرتفع جدول قوس قزح إلى أكثر من 6,000,000,000 تيرابايت. تكمّن المشكلة في هذا النهج في أن شفرة التجزئة لا تزال سريعة للغاية وأن بطاقات الرسومات الحديثة هي في الأساس أجهزة كمبيوتر فائقة متوازية على نطاق واسع، ويمكن لبطاقة إنفيدي آر تي إكس (Nvidia RTX) 4090 (بطاقة فيديو متطورة من عام 2022) حساب ما يقرب من 400,000,000,000 شفرة تجزئة إس إتش إيه مملحة في الثانية مما يسمح للأفراد العاديين باختراق معظم كلمات المرور في دقائق أو ساعات.

خوارزميات تخزين كلمات المرور الخاصة: تكمن المشكلة في شفرة التجزئة التشفيرية في أنها مصممة لتكون سريعة وفعالة، وتأتي معظم فائدتها من استخدامها في التحقق من أن البيانات لم يتم العبث بها. تمت معالجة هذه المشكلة منذ عام 1976 مع ظيفة تشفير يونكس التي قامت بتمليح وتشفير كلمة المرور عدة مرات لإبطاء طريقة القوة الغاشمة، ولا يثير الدهشة أن هذه الخوارزمية لن تصمد أمام موارد الحوسبة الحديثة ولكن الفكرة العامة لا تزال تُستخدم اليوم مع خوارزميات خاصة مصممة لتخزين مشتقات كلمة المرور. تم تصميم هذه الخوارزميات لتستفيد من وحدة المعالجة المركزية القابلة للضبط وموارد الذاكرة وللموازنة بشكل جيد بين الأداء ومقاومة القوة الغاشمة. تتضمن خوارزميات معالجة كلمة المرور الجيدة (بترتيب تفضيلي متناقص) سكريبت (scrypt) وآرغون 2 (argon2) وب كريبت ()bcrypt وب بي كيه دي إف 2 (PBKDF2). كإجراء دفاعي متقدم من المستحسن دمج كلمة مرور المستخدم مع سر لا يتم تخزينه في قاعدة البيانات نفسها، وعلى سبيل المثال يمكن ترميز السر في التطبيق نفسه. ومن المحتمل أن يمنع هذا استرداد كلمة المرور في حالة فقدان قاعدة بيانات كلمة المرور فقط.

جرب بنفسك!

سجّل الدخول إلى دي في دبليو إيه الخاص بك وتأكد من ضبط مستوى الأمان ليكون منخفضًا. ثم انتقل إلى قسم حقن لغة الاستعلامات البنيوية وأدخل ما يلي في مربع النص:
​​999' union all select user, password from users where '1'='1 سيؤدي هذا إلى عرض الاسمين الأول والأخير لجميع المستخدمين الذين لديهم userid يكون 999 (لا يوجد أي واحد) وكذلك شفرة التجزئة لاسم المستخدم وكلمة المرور لجميع المستخدمين. استخدم موقع بحث شفرة تجزئة عبر الإنترنت (على https://www.whatsmyip.org/hash-lookup/) للبحث عن تجزئة كلمة مرور المستخدم المسؤول، ما نوع التجزئة المستخدمة لتخزين كلمات مرور مستخدمي دي في دبليو إيه؟ ما هي كلمة مرور المستخدم المسمى “1337”؟

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

إعادة تعيين كلمة السر

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

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

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

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

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

قوة الاعتماد

تستخدم معظم تطبيقات الويب كلمات مرور للمصادقة على الرغم من أنه تتزايد شعبية تقنيات مثل المصادقة عبر الويب (WebAuthentication) باستخدام مفاتيح الأمان وجلسات المصادقة طويلة الأمد جدًا جنبًا إلى جنب مع روابط تسجيل الدخول عبر البريد الإلكتروني. في حال استخدام موقع الويب لكلمات مرور فمن المهم أن تكون كلمات المرور هذه قوية، ولكن قد تغير تعريف كلمة المرور “القوية” على مر السنين. هناك ثلاث طرق أساسية يستخدمها المهاجمون لاستهداف كلمات مرور المستخدم مباشرة:

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

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

1. منع إعادة استخدام كلمة المرور وبالأخص بالنسبة لكلمات المرور المخترقة المعروفة: لكن هذا أمر مستحيل القيام به تمامًا ويمكن أيضًا أن يتسبب بمشكلات في واجهة المستخدم. لكن هناك خدمات مثل هاف آي بن بوند(Have I Been Pwned) (الإنجليزية، تبدأ الاشتراكات في استخدام واجهة برمجة التطبيقات بسعر 40 دولارًا أمريكيًا في السنة)، وهولد سيكيوريتي (Hold Security) وسباي كلاود (SpyCloud)وما إلى ذلك التي يمكن أن تخبرك ما إذا كان اسم مستخدم وكلمة مرور معينين قد ظهرا في تفريغ كلمة المرور. ويمكن أيضًا تنزيل تجميعات كلمات المرور المفرّغة والتحقق منها محليًا.
2. منع استخدام كلمات المرور الشائعة: حيث يجب أن تقارن الصفحات التي تسمح للمستخدمين بتعيين كلمة المرور الخاصة بهم كلمة مرور المستخدم مقابل قائمة بكلمات المرور الأكثر شيوعًا (عادة ما يتم الحصول عليها من عمليات تفريغ كلمات المرور). وبعض هذه القوائم متاحة على غت هب(GitHub). لاحظ أن المهاجمين سيستخدمون ذات القوائم لذلك من غير المرجح أن يكون حظر أكثر 100 أو 1000 مرور شيوعًا فعّالًا للغاية.
3. تأكد من أن كلمات المرور تحتوي على ما يكفي من الإنتروبيا لمقاومة هجمات القوة الغاشمة : على الرغم من أن شيئًا مثل “w)*l3” ليس كلمة مرور شائعة إلا أنه سيتم اكتشافه بسرعة من خلال هجوم بالقوة الغاشمة، ويمكن أن يساعد تعيين الحد الأدنى لطول كلمة المرور في التخفيف من هجمات القوة الغاشمة. بالطبع يجب تحقيق التوازن بين هذه الأولويات ومتطلبات المستخدم إما لاستخدام مدير كلمات المرور أو لتذكر كلمة المرور الخاصة به. كما أن كلمات المرور بصفتها طريقة مصادقة تُمثل مشكلة إلى حد ما ويغطي القسم التالي المصادقة متعددة العوامل وبدائلها.

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

مصادقة متعددة العوامل

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

التصيد الاحتيالي والهجمات ذات الصلة

يُعدّ التصيد الاحتيالي أحد فئات هجمات الهندسة الاجتماعية التي يستخدمها المهاجمون لمهاجمة الأفراد، وعلى الرغم من أنه يمكن أن يكون للتصيد الاحتيالي العديد من الأهداف (مثل إقناع المستخدمين بتثبيت برمجيات ضارة على أجهزة الكمبيوتر الخاصة بهم أو تحويل الأموال إلى المهاجمين)، إلا أن الهدف الذي نهتم به هو سرقة كلمات مرور المستخدمين. وعلى الرغم من أن التصيد الاحتيالي يُشير عادةً إلى الهجمات التي يتم شنها عبر البريد الإلكتروني إلا أنه يمكن استخدام تقنيات مماثلة عبر مجموعة متنوعة من وسائل الاتصالات، مثل الرسائل النصية القصيرة (SMS) وواتساب (WhatsApp) وسيغنال (Signal) وحتى رموز الاستجابة السريعة (QR). في حملة تصيد احتيالي نموذجية لبيانات الاعتماد سيرسل المهاجمون رسائل بريد إلكتروني إلى ضحاياهم يزعمون إرسالها من موقع ويب سليم، وسيحتوي البريد الإلكتروني على عبارة تحث المستخدم على اتخاذ إجراء (مثل طلب تغيير كلمة المرور أو الإقرار بإشعار) مع رابط إلى موقع ويب يتحكم فيه المهاجم ويحتوي على صفحة تسجيل دخول تبدو سليمة. إذا نقر أحد الضحايا على الرابط ثم أدخل كلمة المرور الخاصة به على موقع الويب سيرسل الموقع كلمة المرور الخاصة به إلى المهاجم. (لمزيد من المعلومات حول التصيد الاحتيالي، انظر التحقيق في مسار تعلّم البنية التحتية الضارة.)

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

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

لمحة عامة عن المصادقة متعددة العوامل

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

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

الأسئلة السرية

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

رموز الرسائل النصية القصيرة

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

كلمات مرور تستخدم مرة واحدة ولفترة زمنية محدودة TOTP

عند استخدام كلمات المرور التي تستخدم لمرة واحدة ولفترة زمنية محدودة (Time-based One-Time Password أو اختصارًا TOTP)، خلال بدء النظام يقوم الخادم والجهاز الذي يتحكم فيه المستخدم بتبادل رمز تشفير سري (“القيمة الأولية”) ومزامنة الساعات. وبعد ذلك عندما يرغب المستخدم في المصادقة على موقع ويب يقوم جهاز المستخدم بإجراء عملية تشفير على القيمة الأولية والوقت الحالي مما يؤدي إلى إنشاء رمز يصلح فقط لثواني أو دقائق. يؤدي الخادم العملية ذاتها ويستخدمها للتحقق من رمز المستخدم. في الماضي كان نظام كلمات المرور التي تستخدم مرة واحدة ولفترة زمنية محدودة الأكثر شيوعًا هو المعرّفات الآمنة من آر إس إيه (RSA SecureIDs) والذي كان باهظ الثمن، لكن تعمل معظم أنظمة كلمات المرور التي تستخدم لمرة واحدة اليوم على الهواتف الذكية. ومن الأمثلة على ذلك غوغل أوثنتيكيتر (Google Authenticator) وأوثي (Authy). وبغض النظر يعمل نظام كلمات المرور التي تستخدم لمرة واحدة لديك بحيث يكون شيئًا لديك (القيمة الأولية للنظام) لأغراض المصادقة.

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

مفاتيح الأمان

مفاتيح الأمان (يشار إليها أحيانًا باسم المعامل الثاني الشامل (U2F) وإف آي دي أوْ (FIDO) أو وويب أوثنتكيشن ويوبيكيز (Yubikeys) وما إلى ذلك) هي أجهزة تُنفذ بروتوكول مصادقة التشفير. عند تسجيل مفتاح أمان مع موقع ويب، يقوم الموقع والمفتاح بتبادل مفتاح عام، وفي عمليات المصادقة اللاحقة يُقدم الخادم تحديًا موقّعًا إلى الجهاز، حيث يتحقق الجهاز من توقيع المَوقع ثم يستجيب باستخدام استجابة موقّعة، وأخيرًا يتحقق الخادم من توقيع الجهاز. يُثبت هذا للخادم أنك تمتلك المفتاح الذي تم تسجيله في البداية مما يجعله شيئًا تملكه. وتقليديًا كانت مفاتيح الأمان عبارة عن أجهزة قائمة بذاتها تتحدث إلى جهاز كمبيوتر أو جهاز محمول عبر الناقل التسلسلي العالمي (USB) أو الاتصال بالحقل القريب (NFC) على الرغم من أن دعم استخدام الهواتف الذكية وأجهزة الكمبيوتر متاح في بعض التكوينات.

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

كلمات المرور المخصصة للاستخدام مرة واحدة

تُستخدم كلمات المرور المخصصة للاستخدام لمرة واحدة التي تم إنشاؤها مسبقًا في بعض الأحيان كنسخة احتياطية لطرق المصادقة متعددة العوامل الأخرى، وسبق استخدامها للتطبيقات عالية الأمان قبل انتشار استخدام الهواتف الذكية. تُشير مواقع الويب الحديثة في كثير من الأحيان إلى هذه باسم “الرموز الاحتياطية”، حيث يقوم الخادم بإنشاء قائمة بالرموز وتخزينها وتقديمها إلى المستخدم. يقوم المستخدم عمومًا بطباعتها وتخزين الورق في مكان آمن، وفي كل مرة يُستخدم فيها رمز توضع عليه علامة أنه غير صالح من قبل الخادم. وتُعدّ هذه عُرضة لذات نقاط ضعف كلمات مرور تستخدم مرة واحدة ولفترة زمنية محدودة ولكن لديها ميزة ضارة لكونها غير مريحة للغاية، وعلى هذا النحو تُستخدم بشكل متكرر لتكون بديلًا احتياطيًا لطرق المصادقة متعددة العوامل الأخرى. نأمل أن يكون استخدامها نادرًا بما يكفي بحيث إذا طُلب من المستخدم إدخال رمز احتياطي أن يتوقف ويدقق في موقع الويب مقدم الطلب مما يجعل أرجحية نجاح هجوم التصيد الاحتيالي أقل. ومن الأمثلة على المواقع التي تستخدم رموز الاحتياطية البديلة هي جيميل (Gmail) وغت هب (Github).

لأجل مصادقة إضافية راجع ورقة المعلومات المرجعية حول المصادقة من مشروع أمان تطبيق الويب المفتوح و ورقة المعلومات المرجعية للمصادقة متعددة العوامل من مشروع أمان تطبيق الويب المفتوح. لأجل استكشاف متعمّق راجع مسار تعلّم تقييم أمان تطبيقات الويب.

تثبيت الجلسة

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

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

يمكن استخدام تقنيات مختلفة لتنفيذ هذا الهجوم حسب كيفية تعامل تطبيق الويب مع رموز الجلسة:

1. رمز الجلسة في وسيطة عنوان موقع الويب: يُرسل المهاجم معرّف الجلسة إلى الضحية عبر رابط تشعبي مما يؤدي بالضحية إلى الوصول إلى الموقع من خلال عنوان موقع الويب الضار.
2. رمز الجلسة في حقل نموذج مخفي: يخدع المهاجم الشخص المستهدف في المصادقة على خادم الويب المستهدف باستخدام نموذج تسجيل الدخول الذي طوره المهاجم والذي يحتمل أن يكون مستضافًا على خادم غير شرعي أو ضمن بريد إلكتروني بتنسيق لغة تمييز النص التشعبي.
3. معرّف الجلسة في ملف تعريف الارتباط:

• البرنامج النصي من جانب العميل: يستخدم البرمجة النصية من جانب العميل لحقن التعليمات البرمجية الضارة، غالبًا عبر هجمات البرمجة النصية عبر المواقع في ارتباط تشعبي ويُحدد معرّف الجلسة في ملف تعريف ارتباط الشخص المستهدف باستخدام وظيفة document.cookie.
• وسم : شكل آخر من أشكال هجوم حقن التعليمات البرمجية وهو أكثر فعالية من البرمجة النصية عبر المواقع حيث لا يمكن تعطيله أو رفضه بسهولة من قبل المتصفحات.
• استجابة رأس بروتوكول نقل النص التشعبي: يستغل استجابات الخادم لتضمين معرّف الجلسة في متصفح الضحية من خلال تضمين معلمة “Set-Cookie” في استجابة رأس بروتوكول نقل النص التشعبي.

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

الوقاية من ثغرات تثبيت الجلسة

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

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

إذا كنت ستقوم بترميز تطبيق ويب بقدرات المصادقة فإننا نوصي بقراءة هذه المقالة وتنفيذ التدابير التالية التي توصي بها، والتي تساعد على حماية تطبيق الويب من هجمات تثبيت الجلسة:

1. تجنّب قبول معرّفات الجلسة عبر معلمات GET أو POST لأن هذا يقلل من مخاطر الاستغلال عن طريق تقليل الاعتماد على ثغرات المتصفح، وبالإضافة إلى ذلك يجب أن يتم إنشاء جميع معرّفات الجلسة بواسطة الخادم مما يلغي أي حاجة إلى معرّفات الجلسة المقترحة من العميل.
2. بعد تسجيل الدخول ابدأ تغيير معرّف الجلسة عن طريق إنشاء معرّف جديد على الخادم وتحديثه ليكون ملف تعريف ارتباط، وفي الوقت نفسه قم بإبطال أي جلسة موجودة مرتبطة بالمستخدم.
3. ضمّن وظيفة تسجيل خروج تُمكّن المستخدمين من إنهاء جلساتهم على الفور وبالتالي ضمان الإنهاء الفوري للجلسة من جانب الخادم بدلًا من مجرد حذف ملف تعريف ارتباط المتصفح، وبالإضافة إلى ذلك نفّ آليات انتهاء الجلسة لإبطال بيانات الجلسة تلقائيًا بعد فترة زمنية محددة مسبقًا مما يحد من فرصة المهاجمين للاستفادة من الجلسات المخترقة.

اختبار مهارة

Exercise 1: Broken access controls

Go to the Try Hack Me website, create an account, and go through the room called OWASP Broken Access Control and follow the instructions.

Exercise 2: Using rainbow tables to better understand insecure password storage mechanisms (optional)

Note: while this exercise provides a great learning opportunity on how adversaries could crack badly secured passwords, it does require quite a bit of free disk space and uses a tool which is only available on Windows and Linux. Since not all learners might be able to do this practice exercise, we have marked it as clearly optional. We encourage learners who want to learn more about rainbow tables and secure password storage, both those who can and cannot do the below exercise, to consult further reading through posts such as this one.

When authenticating users we need a way to verify whether they entered correct credentials. The easiest way of doing that is to store the password itself in a database. This is insecure, as anyone with access to that database could learn users’ plaintext passwords, and they would be revealed in case of a leak or application vulnerability. A simple protection can be implemented by storing a hash value of the password instead. This exercise will demonstrate how easy it is to break such protection and learn plaintext passwords from hashed values. The point of this exercise is not to make learners believe that all authentication mechanisms can be easily broken but rather to demonstrate how easy it is to break passwords which have only been hashed without any additional security mechanisms such as salting.

Rainbow tables are a smart way of reducing computation time in exchange for disk space when trying to brute-force a hashed password. They consist of pre-calculated chains of hashes that can be used to discover a hashed value (the plaintext password).

The exercise

Given the hash value of 168f3c743786fea2e04aeeee33e112da , try to discover the password using rainbow tables. 🌈 Use RainbowCrack (http://project-rainbowcrack.com/). The easiest way to run RainbowCrack might be to use Kali Linux (https://www.kali.org/) in a VM or booted from a LiveUSB (refer to the links in Basic information section at the beginning of this learning path for more info). The hashing algorithm is MD5 and the hash is unsalted.

Hint: the password is lowercase alphanumeric, max. 6 characters. Once you’ve installed RainbowCrack you can use the following command to generate the required table:

rtgen md5 loweralpha-numeric 1 6 0 3800 1000000 0

_(Optional) _Try to use the generated table to break another hash: feadfd87d487818698d63aedf385c4e2.

Hint: If that fails you can try to generate more tables to increase the success rate of your table set (coverage). Just change the fifth parameter of the rtgen command to different values (try 1-5).

Try to break the following salted hash: 93e99d25dd6e8f524f23814908b6c039

The walkthrough

Generating a rainbow table requires specifying a hash algorithm to use, maximum length of the plaintext values were interested in and their character set. Those parameters only influence the time it takes for a table to be generated (amount of computation required).

Tables for shorter passwords with smaller character sets (eg. only lowercase letters) will take a shorter time to generate than tables for long passwords with numbers and special characters.

Additionally, you need to choose how many chains to generate and of what length. Those parameters are more complex to explain (see Philippe Oechslin’s whitepaper for more background) but have effects on coverage of the table. Only a subset of all possible plaintext values is included in each rainbow table.

The bigger the values of these parameters, the larger and more costly (in terms of CPU time) the table is, but also the more plaintext values can be discovered using it.

Pre-calculated tables for different hash functions, password lengths and character sets can be downloaded from the Internet (eg. https://freerainbowtables.com/) or obtained at IT security conferences and hacker camps (see https://dcddv.org/). For the purposes of this exercise we’ll generate our own!

You can install rainbowcrack on your system or use Kali Linux Live. For Kali, open a terminal window and run:

sudo apt update
sudo apt install rainbowcrack

This will install the software. You can use the rtgen command to generate tables. According to its manual the command takes quite a few parameters:

rtgen hash_algorithm charset plaintext_len_min plaintext_len_max table_index chain_len chain_num part_index

We’ll use MD5 as our hash algorithm. We’ll be looking for passwords of length from 1 to 6 characters. We’ll use the loweralpha-numeric charset, which includes lowercase letters and numbers only. We’re going to use 3800 for chain length, 1000000 for number of chains.

To generate our first table run:

sudo rtgen md5 loweralpha-numeric 1 6 0 3800 1000000 0

This command might take a while to execute, depending on your system configuration.

After generation, one more step is required before we can use our new tables:

sudo rtsort

This will sort the data to make using the table faster. rtcrack will refuse to work with unsorted tables.

Let’s take a crack at our first hash:

rcrack . -h 168f3c743786fea2e04aeeee33e112da

This should take just a moment and reveal our plaintext password:

1 rainbow tables found
memory available: 11361376665 bytes
memory for rainbow chain traverse: 60800 bytes per hash, 60800 bytes for 1 hashes
memory for rainbow table buffer: 2 x 16000016 bytes
disk: ./md5_loweralpha-numeric#1-6_0_3800x1000000_0.rt: 16000000 bytes read
disk: finished reading all files


plaintext of 168f3c743786fea2e04aeeee33e112da is 1nfus3


statistics
----------------------------------------------------------------
plaintext found:                             1 of 1
total time:                                  0.33 s
time of chain traverse:                      0.22 s
time of alarm check:                         0.11 s
time of disk read:                           0.00 s
hash & reduce calculation of chain traverse: 7216200
hash & reduce calculation of alarm check:    4133612
number of alarm:                             3194
performance of chain traverse:               32.80 million/s
performance of alarm check:                  36.91 million/s


result
----------------------------------------------------------------
168f3c743786fea2e04aeeee33e112da  1nfus3  hex:316e66757333

Success! Now let’s try our second hash:

rcrack . -h feadfd87d487818698d63aedf385c4e2

The result:

1 rainbow tables found
memory available: 11236982784 bytes
memory for rainbow chain traverse: 60800 bytes per hash, 60800 bytes for 1 hashes
memory for rainbow table buffer: 2 x 16000016 bytes
disk: ./md5_loweralpha-numeric#1-6_0_3800x1000000_0.rt: 16000000 bytes read
disk: finished reading all files


statistics
----------------------------------------------------------------
plaintext found:                             0 of 1
total time:                                  0.31 s
time of chain traverse:                      0.20 s
time of alarm check:                         0.11 s
time of disk read:                           0.00 s
hash & reduce calculation of chain traverse: 7216200
hash & reduce calculation of alarm check:    4238786
number of alarm:                             3324
performance of chain traverse:               36.08 million/s
performance of alarm check:                  37.18 million/s


result
----------------------------------------------------------------
feadfd87d487818698d63aedf385c4e2  <not found>  hex:<not found>

We didn’t find our hash in this table. Let’s generate a few more tables with the hope of increasing our coverage. We’ll use the same rtgen command, only changing the table_index parameter:

sudo rtgen md5 loweralpha-numeric 1 6 1 3800 1000000 0
sudo rtgen md5 loweralpha-numeric 1 6 2 3800 1000000 0
sudo rtgen md5 loweralpha-numeric 1 6 3 3800 1000000 0
sudo rtgen md5 loweralpha-numeric 1 6 4 3800 1000000 0
sudo rtgen md5 loweralpha-numeric 1 6 5 3800 1000000 0
sudo rtsort .

Let’s try again:

rcrack . -h feadfd87d487818698d63aedf385c4e2

The result:

6 rainbow tables found
memory available: 10784174899 bytes
memory for rainbow chain traverse: 60800 bytes per hash, 60800 bytes for 1 hashes
memory for rainbow table buffer: 6 x 16000016 bytes
disk: ./md5_loweralpha-numeric#1-6_0_3800x1000000_0.rt: 16000000 bytes read
disk: ./md5_loweralpha-numeric#1-6_1_3800x1000000_0.rt: 16000000 bytes read
disk: ./md5_loweralpha-numeric#1-6_2_3800x1000000_0.rt: 16000000 bytes read
disk: ./md5_loweralpha-numeric#1-6_3_3800x1000000_0.rt: 16000000 bytes read
disk: ./md5_loweralpha-numeric#1-6_4_3800x1000000_0.rt: 16000000 bytes read
disk: ./md5_loweralpha-numeric#1-6_5_3800x1000000_0.rt: 16000000 bytes read
disk: finished reading all files
plaintext of feadfd87d487818698d63aedf385c4e2 is trolo0


statistics
----------------------------------------------------------------
plaintext found:                             1 of 1
total time:                                  0.54 s
time of chain traverse:                      0.41 s
time of alarm check:                         0.13 s
time of disk read:                           0.02 s
hash & reduce calculation of chain traverse: 14432400
hash & reduce calculation of alarm check:    4766264
number of alarm:                             4606
performance of chain traverse:               35.46 million/s
performance of alarm check:                  36.66 million/s


result
----------------------------------------------------------------
feadfd87d487818698d63aedf385c4e2  trolo0  hex:74726f6c6f30

Got it! Additional tables increased the coverage and the hash was found out.

An improvement on using simple hashing for password protection is called “salting” the hashes – adding an application-specific secret to the plaintext value. That increases the length and character set of the hashed value, making a rainbow table approach infeasible. Trying the third (salted) hash given in this exercise will fail with this method as it would require rainbow tables bigger than can be currently generated (and stored).

Skill Check

Exercise 1: recap

Complete the exercise we described above: carry out a SQL injection on DVWA and compare the hashes you discovered to those you found on a hash lookup site.

Exercise 2: multiple choice quiz

Broken authentication represents a significant threat to the security of web applications, allowing attackers to compromise user credentials, hijack sessions, and gain unauthorized access to sensitive information. In this set of multiple-choice questions, you can explore the concept of broken authentication and delve into the various risks associated with this vulnerability. Additionally, if you have a mentor or with a peer you can examine different types of flaws that can lead to compromised authentication mechanisms and discuss specific mitigation strategies tailored to address each of these vulnerabilities effectively.

Enhance your understanding of web application security and learn how to mitigate the risks posed by broken authentication with these questions:

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

السؤال 2. ما هي المخاطر المحتملة المرتبطة بثغرات المصادقة المعطلة؟

أ) الوصول غير المصرح به إلى البيانات الحساسة وحسابات المستخدمين.
ب) كشف رموز الجلسة مما يؤدي إلى هجمات اختطاف الجلسة.
ج) اختراق بيانات اعتماد المستخدم بما في ذلك كلمات المرور ورموز المصادقة.
د) كل ما سبق\

السؤال 3. أي مما يلي ليس مثالًا على آلية التخفيف لثغرات المصادقة المعطلة؟

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

السؤال 4. ما نوع الخلل الذي قد يؤدي إلى اختراق آليات المصادقة ويسمح للمهاجمين بتخمين كلمات مرور المستخدم أو اختراقها؟

أ) تثبيت الجلسة
ب) تزييف طلب مواقع مشتركة\
ج) عدم كفاية تعقيد كلمة المرور\
د) البرمجة النصية عبر الموقع

السؤال 5. ما هو المثال المحدد لاستراتيجية التخفيف لمعالجة عيب عدم كفاية تعقيد كلمة المرور؟

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

السؤال 6. ما هي استراتيجية التخفيف التي تهدف إلى منع المهاجمين من استغلال ثغرات تثبيت الجلسة؟

أ) تنفيذ آليات مهلة الجلسة.
ب) تشفير ملفات تعريف الارتباط للجلسة باستخدام بروتوكول نقل النص التشعبي الآمن.\
ج) تجديد معرّفات الجلسة بعد نجاح المصادقة.
د) فرض سياسات كلمة مرور قوية لحسابات المستخدمين.\

السؤال 7. ما نوع الخلل الذي قد يؤدي إلى اختراق آليات المصادقة من خلال السماح للمهاجمين باختطاف جلسات المستخدم النشطة؟

أ) فترة انتهاء صلاحية الجلسة غير ملائمة\
ب) تخزين الرمز المميز غير آمن\
ج) البرمجة النصية عبر الموقع\
د) تزييف طلب المواقع المشتركة

السؤال 8. ما هي استراتيجية التخفيف التي تعالج عيب تخزين الرموز غير الآمنة من خلال إدارة رموز المصادقة بشكل آمن؟

أ) تخزين الرموز في نص عادي داخل ملفات تعريف الارتباط من جانب العميل. ب) تشفير الرموز باستخدام خوارزمية تشفير متماثلة. ج) تنفيذ خوارزميات تجزئة كلمة المرور الآمنة. د) استخدام رؤوس بروتوكول نقل النص التشعبي لنقل رموز المصادقة.

السؤال 9. ما هو المثال المحدد لاستراتيجية التخفيف لمنع هجمات تثبيت الجلسة؟

أ) تبديل معرّفات الجلسة بعد نجاح تسجيل الدخول.\
ب) تنفيذ المصادقة متعددة الخطوات.\
ج) استخدام تحديات اختبار كابتشا للتحقق من صحة المستخدم.\ د) فرض التحقق الصارم من صحة المدخلات في نموذج تسجيل الدخول.

السؤال 10. ما نوع الخلل الذي قد يؤدي إلى اختراق آليات المصادقة من خلال السماح للمهاجمين بتزوير الطلبات إلى تطبيق الويب أثناء المصادقة بصفته مستخدمًا آخر؟

أ) فترة انتهاء صلاحية الجلسة غير ملائمة
ب) حماية طبقة النقل غير كافية\ ج) البرمجة النصية عبر الموقع
د) تزييف طلب المواقع المشتركة

مفتاح الإجابات

1. ب) نقطة ضعف في آلية المصادقة لتطبيق الويب تؤدي إلى اختراق بيانات اعتماد المستخدم.
2. د) كل ما سبق
3. ج) تعطيل بروتوكول نقل النص التشعبي الآمن لمنع اعتراض بيانات اعتماد المصادقة.
4. ج) عدم كفاية تعقيد كلمة المرور
5. ب) فرض متطلبات طول كلمة المرور وتعقيدها.
6. ج) تجديد معرّفات الجلسة بعد نجاح المصادقة.
7. أ) فترة انتهاء صلاحية الجلسة غير ملائمة
8. ب) تشفير الرموز باستخدام خوارزمية تشفير متماثلة.
9. أ) تبديل معرّفات الجلسة بعد نجاح تسجيل الدخول.
10. د) تزييف طلب المواقع المشتركة

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

بعد استكمال هذا الموضوع الفرعي، يجب أن يكون الممارسون قادرين على القيام بما يلي: فهم الأنواع الشائعة من ثغرات المصادقة فهم الآثار المحتملة لهذه الأنواع من الثغرات فهم آليات عمل هذه الثغرات فهم كيفية منع ثغرات هذه بشكل عام العرض تُعدّ المصادقة هي العملية التي يُثبت من خلالها مستخدم النظام هويته، وهي الأساس الذي يستند إليه التحكم في الوصول. عادةً ما يقدم المستخدم جزءًا من المعلومات التي تُعرّف هويته (اسم المستخدم وعنوان البريد الإلكتروني ورقم الهاتف وما إلى ذلك)، ومعلومات سرية تتحقق من صحة تلك الهوية (عادةً ما تكون كلمة مرور أو عبارة مرور ولكن هناك طرق بديلة أو إضافية تكتسب شعبية مثل مفاتيح الأمان والمصادقة عبر الويب (WebAuthn) ومفاتيح المرور (Passkeys)). سيغطي هذا الموضوع الفرعي بعض فئات الثغرات الشائعة وذات التأثير العالي على تطبيقات الويب. تخزين كلمة المرور بشكل غير آمن إذا أراد المستخدمون تسجيل الدخول إلى موقع باسم مستخدم وكلمة مرور فيجب أن يكون الموقع قادرًا على التحقق من أن المستخدم أدخل كلمة المرور الصحيحة، وعلاوة على ذلك يجب تخزين كلمات المرور بشكل آمن في قاعدة بيانات مصادقة التطبيق لأن قاعدة البيانات هذه قد تتعرض للاختراق بفعل حقن لغة الاستعلامات البنيوية أو فقدان النسخ الاحتياطية أو حتى أعضاء خبيثين أو مُخترقين في المؤسسة التي تدير الموقع. وهناك عدة طرق لتخزين كلمات المرور: نص عادي من الواضح أن هذه هي أسوأ طريقة لتخزين كلمات المرور لأنها تعني تخزين الأحرف الفعلية التي كتبها المستخدم عند إعداد كلمة المرور. وفي حالة اختراق قاعدة بيانات كلمات المرور سيتمكن المهاجمون من الوصول الكامل إلى جميع كلمات مرور المستخدم. لا يمكن استخدام كلمات المرور هذه للوصول إلى موقع الويب نفسه فحسب بل يمكن استخدامها في هجمات إعادة استخدام كلمة المرور ضد مواقع أو تطبيقات أخرى. مشفرّة يتمثل الحل الواضح لتخزين كلمة مرور النص العادي هو في تشفير كلمات المرور، ولكن لا يوفر هذا سوى حماية متواضعة ضد العديد من التهديدات. ويجب أن يعرف التطبيق نفسه مفتاح التشفير وبالتالي يجب تخزين المفتاح في مكان ما. من شبه المؤكد أن يتمكن المطلّعون الخبيثون أو المُخترقون الذين لديهم حق الوصول إلى قاعدة البيانات من الوصول إلى مفتاح التشفير، وهناك أيضًا مجموعة متنوعة من الثغرات الأمنية الشائعة في خادم الويب والتي قد تسمح للمهاجمين عن بُعد بالوصول إلى المفتاح. وبمجرد حصول شخص ما على مفتاح التشفير سيكون قادرًا على معرفة كلمات المرور. شفرة التجزئة كما اتضح لا يحتاج خادم الويب أبدًا إلى استرداد كلمة مرور المستخدم من التخزين بل يحتاج فقط إلى معرفة ما إذا كانت كلمة المرور التي أدخلها المستخدم هي نفس كلمة المرور الحقيقية للمستخدم، وهناك فئة من الخوارزميات يشار إليها باسم شفرة التجزئة التشفيرية التي تقوم بتحويل أحادي الاتجاه على البيانات. ومن الأمثلة على تلك الخوارزميات هي إم دي 5 (MD5) وSHA، ومن المستحيل فعليًا بالنظر إلى التجزئة تحديد بيانات المصدر التي ولدَّت التجزئة. لسوء الحظ تكون كلمات المرور عادةً قصيرة إلى حد ما وتميل دالات شفرة التجزئة التشفيرية إلى أن تكون سريعة للغاية، وبالنسبة لدالة تجزئة معينة من الممكن تجزئة كل كلمة مرور ممكنة بطول معين وتخزين كلمة المرور والتجزئة الناتجة. وبعد ذلك بالنظر إلى تجزئة كلمة مرور معينة يمكن للمرء ببساطة البحث عن كلمة المرور التي أنشأت هذه التجزئة. في منتصف العقد الأول من القرن الحادي والعشرين، كان من الممكن حساب وتخزين وتوزيع قواعد البيانات هذه التي تسمى جداول قوس قزح للاستخدام العام. أحد حلول مشكلة جداول قوس قزح هو إضافة القليل من البيانات (تسمى التمليح) إلى كلمة المرور قبل شفرة تجزئتها، ولا يجب أن تكون هذه البيانات سرية أو مرتفعة الانتروبيا بشكل خاص بل يجب أن تكون مختلفة لكل مستخدم. يتمثل النهج الشائع في استخدام شفرة تجزئة اسم المستخدم وكلمة المرور معًا، ويحتوي جدول قوس قزح لكلمة مرور مايكروسوفت ويندوز مدير لان نيو تكنولوجي على شفرات تجزئة يصل طولها إلى 9 أحرف وتستوعب 6.7 تيرابايت. عند تمليح شفرة تجزئة كلمة المرور هذه فقط باستخدام 5 أحرف أبجدية رقمية سيرتفع جدول قوس قزح إلى أكثر من 6,000,000,000 تيرابايت. تكمّن المشكلة في هذا النهج في أن شفرة التجزئة لا تزال سريعة للغاية وأن بطاقات الرسومات الحديثة هي في الأساس أجهزة كمبيوتر فائقة متوازية على نطاق واسع، ويمكن لبطاقة إنفيدي آر تي إكس (Nvidia RTX) 4090 (بطاقة فيديو متطورة من عام 2022) حساب ما يقرب من 400,000,000,000 شفرة تجزئة إس إتش إيه مملحة في الثانية مما يسمح للأفراد العاديين باختراق معظم كلمات المرور في دقائق أو ساعات. خوارزميات تخزين كلمات المرور الخاصة تكمن المشكلة في شفرة التجزئة التشفيرية في أنها مصممة لتكون سريعة وفعالة، وتأتي معظم فائدتها من استخدامها في التحقق من أن البيانات لم يتم العبث بها. تمت معالجة هذه المشكلة منذ عام 1976 مع وظيفة تشفير يونكس التي قامت بتمليح وتشفير كلمة المرور عدة مرات لإبطاء طريقة القوة الغاشمة، ولا يثير الدهشة أن هذه الخوارزمية لن تصمد أمام موارد الحوسبة الحديثة ولكن الفكرة العامة لا تزال تُستخدم اليوم مع خوارزميات خاصة مصممة لتخزين مشتقات كلمة المرور. تم تصميم هذه الخوارزميات لتستفيد من وحدة المعالجة المركزية القابلة للضبط وموارد الذاكرة وللموازنة بشكل جيد بين الأداء ومقاومة القوة الغاشمة. تتضمن خوارزميات معالجة كلمة المرور الجيدة (بترتيب تفضيلي متناقص) سكريبت (scrypt) وآرغون 2 (argon2) وب كريبت ()bcrypt وب بي كيه دي إف 2 (PBKDF2). كإجراء دفاعي متقدم من المستحسن دمج كلمة مرور المستخدم مع سر لا يتم تخزينه في قاعدة البيانات نفسها، وعلى سبيل المثال يمكن ترميز السر في التطبيق نفسه. ومن المحتمل أن يمنع هذا استرداد كلمة المرور في حالة فقدان قاعدة بيانات كلمة المرور فقط. جرب بنفسك! سجّل الدخول إلى دي في دبليو إيه الخاص بك وتأكد من ضبط مستوى الأمان ليكون منخفضًا. ثم انتقل إلى قسم حقن لغة الاستعلامات البنيوية وأدخل ما يلي في مربع النص:

​​999’ union all select user, password from users where ‘1’=‘1 سيؤدي هذا إلى عرض الاسمين الأول والأخير لجميع المستخدمين الذين لديهم userid يكون 999 (لا يوجد أي واحد) وكذلك شفرة التجزئة لاسم المستخدم وكلمة المرور لجميع المستخدمين. استخدم موقع بحث شفرة تجزئة عبر الإنترنت (على https://www.whatsmyip.org/hash-lookup/) للبحث عن تجزئة كلمة مرور المستخدم المسؤول، ما نوع التجزئة المستخدمة لتخزين كلمات مرور مستخدمي دي في دبليو إيه؟ ما هي كلمة مرور المستخدم المسمى “1337”؟ لمزيد من المعلومات حول التعامل مع كلمة المرور، راجع ورقة معلومات تخزين كلمة مرور مشروع أمان تطبيق الويب المفتوح. إعادة تعيين كلمة السر إذا نسي المستخدم على موقع الويب كلمة المرور الخاصة به توفر معظم المواقع طريقة آلية للمستخدم للتحقق من هويته من أجل تعيين كلمة مرور جديدة، ومن الناحية المثالية تكون هذه الطرق آمنة تقريبًا بقدر عملية التحقق من كلمة المرور القياسية التي يكتب فيها المستخدم كلمة مرور سرية يعرفها في صفحة ويب ولكنها أقل سهولة بشكل ملحوظ. ستفترض معظم المواقع أن حساب البريد الإلكتروني للمستخدم آمن بشكل معقول وترسل إلى المستخدم رابطًا يسمح له بإعادة تعيين كلمة المرور الخاصة به، وربما يكون هذا الافتراض صحيحًا بالنسبة للغالبية العظمى من حسابات المستخدمين على الغالبية العظمى من مواقع الويب. يجب أن تحتوي روابط إعادة تعيين كلمة المرور (بالإضافة إلى روابط “تسجيل الدخول السحري”) على الخصائص التالية من أجل تقليل مخاطر المستخدم: يجب أن تكون روابط بروتوكول أمان طبقة النقل إلى الإصدار المشفر من الموقع. (لاحظ أنه لا توجد طريقة مجدية لضمان تشفير البريد الإلكتروني نفسه أثناء النقل ولكن من المرجح أن يتم اعتراض حركة مرور شبكة المستخدم النهائي مثل قيام المستخدم بالوصول إلى صفحة ويب أكثر من حركة المرور بين الخوادم مثل رسائل البريد الإلكتروني المرسلة من خادم إلى آخر.) يجب أن يحتوي الرابط على رمز وصول يضم حوالي 128 بت من البيانات التي تم إنشاؤها عشوائيًا من مولد أرقام عشوائية قوي مشفر، ولاحظ أن 128 بت من البيانات تشغل 172 محرفًا أو أكثر عند ترميزها في عنوان موقع الويب. لا توجد ميزة حقيقية لاستخدام أكثر من 128 بت من البيانات واستخدام 128 بت يعني عدم الحاجة إلى حماية إضافية من القوة الغاشمة. يجب أن يكون رمز الوصول محدودًا زمنيًا (على سبيل المثال تنتهي صلاحيته بعد ساعة) وأن يكون للاستخدام مرة واحدة، ولا تحد حقيقة أنها مخصصة للاستخدام مرة واحدة من قدرة المهاجم على تغيير كلمة مرور المستخدم فحسب بل قد تنبه المستخدم أيضًا في حالة تمكن المهاجم من الحصول على الرمز المميز وتغيير كلمة مرور المستخدم. يجب ربط الرمز المميز نفسه بحساب المستخدم مما يمنع المستخدمين من استخدام الرمز المميز لتغيير كلمة مرور مستخدم آخر. قد يتم أيضًا إرسال روابط إعادة التعيين عبر الرسائل النصية القصيرة، ومن غير المرجح أن يتم اعتراض الرسائل النصية القصيرة من البريد الإلكتروني من قبل المتسللين العاديين ولكن يمكن أن تعترضها الحكومات في البلد الذي يتواجد فيه المستخدم. إذا تم إرسال رمز مميز أقصر (مثل رقم التعريف الشخصي (PIN)) عبر الرسائل النصية القصيرة، من المهم أن يكون لديك حماية قوية من القوة الغاشمة على الصفحة التي تقبل رقم التعريف الشخصي (PIN) على سبيل المثال عمر رقم التعريف الشخصي (PIN) لمدة 10 دقائق وحد المعدل. لاحظ أيضًا أن هناك هجمات لكسب المال وهجمات حجب الخدمة بسيطة تتضمن جعل الخادم يرسل رسائل نصية قصيرة إلى رقم هاتف يختاره المهاجم، ومن خلال إجراء عدد كبير من عمليات إعادة تعيين كلمة مرور الرسائل النصية القصيرة، يمكن للمهاجم أن يتسبب بتكاليف عالية لمشغل موقع الويب مما قد يؤدي إلى كسب المال لصالحه في هذه العملية. تتضمن الطريقة البديلة لإجراء إعادة تعيين كلمة المرور طرح أسئلة على المستخدم يعرف كل من موقع الويب والمستخدم إجاباتها ولكن قد لا يعرفها المهاجم، وتميل هذه الطرق إلى أن تكون ضعيفة أو قوية للغاية للتحقق من هوية المستخدم. وتُعدّ “الأسئلة السرية” القياسية مثل السؤال عن مكان ولادة المستخدم، واسم والدته قبل الزواج، وطراز سيارته الأولى وما إلى ذلك ضعيفة للغاية. ففي البداية قد يتمكن المهاجم من العثور بسهولة على إجابة لهذه الأسئلة، وثانيًا من المستحيل تغيير معظمها لذلك في حالة اكتشاف المهاجم إجابة (حتى عن طريق اختراق موقع ويب آخر) فسيكون قادرًا على استخدامها مرارًا وتكرارًا. وفي النهاية لمعظم هذه الأسئلة عدد محدود من الإجابات الشائعة، وعلى سبيل المثال إذا سألت شخصًا كوريًا عن اسم والدته قبل الزواج، فستكون نسبة كبيرة من الإجابات “كيم” أو “لي”. يتضمن النوع الآخر الأكثر أمانًا من الأسئلة السرية التواصل دون اتصال بالإنترنت بين موقع الويب والمستخدم، ومن الأمثلة على ذلك أشياء مثل فواتير الخدمات العامة والكشوف المصرفية. كي يتمكن المستخدم من إعادة تعيين كلمة المرور الخاصة به سيدخل على سبيل المثال مبالغ المعاملات الثالثة والخامسة في كشف حسابه المصرفي. لن يُسمح للمستخدم إلا ببضع محاولات ثم سيحتاج إلى إجراء عملية إعادة تعيين أقل راحة مع خدمة العملاء، ويمكن أن تكون عملية إعادة التعيين هذه آمنة للغاية على الرغم من أنها في أيام الكشوف عبر الإنترنت ربما تكون أقل أمانًا من إرسال رمز مميز عبر البريد الإلكتروني. لمزيد من المعلومات حول إعادة تعيين كلمة المرور الآمنة، راجع ورقة معلومات مرجعية لمشروع أمان تطبيق الويب المفتوح حول نسيت كلمة المرور. للحصول على استكشاف متعمّق لثغرات المصادقة والتخويل راجع مسار تعلّم تقييم أمان تطبيقات الويب. قوة الاعتماد تستخدم معظم تطبيقات الويب كلمات مرور للمصادقة على الرغم من أنه تتزايد شعبية تقنيات مثل المصادقة عبر الويب (WebAuthentication) باستخدام مفاتيح الأمان وجلسات المصادقة طويلة الأمد جدًا جنبًا إلى جنب مع روابط تسجيل الدخول عبر البريد الإلكتروني. في حال استخدام موقع الويب لكلمات مرور فمن المهم أن تكون كلمات المرور هذه قوية، ولكن قد تغير تعريف كلمة المرور “القوية” على مر السنين. هناك ثلاث طرق أساسية يستخدمها المهاجمون لاستهداف كلمات مرور المستخدم مباشرة: التخمين عبر الإنترنت على أساس إعادة استخدام كلمة المرور: حيث يستخدم المهاجم في هذا الهجوم كلمات مرور معروفة متعلقة بالمستخدم ويحاول ببساطة استخدام كلمات المرور هذه في نموذج تسجيل الدخول إلى الموقع، ونظرًا لأن العديد من الأشخاص يستخدمون نفس كلمات المرور عبر مواقع ويب متعددة فقد يكون هذا الهجوم فعالًا بشكل مدمر. تتوفر أسماء المستخدمين وكلمات المرور من المواقع المخترقة على نطاق واسع على الويب العام والويب المظلم وللبيع على مواقع الويب الخاصة، ويمكن للمهاجمين ببساطة إدخال جميع كلمات المرور المعروفة لمستخدم معين، أما إذا كان المهاجم يستهدف عددًا صغيرًا من المستخدمين فإن هذا الهجوم لا يتطلب حتى الأتمتة. الاختراق بطريقة القوة الغاشمة عبر الإنترنت من خلال حشو بيانات الاعتماد: وهو نوع هجوم يحاول فيه عميل برنامج (إما متصفح ويب نصي عبر شيء مثل سيلينيوم (Selenium) أو برنامج نصي مخصص) تلقائيًا تسجيل الدخول إلى الموقع المستهدف، وبالإضافة إلى ذلك يمكن أن تستخدم هذه الهجمات مجموعة موزعة من الخوادم الوكيلة لتبدو وكأنها تأتي من مجموعة متنوعة من أجهزة الكمبيوتر المختلفة. يكون معدل هذه الهجمات محدودًا عمومًا بسرعة خادم الويب ووقت استجابة الشبكة ولذلك سيكون المهاجمون حريصين عمومًا على اختيار بيانات الاعتماد الأكثر احتمالًا للمحاولة فقط. على سبيل المثال غالبًا ما يقصرون أسماء المستخدمين على مجموعة مستهدفة أو ضمن مجموعة أسماء مستخدمين سليمة معروفة إذا كانت هناك ثغرة أمنية في تعداد أسماء المستخدمين على الموقع. (لاحظ أنه في معظم الحالات يكون منع تعداد اسم المستخدم دفاعًا متعمقًا ويجب ألا يكون أولوية عالية لتطبيقات الويب.) بالإضافة إلى ذلك، سيحاول المهاجم تحديد أولويات كلمات المرور المحتملة باستخدام تفريغ كلمات المرور لتجربة كلمات المرور المعاد استخدامها وتجربة كلمات المرور شائعة الاستخدام. القوة الغاشمة دون اتصال: إذا تمكن المهاجم من الحصول على نسخة من قاعدة بيانات كلمات مرور التطبيق (على سبيل المثال عن طريق حقن لغة الاستعلامات البنيوية) فمن المحتمل أن يحاول استخدام القوة الغاشمة لاستخراج بيانات الاعتماد المخزنة. وحسب كيفية تخزين بيانات الاعتماد وقدرات أجهزة المهاجم قد يتمكن المهاجمون من تجربة مئات تريليونات كلمات المرور في الثانية أو مئات منها. على أي حال بمجرد امتلاك المهاجم قاعدة بيانات كلمة المرور لا يمكن للتطبيق اكتشاف الهجوم أو إيقافه، وسيعطي المهاجمون عمومًا الأولوية لكلمات المرور المحتملة في هذا الهجوم ولكن إذا كانت ممولة جيدًا أو إذا كانت خوارزمية تخزين كلمة المرور ضعيفة فيمكن للمهاجم البدء في تعداد جميع كلمات المرور المحتملة. من بين هذه الهجمات تُعدّ الهجمات عبر الإنترنت أكثر شيوعًا، ومن الناحية المثالية لن تكون التطبيقات عُرضة لحقن لغة الاستعلامات البنيوية ولن يتعرض المطلعون للاختراق ولن يقوموا بأشياء خبيثة ولن تضيع النسخ الاحتياطية لقاعدة البيانات أبدًا. لكن سيكون من غير المسؤول تجاهل إمكانية حدوث هجوم غير يتم دون الاتصال بالإنترنت، وبالنظر إلى ذلك يجب أن تكون أولويات تطبيق الويب (بالترتيب): منع إعادة استخدام كلمة المرور وبالأخص بالنسبة لكلمات المرور المخترقة المعروفة: لكن هذا أمر مستحيل القيام به تمامًا ويمكن أيضًا أن يتسبب بمشكلات في واجهة المستخدم. لكن هناك خدمات مثل هاف آي بن بوند (Have I Been Pwned) (الإنجليزية، تبدأ الاشتراكات في استخدام واجهة برمجة التطبيقات بسعر 40 دولارًا أمريكيًا في السنة)، وهولد سيكيوريتي (Hold Security) وسباي كلاود (SpyCloud)وما إلى ذلك التي يمكن أن تخبرك ما إذا كان اسم مستخدم وكلمة مرور معينين قد ظهرا في تفريغ كلمة المرور. ويمكن أيضًا تنزيل تجميعات كلمات المرور المفرّغة والتحقق منها محليًا. منع استخدام كلمات المرور الشائعة: حيث يجب أن تقارن الصفحات التي تسمح للمستخدمين بتعيين كلمة المرور الخاصة بهم كلمة مرور المستخدم مقابل قائمة بكلمات المرور الأكثر شيوعًا (عادة ما يتم الحصول عليها من عمليات تفريغ كلمات المرور). وبعض هذه القوائم متاحة على غت هب (GitHub). لاحظ أن المهاجمين سيستخدمون ذات القوائم لذلك من غير المرجح أن يكون حظر أكثر 100 أو 1000 مرور شيوعًا فعّالًا للغاية. تأكد من أن كلمات المرور تحتوي على ما يكفي من الإنتروبيا لمقاومة هجمات القوة الغاشمة: على الرغم من أن شيئًا مثل “w)*l3” ليس كلمة مرور شائعة إلا أنه سيتم اكتشافه بسرعة من خلال هجوم بالقوة الغاشمة، ويمكن أن يساعد تعيين الحد الأدنى لطول كلمة المرور في التخفيف من هجمات القوة الغاشمة. بالطبع يجب تحقيق التوازن بين هذه الأولويات ومتطلبات المستخدم إما لاستخدام مدير كلمات المرور أو لتذكر كلمة المرور الخاصة به. كما أن كلمات المرور بصفتها طريقة مصادقة تُمثل مشكلة إلى حد ما ويغطي القسم التالي المصادقة متعددة العوامل وبدائلها. لمزيد من المعلومات حول قوة كلمة المرور، راجع هذا الملخص لإرشادات المصادقة من المعهد الوطني للمعايير والتكنولوجيا الخاص بالحكومة الأمريكية. مصادقة متعددة العوامل كما يتضح من القسم السابق فإن أمان كلمة المرور صعب للغاية، ويزداد الأمر سوءًا عندما تفكر في هجمات الهندسة الاجتماعية مثل التصيد الاحتيالي. التصيد الاحتيالي والهجمات ذات الصلة يُعدّ التصيد الاحتيالي أحد فئات هجمات الهندسة الاجتماعية التي يستخدمها المهاجمون لمهاجمة الأفراد، وعلى الرغم من أنه يمكن أن يكون للتصيد الاحتيالي العديد من الأهداف (مثل إقناع المستخدمين بتثبيت برمجيات ضارة على أجهزة الكمبيوتر الخاصة بهم أو تحويل الأموال إلى المهاجمين)، إلا أن الهدف الذي نهتم به هو سرقة كلمات مرور المستخدمين. وعلى الرغم من أن التصيد الاحتيالي يُشير عادةً إلى الهجمات التي يتم شنها عبر البريد الإلكتروني إلا أنه يمكن استخدام تقنيات مماثلة عبر مجموعة متنوعة من وسائل الاتصالات، مثل الرسائل النصية القصيرة (SMS) وواتساب (WhatsApp) وسيغنال (Signal) وحتى رموز الاستجابة السريعة (QR). في حملة تصيد احتيالي نموذجية لبيانات الاعتماد سيرسل المهاجمون رسائل بريد إلكتروني إلى ضحاياهم يزعمون إرسالها من موقع ويب سليم، وسيحتوي البريد الإلكتروني على عبارة تحث المستخدم على اتخاذ إجراء (مثل طلب تغيير كلمة المرور أو الإقرار بإشعار) مع رابط إلى موقع ويب يتحكم فيه المهاجم ويحتوي على صفحة تسجيل دخول تبدو سليمة. إذا نقر أحد الضحايا على الرابط ثم أدخل كلمة المرور الخاصة به على موقع الويب سيرسل الموقع كلمة المرور الخاصة به إلى المهاجم. (لمزيد من المعلومات حول التصيد الاحتيالي، انظر التحقيق في مسار تعلّم البنية التحتية الضارة.) تُعدّ هجمات التصيد الاحتيالي منخفضة التكلفة للغاية بالنسبة للمهاجمين وتميل إلى أن تكون فعالة للغاية، وبمجرد أن يحصل المهاجم على كلمة مرور الضحية يمكنه تسجيل الدخول إلى موقع الويب المستهدف بصفته ضحية. مع التحضير يمكن للمهاجم استخدام الأتمتة لتنفيذ الإجراءات على الفور على حساب الضحية بما في ذلك تغيير عنوان البريد الإلكتروني للمستخدم وكلمة المرور لقفل الضحية خارج حسابه الخاص. نظرًا لخطر هجمات التصيد الاحتيالي وعدم القدرة الكاملة على مصادقة كلمة المرور لإيقاف التصيد الاحتيالي يجب تقييم أي مخطط مصادقة متعدد العوامل مقابل مقاومة التصيد الاحتيالي. لمحة عامة عن المصادقة متعددة العوامل هناك ثلاثة أنواع من الأمور (تسمى العوامل) التي يمكن استخدامها للمصادقة: شيء تعرفه: أكثر أمثلة ذلك شيوعًا هي كلمة المرور، وهي أمر تعرفه أنت (ونأمل أن تعرفه أنت فقط)، وهو شائع جدًا لأنه من السهل جدًا إنشاء كلمة مرور سرية ومن السهل تغييرها بشكل عام. شيء لديك: أكثر أمثلة ذلك الشيء شيوعًا هو مفتاح، وهو شيء لديك يصعب تكراره، وهو أقل شيوعًا لأنه من السهل خسارته ويصعب إعداده في البداية ويصعب تغييره. شيء منك: أكثر أمثلة ذلك الشيء شيوعًا هو بصمة الإصبع ولكن التعرف على الوجه أصبح شائعًا بشكل متزايد وهو شيء جوهري بالنسبة لك، ومن السهل بشكل مدهش “فقدانها” (مثل تعرض بصمات الأصابع للأذى نتيجة الاحتراق، ومن الصعب للغاية تغييرها عن قصد وعادة ما يمكن أن تحصل أخطاء في عملية التحقق. تجمع المصادقة متعددة العوامل بين اثنين أو أكثر من هذه العوامل معًا لتعزيز نظام المصادقة الخاص بالنظام، وهناك العديد من الأمثلة على المصادقة متعددة العوامل في الحياة اليومية. يتطلب استخدام ماكينة الصراف الآلي شيئًا لديك (هو البطاقة) وشيئًا تعرفه (رقم التعريف الشخصي الخاص بك). تحتوي العديد من أنظمة التحكم في الوصول إلى المبنى على شارة لفتح الباب ولكن هذه الشارة تظهر أيضًا وجه حامل الشارة على شاشة يمكن للحارس رؤيتها وتجمع بين شيء لديك (الشارة) وشيء منك (وجهك). في الجزء المتبقي من هذا القسم الفرعي سنناقش مجموعة متنوعة من طرق المصادقة متعددة العوامل الشائعة للويب. الأسئلة السرية على الرغم من أن هذا من الناحية الفنية ليس مصادقة متعددة العوامل (لأنها تجمع بين أشياء متعددة يعرفها المستخدم)، إلا أن استخدامها كان شائعًا جدًا في الماضي ولا تزال قيد الاستخدام في العديد من السياقات. كما يوفر استخدام الأسئلة السرية كجزء من المصادقة درجة معينة من الدفاع ضد إعادة استخدام كلمة المرور وهجمات تخمين كلمة المرور، ويوفر حماية ضعيفة جدًا ولا قيمة لها تقريبًا ضد التصيد الاحتيالي. ويمكن لموقع المهاجم ببساطة محاولة تسجيل الدخول إلى موقع الويب الحقيقي ثم الانتقال وطرح الأسئلة السرية على المستخدم، وبالإضافة إلى ذلك كما تمت مناقشته في القسم الفرعي لإعادة تعيين كلمة المرور أعلاه غالبًا ما تكون إجابات الأسئلة السرية قابلة للتخمين. ولهذه الأسباب فإن الأسئلة السرية ليست طريقة قوية للمصادقة متعددة العوامل. رموز الرسائل النصية القصيرة تتمثل طريقة المصادقة متعددة العوامل الفعلية شائعة الاستخدام في إرسال رمز إلى المستخدم عند تسجيل الدخول ثم طلب هذا الرمز لإكمال عملية تسجيل الدخول، ويجمع بين شيء يعرفه المستخدم (كلمة المرور الخاصة به) وشيء يملكه (الهاتف الذي يتلقى الرسائل على رقم معين)، لكن لسوء الحظ فإن رموز الرسائل النصية القصيرة لا قيمة لها تقريبًا أمام التصيد الاحتيالي. عندما يقوم المستخدم بتسجيل الدخول إلى موقع الويب المزيف الذي يتحكم فيه المهاجم سيقوم موقع الويب المزيف بتسجيل الدخول إلى موقع الويب الحقيقي، وسيقوم موقع الويب الحقيقي بإرسال رسالة نصية إلى المستخدم ثم يقوم المستخدم بإدخال الرمز في موقع الويب المزيف. يستخدم الموقع المزيف بعدها الرمز الموجود على الموقع الحقيقي ثم يسجل الدخول بصفته الضحية. بالإضافة إلى ذلك يمكن أن تسمح هجمات تبديل بطاقات سيم (SIM) للمهاجمين بالاستيلاء على رقم هاتف الضحية مما يسمح للمهاجم بتلقي رسائل نصية قصيرة مخصصة للضحية. ولهذه الأسباب لا تُعدّ رموز الرسائل النصية القصيرة طريقة متعددة العوامل قوية لمواقع الويب الحساسة أو المهمة. كلمات مرور تستخدم مرة واحدة ولفترة زمنية محدودة عند استخدام كلمات المرور التي تستخدم لمرة واحدة ولفترة زمنية محدودة (Time-based One-Time Password أو اختصارًا TOTP)، خلال بدء النظام يقوم الخادم والجهاز الذي يتحكم فيه المستخدم بتبادل رمز تشفير سري (“القيمة الأولية”) ومزامنة الساعات. وبعد ذلك عندما يرغب المستخدم في المصادقة على موقع ويب يقوم جهاز المستخدم بإجراء عملية تشفير على القيمة الأولية والوقت الحالي مما يؤدي إلى إنشاء رمز يصلح فقط لثواني أو دقائق. يؤدي الخادم العملية ذاتها ويستخدمها للتحقق من رمز المستخدم. في الماضي كان نظام كلمات المرور التي تستخدم مرة واحدة ولفترة زمنية محدودة الأكثر شيوعًا هو المعرّفات الآمنة من آر إس إيه (RSA SecureIDs) والذي كان باهظ الثمن، لكن تعمل معظم أنظمة كلمات المرور التي تستخدم لمرة واحدة اليوم على الهواتف الذكية. ومن الأمثلة على ذلك غوغل أوثنتيكيتر (Google Authenticator) وأوثي (Authy). وبغض النظر يعمل نظام كلمات المرور التي تستخدم لمرة واحدة لديك بحيث يكون شيئًا لديك (القيمة الأولية للنظام) لأغراض المصادقة. مثل رموز الرسائل النصية القصيرة تُعدّ كلمات مرور تستخدم مرة واحدة ولفترة زمنية محدودة عُرضة أيضًا للتصيد الاحتيالي، ويمكن للموقع المزيف الذي يتحكم فيه المهاجم ببساطة أن يطلب من المستخدم رمز كلمة المرور التي تستخدم لمرة واحدة الخاص به واستخدامه لتسجيل الدخول إلى الموقع الحقيقي. ولهذا السبب، ليست كلمات المرور التي تستخدم مرة واحدة ولفترة زمنية محدودة طريقة مصادقة متعددة العوامل قوية لمواقع الويب الحساسة أو المهمة. لاحظ أيضًا أنه إذا فقد المستخدم هاتفه أو مسحه فمن غير المرجح أن يتمكن من المصادقة على الموقع حيث فقد القيم الأولية الخاصة به لكلمات المرور التي تستخدم لمرة واحدة ولفترة زمنية محدودة. مفاتيح الأمان مفاتيح الأمان (يشار إليها أحيانًا باسم المعامل الثاني الشامل (U2F) وإف آي دي أوْ (FIDO) أو وويب أوثنتكيشن ويوبيكيز (Yubikeys) وما إلى ذلك) هي أجهزة تُنفذ بروتوكول مصادقة التشفير. عند تسجيل مفتاح أمان مع موقع ويب، يقوم الموقع والمفتاح بتبادل مفتاح عام، وفي عمليات المصادقة اللاحقة يُقدم الخادم تحديًا موقّعًا إلى الجهاز، حيث يتحقق الجهاز من توقيع المَوقع ثم يستجيب باستخدام استجابة موقّعة، وأخيرًا يتحقق الخادم من توقيع الجهاز. يُثبت هذا للخادم أنك تمتلك المفتاح الذي تم تسجيله في البداية مما يجعله شيئًا تملكه. وتقليديًا كانت مفاتيح الأمان عبارة عن أجهزة قائمة بذاتها تتحدث إلى جهاز كمبيوتر أو جهاز محمول عبر الناقل التسلسلي العالمي (USB) أو الاتصال بالحقل القريب (NFC) على الرغم من أن دعم استخدام الهواتف الذكية وأجهزة الكمبيوتر متاح في بعض التكوينات. على عكس طرق المصادقة متعددة العوامل الأخرى التي تمت مناقشتها هنا تُعدّ مفاتيح الأمان مقاومة للتصيد الاحتيالي، وتتمثل الفكرة هنا بأن التحدي الموقّع يتضمن هوية موقع الويب الذي يطلب المصادقة. بالنسبة لموقع سليم سيتطابق هذا مع مفتاح موقع موجود على الجهاز، وبالنسبة للموقع الذي يتحكم فيه المهاجمون لن يتطابق الموقع مع أي مفتاح موقع حالي وبالتالي لن يتم إجراء مصادقة متعددة العوامل. لذلك قد يكون لدى المهاجم كلمة مرور المستخدم ولكنه لن يتمكن من إكمال المصادقة على موقع الويب المستهدف حيث لا توجد طريقة للمهاجم لإكمال عملية المصادقة متعددة العوامل، لكن من الناحية السلبية يمكن فقدان مفاتيح الأمان، وبشكل عام ستسمح المواقع التي تستخدم مفاتيح الأمان للمستخدمين بتسجيل مفاتيح متعددة بحيث في حالة فقدان أحدها أو تلفه يمكن استخدام نسخة احتياطية. كلمات المرور المخصصة للاستخدام مرة واحدة تُستخدم كلمات المرور المخصصة للاستخدام لمرة واحدة التي تم إنشاؤها مسبقًا في بعض الأحيان كنسخة احتياطية لطرق المصادقة متعددة العوامل الأخرى، وسبق استخدامها للتطبيقات عالية الأمان قبل انتشار استخدام الهواتف الذكية. تُشير مواقع الويب الحديثة في كثير من الأحيان إلى هذه باسم “الرموز الاحتياطية”، حيث يقوم الخادم بإنشاء قائمة بالرموز وتخزينها وتقديمها إلى المستخدم. يقوم المستخدم عمومًا بطباعتها وتخزين الورق في مكان آمن، وفي كل مرة يُستخدم فيها رمز توضع عليه علامة أنه غير صالح من قبل الخادم. وتُعدّ هذه عُرضة لذات نقاط ضعف كلمات مرور تستخدم مرة واحدة ولفترة زمنية محدودة ولكن لديها ميزة ضارة لكونها غير مريحة للغاية، وعلى هذا النحو تُستخدم بشكل متكرر لتكون بديلًا احتياطيًا لطرق المصادقة متعددة العوامل الأخرى. نأمل أن يكون استخدامها نادرًا بما يكفي بحيث إذا طُلب من المستخدم إدخال رمز احتياطي أن يتوقف ويدقق في موقع الويب مقدم الطلب مما يجعل أرجحية نجاح هجوم التصيد الاحتيالي أقل. ومن الأمثلة على المواقع التي تستخدم رموز الاحتياطية البديلة هي جيميل (Gmail) وغت هب. لأجل مصادقة إضافية راجع ورقة المعلومات المرجعية حول المصادقة من مشروع أمان تطبيق الويب المفتوح وورقة المعلومات المرجعية للمصادقة متعددة العوامل من مشروع أمان تطبيق الويب المفتوح. لأجل استكشاف متعمّق راجع مسار تعلّم تقييم أمان تطبيقات الويب. تثبيت الجلسة يُعدّ تثبيت الجلسة مفهومًا ذا أهمية في أمان الويب، ويشير إلى هجوم يقوم فيه المهاجم بتعيين معرّف جلسة المستخدم إلى قيمة يعرفها المهاجم. ويمكن أن يحدث هذا من خلال وسائل مختلفة مثل هجمات التصيد الاحتيالي أو من خلال استغلال ثغرات في تطبيق الويب. يتضمن الهجوم الحصول على معرّف جلسة فعّال وإقناع المستخدم بالمصادقة عليه ثم الاستيلاء على الجلسة من خلال الاستفادة من معرّف الجلسة الذي أصبح معروفًا. ويتطلب ذلك من المهاجم توفير معرّف جلسة تطبيق ويب حقيقي والتلاعب بمتصفح الشخص المستهدف كي يقوم باستخدامه، ثم يمكنه الاستيلاء على جلسة المستخدم والتمتع بالوصول غير المصرّح به إلى حساب المستخدم. يستغل تثبيت الجلسة نقاط الضعف في كيفية إدارة تطبيق الويب لمعرّفات الجلسة، وبشكل أساسي يفشل التطبيق الضعيف في تعيين معرّف جلسة جديد أثناء مصادقة المستخدم مما يُمكّن المهاجم من استخدام معرّف جلسة قائم بالفعل. وعلى عكس اختطاف الجلسة الذي يحدث بعد تسجيل دخول المستخدم، يسمح تثبيت الجلسة بالتحكم في الجلسة قبل مصادقة المستخدم. يمكن استخدام تقنيات مختلفة لتنفيذ هذا الهجوم حسب كيفية تعامل تطبيق الويب مع رموز الجلسة: رمز الجلسة في وسيطة عنوان موقع الويب: يُرسل المهاجم معرّف الجلسة إلى الضحية عبر رابط تشعبي مما يؤدي بالضحية إلى الوصول إلى الموقع من خلال عنوان موقع الويب الضار. رمز الجلسة في حقل نموذج مخفي: يخدع المهاجم الشخص المستهدف في المصادقة على خادم الويب المستهدف باستخدام نموذج تسجيل الدخول الذي طوره المهاجم والذي يحتمل أن يكون مستضافًا على خادم غير شرعي أو ضمن بريد إلكتروني بتنسيق لغة تمييز النص التشعبي. معرّف الجلسة في ملف تعريف الارتباط: البرنامج النصي من جانب العميل: يستخدم البرمجة النصية من جانب العميل لحقن التعليمات البرمجية الضارة، غالبًا عبر هجمات البرمجة النصية عبر المواقع في ارتباط تشعبي ويُحدد معرّف الجلسة في ملف تعريف ارتباط الشخص المستهدف باستخدام وظيفة document.cookie. وسم : شكل آخر من أشكال هجوم حقن التعليمات البرمجية وهو أكثر فعالية من البرمجة النصية عبر المواقع حيث لا يمكن تعطيله أو رفضه بسهولة من قبل المتصفحات. استجابة رأس بروتوكول نقل النص التشعبي: يستغل استجابات الخادم لتضمين معرّف الجلسة في متصفح الضحية من خلال تضمين معلمة “Set-Cookie” في استجابة رأس بروتوكول نقل النص التشعبي.

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

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

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

التمرين 1: ملخص

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

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

عزز فهمك لأمن تطبيقات الويب وتعلّم كيفية التخفيف من المخاطر التي تشكلها المصادقة المعطلة من خلال هذه الأسئلة:

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

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

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

السؤال 4. ما نوع الخلل الذي قد يؤدي إلى اختراق آليات المصادقة ويسمح للمهاجمين بتخمين كلمات مرور المستخدم أو اختراقها؟ أ) تثبيت الجلسة ب) تزييف طلب مواقع مشتركة
ج) عدم كفاية تعقيد كلمة المرور
د) البرمجة النصية عبر الموقع

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

السؤال 6. ما هي استراتيجية التخفيف التي تهدف إلى منع المهاجمين من استغلال ثغرات تثبيت الجلسة؟ أ) تنفيذ آليات مهلة الجلسة. ب) تشفير ملفات تعريف الارتباط للجلسة باستخدام بروتوكول نقل النص التشعبي الآمن.
ج) تجديد معرّفات الجلسة بعد نجاح المصادقة. د) فرض سياسات كلمة مرور قوية لحسابات المستخدمين.

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

السؤال 8. ما هي استراتيجية التخفيف التي تعالج عيب تخزين الرموز غير الآمنة من خلال إدارة رموز المصادقة بشكل آمن؟ أ) تخزين الرموز في نص عادي داخل ملفات تعريف الارتباط من جانب العميل.
ب) تشفير الرموز باستخدام خوارزمية تشفير متماثلة.
ج) تنفيذ خوارزميات تجزئة كلمة المرور الآمنة.
د) استخدام رؤوس بروتوكول نقل النص التشعبي لنقل رموز المصادقة.

السؤال 9. ما هو المثال المحدد لاستراتيجية التخفيف لمنع هجمات تثبيت الجلسة؟ أ) تبديل معرّفات الجلسة بعد نجاح تسجيل الدخول.
ب) تنفيذ المصادقة متعددة الخطوات
ج) استخدام تحديات اختبار كابتشا للتحقق من صحة المستخدم.
د) فرض التحقق الصارم من صحة المدخلات في نموذج تسجيل الدخول.

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

مفتاح الإجابات

1. ب) نقطة ضعف في آلية المصادقة لتطبيق الويب تؤدي إلى اختراق بيانات اعتماد المستخدم.
2. د) كل ما سبق
3. ج) تعطيل بروتوكول نقل النص التشعبي الآمن لمنع اعتراض بيانات اعتماد المصادقة.
4. ج) عدم كفاية تعقيد كلمة المرور
5. ب) فرض متطلبات طول كلمة المرور وتعقيدها.
6. ج) تجديد معرّفات الجلسة بعد نجاح المصادقة.
7. أ) فترة انتهاء صلاحية الجلسة غير ملائمة
8. ب) تشفير الرموز باستخدام خوارزمية تشفير متماثلة.
9. أ) تبديل معرّفات الجلسة بعد نجاح تسجيل الدخول.
10. د) تزييف طلب المواقع المشتركة

موارد التعلّم