Top10 Documentation

Technical Documentation: OWASP/Top10

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (README.md) Copy Section

Top10

Official OWASP Top 10 Document Repository

OWASP Top 10 2025 - RELEASED Copy Chapter

We have released the OWASP Top 10:2025 (Final):

• OWASP Top10:2025

Please log any feedback, comments, or log issues here.

OWASP Top 10 2021 - SUPERSEDED Copy Chapter

• OWASP Top10:2021

OWASP Top 10 2017 - HISTORIC Copy Chapter

• OWASP Top 10:2017 (PPTX)
• OWASP Top 10:2017 (PDF)

OWASP Top 10 Leadership Copy Chapter

There are currently five co-leaders for the OWASP Top 10:

• Andrew van der Stock - X: @vanderaj
• Brian Glas - X: @infosecdad
• Neil Smithline - X: @appsecneil
• Tanya Janca - X: @shehackspurple
• Torsten Gigler - Mastodon: @[email protected]

OWASP Top 10 References Copy Chapter

• OWASP Top 10 Project Page
• HISTORIC: OWASP 2017 Summit Outcomes

2021 Docs Ar Index (`2021/docs/ar/index.md`) Copy Section

مقدمة

مرحباً بكم في أعلى عشرة مخاطر لعام 2021 Copy Chapter

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

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

ما هي التغييرات التي طرأت على أعلى عشرة مخاطر لعام 2021 Copy Chapter

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

A01:2021-تخطي صلاحيات الوصولاحتل (تخطي صلاحيات الوصول) المرتبة الأولى بعد أن كان في الترتيب الخامس، حيث أنه تم إجراء اختبار لنقاط الضعف وكانت النسبة هي 94% من التطبيقات مصابه بتخطي صلاحيات الوصول إن تخطي صلاحيات الوصول والمرتبط بـ 34 CWEs هو من أكثر الثغرات التي تحدث على مستوى التطبيقات.

A02:2021-فشل آلية التشفير يأتي فشل آلية التشفير في المرتبة رقم #2 والتي كانت تعرف بالبيانات الحساسة الغير محمية أو المكشوفة، والتي قد تكون أسبابها متعددة دون أن تعود جميعها لسبب جذري واحد، ويأتي التركيز هنا بشكل متجدد على حالات الفشل في الطرق المتعلقة بالتشفير والتي غالبًا ما تؤدي إلى كشف غير مصرّح به إلى بيانات حساسة أو اختراق الأنظمة.

A03:2021-الحقن تتراجع الحقن الى الخطر رقم 3. حيث انه تم اجراء اختبار لنقاط الضعف وكانت النسبة هي 94% من التطبيقات مصابه بثغرات الحقن. ان ثغرة الحقن والمرتبطة بـ 33 CWEs تعتبر ثاني اعلى ثغرة من الثغرات التي من الممكن إصابة التطبيقات بها. والجدير بالذكر ان ثغرات XSS تم دمجها هنا مع ثغرة الحقن في هذه النسخة.

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

A05:2021- الإعدادات الأمنية الخاطئة بعد أن كان هو الخطر رقم #6 الآن نراه في المرتبة #4، حيث أنه تم إجراء اختبار لنقاط الضعف وكانت النسبة هي 90% من التطبيقات يوجد بها أخطاء في طريقة الإعدادات الصحيحة. وهذا يحدث مع البرمجيات الحديثة والتي تستلزم تغيير الإعدادات بشكل مستمر مما يجعل نسبة الخطأ في ارتفاع، وهذا الذي جعل (الإعدادات الخاطئة) ترتفع من المرتبة السادسة إلى الرابعة. والجدير بالذكر أنه تم ضم " XML External Entities XXE" لهذا النوع من الإعدادات الخاطئة.

A06:2021-الثغرات و المكونات الغير المحدثة سابقًا كانت تعرف بـ “استخدام الأنظمة والمنتجات ذات ثغرات معروفة". وبناءً على على استطلاع في أمن التطبيقات كانت هي #2 أعلى ثغرة على مستوى خطر المنتجات. ومن خلال تحليل البيانات وبعد أن كانت هي الخطر رقم #9 في الإصدار السابق لعام #2017 ارتفعت في إصدار #2021 إلى الخطر رقم #6. وعند النظر إلى معايير CVEs أو CWEs لا نرى لها أي تصنيف بالخطورة. ولذلك يتم تصنيف خطورتها بشكل افتراضي بناءً على مستوى التأثير وهو 5.0.

A07:2021-الهوية و فشل عملية التحقق والتي كانت تعرف في الإصدارات السابقة "ضعف التحقق من الهوية" وبعد أن كانت كذلك هي الخطر رقم #2. وبعد عملية ربطها مع إطار CWEs وتسميتها بـ “فشل عملية التحقق. وكما نقول أن زيادة المعايير أدّت إلى تقليل المخاطر ولكن ليس بشكل كامل لذلك نراها هنا من ضمن أعلى عشرة مخاطر.

A08:2021- فشل سلامة البيانات والبرمجيات تمت إضافتها حديثًا في هذا الإصدار 2021. والتي تركّز بشكل كبير على تحديث البرمجيات والبيانات مع التأكد على عدم تأثر سلامة دورة حياة CI/CD. وعند النظر إلى تقييم المخاطر المحتملة حسب تصنيف CVE/CVSS وارتباطها مع CWEs نجد أن تقييم الخطر هو 10 ويعتبر مرتفع جدًا. الجدير بالذكر أن "Insecure Deserialization" أصبحت جزء من هذا التصنيف.

A09:2021-فشل في تسجيل السجلات الأمنية والمراقبة والتي كانت تعرف سابقًا بـ “تسجيل الأحداث والمراقبة بشكل غير صحيح. وبعد عمل الاستطلاع التي تم اجراءها في أمن التطبيقات احتلت المرتبة رقم 3 في عملية الاستطلاع. والذي جعلها تصعد مرتبة واحدة بعد أن كانت في المرتبة 10. الجدير بالذكر أن هناك العديد من عمليات الفشل التي تحدث في المراقبة وتسجيل الأحداث التي تم ضمها هنا. وحينما نرى CVE/CVSS لا نرى لها أي تصنيف واضح ولكن مع القصور في عمليات المراقبة وتسجيل الأحداث والتي تشكل تأثيرًا بالغًا في عملية التغطية على مستوى الأنظمة، والتنبيه في حال وجود حوادث أو الاستفادة منها في عمليات التحقيق الجنائي الرقمي.

A10:2021-تزوير الطلبات من جانب الخادم SSRF تم إضافة هذا التصنيف بناءً على الاستطلاع رقم #1. وتظهر البيانات حسب الاختبارات التي تم إجراؤها أن هذا التصنيف معدل الإصابة به فوق المتوسط مع ارتفاع منخفض. ومدى ارتباطه بمعدل التأثير وإمكانية الاستغلال. ويفيد المختصين في المجال أن وجود هذا التصنيف من ضمن المخاطر هو أمر مهم جدًا حتى وإن كانت البيانات الحالية غير مكتملة في الوقت الحالي.

المنهجية Copy Chapter

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

وكما أن هناك بعض التغييرات الجوهرية التي تم اعتمادها من قبل منظمة أواسب لمواصلة المنهجية المتّبعة في تصنيف أعلى عشرة مخاطر.

كيف يتم تنظيم التصنيفات Copy Section

تم تغيير بعض التصنيفات من الإصدار السابق لأعلى عشر مخاطر وهنا ملخص لما تم تغيره على مستوى التصنيفات

تركز الجهود المبذولة في جمع البيانات على مجموعات فرعية من CWEs بعدد 30 مجال مع الاخذ بالاعتبار ان بعض التصنيفات الفرعية تحتاج الى بيانات ونتائج إضافية.
لذلك قرّرت المنظمة أنها ستقوم بالتركيز على 30 تصنيف من CWEs بشكل أساسي وقد يتطلّب التركيز في بعض الأحيان النظر في التصنيفات المتفرعة منها وسيكون في نطاق محدود وضيّق. وتبعًا للإجراءات المعتادة قمنا بطلب البيانات وبدون أي قيود على CWEs. وقمنا بطلب عدد من التطبيقات التي تم اختبارها لسنوات محددة (بدءًا من عام 2017)، و التطبيقات التي تم تقييمها بإصابتها بأحد CWEs على الأقل. وتسمح لنا هذه الطريقة معرفة مدى ارتباط التطبيقات بتصنيفات CWEs. مع الأخذ بعين الاعتبار أننا تجاهلنا التكرار لأسباب معيّنة، وأن في بعض الحالات يكون ضروريًا الأخذ به والذي قد يؤثر في بعض الأحيان في حال كان التطبيق منتشر ومشهور ومستخدم بكثرة. والجدير بالذكر أن مهما كان التطبيق مصاب بـ 4 من CWEs أو 4,000 فهذا لا يؤثر على آلية احتساب أعلى عشرة مخاطر لدينا. ولقد كان لدينا حوالي 400 CWEs تقريبًا وقمنا بحصرها وتقليلها إلى 30 CWEs وذلك من خلال تحليل مجموعة من البيانات. وكما نخطط في المستقبل في إجراء تحليلات إضافية والتي بدورها ستنعكس على إضافة بعض من CWEs وقد يكون هناك تغيير كذلك على هيكلة وتصنيف أعلى عشرة مخاطر.

لقد أمضينا عدة أشهر في تجميع وتصنيف CWEs وكان من الممكن أن نستمر لأشهر إضافية. ولكن كان علينا التوقف عند نقطة ما. كما أن هناك أنواع في CWEs ما يسمى بـ “سبب جذري" و "الأعراض". وعلى سبيل المثال على "سبب جذري" كفشل التشفير أو الإعدادات الخاطئة والذي يتم إقرانه بالأعراض مثل بيانات حساسة مكشوفة أو حجب الخدمة. لذلك قرّرنا أن نركز على "السبب الجذري" قدر الإمكان وذلك لتوفّر التوصيات والإرشادات وطرق تلافي تلك الأسباب. كما أن التركيز على الأسباب الجذرية أكثر من الأعراض ليس مفهوم جديد، كما أن أعلى عشرة مخاطر جاءت بشكل مختلط ما بين "الأسباب الجذرية" و "الأعراض" وهو الأسلوب المتّبع في CWEs كذلك. وهدفنا أن نكون على توازن بينهم. إن متوسط التصنيفات حسب CWEs هو 19.6 حيث حصلت A10 تزوير الطلبات من جانب الخادم SSRF على 1 CWEs و 40 CWEs لصالح A04:2021- التصميم الغير آمن . إن التحديث الذي جرى على التصنيفات مفيد جدًا للمنظمات من ناحية التركيز على منافع الاستفادة من التدريب على CWEs واستخدمها كلغة عمل وإطار.

كيف يتم استخدام البيانات لبعض التصنيفات المختارة Copy Section

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

قمنا بتنزيل " OWASP Dependency Check" واستخرجنا نتائج CVSS للاختراق والآثار التي تم جمعها سابقاً من CWEs ذات العلاقة. ولا يخفى عليكم ان هذا الجهد من البحث اخذ قدر لا باس به لان جميع CVEs لديها درجات من CVSSv2 كذلك. ولكن هنا بعض الخلل ما بين CVSSv2 وCVSSv3 والذي يجب معالجته. وسنرى في القريب ان جميع CVEs ستقوم باستخدام CVSSv3. ونود ان نلفت الانتباه ان معادلة CVSSv2 وCVSSv3 والدرجات متغيرة ومتحدثة.

في CVSSv2، من الممكن ان يصل الأثر و الاستغلال الى 10.0، ولكن بعد استخدام المعادلة قد تنخفض الى 60% لاستغلال و 40% للتأثير. وفي CVSSv3 كان الحد الأعلى هو 6.0 للاستغلال و 4.0 للأثر. مع الاخذ بالاعتبار مدى ثقل أحدهما. وعند النظر الى CVSSv3 نرى ان الأثر ارتفع حوالي نقطة ونصف، والاستغلال انخفض بمقدار النصف نقطة تقريباً.

هناك أكثر من 125 ألف سجل من CVE تم ربطها مع CWEs في منصة NVD والتي تم استخدمها في " OWASP Dependency Check". وهناك أكثر من 241 تصنيف فرعي فريد في CWEs تم ربطها في أكثر من CVE. وهناك أكثر من 62 ألف من CWE تم ربطها في CVSSv3. والتي تمثل نصف البيانات التي تم حصرها.

في قائمة أعلى عشر مخاطر، قمنا بحساب متوسط نقاط الاستغلال والأثر بالطرق التالية. قمنا بتجميع درجات CVEs مع CVSS بواسطة CWE وقمنا بتقييم كل من الأثر والاستغلال باستخدام النسبة المئوية الموجودة في CVSSv3 بالإضافة الى جميع ما يوجد في CVSSv2 لاحتساب المتوسط الإجمالي. وبعد ذلك قمنا بربط المتوسط بـ CWEs في قاعدة البيانات وذلك لاستخدمها لتقييم درجات الأثر والاستغلال والاستفادة منها كذلك في احتساب المخاطر بناء على المعادلة المستخدمة.

لماذا لا تكون مجرد بيانات إحصائية بحتة؟ Copy Chapter

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

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

لماذا معدل الحدوث بدلا من التكرار؟ Copy Chapter

هناك ثلاثة مصادر أساسية للبيانات. نحددها على أنها الانسان يساعد الأدوات (HaT) ، او الأدوات تساعد الإنسان (TaH) ، او الأدوات من غير أي تعديلات.

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

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

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

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

ما هي عملية جمع البيانات وتحليلها؟ Copy Chapter

تم إضفاء الطابع الرسمي على عملية جمع بيانات أعلى عشر مخاطر في قمة Open Security Summit في عام 2017. وبعد ذلك أمضى المسؤولين في منظمة آواسب يومين في العمل على جعل عملية جمع البيانات مبنية على سياسة واضحة وشفافة. تعد نسخة 2021 هي المرة الثانية التي نستخدم فيها هذه المنهجية.

قمنا بدعوة للحصول على البيانات من خلال قنوات التواصل الاجتماعي المتاحة لنا، لكلًّا من المشروع و OWASP. وفي صفحة مشروع OWASP, نقوم بإدراج عناصر وهيكل البيانات التي نبحث عنها وكيفية إرسالها.
وفي مشروع GitHub, لدينا أمثلة لملفات تعمل كقوالب. نعمل مع المنظمات الأخرى حسب الحاجة للمساعدة في تحديد الهيكلورسمه وربطه بـ CWEs.

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

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

العوامل المستخدمة مع البيانات Copy Chapter

هناك عوامل بيانات مدرجة لكل تصنيف من تصنيفات أعلى عشر مخاطر، وإليك ما تعنيه:

• ربط بـ CWEs: عدد CWEs الذي تم ربطها بواسطة الفريق.

• معدل الحدوث/الحوادث: معدل الحدوث وهو النسبة المئوية للتطبيقات المعرضة لثغرات ومعرفة مدى ارتباطها بمعيار CWE خلال الاختبارات التي. أجرتها المؤسسات في سنة محددة.

• (الاختبارات) والتغطية:النسبة المئوية للتطبيقات التي تم اختبارها من قبل جميع المنظمات لـ CWE مُعيّن.

• خطورة الاستغلال: معرفة الاستغلال و النقاط الفرعية له من CVSSv2 و CVSSv3 والتي لديها CVEs ومرتبطة بـ CWEs، ،موائمتها ، ووضعها على مقياس 10pt.

• التأثير المتوقع: تأثير النقاط الفرعية من CVSSv2 و CVSSv3 والتي لديها CVEs ومرتبطة بـ CWEs، ،موائمتها ، ووضعها على مقياس 10pt.

• إجمالي التكرار/الحوادث: إجمالي عدد التطبيقات التي تم ربطها بـ CWEs وتم وضع تصنيف محدد لها.

• إجمالي CVEs: إجمالي عدد CVEs في NVD DB التي تم ربطها بـ CWEs وتم وضع تصنيف محدد لها.

علاقات التصنيفات لعام 2021 مع تصنيفات عام 2017 Copy Chapter

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

يمثل مخطط Venn أعلاه الترابط بين التصنيفات في أعلى عشر مخاطر لعام 2017. وأثناء القيام بذلك، أصبحت بضع نقاط أساسية واضحة:

1. كان يُرى بأن هجوم - ثغرات XSS تنتمي في حقيقة الأمر إلى ثغرات الحقن(Injection) لأنها في الأساس عبارة عن حقن المحتوى. بالنظر إلى بيانات عام 2021 ، أصبح من الواضح أن ( XSS )بحاجة إلى الانتقال إلى الحقن(Injection).

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

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

شكراً لكل من ساهم معنا في جمع هذه البيانات

ساهمت المنظمات التالية (جنبًا إلى جنب مع بعض المساهمين-المتبرعين المجهولين) لبيانات لأكثر من 500,000 تطبيق وجعلها هي القائمة الأكبر والأكثر والأشمل من التطبيقات التي تم إجراء اختبارات الأمان عليها وجعلها في قاعدة بيانات. وتأكد أنه من غير اسهاماتك لن يكون هذا ممكن.

شكرا لجميع داعمينا الماليين

{ width="256" }

{ width="256" }

2021 Docs De Index (`2021/docs/de/index.md`) Copy Section

source: "https://owasp.org/Top10/index" title: "A00_2021_Startseite" id: "Startseite" lang: "de" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".index" -%}
{%- set parent_2017 = extra.osib.document ~ ".2017" -%}

Einführung

Willkommen bei den OWASP Top 10 – 2021 Copy Chapter

{:class="img-responsive"}

Willkommen zur neuesten Ausgabe der OWASP Top 10! Die OWASP Top 10:2021 sind völlig neu, mit einem neuen Grafikdesign mit Piktogrammen je Risiko und Mobilgeräte-freundlichen Webseiten.

Ein großes Dankeschön an alle, die mit ihrer Zeit und Daten für diese Ausgabe beigetragen haben. Ohne Sie wäre diese Version nicht zustande gekommen. HERZLICHEN DANK!

Was sich in den Top 10 für 2021 geändert hat Copy Chapter

Es gibt drei neue Kategorien, vier Kategorien mit Änderungen im Namen und teilweise auch im Umfang (im englischen Original, siehe auch Vorwort der deutschen Version) und eine gewisse Konsolidierung in den Top 10 für 2021. Wir haben bei Bedarf Namen geändert, um uns auf die jeweilige Grundursache statt auf Symptome zu konzentrieren.

• A01:2021-Mangelhafte Zugriffskontrolle steigt von der {{ osib_link(link=parent_2017 ~ ".5", text= "fünften Position", doc="", Latest=0) }} in die Kategorie mit dem schwerwiegendsten Sicherheitsrisiko für Webanwendungen auf. Die uns zur Verfügung gestellten Daten zeigen, dass im Durchschnitt 3,81% der getesteten Anwendungen eine oder mehrere Common Weakness Enumerations (CWEs) dieser Kategorie aufweisen. Insgesamt wurden mehr als 318.000 CWEs in dieser Risikokategorie genannt. Die 34 CWE-Typen, die wir der 'mangelhaften Zugriffskontrolle' zuordneten, traten in Anwendungen häufiger auf, als die jeder anderen Kategorie.
• A02:2021-Fehlerhafter Einsatz von Kryptographie steigt mit neuem Namen um eine Position auf Nummer 2 auf. Bisher hieß diese Kategorie {{ osib_link(link=parent_2017 ~ ".3", doc="", Latest=0) }}, was eher ein (allgemeines) Symptom, als die Grundursache war. Der neue Name fokussiert auf Fehler im Zusammenhang mit der Kryptographie, wie dies bereits implizit der Fall war. Diese Kategorie führt häufig zur Offenlegung vertraulicher Daten oder zur Kompromittierung des Systems.
• A03:2021-Injection {{ osib_link(link=parent_2017 ~ ".1", text="steigt von der ersten", doc= "", Latest=0) }} auf die dritte Position ab. 94% der Anwendungen wurden auf eine Art von 'Injection' getestet, mit einer maximalen Inzidenzrate von 19% und einer durchschnittlichen Rate von 3,37%. Die 33 CWE-Typen dieser Kategorie weisen mit einem Vorkommen von insgesamt 274.000 Nennungen die zweithäufigsten Vorfälle bei Webanwendungen auf. 'Cross-Site Scripting' (XSS) wurde in dieser Ausgabe der Top 10 nun Teil dieser Kategorie.
• A04:2021-Unsicheres Anwendungsdesign ist eine neue Kategorie dieser Ausgabe, die sich mit Risiken im Zusammenhang mit Designfehlern bei Anwendungen beschäftigt. Um die IT-Sicherheit früher im Software-Entwicklungsprozess zu berücksichtigen, brauchen wir mehr Bedrohungsmodellierung, sichere Entwurfsmuster und -prinzipien sowie Referenzarchitekturen. Ein unsicheres Design kann nicht durch eine perfekte Implementierung behoben werden, da die erforderlichen Sicherheitsmaßnahmen definitionsgemäß nie zur Abwehr bestimmter Angriffe berücksichtigt und implementiert wurden.
• A05:2021-Sicherheitsrelevante Fehlkonfiguration wechselt von {{ osib_link(link=parent_2017 ~ ".6", text="Position 6 in der vorherigen Ausgabe", doc="", Latest=0) }} einen Platz nach oben. 90% der Anwendungen wurden auf irgendeine Art von Fehlkonfiguration getestet, mit einer durchschnittlichen Inzidenzrate von 4,5% und über 208.000 CWEs, die dieser Risikokategorie zugeordnet wurden. Angesichts der zunehmenden Verlagerung zu hoch konfigurierbarer Software, ist es nicht verwunderlich, dass diese Kategorie aufsteigt. Die frühere Kategorie für {{ osib_link(link=parent_2017 ~ ".4", doc="", Latest=0) }} ist jetzt auch Teil dieses Riikos.
• A06:2021-Unsichere oder veraltete Komponenten trug zuvor den Titel "{{ osib_link(link=parent_2017 ~ ".9", doc="", Latest=0) }}" und ist Nr. 2 in der Top-10-Community-Umfrage, verfügte jedoch über genügend Nennungen in den gespendeten Daten, um es bereits darüber in die Top 10 zu schaffen. Diese Kategorie steigt von {{ osib_link(link=parent_2017 ~ ".9", text="Position 9 im Jahr 2017", doc="", Latest=0) }} auf Position 6 auf. Es handelt sich hierbei um ein bekanntes Problem, dessen Risiko wir nur schwer testen und bewerten können. Es ist die einzige Kategorie, bei der die zugeordneten CWEs von keiner 'Common Vulnerability and Exposure' (CVE) referenziert wird, sodass in ihren Bewertungen ein mittlerer Standard-Score von 5,0 für Exploit und in der Auswirkung berücksichtigt werden.
• A07:2021-Fehlerhafte Authentifizierung fällt von der {{ osib_link(link=parent_2017 ~ ".2", text="zweiten Position", doc="", Latest=0) }} auf Platz 7 zurück. Das Risiko enthält jetzt CWEs, die eher mit Identifikationsfehlern zusammenhängen. Diese Kategorie ist immer noch ein fester Bestandteil der Top 10, aber die zunehmende Verfügbarkeit standardisierter Frameworks scheint hier zu helfen.
• A08:2021-Fehlerhafte Prüfung der Software- und Datenintegrität ist eine weitere, neue Kategorie für die Ausgabe von 2021, die sich auf Annahmen im Zusammenhang mit Software-Updates, kritischen Daten und CI/CD-Pipelines ohne Überprüfung der Integrität befasst. Die 10 CWE-Typen dieser Kategorie werden von 'Common Vulnerability and Exposures' (CVEs) mit den höchsten 'Common Vulnerability Scoring System' (CVSS)-Scores referenziert. {{ osib_link(link=parent_2017 ~ ".8", doc="", Latest=0) }} ist jetzt ein Teil dieser umfangreicher gewordenen Kategorie.
• A09:2021-Unzureichendes Logging und Sicherheitsmonitoring hieß früher {{ osib_link(link=parent_2017 ~ ".10", doc="", Latest=0) }}, wurde auf Basis der Top-10-Community-Umfrage (Nr. 3) hinzugefügt und rückt von Platz 10 auf. Diese Kategorie wurde erweitert, um mehr Fehlertypen abzudecken, ist schwierig zu testen und ist in den CVE/CVSS-Daten nicht gut vertreten. Fehler in dieser Kategorie können sich jedoch direkt auf die Sichtbarkeit, Alarmierung bei Vorfällen und Forensik der Anwendung auswirken.
• A10:2021-Server-Side Request Forgery wurde aus der Top-10-Community-Umfrage (Nr. 1) hinzugefügt. Die Daten zeigen eine relativ niedrige Inzidenzrate bei einer überdurchschnittlichen Testabdeckung sowie überdurchschnittlichen Bewertungen für Exploit- und Impact-Potenzial. Diese Kategorie entspricht dem Szenario, bei dem die Mitglieder der Sicherheits-Community uns mitteilen, dass dies wichtig ist, auch wenn es in den Daten zu diesem Zeitpunkt nicht abgebildet wird.

Methodik Copy Chapter

Diese Ausgabe der Top 10 ist datengestützter denn je, aber nicht mit blindem Vertrauen. Wir haben acht der zehn Kategorien aus den Datenbeiträgen und zwei Kategorien aus der Experten-Umfrage in der OWASP-Community mit den höchsten Bewertungen ausgewählt. Wir tun dies aus einer grundsätzlichen, methodischen Überlegung: Der Blick auf die erhaltenen Daten ist ein Blick in die Vergangenheit. IT-Sicherheitsforschende nehmen sich Zeit, um neue Schwachstellen und neue Möglichkeiten zu finden, diese zu testen. Es braucht Zeit, diese Tests in Tools und Prozesse zu integrieren. Bis eine Schwachstelle in großem Maßstab zuverlässig getestet wird, sind wahrscheinlich Jahre vergangen. Um diesen Umstand auszugleichen, nutzen wir eine Community-Umfrage, um Expertinnen und Experten für Anwendungssicherheit und Software-Entwicklung an vorderster Front zu befragen, was ihrer Meinung nach wesentliche Schwachstellen sind, die die Auswertung der Datenstatistik möglicherweise noch nicht aufzeigt.

Wir haben einige, wichtige Änderungen vorgenommen, um die Top 10 weiterzuentwickeln.

Wie die Kategorien aufgebaut sind Copy Chapter

Einige Kategorien haben sich gegenüber der vorherigen Ausgabe der OWASP Top Ten von 2017 geändert. Im Folgenden finden Sie eine Zusammenfassung der Änderungen in den einzelnen Kategorien.

Frühere Datenerhebungen konzentrierten sich auf eine vorgegebene Teilmenge von etwa 30 CWE-Typen. In einem Freitextfeld wurde nach zusätzlichen Erkenntnissen gefragt. Wir haben gelernt, dass sich Unternehmen in erster Linie auf diese 30 CWE-Typen konzentrieren und nur selten weitere CWEs ergänzten, die sie gefunden hatten. In dieser Ausgabe haben wir das Verfahren geöffnet und nur nach Daten gefragt, ohne Einschränkung auf bestimmte CWE-Typen. Wir fragten nach der Anzahl der getesteten Anwendungen für ein bestimmtes Jahr (ab 2017) und nach der Anzahl der Anwendungen, bei denen mindestens ein CWE im Test gefunden wurde. Mit dieser Vorgehensweise können wir erkennen, wie oft die einzelnen CWE-Typen jeweils in den Anwendungen vorkommen. Wir ignorieren dabei für unsere Zwecke bewusst die Häufigkeit von Schwachstellen je Anwendung. Während es in anderen Situationen sinnvoll und notwendig sein kann, würde sie hier nur das tatsächliche Vorkommen in der Anwendungspopulation verschleiern. Ob in einer Anwendung ein CWE-Typ viermal vorkommt oder 4.000 Mal, ist für die Risikoberechnung der Top 10 nicht relevant. Durch dieses Vorgehen ist die Datenbasis von etwa 30 CWE-Typen auf fast 400 gestiegen, die wir für diese Ausgabe analysiert haben. Wir planen, in Zukunft weitere zusätzliche Datenanalysen durchzuführen. Dieser deutliche Anstieg der CWE-Typen erfordert Änderungen in der Strukturierung der Kategorien.

Wir haben mehrere Monate damit verbracht, CWE-Typen zu gruppieren und zu kategorisieren, und hätten noch weitere Monate damit fortfahren können. Irgendwann mussten wir zu einem Ergebnis kommen. Es gibt sowohl CWEs, die sich auf Grundursachen beziehen, als auch solche, die sich auf Symptome beziehen. Beispiele für Grundursache-Typen sind „Kryptografischer Fehler“ und „Fehlkonfiguration“, für Symptomtypen können „Sensitive Data Exposure“ (Verlust der Vertraulichkeit sensibler Daten) und „Denial of Service“ (mutwillige Dienstblockade) genannt werden. Wir haben uns entschieden, uns - wann immer möglich - auf die Grundursache zu konzentrieren, da dies sinnvoller ist, um Hinweise zur Identifizierung und Behebung zu geben. Sich auf die Grundursache statt auf das Symptom zu konzentrieren, ist kein neues Konzept. Die Top Ten waren bisher eine Mischung aus Symptomen und Grundursachen. CWEs sind ebenfalls eine Mischung aus Symptomen und Grundursachen. Wir gehen einfach bewusster damit um und benennen sie.In dieser Version gibt es durchschnittlich 19,6 CWE-Typen pro Top10-Kategorie, wobei das Minimum bei 1 CWE für A10:2021-Server-Side Request Forgery und das Maximum bei 40 CWEs in A04:2021-Unsicheres Anwendungsdesign liegt. Diese aktualisierte Kategoriestruktur bietet zusätzliche Vorteile bei Schulungen, da sich Unternehmen jeweils auf die CWEs konzentrieren können, die für eine Programmiersprache/ein Framework besonders sinnvoll erscheinen.

Wie die Daten zur Auswahl und Priorisierung der Kategorien verwendet werden Copy Chapter

Im Jahr 2017 haben wir die Top10-Kategorien zunächst nach der Häufigkeit ihres Vorkommens in den Daten klassifiziert, um die Verbreitung zu bestimmen. Die weiteren Risikofaktoren Ausnutzbarkeit, Auffindbarkeit und technische Auswirkungen haben wir dann durch Teamdiskussionen basierend auf CVSS-Scores und jahrzehntelanger Erfahrung eingestuft. In 2021 wollten wir neben der, aus den aktuellen Daten abgeleiteten Verbreitung, nach Möglichkeit auch zur Einwertung der Faktoren Ausnutzbarkeit und (technische) Auswirkungen ausschließlich Daten verwenden.

Wir haben OWASP Dependency Check heruntergeladen, die CVSS-Exploit- und Impact-Scores extrahiert und sie nach den verwandten CWE-Typen gruppiert. Es war einiges an Recherche und Aufwand erforderlich, da zwar alle CVEs über CVSSv2-Einwertungen verfügen, bei den jedoch teilweise noch Mängel vorhanden sind, die erst durch CVSSv3 beheben wurden. Ab einem bestimmten Zeitpunkt haben alle CVEs auch ein CVSSv3-Score erhalten. Darüber hinaus wurden die Bewertungsskalen und Formeln zwischen CVSSv2 und CVSSv3 verändert.

In CVSSv2 konnten sowohl die Kategorie Exploit als auch (Technical) Impact Werte bis zu 10,0 betragen, aber die Formel würde sie auf 60% für Exploit und 40% für Impact begrenzen. In CVSSv3 ist das theoretische Maximum für Exploit auf 6,0 und für Impact auf 4,0 begrenzt. Unter Berücksichtigung der Gewichtung in der Formel von CVSSv3 erhöhte sich der Einfluss der Impact-Bewertung, im Durchschnitt um fast eineinhalb Punkte, der für Exploit sank im Durchschnitt um fast einen halben Punkt.

Im OWASP Dependency Check gibt es 125.000 Datensätze der National Vulnerability Database (NVD) in der CVEs, einer CWE zugeordnet sind, und es gibt 241 CWEs, die mindestens einer CVE zugeordnet sind. 62.000 CWEs haben einen CVSSv3-Score, was in etwa der Hälfte des Datenbestands entspricht.

Für die Top Ten 2021 haben wir die durchschnittlichen Exploit- und Impact-Werte wie folgt berechnet. Wir haben alle CVEs mit CVSS-Scores nach CWE gruppiert und sowohl die Exploit- als auch die Impact-Scores jeweils getrennt für die CVEs mit CVSSv3 und die mit ausschließlich CVSSv2-Einwertungen berechnet. Die Einzelwerte wurden normalisiert und zu einem Gesamt-Mittelwert zusammengefasst, der die Anzahl der jeweiligen CVSS-Bewertungen berücksichtigt. Die Ergebnisse haben wir als (gewichtete) 'durchschnittliche Ausnutzbarkeit' bzw. (gewichtete) 'durchschnittliche Auswirkung' bezeichnet und als Risikofaktoren verwendet.

Warum nicht nur reine statistische Daten? Copy Chapter

Die Ergebnisse in den zur Verfügung gestellten Daten beschränken sich in erster Linie auf das, was automatisiert getestet werden kann. Sprechen Sie mit erfahrenen AppSec-Expertinnen und Experten und sie werden Ihnen von Dingen erzählen, die sie gefunden haben, und von Trends, die sie sehen, die jedoch noch nicht in den Daten enthalten sind. Es braucht Zeit, um Testmethoden für bestimmte Schwachstellentypen zu entwickeln, und dann noch mehr Zeit, bis diese Tests automatisiert und für eine große Anzahl von Anwendungen ausgeführt werden. Alles, was wir finden, blickt zurück in die Vergangenheit und könnte Trends aus dem letzten Jahr übersehen, die in den Daten nicht vorhanden sind.

Daher wählen wir aus den Daten nur acht von zehn Kategorien aus, da sie unvollständig sind. Die anderen beiden Kategorien stammen aus der Top-10-Community-Umfrage. Sie ermöglicht den Praktikerinnen und Praktikern an vorderster Front für die, aus ihrer Sicht größten Risiken zu stimmen, die möglicherweise noch nicht in den Daten enthalten sind oder darüber nie abgeleitet werden können.

Warum Inzidenzrate statt Häufigkeit? Copy Chapter

Es gibt drei Hauptdatenquellen. Wir bezeichnen sie als Human-Assisted Tooling (HaT), Tool-Assisted Human (TaH) und Raw Tooling.

Raw Tooling und HaT sind Massen-Suchgeneratoren. Die Tools suchen nach bestimmten Schwachstellen und versuchen unermüdlich, jedes Vorkommen dieser Schwachstelle zu finden. Dabei werden für einige Schwachstellentypen hohe Fundzahlen generiert. Bei Cross-Site Scripting gibt es in der Regel zwei Arten von Schwachstellen: Entweder handelt es sich um einen kleineren, isolierten Fehler oder um ein systemisches Problem. Wenn es sich um ein systemisches Problem handelt, kann die Zahl der Befunde bei einer einzigen Anwendung in die Tausende gehen. Diese hohe Häufigkeit übertönt die meisten anderen, in Berichten oder in Daten gefundenen Schwachstellen.

TaH hingegen wird ein breiteres Spektrum an Schwachstellentypen finden, diese jedoch aus Zeitgründen viel seltener. Wenn Menschen eine Anwendung testen und so etwas wie Cross-Site Scripting sehen, ermitteln sie normalerweise drei oder vier Vorkommen und brechen die weitere Suche dann ab. Sie können ein systemisches Problem erkennen und die Schwachstelle mit einer Empfehlung zur anwendungsweiten Behebung versehen. Es ist weder die Notwendigkeit noch die Zeit vorhanden, jedes (einzelne) Vorkommen zu finden.

Angenommen, wir nehmen diese beiden unterschiedlichen Datensätze und versuchen, sie nach Häufigkeit zusammenzuführen. In diesem Fall würden die Tooling- und HaT-Daten die genaueren (aber weit gefassten) TaH-Daten übertönen, und das ist ein guter Grund dafür, warum etwas wie Cross-Site Scripting in vielen Listen so hoch eingestuft wird, obwohl die Auswirkungen im Allgemeinen gering bis moderat sind. Das liegt an der schieren Menge an Fundstellen (Cross-Site Scripting lässt sich auch relativ einfach testen, daher gibt es auch viel mehr Tests dafür).

Im Jahr 2017 haben wir stattdessen die Verwendung der Inzidenzrate eingeführt, um einen neuen Blick auf die Daten zu werfen und Raw Tooling- und HaT-Daten angemessen mit TaH-Daten zusammenzuführen. Die Inzidenzrate bewertet, wie viele Prozent der Anwendungen mindestens ein Vorkommen eines Schwachstellentyps aufweist. Es ist uns egal, ob es einmalig oder systemisch war. Das ist für unsere Zwecke irrelevant. Wir müssen lediglich wissen, wie viele Anwendungen mindestens ein Vorkommen hatte, was dazu beiträgt, einen klareren Überblick über die Testergebnisse über mehrere, unterschiedliche Testtypen hinweg zu erhalten, ohne dass die Daten von Massen-Suchgeneratoren die Ergebnisse dominieren. Dies entspricht auch einer risikoorientierten Sichtweise, da Angreifende nur ein einziges Auftreten einer Schwachstelle benötigen, um eine Anwendung über die Kategorie erfolgreich anzugreifen.

Wie sieht Ihr Datenerfassungs- und Analyseprozess aus? Copy Chapter

Wir haben den OWASP-Top-10-Datenerfassungsprozess auf dem Open Security Summit 2017 formalisiert. OWASP Top 10 Co-Leader und die Community haben zwei Tage damit verbracht, einen transparenten Datenerfassungsprozess zu formalisieren. Die aktuelle Ausgabe 2021 ist die zweite Edition, in der wir diese Methodik verwenden.

Wir haben zunächst einen Aufruf zur Datenerhebung über die uns zur Verfügung stehenden Social-Media-Kanäle veröffentlicht, sowohl über Projekt- als auch über OWASP-Kanäle. Auf der OWASP-Projektseite listen wir die Datenelemente und die Struktur auf, die wir benötigten, und wie die Daten erfasst und eingereicht werden konnten. Im GitHub-Projekt hatten wir Beispieldaten als Vorlage zur Verfügung gestellt. Bei Bedarf haben wir die Organisationen unterstützt, um die Struktur und Zuordnung zu CWEs herauszufinden.

Die Datenspenden stammen von den unterschiedlichsten Organisationen, darunter welche, die Anbieter nach Branchen testen, Bug-Bounty-Anbietern und Organisationen, die interne Testergebnisse beigesteuert haben. Die eingereichten Daten wurden zuerst grundlegend analysiert und hinsichtlich der zugeordneten CWEs auf Plausibilität geprüft und den Risikokategorien zugeordnet. Es gibt Überschneidungen zwischen einigen CWEs und andere sind sehr eng miteinander verbunden (z. B. kryptografische Schwachstellen). Alle Entscheidungen im Zusammenhang mit der Analyse der übermittelten Rohdaten wurden dokumentiert und veröffentlicht, um offen und transparent zu machen, wie wir die Daten normalisiert haben.

Die acht Kategorien mit den höchsten Inzidenzraten wurden in die Top 10 aufgenommen. Wir schauen uns auch die Ergebnisse der Top 10-Community-Umfrage an, um zu sehen, welche davon möglicherweise bereits in den Daten vorhanden waren. Die beiden Kategorien mit den meisten Stimmen, die nicht in den acht datengestützten Kategorien vorhanden waren, wurden für die beiden verbliebenen Plätze der Top 10 ausgewählt. Für die zehn ausgewählten Kategorien wurden jeweils neben der Inzidenzrate die weiteren Faktoren für Ausnutzbarkeit, Expolit und die (technische) Auswirkung, Impact berücksichtigt, um die Top 10:2021 in nach ihren Risiken zu ordnen.

Datenfaktoren Copy Chapter

Für die Top-10-Kategorien sind jeweils Datenfaktoren aufgeführt, die im Folgenden erläutert werden:

• Zugeordnete CWEs: Die Anzahl der CWEs, die der Kategorie vom Top-10-Team zugeordnet wurden.
• Häufigkeit: Die Inzidenzrate ist der Prozentsatz der Anwendungen, die für CWEs der Kategorie anfällig sind, bezogen auf die Summe aller Anwendungen, die von einer Organisation im jeweiligen Jahr getestet wurden.
• Durchschn. Ausnutzbarkeit: Der Exploit-Subscore aus CVSSv2- und CVSSv3-Scores von CVEs, die die CWEs der Kategorie referenziert haben, normalisiert auf eine 10-Punkte-Skala.
• Durchschn. Auswirkungen: Der Impact-Subscore aus CVSSv2- und CVSSv3-Scores von CVEs, die die CWEs der Kategorie referenziert haben, normalisiert auf eine 10-Punkte-Skala
• (Test-)Abdeckung: Der Prozentsatz der Anwendungen, die von allen Organisationen, die auf die CWEs der Kategorie getestet wurden.
• Gesamtanzahl: Gesamtzahl der Anwendungen, bei denen CWEs der Kategorie zugeordnet wurden.
• CVEs insgesamt: Gesamtzahl der CVEs in der NVD-Datenbank, die den CWEs der Kategorie zugeordnet wurden.

Vielen Dank an unsere Daten-Spender Copy Chapter

Die folgenden Organisationen (und weitere anonyme Spender) haben freundlicherweise Daten für über 500.000 Anwendungen gespendet, um dies zum größten und umfassendsten Datensatz zur Anwendungssicherheit zu machen. Ohne Sie wären diese Top 10 nicht möglich gewesen.

• AppSec Labs
• Cobalt.io
• Contrast Security
• GitLab
• HackerOne
• HCL Technologies
• Micro Focus
• PenTest-Tools
• Probely
• Sqreen
• Veracode
• WhiteHat (NTT)

Vielen Dank an unsere weiteren Sponsoren Copy Chapter

Das OWASP Top 10 2021-Team dankt Secure Code Warrior und Just Eat für die finanzielle Unterstützung.

{ width="256" }

{ width="256" }

2021 Docs En Index (`2021/docs/en/index.md`) Copy Section

OWASP Top 10:2021

Welcome to the OWASP Top 10:2021 documentation.

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.

Getting Started Copy Chapter

Start with the Introduction to learn about the OWASP Top 10:2021.

Navigation Copy Chapter

Use the navigation menu on the left to explore:

• Introduction
• Notice
• How to use the OWASP Top 10 as a standard
• How to start an AppSec program with the OWASP Top 10
• About OWASP

The Top 10:2021 List Copy Section

1. A01 Broken Access Control
2. A02 Cryptographic Failures
3. A03 Injection
4. A04 Insecure Design
5. A05 Security Misconfiguration
6. A06 Vulnerable and Outdated Components
7. A07 Identification and Authentication Failures
8. A08 Software and Data Integrity Failures
9. A09 Security Logging and Monitoring Failures
10. A10 Server Side Request Forgery (SSRF)

Looking for the 2025 Release Candidate? Visit https://owasp.org/Top10/2025/

2021 Docs Es Index (`2021/docs/es/index.md`) Copy Section

Introducción

Bienvenido al OWASP Top 10 - 2021 Copy Chapter

¡Bienvenido a la última entrega del OWASP Top 10! El OWASP Top 10 2021 ha sido totalmente renovado, con un nuevo diseño gráfico y una infografía de una sola página que puedes imprimir u obtener desde nuestra página web.

Un enorme agradecimiento a todos los que han contribuido con su tiempo y datos para esta iteración. Sin ustedes, esta entrega no sería posible. GRACIAS!

Qué ha cambiado en el Top 10 de 2021 Copy Chapter

Hay tres nuevas categorías, cuatro categorías con cambios de nombre y alcance, y alguna consolidación en el Top 10 de 2021. Hemos cambiado los nombres cuando ha sido necesario para centrarnos en la causa principal en lugar del síntoma.

• A01:2021 - Pérdida de Control de Acceso sube de la quinta posición a la categoría con el mayor riesgo en seguridad de aplicaciones web; los datos proporcionados indican que, en promedio, el 3,81% de las aplicaciones probadas tenían una o más Common Weakness Enumerations (CWEs) con más de 318.000 ocurrencias de CWEs en esta categoría de riesgo. Las 34 CWEs relacionadas con la Pérdida de Control de Acceso tuvieron más apariciones en las aplicaciones que cualquier otra categoría.
• A02:2021 - Fallas Criptográficas sube una posición ubicándose en la segunda, antes conocida como A3:2017-Exposición de Datos Sensibles, que era más una característica que una causa raíz. El nuevo nombre se centra en las fallas relacionadas con la criptografía, como se ha hecho implícitamente antes. Esta categoría frecuentemente conlleva a la exposición de datos confidenciales o al compromiso del sistema.
• A03:2021 - Inyección desciende hasta la tercera posición. El 94% de las aplicaciones fueron probadas con algún tipo de inyección y estas mostraron una tasa de incidencia máxima del 19%, promedio de 3.37%, y las 33 CWEs relacionadas con esta categoría tienen la segunda mayor cantidad de ocurrencias en aplicaciones con 274.000 ocurrencias. El Cross-Site Scripting, en esta edición, forma parte de esta categoría de riesgo.
• A04:2021 - Diseño Inseguro nueva categoría para la edición 2021, con un enfoque en los riesgos relacionados con fallas de diseño. Si realmente queremos madurar como industria, debemos "mover a la izquierda" del proceso de desarrollo las actividades de seguridad. Necesitamos más modelos de amenazas, patrones y principios con diseños seguros y arquitecturas de referencia. Un diseño inseguro no puede ser corregida con una implementación perfecta debido a que, por definición, los controles de seguridad necesarios nunca se crearon para defenderse de ataques específicos.
• A05:2021 - Configuración de Seguridad Incorrecta asciende desde la sexta posición en la edición anterior; el 90% de las aplicaciones se probaron para detectar algún tipo de configuración incorrecta, con una tasa de incidencia promedio del 4,5% y más de 208.000 casos de CWEs relacionadas con esta categoría de riesgo. Con mayor presencia de software altamente configurable, no es sorprendente ver qué esta categoría ascendiera. El A4:2017-Entidades Externas XML(XXE), ahora en esta edición, forma parte de esta categoría de riesgo.
• A06:2021 - Componentes Vulnerables y Desactualizados antes denominado como Uso de Componentes con Vulnerabilidades Conocidas, ocupa el segundo lugar en el Top 10 de la encuesta a la comunidad, pero también tuvo datos suficientes para estar en el Top 10 a través del análisis de datos. Esta categoría asciende desde la novena posición en la edición 2017 y es un problema conocido que cuesta probar y evaluar el riesgo. Es la única categoría que no tiene ninguna CVE relacionada con las CWEs incluidas, por lo que una vulnerabilidad predeterminada y con ponderaciones de impacto de 5,0 son consideradas en sus puntajes.
• A07:2021 - Fallas de Identificación y Autenticación previamente denominada como Pérdida de Autenticación, descendió desde la segunda posición, y ahora incluye CWEs que están más relacionadas con fallas de identificación. Esta categoría sigue siendo una parte integral del Top 10, pero el incremento en la disponibilidad de frameworks estandarizados parece estar ayudando.
• A08:2021 - Fallas en el Software y en la Integridad de los Datos es una nueva categoría para la edición 2021, que se centra en hacer suposiciones relacionadas con actualizaciones de software, los datos críticos y los pipelines CI/CD sin verificación de integridad. Corresponde a uno de los mayores impactos según los sistemas de ponderación de vulnerabilidades (CVE/CVSS, siglas en inglés para Common Vulnerability and Exposures/Common Vulnerability Scoring System). La A8:2017-Deserialización Insegura en esta edición forma parte de esta extensa categoría de riesgo.
• A09:2021 - Fallas en el Registro y Monitoreo previamente denominada como A10:2017-Registro y Monitoreo Insuficientes, es adicionada desde el Top 10 de la encuesta a la comunidad (tercer lugar) y ascendiendo desde la décima posición de la edición anterior. Esta categoría se amplía para incluir más tipos de fallas, es difícil de probar y no está bien representada en los datos de CVE/CVSS. Sin embargo, las fallas en esta categoría pueden afectar directamente la visibilidad, las alertas de incidentes y los análisis forenses.
• A10:2021 - Falsificación de Solicitudes del Lado del Servidor es adicionada desde el Top 10 de la encuesta a la comunidad (primer lugar). Los datos muestran una tasa de incidencia relativamente baja con una cobertura de pruebas por encima del promedio, junto con calificaciones por encima del promedio para la capacidad de explotación e impacto. Esta categoría representa el escenario en el que los miembros de la comunidad de seguridad nos dicen que esto es importante, aunque no está visualizado en los datos en este momento.

Metodología Copy Chapter

Esta entrega del Top 10 está más orientada a los datos que nunca, pero no a ciegas. Hemos seleccionado ocho de las diez categorías a partir de los datos aportados y dos categorías a partir de la encuesta de la comunidad del Top 10 a un alto nivel. Hacemos esto por una razón fundamental, mirar los datos aportados es mirar al pasado. Los investigadores de seguridad en aplicaciones se toman su tiempo para encontrar nuevas vulnerabilidades y nuevas formas de probarlas. Se necesita tiempo para integrar estas pruebas en las herramientas y los procesos. Para el momento en que podamos probar de forma fiable una vulnerabilidad a escala, es probable que hayan pasado años. Para compensar este punto de vista, utilizamos una encuesta de la comunidad en la que preguntamos a los expertos en seguridad y desarrollo de aplicaciones que se encuentran en primera línea cuáles son, en su opinión, las vulnerabilidades esenciales que los datos aún no muestran.

Hay algunos cambios críticos que hemos adoptado para seguir madurando el Top 10.

Cómo se estructuran las categorías Copy Chapter

Algunas categorías han cambiado con respecto a la anterior entrega del OWASP Top Ten. A continuación se presenta un resumen de alto nivel de los cambios de categoría.

Los trabajos anteriores de recopilación de datos se centraban en un subconjunto prescrito de aproximadamente 30 CWEs, con un campo que solicitaba hallazgos adicionales. Nos dimos cuenta de que las organizaciones se centraban principalmente en esas 30 CWEs y rara vez añadían otras CWEs que veían. En esta iteración, lo abrimos y solo pedimos datos, sin ninguna restricción sobre las CWEs. Solicitamos el número de aplicaciones analizadas para un año determinado (a partir de 2017) y el número de aplicaciones con al menos una instancia de una CWE encontrada en las pruebas. Este formato nos permite rastrear la prevalencia de cada CWE dentro de la población de aplicaciones. Ignoramos la frecuencia para nuestros propósitos; aunque puede ser necesaria para otras situaciones, solo oculta la prevalencia real en la población de aplicaciones. El hecho de que una aplicación tenga cuatro instancias de una CWE o 4.000 instancias no forma parte del cálculo para el Top 10. Hemos pasado de aproximadamente 30 CWEs a casi 400 CWEs para analizar en el conjunto de datos. Tenemos previsto realizar análisis de datos adicionales como complemento en el futuro. Este aumento significativo en el número de CWEs hace necesario cambiar la estructura de las categorías.

Pasamos varios meses agrupando y clasificando las CWEs y podríamos haber seguido durante más tiempo. En algún momento tuvimos que parar. Hay tipos de CWE de causa raíz y de síntoma, donde los de causa raíz serían "Falla Criptográfica" y "Configuración de Seguridad Incorrecta" en contraste con los de síntoma como "Exposición de Datos Sensibles" y "Denegación de Servicio". Hemos decidido centrarnos en la causa raíz siempre que sea posible, ya que es más lógico para proporcionar orientación sobre la identificación y la reparación. Centrarse en la causa raíz en lugar de en el síntoma no es un concepto nuevo; el Top Ten ha sido una mezcla de síntoma y causa raíz. Las CWEs también son una mezcla de síntoma y causa raíz; simplemente estamos siendo más explícitos al respecto y lo señalamos. Hay un promedio de 19,6 CWEs por categoría en esta entrega, con el límite inferior de 1 CWE para A10:2021-Falsificación de Solicitudes del Lado del Servidor (SSRF) a 40 CWEs en A04:2021-Diseño Inseguro. Esta actualización en la estructura de las categorías ofrece beneficios adicionales de capacitación, ya que las empresas pueden centrarse en las CWE que tienen sentido para un lenguaje/framework.

Cómo se utilizan los datos para seleccionar las categorías Copy Chapter

En 2017, seleccionamos las categorías según la tasa de incidencia para determinar la probabilidad, y luego las clasificamos según la discusión del equipo basada en décadas de experiencia respecto a la Explotabilidad, la Detectabilidad (también probabilidad) y el Impacto técnico. Para 2021, queremos utilizar los datos de Explotabilidad e Impacto (técnico) si es posible.

Descargamos OWASP Dependency Check y extrajimos las puntuaciones de CVSS de Explotación e Impacto agrupadas por CWEs relacionadas. Nos costó bastante investigación y esfuerzo, ya que todas las CVEs tienen puntuaciones CVSSv2, pero hay fallos en CVSSv2 que CVSSv3 debería solucionar. A partir de cierto momento, a todas las CVEs se les asignó también una puntuación CVSSv3. Además, los rangos y fórmulas se han actualizado entre CVSSv2 y CVSSv3.

En CVSSv2, tanto Explotabilidad como Impacto técnico podían llegar a 10,0, pero la fórmula los rebajaba al 60% para Explotabilidad y al 40% para Impacto técnico. En CVSSv3, el máximo teórico se limitó a 6,0 para Explotabilidad y 4,0 para Impacto técnico. Con la ponderación considerada, la puntuación de Impacto Técnico se elevó, casi un punto y medio en promedio en CVSSv3, y la Explotabilidad se redujo casi medio punto.

Hay 125 mil registros de una CVE mapeadas a una CWE en los datos de la Base de Datos Nacional de Vulnerabilidades (NVD) extraídos del OWASP Dependency Check, y hay 241 CWEs únicas mapeadas a una CVE. 62 mil mapeos de CWE tienen una puntuación CVSSv3, lo cual representa aproximadamente la mitad de la población en el conjunto de datos.

Para el Top Ten 2021, calculamos las puntuaciones promedio de explotabilidad e impacto técnico de la siguiente manera. Agrupamos todas las CVEs con puntuaciones CVSS por CWE y ponderamos las puntuaciones de explotabilidad e impacto técnico por el porcentaje de la población que tenía CVSSv3 + la población restante de puntuaciones CVSSv2 para obtener una media global. Mapeamos estos promedios a las CWEs en el conjunto de datos para utilizarlos como puntuación de Explotabilidad e Impacto (Técnico) para la otra mitad de la ecuación del riesgo.

¿Por qué no solo los datos estadísticos puros? Copy Chapter

Los resultados de los datos se limitan principalmente a lo que podemos comprobar de forma automatizada. Si hablas con un profesional experimentado de la seguridad de las aplicaciones, te hablará de las cosas que encuentra y de las tendencias que ve y que aún no están en los datos. Se necesita tiempo para desarrollar metodologías de pruebas para ciertos tipos de vulnerabilidades y más tiempo aún para que esas pruebas sean automatizadas y ejecutadas contra una gran población de aplicaciones. Todo lo que hallamos está mirando al pasado y puede que falten algunas tendencias del último año, que aún no están presentes en los datos.

Es por eso que solo recogemos ocho de las diez categorías de los datos, porque están incompletos. Las otras dos categorías proceden de la encuesta a la comunidad del Top 10. Esto permite a los profesionales de primera línea votar por los que ellos consideran que son los mayores riesgos y que podrían no estar en los datos (y puede que nunca se expresen en ellos).

¿Por qué la tasa de incidencia en lugar de la frecuencia? Copy Chapter

Hay tres fuentes principales de datos. Las identificamos como Herramienta asistida por Humanos (HaT), Humano asistido por Herramientas (TaH) y Herramientas en bruto.

Herramientas y HaT son generadores de hallazgos de alta frecuencia. Las herramientas buscarán vulnerabilidades específicas e intentarán incansablemente encontrar cada instancia de esa vulnerabilidad y generarán un elevado número de hallazgos para algunos tipos de vulnerabilidades. Por ejemplo, el Cross-Site Scripting, suele ser de dos tipos: o bien es un error menor y aislado, o bien es un problema sistémico. Cuando se trata de un problema sistémico, el número de hallazgos puede ser de miles para una sola aplicación. Esta alta frecuencia ahoga a la mayoría de las demás vulnerabilidades encontradas en los informes o datos.

Por otro lado, TaH encontrará una gama más amplia de tipos de vulnerabilidades, pero con una frecuencia mucho menor debido a las limitaciones de tiempo. Cuando los humanos prueban una aplicación y ven algo como un Cross-Site Scripting, normalmente encontrarán tres o cuatro instancias y se detendrán. Pueden determinar un hallazgo sistémico y escribir una recomendación para corregirlo a gran escala en la aplicación. No hay necesidad (ni tiempo) de encontrar cada instancia.

Supongamos que tomamos estos dos conjuntos de datos distintos y tratamos de fusionarlos por su frecuencia. En ese caso, los datos de Herramientas y HaT ahogarán los datos más precisos (aunque amplios) de TaH y es en buena parte la razón por la que algo como el Cross-Site Scripting ha sido clasificado tan alto en muchas listas cuando el impacto es generalmente bajo o moderado. Se debe al gran volumen de hallazgos. (El Cross-Site Scripting es además razonablemente fácil de probar, por lo que hay muchas más pruebas para ello).

En 2017, introdujimos el uso de la tasa de incidencia en su lugar para dar una nueva mirada a los datos y combinar de manera transparente los datos de Herramientas y HaT con los datos de TaH. La tasa de incidencia se refiere al porcentaje de la población de aplicaciones que tiene al menos una instancia de un tipo de vulnerabilidad. No nos importa si fue algo puntual o sistémico. Eso es irrelevante para nuestros objetivos; solo necesitamos saber cuántas aplicaciones tenían al menos una instancia, lo cual ayuda a proporcionar una visión más clara de los hallazgos de las pruebas a través de múltiples tipos de pruebas sin ahogar los datos en resultados de alta frecuencia. Esto corresponde a una visión relacionada con el riesgo, ya que un atacante solo necesita una instancia para atacar una aplicación con éxito a través de dicha categoría.

¿Cuál es su proceso de recopilación y análisis de datos? Copy Chapter

En el Open Security Summit de 2017 formalizamos el proceso de recopilación de datos del OWASP Top 10. Los líderes del OWASP Top 10 y la comunidad pasaron dos días trabajando en la formalización de un proceso de recopilación de datos transparente. La edición de 2021 es la segunda vez que utilizamos esta metodología.

Publicamos la solicitud de datos a través de las redes sociales de las que disponemos, tanto del proyecto como de OWASP. En la página del proyecto, enumeramos los elementos y la estructura de los datos que buscamos y cómo presentarlos. En el proyecto de GitHub, disponemos de archivos de ejemplo que sirven como plantillas. También, en caso necesario, trabajamos con las organizaciones para ayudarles a determinar la estructura y el mapeo con las CWEs.

Recibimos estos datos de organizaciones que son proveedores de servicios de seguridad, proveedores de bug bounty y organizaciones que aportan datos de pruebas internas. Una vez que recibimos los datos, los cargamos y realizamos un análisis fundamental de las categorías de riesgo de las CWEs. Hay un solapamiento entre algunas CWEs, y otros están muy relacionados (por ejemplo, las fallas criptográficas). Toda decisión relacionada con los datos en bruto se ha documentado y publicado para ser abiertos y transparentes en cuanto a la normalización de los datos.

Analizamos las ocho categorías con las tasas de incidencia más altas para incluirlas en el Top 10. También miramos los resultados de la encuesta a la comunidad del Top 10 para ver cuáles pueden estar ya presentes en los datos. Las dos más votadas que no estén ya presentes en los datos serán seleccionadas para los otros dos puestos del Top 10. Una vez seleccionados las diez, aplicamos factores generalizados de explotabilidad e impacto; para así poder ordenar el Top 10 2021 en función del riesgo.

Data Factors Copy Chapter

Hay factores de datos que se enumeran para cada una de las 10 categorías, aquí está lo que significan:

• CWEs mapeadas: El número de CWEs asignadas a una categoría por el equipo del Top 10.
• Tasa de incidencia: La tasa de incidencia es el porcentaje de aplicaciones vulnerables a esa CWE de la población analizada por esa organización para ese año.
• Cobertura (de pruebas): El porcentaje de aplicaciones que han sido testadas por todas las organizaciones para una determinada CWE.
• Explotabilidad ponderada: La sub-puntuación de explotabilidad de las puntuaciones CVSSv2 y CVSSv3 asignadas a las CVEs mapeadas a las CWEs, normalizados y colocados en una escala de 10 puntos.
• Impacto ponderado: La sub-puntuación de Impacto de las puntuaciones CVSSv2 y CVSSv3 asignadas a las CVEs mapeadas a las CWEs, normalizados y colocados en una escala de 10 puntos.
• Total de ocurrencias: Número total de aplicaciones en las que se han encontrado las CWEs asignados a una categoría.
• Total de CVEs: Número total de CVEs en la base de datos del NVD que fueron asignadas a las CWEs asignados a una categoría.

Gracias a nuestros proveedores de datos Copy Chapter

Las siguientes organizaciones (junto con algunos donantes anónimos) han tenido la amabilidad de donar datos de más de 500.000 aplicaciones para hacer de este el mayor y más completo conjunto de datos sobre seguridad de las aplicaciones. Sin ustedes, esto no sería posible.

• AppSec Labs
• Cobalt.io
• Contrast Security
• GitLab
• HackerOne
• HCL Technologies
• Micro Focus
• PenTest-Tools
• Probely
• Sqreen
• Veracode
• WhiteHat (NTT)

Gracias a nuestro patrocinador Copy Chapter

El equipo del OWASP Top 10 2021 agradece el apoyo financiero de Secure Code Warrior y Just Eat.

{ width="256" }

{ width="256" }

2021 Docs Fr Index (`2021/docs/fr/index.md`) Copy Section

Introduction

Bienvenue à l'OWASP Top 10 - 2021 Copy Chapter

{:class="img-responsive"}

Bienvenue à cette nouvelle édition de l'OWASP Top 10 ! L'OWASP Top 10 2021 apporte de nombreux changements, avec notamment une nouvelle interface et une nouvelle infographie, disponible sur un format d'une page qu'il est possible de se procurer depuis notre page d'accueil.

Un très grand merci à l'ensemble des personnes qui ont contribué de leur temps et leurs données pour cette itération. Sans vous, cette mouture n'aurait pas vu le jour. MERCI.

Les changements du Top 10 pour 2021 Copy Chapter

Il y a trois nouvelles catégories, quatre catégories avec un changement de nom et de périmètre, ainsi que des consolidations dans ce Top 10 2021. Nous avons changé les noms si nécessaire pour se concentrer sur la cause plutôt que le symptôme.

• A01:2021-Contrôles d'accès défaillants passe de la cinquième position à celle de catégorie présentant le risque de sécurité le plus sérieux pour une application web ; les données partagées indiquent, qu'en moyenne, 3,81% des applications testées avaient une ou plusieurs Common Weakness Enumeration (CWEs) avec plus de 318k occurrences de CWEs de cette catégorie. Les 34 CWEs associées ont eu plus d'occurrences dans les applications auditées que n'importe quelle autre catégorie.
• A02:2021-Défaillances cryptographiques gagne une position et prend la deuxième place, précédemment connue sous le nom de A3:2017-Exposition de données sensibles, qui était un symptôme large plutôt qu'une cause principale. L'accent est mis sur des défaillances liées à la cryptographie, ce qui était le cas implicitement auparavant. Cette catégorie entraîne souvent une exposition de données sensibles ou une compromission de système.
• A03:2021-Injection glisse à la troisième position. 94% des applications ont été testées sur des vulnérabilités de ce type, avec une incidence maximale de 19% et une incidence moyenne de 3,37%. Les 33 CWEs associées à cette catégorie ont eu le deuxième plus grand nombre d'occurrences. Cross-Site Scripting fait désormais partie de cette catégorie dans cette édition.
• A04:2021-Conception non sécurisée est une nouvelle catégorie, avec un accent sur les défauts de conception. Si nous voulons ajouter des contrôles en amont, nous avons besoin de modèles de menaces, de modèles et principes de conception sécurisés, et d'architectures de référence. Une conception non sécurisée ne peut pas être corrigé par une implémentation parfaite car, par définition, les contrôles de sécurité nécessaires pour se défendre contre certaines attaques n'ont jamais été créés.
• A05:2021-Mauvaise configuration de sécurité gagne une place ; 90% des applications ont été testées sur des vulnérabilités de ce type, avec une incidence moyenne de 4,5% et plus de 208k occurrences des CWEs associées. Avec des logiciels de plus en plus paramétrables, il n'est pas surprenant de voir cette catégorie prendre de l'ampleur. L'ancienne catégorie A4:2017-XML Entités externes (XXE) est incluse dans celle-ci.
• A06:2021-Composants vulnérables et obsolètes était précédemment nommée Utilisation de Composants avec des Vulnérabilités Connues. Elle se place deuxième de l'enquête auprès de la communauté du Top 10, mais pouvait également entrer dans le Top 10 via l'analyse de données. Cette catégorie progresse depuis sa neuvième place en 2017, elle est un problème connu dont nous avons du mal à tester et à mesurer les risques. Il s'agit de la seule catégorie à n'avoir aucunes Common Vulnerability and Exposures (CVEs) associées aux CWEs concernées, en conséquence les coefficients d'impact et de poids ont été renseignés à 5.0 par défaut.
• A07:2021-Identification et authentification de mauvaise qualité était précédemment Authentification de mauvaise qualité, elle perd la deuxième place. Elle inclut désormais des CWEs également liées aux échecs d'identification. Cette catégorie est toujours présente dans le Top 10, mais la mise à disposition croissante de frameworks standardisés semble aider.
• A08:2021-Manque d'intégrité des données et du logiciel est une nouvelle catégorie, se concentrant sur la formulation d'hypothèses sur les mises à jour logicielles, les données critiques et les pipelines CI/CD sans vérifier leur intégrité. L'un des impacts les plus élevés à partir des données de Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) associées aux 10 CWEs de cette catégorie. A8:2017-Désérialisation non sécurisée, listée en 2017, est désormais partie intégrante de cette catégorie.
• A09:2021-Carence des systèmes de contrôle et de journalisation, précédemment A10:2017-Supervision et Journalisation Insuffisantes, est ajoutée de l'enquête auprès de l'industrie (3ème), précédemment à la dixième place. Cette catégorie a été étendue pour inclure plus de types de défaillances, est difficile à tester et est dès lors mal représentée dans les données CVE/CVSS. Toutefois, des incidents dans cette catégorie peuvent impacter directement la visibilité, la levée d'alertes et l'analyse forensique.
• A10:2021-Falsification de requête côté serveur provient de l'enquête auprès de la communauté Top 10 (1ère). Les données montrent une incidence faible, avec un taux de couverture des tests supérieur à la moyenne, accompagné de notes de potentiel d'exploitabilité et d'impact supérieur à la moyenne. Cette catégorie est un exemple où les membres de la communauté sécurité nous indiquent que cette catégorie est importante, même si cela ne transparaît pas encore dans les données.

Méthodologie Copy Chapter

Cette version du Top 10 est bien plus basée sur des données que les précédentes, mais elle n'est pas pour autant aveuglée par celles-ci. Parmi les dix catégories, huit proviennent des données fournies et les deux dernières proviennent d'une enquête à haut niveau auprès de la communauté. Nous faisons ceci pour une raison fondamentale, observer les données consiste à observer le passé. Les chercheurs en sécurité s'investissent pour trouver de nouvelles vulnérabilités et de nouveaux moyens pour les détecter. Un temps certain est nécessaire pour intégrer ces tests au sein des outils et des processus. Au moment où nous pouvons tester ces vulnérabilités à l'échelle, des années se sont bien souvent écoulées. Pour équilibrer cette approche, nous avons utilisé une enquête communautaire pour demander aux experts en sécurité applicative et en développement, en première ligne, ce qu'ils constatent comme failles essentielles, que les données pourraient ne pas encore montrer.

Nous avons adopté quelques changements importants pour continuer à faire mûrir le Top 10.

Comment les catégories sont structurées Copy Chapter

Quelques catégories ont changé depuis la précédente édition de l'OWASP Top Ten. Voici ici un bref résumé des changements.

Les précédentes collectes de données étaient concentrées sur un sous ensemble d'approximativement 30 CWEs accompagnées d'un champ demandant des découvertes complémentaires. Nous avons appris que les organisations se concentraient sur les seules 30 CWEs et n'ajoutaient que rarement d'autres CWEs qu'elles rencontraient. Dans cette édition, nous nous sommes contentés de demander des données, sans aucune restriction sur les CWEs. Nous avons demandé le nombre d'applications testées pour une année donnée (à partir de 2017), et le nombre d'applications avec au moins une instance d'une CWE trouvée lors des tests. Ce format nous permet de déterminer la prévalence de chaque CWE au sein des applications. Nous ignorons la fréquence pour nos besoins ; bien que cela pourrait être nécessaire dans d'autres situations, cela cache la prévalence au sein du panel. Qu'une application ait quatre instances d'une CWE ou 4 000 ne fait pas partie du calcul du Top 10. Nous sommes passés d'approximativement 30 CWEs à près de 400 CWEs à analyser dans le jeu de données. Nous prévoyons d'ajouter des analyses complémentaires dans le futur. Cette augmentation significative dans le nombre de CWEs nécessite des changements dans la façon dont les catégories sont structurées.

Nous avons passé plusieurs mois à regrouper et catégoriser les CWEs. Nous aurions pu continuer encore pendant des mois. Nous avons dû nous arrêter à un moment donné. Il existe à la fois des CWEs de type cause racine et symptôme, où les types cause racine sont de la forme "Défaillances cryptographiques" et "Mauvaise configuration", en contraste avec les types symptôme tels que "Exposition de données sensibles" et "Déni de service". Nous avons décidé de nous concentrer sur les types cause racine autant que possible car ils sont plus logiques pour fournir des conseils d'identification et de remédiation. Se concentrer sur la cause racine plutôt que le symptôme n'est pas un concept nouveau ; le Top 10 a été un mélange de symptômes et de causes racines. Les CWEs le sont également ; nous faisons ce choix délibérément et lançons un appel à ce sujet. Il y a une moyenne de 19,6 CWEs par catégorie dans cette édition, avec un minimum d'1 CWE pour A10:2021-Falsification de requête côté serveur et un maximum de 40 CWEs pour A04:2021-Conception non sécurisée. Cette nouvelle organisation de catégories apporte des avantages pour les formations, les sociétés peuvent se concentrer sur les CWEs les plus pertinentes pour un langage ou un framework.

Comment les données ont été utilisées pour sélectionner les catégories Copy Chapter

En 2017, nous avons sélectionné les catégories à partir du taux d'incidence pour déterminer la probabilité, puis les avons classées via des discussions en équipe basées sur des décennies d'expérience sur des critères d'Exploitabilité, Détectabilité (également probabilité) et Impact technique. Pour 2021, nous souhaitons, si possible, utiliser des données pour Exploitabilité et Impact (technique).

Nous avons téléchargé OWASP Dependency Check et extrait les scores CVSS d'exploitabilité et d'impact agrégés par CWE connexes. Cela a nécessité un temps de recherche significatif, car toutes les CVEs ont un score CVSSv2, mais celui-ci possède des défauts que CVSSv3 devrait corriger. Après un certain temps, toutes les CVEs reçoivent également un score CVSSv3. De plus, les plages de notation et les formules ont été mises-à-jour entre CVSSv2 et CVSSv3.

En CVSSv2, Exploitabilité et Impact (technique) peuvent atteindre 10, mais la formule les ramène à 60 % pour Exploitabilité et 40 % pour Impact. En CVSSv3, le maximum théorique est limité à 6,0 pour Exploitabilité et 4,0 pour Impact. Avec la pondération prise en compte, le score d'impact a augmenté, de près d'un point et demi en moyenne dans CVSSv3, et l'exploitabilité a baissé de près d'un demi-point en moyenne.

Il y a 125 000 enregistrements d'une CVE associée à une CWE dans les données de la National Vulnerability Database (NVD) extraites d'OWASP Dependency Check, et il y a 241 CWE uniques associées à une CVE. 62 000 enregistrements ont un score CVSSv3, ce qui représente environ la moitié des données.

Pour le Top Ten 2021, nous avons calculé les scores moyens d'exploitabilité et d'impact de la manière suivante. Nous avons regroupé toutes les CVEs avec des scores CVSS par CWE et pondéré à la fois exploitabilité et impact notés par le pourcentage de la population qui disposait d'un score CVSSv3, plus la population restante de scores CVSSv2 pour obtenir une moyenne globale. Nous avons associé ces moyennes aux CWEs de l'ensemble de données à utiliser comme notes d'Exploitabilité et d'Impact (technique) pour l'autre moitié de l'équation de risque.

Pourquoi ne pas se reposer uniquement sur des données statistiques ? Copy Chapter

Les résultats obtenus à partir des données sont principalement limités à ce que nous pouvons tester de manière automatisée. Parlez à un professionnel chevronné de la sécurité, il vous parlera de ce qu'il trouve et des tendances qu'il observe qui ne sont pas encore dans les données. Il faut du temps aux gens pour développer des méthodologies de test pour certains types de vulnérabilités, puis plus de temps pour que ces tests soient automatisés et exécutés sur un grand nombre d'applications. Tout ce que nous trouvons sont des vestiges du passé qui pourraient manquer les tendances de l'année écoulée, qui ne sont pas présentes dans les données.

Par conséquent, nous ne sélectionnons que huit catégories sur dix à partir des données, car elles sont incomplètes. Les deux autres catégories proviennent de l'enquête communautaire Top 10. Cela permet aux praticiens en première ligne de voter pour ce qu'ils considèrent comme les risques les plus élevés qui pourraient ne pas être représentés par les données (et qui pourraient ne jamais être exprimés par les données).

Pourquoi le taux d'incidence au lieu de la fréquence ? Copy Chapter

Il y a trois sources principales de données. Nous les identifions comme étant l'outillage assisté par l'homme (OaH), l'homme assisté par l'outil (HaO) et l'outillage brut.

L'outillage et l'OaH sont des générateurs de recherche à haute fréquence. Les outils cherchent des vulnérabilités spécifiques, tentent inlassablement de trouver chaque instance de cette vulnérabilité et génèrent un nombre élevé de découvertes pour certains types de vulnérabilité. Prenez Cross-Site Scripting, qui est généralement l'une de ces deux variantes : il s'agit soit d'une erreur mineure et isolée, soit d'un problème systémique. Lorsqu'il s'agit d'un problème systémique, le nombre de constatations peut se chiffrer par milliers pour une seule application. Cette fréquence élevée noie la plupart des autres vulnérabilités trouvées dans les rapports ou les données.

L'HaO, d'autre part, trouvera une gamme plus large de types de vulnérabilités mais à une fréquence beaucoup plus faible en raison de contraintes de temps. Lorsque les humains testent une application et détectent une vulnérabilité comme Cross-Site Scripting, ils trouveront généralement trois ou quatre instances et s'arrêteront. Ils peuvent déterminer une découverte systémique et la rédiger avec une recommandation à corriger à l'échelle de l'application. Il n'y a pas de besoin (ou de temps) de trouver chaque instance.

Supposons que nous prenions ces deux ensembles de données distincts et essayions de les fusionner en se basant sur la fréquence. Dans ce cas, les données d'outillage et d'OaH noieront les données HaO plus précises (mais plus larges) et expliquent en grande partie pourquoi une catégorie comme Cross-Site Scripting a été si bien classée dans de nombreuses listes alors que l'impact est généralement faible à modéré. C'est à cause du volume considérable de résultats. Le Cross-Site Scripting est également assez facile à tester, il y a donc beaucoup plus de tests pour cela.

En 2017, nous avons introduit le taux d'incidence pour jeter un nouveau regard sur les données et fusionner proprement les données d'outillage et d'OaH avec les données d'HaO. Le taux d'incidence demande quel pourcentage de la population d'applications avait au moins une instance d'un type de vulnérabilité. Peu nous importe si c'était ponctuel ou systémique. Ce n'est pas pertinent pour nos fins ; nous avons seulement besoin de savoir combien d'applications ont eu au moins une instance, ce qui permet de fournir une vue plus claire des résultats des tests sur plusieurs types de tests sans noyer les données dans des résultats à haute fréquence. Cela correspond à une vue liée au risque, car un attaquant n'a besoin que d'une seule instance pour attaquer une application avec succès via la catégorie.

Quel est votre processus de collecte et d'analyse des données ? Copy Chapter

Nous avons formalisé le processus de collecte de données de l'OWASP Top 10 lors de l'Open Security Summit en 2017. Les dirigeants de l'OWASP Top 10 et la communauté ont passé deux jours à formaliser un processus de collecte de données transparent. Cette méthodologie est utilisée pour la seconde fois lors de l'édition 2021.

Nous publions un appel à données via les canaux de réseaux sociaux à notre disposition, à la fois au niveau du projet et de l'OWASP. Sur la page du projet sur le site de l'OWASP, nous listons les éléments de données et la structure que nous recherchons et comment les soumettre. Dans le projet GitHub, nous avons des exemples de fichiers qui servent de modèles. Nous travaillons avec des organisations au besoin pour aider à comprendre la structure et la correspondance avec les CWEs.

Nous obtenons des données d'organisations spécialisées dans l'audit de sécurité, de plateformes de bug bounty et d'organisations qui fournissent des données de tests internes. Une fois que nous avons les données, nous les chargeons ensemble et effectuons une analyse fondamentale de quelles CWEs sont associées aux catégories de risque. Il existe un chevauchement entre certaines CWEs et d'autres sont très étroitement liées (par exemple, les vulnérabilités cryptographiques). Toutes les décisions liées aux données brutes soumises sont documentées et publiées pour être ouvertes et transparentes avec la façon dont nous avons normalisé les données.

Nous examinons les huit catégories avec les taux d'incidence les plus élevés pour l'inclusion dans le Top 10. Nous examinons également les résultats de l'enquête communautaire Top 10 pour voir lesquels peuvent déjà être présents dans les données. Les deux premiers votes qui ne sont pas déjà présents dans les données seront sélectionnés pour les deux autres places du Top 10. Une fois les dix sélectionnées, nous avons appliqué des facteurs généralisés pour l'exploitabilité et l'impact ; pour aider à classer le Top 10 2021 dans un ordre basé sur les risques.

Facteurs des données Copy Chapter

Des facteurs sont répertoriés pour chacune des 10 principales catégories, voici ce qu'ils signifient :

• CWEs associées : le nombre de CWEs associées à une catégorie par l'équipe du Top 10.
• Taux d'incidence : le taux d'incidence est le pourcentage d'applications vulnérables à cette CWE parmi la population testée par cette organisation pour cette année.
• Couverture (Test) : Le pourcentage d'applications testées par toutes les organisations pour une CWE donnée.
• Exploitation pondérée : le sous-score Exploitation des scores CVSSv2 et CVSSv3 attribués aux CVEs associées aux CWEs, normalisés et placés sur une échelle de 10 points.
• Impact pondéré : le sous-score d'impact des scores CVSSv2 et CVSSv3 attribués aux CVEs associées aux CWEs, normalisés et placés sur une échelle de 10 points.
• Nombre total d'occurrences : nombre total d'applications trouvées pour lesquelles les CWEs sont associées à une catégorie.
• Nombre total de CVEs : nombre total de CVEs dans la base de données NVD qui ont été associées aux CWEs associées à une catégorie.

Merci à nos contributeurs de données Copy Chapter

Les organisations suivantes (ainsi que certains donateurs anonymes) ont aimablement fait don des données de plus de 500 000 applications pour en faire l'ensemble de données de sécurité des applications le plus vaste et le plus complet. Sans vous, cela ne serait pas possible.

• AppSec Labs
• Cobalt.io
• Contrast Security
• GitLab
• HackerOne
• HCL Technologies
• Micro Focus
• PenTest-Tools
• Probely
• Sqreen
• Veracode
• WhiteHat (NTT)

Merci à notre sponsor Copy Chapter

L'équipe de l'OWASP Top 10 2021 remercie le soutien financier de Secure Code Warrior et Just Eat.

{ width="256" }

{ width="256" }

2021 Docs Id Index (`2021/docs/id/index.md`) Copy Section

Pengantar

Selamat datang ke OWASP Top 10 - 2021 Copy Chapter

{:class="img-responsive"}

Selamat datang ke versi terakhir dari OWASP Top 10! OWASP Top 10 2021 semua baru, dengan desain grafis baru dan suatu infografis satu-halaman yang dapat Anda cetak atau dapatkan dari beranda kami.

Terima kasih sebesar-besarnya ke semua orang yang menyumbangkan waktu dan data mereka ke iterasi ini. Tanpa Anda, versi ini tidak akan ada. TERIMA KASIH

Apa yang berubah di Top 10 untuk 2021 Copy Chapter

Terdapat tiga kategori baru, empat kategori dengan penamaan dan perbuahan ruang lingkup, dan beberapa konsolidasi baru di Top 10 untuk 2021

• A01:2021-Broken Access Control naik dari posisi kelima; 94% dari aplikasi yang telah diuji dengan broken access kontrol dalam beberapa bentuk. 34 CWE yang dipetakan ke Broken Access Control memiliki lebih banyak kemunculan dalam aplikasi daripada kategori lainnya.
• A02:2021-Cryptographic Failures menggeser satu posisi menjadi #2, sebelumnya dikenal sebagai Pengungkapan Data Sensitif, yang merupakan gejala luas dan bukan penyebab utama. Fokus baru di sini adalah pada kegagalan yang terkait dengan Kriptografi yang sering mengarah pada Pengungkapan Data Sensitif atau sistem yang telah terinfeksi oleh hacker.
• A03:2021-Injection turun ke posisi ketiga. 94% aplikasi diuji untuk beberapa bentuk injeksi, dan 33 CWE yang dipetakan ke dalam kategori ini memiliki kejadian terbanyak kedua dalam aplikasi. Skrip cross-site sekarang menjadi bagian dari kategori ini dalam edisi ini.
• A04:2021-Insecure Design adalah kategori baru untuk tahun 2021, dengan fokus pada resiko yang terkait dengan kekurangan desain. Jika kita ingin benar-benar bergerak sebagai industri, itu membutuhkan lebih banyak penggunaan pemodelan ancaman, pola dan desain yang aman, dan arsitektur referensi
• A05:2021-Security Misconfiguration naik dari #6 di edisi sebelumnya; 90% aplikasi diuji untuk beberapa bentuk kesalahan konfigurasi. Dengan lebih banyak perubahan ke software dengan konfigurasi yang banyak, tidak mengherankan melihat kategori ini naik. Kategori sebelumnya untuk XML External Entities (XXE) sekarang menjadi bagian dari kategori ini.
• A06:2021-Vulnerable and Outdated Components sebelumnya berjudul Using Components with Known Vulnerabilities dan #2 dalam survei industri, tapi juga memiliki cukup data untuk masuk TOP 10 melalui analisis data. Kategori ini naik dari #9 di tahun 2017 dan merupakan masalah umum yang kami perjuangkan untuk menguji dan menilai resiko. Ini adalah satu-satunya kategori yang tidak memiliki CVE yang dipetakan ke CWE yang disertakan, jadi eksploitasi default dan bobot dampak 5.0 diperhitungkan dalam skornya.
• A07:2021-Identification and Authentication Failures sebelumnya dalah Broken Authentication dan turun dari posisi kedua, dan sekarang termasuk CWE yang lebih terkait dengan kegagalan identifikasi. Kategori ini masih merupakan bagian integral dari Top 10, tetapi peningkatan ketersediaan framework yang telah distandarisasi tampaknya membantu.
• A08:2021-Software and Data Integrity Failures adalah kategori baru untuk tahun 2021, yang berfokus pada pembuatan asusmsi terkait pembaruan perangkat lunak, data penting, dan pipeline CI/CD tanpa memverifikasi integritas. Salah satu dampak tertinggi dari CVE/CVSS yang dipetakan ke 10 CWE dalam kategori ini. Insecure Deserialization dari tahun 2017 sekarang menjadi bagian dari kategori yang lebih besar ini.
• A09:2021-Security Logging and Monitoring Failures sebelumnya Logging dan Monitoring tidak memadai dan ditambahkan dari survei industri (#3), naik dari #10 sebelumnya. Kategori ini diperluas untuk mencakup lebih banyak jenis kegagalan, suatu tantangan untuk diiuji, dan tidak terwakili dengan baik dalam data CVE/CVSS. Namun, kegagalan dalam kategori ini dapat secara langsung mempengaruhi visibilitas, alert pada insiden, dan forensik
• A10:2021-Server-Side Request Forgery ditambahkan dari survei industri (#1). Data menunjukkan tingkat insiden yang relatif rendah dengan cakupan pengujian di atas rata-rata, bersama dengan peringkat di atas rata-rata untuk potensi eksploitasi dan dampak. Kategori ini mewakili skenario di mana para profesional industri memberi tahu kami bahwa ini penting, meskipun tidak diilustrasikan dalam data saat ini.

Metodologi Copy Chapter

Penyusunan dari Top 10 ini lebih didorong oleh data daripada sebelumnya tetapi tidak didorong oleh data yang tidak di verifikasi dahulu. Kami memilih delapan dari sepuluh kategori dari kontribusi data dan 2 kategori dari survei industri tingkat tinggi. Kami melakukan ini karena alasan mendasar, melihat data yang telah dikumpulkan sama dengan melihat ke masa lalu. Peneliti AppSec membutuhkan waktu untuk menemukan kerentanan baru dan cara baru untuk mengujinya. Dibutuhkan waktu untuk mengintegrasikan tes ini ke dalam alat dan proses. Pada saat kita dapat dengan andal menguji kelemahan dalam skala, tahun-tahun kemungkinan telah berlalu. Untuk menyeimbangkan pandangan itu, kami menggunakan survei industri untuk bertanya kepada orang-orang di garis depan apa yang mereka lihat sebagai kelemahan penting yang mungkin belum ditunjukkan oleh data.

Ada beberapa perubahan penting yang kami adopsi untuk terus mematangkan Top 10.

Bagaimana kategori disusun Copy Chapter

Beberapa kategori telah berubah dari pemasangan OWASP Top 10 sebelumnya. Berikut adalah ringkasan tingkat tinggi dari perubahan kategori

Upaya pengumpulan data sebelumnya difokuskan pada subset yang ditentukan sekitar 30 CWE dengan bidang yang meminta temuan tambahan. Kami mengetahui bahwa organisasi akan fokus hanya pada 30 CWE tersebut dan jarang menambahkan CWE tambahan yang mereka lihat. Dalam iterasi ini, kami membukanya dan hanya meminta data, tanpa batasan pada CWE. Kami meminta jumlah aplikasi yang diuji untuk tahun tertentu (mulai 2017), dan jumlah aplikasi dengan setidaknya satu contoh CWE yang ditemukan dalam pengujian. Format ini memungkinkan kami untuk melacak seberapa lazim setiap CWE dalam populasi aplikasi. Kami mengabaikan frekuensi untuk tujuan kami; sementara mungkin diperlukan untuk situasi lain, itu hanya menyembunyikan prevalensi aktual dalam populasi aplikasi. Apakah sebuah aplikasi memiliki empat instans CWE atau 4.000 instans bukanlah bagian dari perhitungan untuk 10 Besar. Kami beralih dari sekitar 30 CWE menjadi hampir 400 CWE untuk dianalisis dalam kumpulan data. Kami berencana untuk melakukan analisis data tambahan sebagai suplemen di masa depan. Peningkatan jumlah CWE yang signifikan ini memerlukan perubahan pada struktur kategori.

Kami menghabiskan beberapa bulan untuk mengelompokkan dan mengkategorikan CWE dan dapat melanjutkannya selama beberapa bulan lagi. Kami harus berhenti di beberapa titik. Ada akar penyebab dan jenis gejala CWE, di mana jenis akar penyebab seperti "Kegagalan Kriptografis" dan "Kesalahan Konfigurasi" kontras dengan jenis gejala seperti "Pengungkapan Data Sensitif" dan "Penolakan Layanan." Kami memutuskan untuk fokus pada akar penyebab bila memungkinkan karena lebih logis untuk memberikan panduan identifikasi dan perbaikan. Berfokus pada akar penyebab di atas gejala bukanlah konsep baru; Sepuluh Besar telah menjadi campuran gejala dan akar penyebab. CWE juga merupakan campuran dari gejala dan akar penyebab; kami hanya menjadi lebih berhati-hati tentang hal itu dan menyebutnya. Ada rata-rata 19,6 CWE per kategori dalam pemasangan ini, dengan batas bawah pada 1 CWE untuk A10:2021-Server-Side Request Forgery (SSRF) hingga 40 CWE dalam A04:2021-Insecure Design. Struktur kategori yang diperbarui ini menawarkan manfaat pelatihan tambahan karena perusahaan dapat fokus pada CWE yang masuk akal untuk bahasa/kerangka kerja.

Bagaimana data digunakan untuk memilih kategori Copy Chapter

Pada tahun 2017, kami memilih kategori berdasarkan tingkat insiden untuk menentukan kemungkinan, lalu memeringkatnya berdasarkan diskusi tim berdasarkan pengalaman puluhan tahun untuk Exploitability, Detectability (juga kemungkinan), dan Dampak Teknis. Untuk tahun 2021, kami ingin menggunakan data untuk Exploitability and Impact jika memungkinkan.

Kami mengunduh Pemeriksaan Ketergantungan OWASP dan mengekstrak Eksploitasi CVSS, dan skor Dampak yang dikelompokkan berdasarkan CWE terkait. Butuh sedikit riset dan usaha karena semua CVE memiliki skor CVSSv2, tetapi ada kekurangan dalam CVSSv2 yang harus diatasi oleh CVSSv3. Setelah titik waktu tertentu, semua CVE juga diberi skor CVSSv3. Selain itu, rentang penilaian dan formula diperbarui antara CVSSv2 dan CVSSv3.

Di CVSSv2, Eksploitasi dan Dampak bisa mencapai 10,0, tetapi rumusnya akan menjatuhkannya hingga 60% untuk Eksploitasi dan 40% untuk Dampak. Di CVSSv3, maks secara teori dibatasi hingga 6,0 untuk Eksploitasi dan 4,0 untuk Dampak. Dengan mempertimbangkan pembobotan, skor Dampak bergeser lebih tinggi, rata-rata hampir satu setengah poin di CVSSv3, dan kemampuan eksploitasi turun rata-rata hampir setengah poin.

Ada 125 ribu catatan CVE yang dipetakan ke CWE dalam data NVD yang diekstraksi dari OWASP Dependency Check, dan ada 241 CWE unik yang dipetakan ke CVE. Peta CWE 62 ribu memiliki skor CVSSv3, yang kira-kira setengah dari populasi dalam kumpulan data.

Untuk Top 10, kami menghitung rata-rata skor eksploitasi dan dampak dengan cara berikut. Kami mengelompokkan semua CVE dengan skor CVSS berdasarkan CWE dan memberi bobot pada skor eksploitasi dan dampak berdasarkan persentase populasi yang memiliki skor CVSSv3 + populasi yang tersisa dari skor CVSSv2 untuk mendapatkan rata-rata keseluruhan. Kami memetakan rata-rata ini ke CWE dalam kumpulan data untuk digunakan sebagai skor Eksploitasi dan Dampak untuk separuh persamaan risiko lainnya.

Kenapa tidak hanya bersumber dari data statistik murni? Copy Chapter

Hasil dalam data utamanya terbatas pada apa yang dapat kami uji secara otomatis. Bicaralah dengan seorang Profesional AppSec, dan mereka akan memberi tahu Anda tentang hal-hal yang mereka temukan dan tren yang mereka lihat yang belum ada dalam data. Dibutuhkan waktu bagi orang untuk mengembangkan metodologi pengujian untuk jenis kerentanan tertentu dan kemudian lebih banyak waktu agar pengujian tersebut diotomatisasi dan dijalankan terhadap populasi aplikasi yang besar. Semua yang kami temukan adalah melihat kembali ke masa lalu dan mungkin kehilangan tren dari tahun lalu, yang tidak ada dalam data.

Oleh karena itu, kami hanya memilih delapan dari sepuluh kategori dari data karena tidak lengkap. Dua kategori lainnya berasal dari survei industri. Hal ini memungkinkan para praktisi di garis depan untuk memilih apa yang mereka lihat sebagai risiko tertinggi yang mungkin tidak ada dalam data (dan mungkin tidak pernah diungkapkan dalam data).

Mengapa tingkatan insiden bukan bersumber dari frekuensi? Copy Chapter

Ada tiga sumber data utama. Kami mengidentifikasi mereka sebagai Human-assisted Tooling (HaT), Tool-assisted Human (TaH), dan raw Tooling.

Tooling dan HaT adalah generator pencarian frekuensi tinggi. Alat akan mencari kerentanan tertentu dan tanpa lelah berusaha untuk menemukan setiap contoh kerentanan itu dan akan menghasilkan jumlah temuan yang tinggi untuk beberapa jenis kerentanan. Lihatlah Cross-Site Scripting, yang biasanya merupakan salah satu dari dua rasa: itu kesalahan kecil yang terisolasi atau masalah sistemik. Jika ini merupakan masalah sistemik, jumlah temuan bisa mencapai ribuan untuk sebuah aplikasi. Frekuensi tinggi ini menenggelamkan sebagian besar kerentanan lain yang ditemukan dalam laporan atau data.
TaH, di sisi lain, akan menemukan jenis kerentanan yang lebih luas tetapi pada frekuensi yang jauh lebih rendah karena kendala waktu. Ketika manusia menguji aplikasi dan melihat sesuatu seperti Cross-Site Scripting, mereka biasanya akan menemukan tiga atau empat instance dan berhenti. Mereka dapat menentukan temuan sistemik dan menuliskannya dengan rekomendasi untuk diperbaiki pada skala aplikasi yang luas. Tidak perlu (atau waktu) untuk menemukan setiap contoh.

Misalkan kita mengambil dua kumpulan data yang berbeda ini dan mencoba menggabungkannya pada frekuensi. Dalam hal ini, data Tooling dan HaT akan menenggelamkan data TaH yang lebih akurat (tetapi luas) dan merupakan bagian yang baik dari mengapa sesuatu seperti Cross-Site Scripting memiliki peringkat yang sangat tinggi di banyak daftar ketika dampaknya umumnya rendah hingga sedang. Itu karena banyaknya temuan. (Cross-Site Scripting juga cukup mudah untuk diuji, jadi ada lebih banyak tes untuk itu juga).
Pada tahun 2017, kami memperkenalkan penggunaan tingkat insiden sebagai gantinya untuk melihat data baru dan menggabungkan data Tooling dan HaT dengan data TaH dengan rapi. Tingkat insiden menanyakan berapa persentase populasi aplikasi yang memiliki setidaknya satu contoh jenis kerentanan. Kami tidak peduli apakah itu satu kali atau sistemik. Itu tidak relevan untuk tujuan kita; kita hanya perlu mengetahui berapa banyak aplikasi yang memiliki setidaknya satu instance, yang membantu memberikan pandangan yang lebih jelas tentang pengujian temuan di beberapa jenis pengujian tanpa menenggelamkan data dalam hasil frekuensi tinggi.

Apa proses pengumpulan dan analisis data Anda? Copy Chapter

Kami meresmikan proses pengumpulan data OWASP Top 10 di Open Security Summit pada 2017. Para Leader OWASP Top 10 dan komunitas telah menghabiskan dua hari untuk memformalkan proses pengumpulan data yang transparan. Edisi 2021 adalah kedua kalinya kami menggunakan metodologi ini.
Kami mempublikasikan panggilan untuk data melalui saluran media sosial yang tersedia untuk kami, baik projek maupun OWASP. Pada halaman Projek OWASP, kami mencantumkan elemen dan struktur data yang kami cari dan cara mengirimkannya. Dalam proyek GitHub, kami memiliki file contoh yang berfungsi sebagai template. Kami bekerja dengan organisasi yang diperlukan untuk membantu mengetahui struktur dan pemetaan ke CWE.
Kami mendapatkan data dari organisasi yang menguji vendor berdasarkan perdagangan, vendor bug bounty, dan organisasi yang menyumbangkan data pengujian internal. Setelah kami memiliki data, kami memuatnya bersama dan menjalankan analisis fundamental tentang apa yang dipetakan CWE ke kategori risiko. Ada tumpang tindih antara beberapa CWE, dan yang lainnya sangat erat kaitannya (mis. Kerentanan kriptografis). Setiap keputusan yang terkait dengan data mentah yang dikirimkan didokumentasikan dan dipublikasikan agar terbuka dan transparan dengan cara kami menormalkan data.

Kami melihat delapan kategori dengan tingkat insiden tertinggi untuk dimasukkan dalam Top 10. Kami juga melihat hasil survei industri untuk melihat mana yang mungkin sudah ada dalam data. Dua suara teratas yang belum ada dalam data akan dipilih untuk dua tempat lainnya di Top 10. Setelah kesepuluh dipilih, kami menerapkan faktor umum untuk eksploitabilitas dan dampak; untuk membantu menentukan peringkat 10 Besar secara berurutan.

Faktor-faktor Data Copy Chapter

Ada data faktor yang dicantumkan untuk masing-masing dari 10 Kategori Teratas, berikut artinya:

• CWEs Mapped: Jumlah CWE yang dipetakan ke kategori oleh 10 tim teratas.
• Incidence Rate: Tingkat insiden adalah persentase aplikasi yang rentan terhadap CWE tersebut dari populasi yang diuji oleh organisasi tersebut untuk tahun tersebut.
• (Pengujian) Cakupan: Persentase aplikasi yang diuji oleh semua organisasi untuk CWE tertentu.
• Weighted Exploit: Sub-skor Eksploitasi dari skor CVSSv2 dan CVSSv3 yang ditetapkan ke CVE yang dipetakan ke CWE, dinormalisasi, dan ditempatkan pada skala 10pt.
• Weighted Impact: Sub-skor Dampak dari skor CVSSv2 dan CVSSv3 yang ditetapkan ke CVE dipetakan ke CWE, dinormalisasi, dan ditempatkan pada skala 10pt.
• Total Kejadian: Jumlah total aplikasi yang ditemukan memiliki CWE yang dipetakan ke suatu kategori.
• Total CVE: Jumlah total CVE dalam NVD DB yang dipetakan ke CWE yang dipetakan ke suatu kategori.

Hubungan Kategori dari 2017 Copy Section

Ada banyak pembicaraan tentang tumpang tindih antara risiko Top 10. Menurut definisi masing-masing (daftar CWE yang termasuk), sebenarnya tidak ada tumpang tindih. Namun, secara konseptual, dapat terjadi tumpang tindih atau interaksi berdasarkan penamaan tingkat yang lebih tinggi. Diagram Venn berkali-kali digunakan untuk menunjukkan tumpang tindih seperti ini.

Diagram Venn di atas merepresentasikan interaksi antara Sepuluh Kategori Risiko Teratas 2017. Saat melakukannya, beberapa poin penting menjadi jelas:

1. Orang bisa berargumen bahwa Cross-Site Scripting pada akhirnya termasuk dalam Injeksi karena pada dasarnya adalah Injeksi Konten. Melihat data tahun 2021, semakin jelas bahwa XSS perlu pindah ke Injeksi.
2. Tumpang tindih hanya satu arah. Kita akan sering mengklasifikasikan kerentanan berdasarkan manifestasi akhir atau "gejala", bukan akar penyebab (yang berpotensi dalam). Misalnya, "Pengungkapan Data Sensitif" mungkin merupakan hasil dari "Kesalahan Konfigurasi Keamanan"; namun, Anda tidak akan melihatnya ke arah lain. Akibatnya, panah digambar di zona interaksi untuk menunjukkan arah mana itu terjadi.
3. Terkadang diagram ini digambar dengan semua yang ada di A06:2021 Menggunakan Komponen dengan Kerentanan yang Diketahui. Sementara beberapa kategori risiko ini mungkin menjadi akar penyebab kerentanan pihak ketiga, mereka umumnya dikelola secara berbeda dan dengan tanggung jawab yang berbeda. Jenis lainnya biasanya mewakili risiko pihak pertama.

Terima kasih kepada kontributor data kami Copy Section

Organisasi berikut (bersama dengan beberapa donor anonim) dengan baik hati menyumbangkan data untuk lebih dari 500.000 aplikasi untuk menjadikan ini kumpulan data keamanan aplikasi terbesar dan terlengkap. Tanpa Anda, ini tidak akan mungkin.

• AppSec Labs
• Cobalt.io
• Contrast Security
• GitLab
• HackerOne
• HCL Technologies
• Micro Focus
• PenTest-Tools
• Probely
• Sqreen
• Veracode
• WhiteHat (NTT)

Thank you to our sponsor Copy Chapter

The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior.

2021 Docs It Index (`2021/docs/it/index.md`) Copy Section

Introduzione alla OWASP Top 10 2021

Vi presentiamo la OWASP Top 10 - 2021 Copy Chapter

{:class="img-responsive"}

Ecco a voi l'ultima versione della OWASP Top 10! La OWASP Top 10 2021 è tutta nuova, con un nuovo design grafico e un'infografica di una pagina che potete stampare o scaricare dalla nostra home page.

Un enorme grazie a tutti coloro che hanno contribuito con il loro tempo e i loro dati per questa versione. Senza di voi, tutto questo non sarebbe stato possibile. GRAZIE!

Cosa è cambiato nella Top 10 2021 Copy Chapter

Ci sono tre nuove categorie, quattro categorie con cambiamenti nella denominazione e nello scopo, e alcuni consolidamenti nella Top 10 per il 2021. Quando necessario abbiamo cambiato i nomi per concentrarci più sulla causa principale anzichè sui sintomi.

• A01:2021-Broken Access Control sale dalla quinta posizione alla categoria con il più grave rischio per la sicurezza delle applicazioni web; i dati analizzati indicano che in media, il 3,81% delle applicazioni testate aveva una o più Common Weakness Enumerations (CWEs) con più di 318k occorrenze di CWEs in questa categoria di rischio. Le 34 CWE che corrispondevano a Broken Access Control avevano più occorrenze di qualsiasi altra categoria.
• A02:2021-Cryptographic Failures si sposta di una posizione alla #2, precedentemente nota come A3:2017-Sensitive Data Exposure, che era un sintomo generico piuttosto che la causa principale. Il nome rinnovato si concentra sulle problematiche relative alla crittografia come è stato prima, ma implicitamente. Questa categoria porta spesso all'esposizione di dati sensibili o alla compromissione del sistema.
• A03:2021-Injection scivola in terza posizione. Il 94% delle applicazioni è stato testato per qualche forma di injection con un tasso di incidenza massimo del 19%, un tasso di incidenza medio del 3,37%, e le 33 CWE che corrispondevano a questa categoria hanno il secondo maggior numero di occorrenze nelle applicazioni, con 274k. In questa edizione il Cross-site Scripting fa parte di questa categoria.
• A04:2021-Insecure Design è una nuova categoria per il 2021, con un focus sui rischi relativi ai difetti di progettazione. Se vogliamo veramente "spostarci a sinistra" come industria, abbiamo bisogno di più threat modeling, secure design patterns e architetture di riferimento. Un design insicuro non può essere corretto con un'implementazione perfetta, poiché per definizione i controlli di sicurezza necessari non sono mai stati creati per difendersi da attacchi specifici.
• A05:2021-Security Misconfiguration sale dal numero 6 dell'edizione precedente; il 90% delle applicazioni è stato testato per qualche forma di misconfigurazione, con un tasso di incidenza medio del 4,5% e oltre 208k casi di CWE corrispondenti a questa categoria di rischio. Con una tendenza al software altamente configurabile, non è sorprendente vedere questa categoria salire. La precedente categoria per A4:2017-XML External Entities (XXE) è ora parte di questa categoria di rischio.
• A06:2021-Vulnerable and Outdated Components era precedentemente intitolata "Using Components with Known Vulnerabilities" ed è #2 nel sondaggio della comunità Top 10, ma aveva anche abbastanza numeri per far parte della Top 10 grazie ai dati raccolti e analizzati. Questa categoria sale dalla #9 del 2017 ed è un problema noto per cui facciamo fatica a testare e a valutarne il rischio. È l'unica categoria a non avere alcun Common Vulnerability and Exposures (CVE) corrispondente alle CWE incluse, quindi nel punteggio è stato inserito un peso predefinito per sfruttabilità e impatto di 5.0.
• A07:2021-Identification and Authentication Failures era precedentemente nota come "Broken Authentication" e sta scivolando giù dalla seconda posizione, e ora include CWEs che sono più legate a problematiche di identificazione. Questa categoria è ancora parte integrante della Top 10, ma la maggiore diffusione di framework standard sembra aiutare.
• A08:2021-Software and Data Integrity Failures è una nuova categoria per il 2021, che si concentra sul fare ipotesi relative agli aggiornamenti del software, ai dati critici e alle pipeline CI/CD senza verificare l'integrità. Uno dei più alti impatti ponderati dai dati di Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) è stato messo in corrispondenza alle 10 CWE di questa categoria. A8:2017-Insecure Deserialization fa ora parte di questa categoria più ampia.
• A09:2021-Security Logging and Monitoring Failures era precedentemente A10:2017-Insufficient Logging & Monitoring e viene aggiunto dal sondaggio della comunità Top 10 (#3), passando dalla precedente #10. Questa categoria è stata ampliata per includere più tipi di problematiche, è difficile da testare e non è ben rappresentata nei dati CVE/CVSS. Tuttavia, le problematiche in questa categoria possono avere un impatto diretto sulla visibilità, sull'alerting degli incidenti e sulle attività forensi.
• A10:2021-Server-Side Request Forgery viene aggiunto dal sondaggio della comunità Top 10 (#1). I dati mostrano un tasso di incidenza relativamente basso con una copertura di test superiore alla media, insieme a valutazioni superiori alla media per il potenziale di sfruttabilità e di impatto. Questa categoria rappresenta lo scenario in cui i membri della nostra comunità ci stanno comunicando che è importante, anche se in questo momento non è evidente dai dati.

Metodologia Copy Chapter

Questa versione della Top 10 è più data-driven che mai, ma non ciecamente data-driven. Abbiamo selezionato otto delle dieci categorie dai dati forniti e due categorie dal sondaggio della comunità Top 10. Questo lo facciamo per una ragione fondamentale, guardare i dati forniti è guardare nel passato. I ricercatori nel campo dell'AppSec impiegano tempo per trovare nuove vulnerabilità e nuovi modi per testarle. Ci vuole tempo per integrare questi test negli strumenti e nei processi. Nel momento in cui possiamo testare in modo affidabile una debolezza su larga scala, probabilmente sono passati anni. Per bilanciare questo punto di vista, usiamo un sondaggio comunitario per chiedere agli esperti di sicurezza e sviluppatori di applicazioni in prima linea quali sono le debolezze essenziali che i dati potrebbero non mostrare ancora.

Ci sono alcuni cambiamenti importanti che abbiamo adottato per continuare a migliorare la Top 10.

Come sono strutturate le categorie Copy Chapter

Alcune categorie sono cambiate dalla precedente versione della Top Ten di OWASP. Ecco un riassunto ad alto livello dei cambiamenti relativi alle categorie.

I precedenti sforzi di raccolta dati erano focalizzati su un sottoinsieme prescritto di circa 30 CWE con un campo aperto che ne richiedeva altri. Abbiamo imparato che le organizzazioni si concentravano principalmente solo su quelle 30 CWE e raramente aggiungevano ulteriori CWE che avevano incontrato. In questa iterazione abbiamo chiesto solo dati, senza restrizioni sulle CWE. Abbiamo chiesto il numero di applicazioni testate per un dato anno (a partire dal 2017), e il numero di applicazioni con almeno un'istanza di una CWE trovata nei test. Questo formato ci permette di tracciare quanto sia prevalente ogni CWE all'interno della popolazione delle applicazioni. Per i nostri scopi ignoriamo la frequenza; mentre può essere necessaria per altre situazioni, nasconde solo la reale prevalenza nella popolazione delle applicazioni. Che un'applicazione abbia quattro istanze di una CWE o 4.000 istanze, questo valore non influisce nel calcolo per la Top 10. Siamo passati da circa 30 CWE a quasi 400 CWE da analizzare. In futuro abbiamo in programma di fare ulteriori analisi dei dati come integrazione. Questo aumento significativo del numero di CWE richiede cambiamenti nel modo in cui le categorie sono strutturate.

Abbiamo trascorso diversi mesi a raggruppare e categorizzare le CWE e avremmo potuto continuare per mesi. Ad un certo punto ci siamo dovuti fermare. Ci sono entrambi i tipi di CWE causa principale e sintomo, dove i tipi causa principale sono come "Cryptographic Failures" e "Misconfiguration" in contrasto con i tipi sintomo come "Sensitive Data Exposure" e "Denial of Service". Abbiamo deciso di concentrarci sulla causa principale ogni volta che è possibile, in quanto è più logico per fornire una guida all'identificazione e al rimedio. Concentrarsi sulla causa principale piuttosto che sul sintomo non è un concetto nuovo; la Top Ten è stata un mix di sintomo e causa principale. Anche le CWE sono un mix di sintomo e causa principale; siamo semplicemente più consapevoli di questo e lo diciamo ad alta voce. C'è una media di 19.6 CWE per categoria in questa versione, con i limiti inferiori a 1 CWE per A10:2021-Server-Side Request Forgery (SSRF) a 40 CWE in A04:2021-Insecure Design. Questa struttura aggiornata delle categorie offre ulteriori benefici per la formazione in quanto le aziende possono concentrarsi sulle CWE che hanno senso per un linguaggio/framework.

Come vengono usati i dati per selezionare le categorie Copy Chapter

Nel 2017, abbiamo selezionato le categorie in base al tasso di incidenza per determinare la probabilità, poi le abbiamo classificate in base alla discussione con il team sulla base di decenni di esperienza per Exploitability, Detectability (anche likelihood), e Technical Impact. Per il 2021, vogliamo usare i dati per Exploitability e (Technical) Impact se possibile.

Abbiamo scaricato OWASP Dependency Check ed estratto i punteggi CVSS relativi a Exploit e Impact raggruppati per CWE correlati. Ci sono voluti un bel po' di ricerche e sforzi, poiché tutti i CVE hanno punteggi CVSSv2, ma ci sono problematiche in CVSSv2 che CVSSv3 dovrebbe risolvere. Dopo un certo periodo di tempo, a tutti i CVE viene assegnato anche un punteggio CVSSv3. Inoltre, gli intervalli di punteggio e le formule sono stati aggiornati tra CVSSv2 e CVSSv3.

Nel CVSSv2, sia Exploit che (Technical) Impact potevano essere fino a 10.0, ma la formula li riduceva al 60% per Exploit e al 40% per Impact. Nel CVSSv3, il massimo teorico era limitato a 6.0 per Exploit e 4.0 per Impact. Con la ponderazione considerata, il punteggio di Impact si è spostato più in alto, quasi un punto e mezzo in media in CVSSv3, e l'exploitability si è spostato quasi mezzo punto più in basso in media.

Ci sono 125k record di una CVE corrispondente a una CWE nei dati del National Vulnerability Database (NVD) estratti da OWASP Dependency Check, e ci sono 241 CWE uniche corrispondenti a un CVE. 62k corrispondenze di CWE hanno un punteggio CVSSv3, che è circa la metà della popolazione nel set di dati.

Per la Top Ten 2021, abbiamo calcolato i punteggi medi di Exploit e Impact nel modo seguente. Abbiamo raggruppato tutte le CVE con punteggi CVSS per CWE e ponderato entrambi i punteggi di Exploit e Impact per la percentuale della popolazione che aveva CVSSv3 più la restante popolazione di punteggi CVSSv2 per ottenere una media complessiva. Abbiamo messo in corrispondenza queste medie alle CWE nel dataset da usare come punteggio di Exploit e (Technical) Impact per l'altra metà dell'equazione del rischio.

Perchè non utilizzare dati puramente statistici? Copy Chapter

I risultati nei dati sono principalmente limitati a ciò che possiamo testare in modo automatico. Parlate con un professionista esperto di AppSec e vi racconterà delle vulnerabilità che trova e delle tendenze che vede che non sono ancora visibili nei dati. Ci vuole tempo perché le persone sviluppino metodologie di test per certi tipi di vulnerabilità e poi ancora più tempo perché quei test siano automatizzati ed eseguiti su una vasta popolazione di applicazioni. Tutto ciò che troviamo sta guardando indietro nel passato e potrebbe mancare delle tendenze dell'ultimo anno, che non sono presenti nei dati.

Pertanto, prendiamo solo otto delle dieci categorie dai dati perché sono incompleti. Le altre due categorie provengono dal sondaggio della comunità Top 10. Questo permette ai professionisti in prima linea di votare per ciò che identificano come i rischi più alti che potrebbero non essere ancora visibili nei dati (e potrebbero non essere mai espressi nei dati).

Perchè tasso di incidenza anzichè frequenza? Copy Chapter

Ci sono tre fonti primarie di dati. Le identifichiamo come Human-assisted Tooling (HaT), Tool-assisted Human (TaH), e Tooling grezzo.

Tooling e HaT generano una grande quantità di dati. Gli strumenti cercheranno vulnerabilità specifiche e tenteranno instancabilmente di trovare ogni istanza di quella vulnerabilità e genereranno un numero elevato di risultati per alcuni tipi di vulnerabilità. Guardate il Cross-Site Scripting, che è tipicamente di due tipi: o è un errore piccolo e isolato o un problema sistemico. Quando si tratta di un problema sistemico, il conteggio può essere di migliaia per una singola applicazione. Questa alta frequenza copre la maggior parte delle altre vulnerabilità trovate nei report o nei dati.

TaH, d'altra parte, troverà una gamma più ampia di tipi di vulnerabilità, ma con una frequenza molto più bassa a causa dei vincoli temporali. Quando gli esseri umani testano un'applicazione e identificano problematiche come il Cross-Site Scripting, in genere trovano tre o quattro istanze e si fermano. Possono determinare una scoperta sistemica e scrivere nel report consigli per la correzione della problematica sull'intera applicazione. Non c'è bisogno (o tempo) di trovare ogni istanza.

Supponiamo di prendere questi due insiemi di dati distinti e cercare di unirli ina base alla frequenza. In questo caso, i dati di Tooling e HaT sommergeranno i più accurati (ma ampi) dati TaH ed è una buona parte del motivo per cui qualcosa come Cross-Site Scripting è stato così altamente classificato in molte liste quando l'impatto è generalmente basso o moderato. È a causa dell'enorme volume di risultati. (Il Cross-Site Scripting è anche ragionevolmente facile da testare, quindi ci sono molti più test anche per questo).

Nel 2017, abbiamo introdotto l'uso del tasso di incidenza per dare un nuovo sguardo ai dati e fondere in modo pulito i dati di Tooling e HaT con i dati TaH. Il tasso di incidenza chiede quale percentuale della popolazione di applicazioni ha avuto almeno un'istanza di un tipo di vulnerabilità. Non ci interessa se era una tantum o sistemica. Questo è irrilevante per i nostri scopi; abbiamo solo bisogno di sapere quante applicazioni ne avevano almeno un'istanza, il che aiuta a fornire una visione più chiara dei risultati senza rischiare di inquinare i dati con risultati relativi a problematiche ad alta frequenza. Questo corrisponde a una visione legata al rischio, poiché un attaccante ha bisogno di una sola istanza di una determinata vulnerabilità per attaccare con successo un'applicazione.

Quale è il processo di raccolta e analisi dei dati? Copy Chapter

Abbiamo formalizzato il processo di raccolta dati OWASP Top 10 all'Open Security Summit del 2017. I leader di OWASP Top 10 e la comunità hanno trascorso due giorni a formalizzare un processo di raccolta dati trasparente. Per l'edizione 2021 è la seconda volta che abbiamo usato questa metodologia.

Richiediamo i dati attraverso i canali dei social media a nostra disposizione, sia del progetto che di OWASP. Sulla pagina del progetto OWASP, elenchiamo quali variabili e quale struttura stiamo cercando nei dati e come inviarli. Nela pagina GitHub, abbiamo file di esempio che servono come modelli. Lavoriamo con le organizzazioni, se necessario, per aiutarle a capire la struttura e la correlazione delle relative CWE.

Otteniamo dati da organizzazioni che sono aziende che svolgono test di sicurezza, piattaforme di bug bounty e organizzazioni che contribuiscono con dati di test interni. Una volta che abbiamo i dati, li carichiamo insieme ed eseguiamo un'analisi fondamentale, ovvero la corrispondenza delle CWE alle categorie di rischio. C'è una sovrapposizione tra alcune CWE, e altre sono strettamente correlati (es. vulnerabilità crittografiche). Qualsiasi decisione relativa ai dati grezzi presentati è documentata e pubblicata per essere aperti e trasparenti sul processo di normalizzazione dei dati.

Guardiamo le otto categorie con i più alti tassi di incidenza per l'inclusione nella Top 10. Guardiamo anche i risultati del sondaggio della comunità Top 10 per vedere quali possono essere già presenti nei dati. I primi due voti che non sono già presenti nei dati saranno selezionati per gli altri due posti nella Top 10. Una volta che tutti e dieci sono stati selezionati, abbiamo applicato fattori generici per la sfruttabilità e l'impatto; per produrre una Top 10 2021 in un ordine basato sul rischio.

Etichette dei dati Copy Chapter

Ci sono alcune etichette che sono elencati per ciascuna delle 10 categorie principali, ecco cosa significano:

• CWEs corrispondenti: Il numero di CWE corrispondenti a una categoria dal team Top 10.
• Tasso di incidenza: Il tasso di incidenza è la percentuale di applicazioni vulnerabili a quel CWE dalla popolazione testata da quella org per quell'anno.
• Copertura (di test): La percentuale di applicazioni testate da tutte le organizzazioni per un dato CWE.
• Sfruttabilità pesata: Il sub-score Exploit dai punteggi CVSSv2 e CVSSv3 assegnati ai CVE corrispondenti ai CWE, normalizzati e posizionati su una scala di 10 punti.
• Impatto pesato: Il sub-score di impatto dai punteggi CVSSv2 e CVSSv3 assegnati ai CVE corrispondenti ai CWE, normalizzato e posizionato su una scala di 10 punti.
• Occorrenze totali: Numero totale di applicazioni trovate che hanno i CWE corrispondenti ad una categoria.
• CVE totali: Numero totale di CVE nel DB NVD che sono stati messi in corrispondenza ai CWE relativi a una categoria.

Ringraziamo chi ha contribuito con i dati Copy Chapter

Le seguenti organizzazioni (insieme ad alcuni donatori anonimi) hanno gentilmente donato i dati per oltre 500.000 applicazioni per rendere questo il più grande e completo set di dati sulla sicurezza delle applicazioni. Senza di voi, questo non sarebbe possibile.

• AppSec Labs
• Cobalt.io
• Contrast Security
• GitLab
• HackerOne
• HCL Technologies
• Micro Focus
• PenTest-Tools
• Probely
• Sqreen
• Veracode
• WhiteHat (NTT)

Grazie ai nostri sponsor Copy Chapter

Il team OWASP Top 10 2021 ringrazia il supporto finanziario di Secure Code Warrior e Just Eat.

{ width="256" }

{ width="256" }

2021 Docs Ja Index (`2021/docs/ja/index.md`) Copy Section

導入

OWASP Top 10 - 2021 へようこそ Copy Chapter

{:class="img-responsive"}

OWASP トップ 10 の最新版へようこそ! OWASP トップ 10 2021年版は、グラフィックデザインが一新され、1ページのインフォグラフィックになっています。インフォグラフィックは、ホームページから入手でき、印刷することができます。

今回のトップ10の作成にあたって、貴重な時間やデータを提供してくださったすべての皆さんに感謝します。皆様のご協力なくしては、OWASP トップ 10 2021年版は存在し得ません。本当に、感謝いたします。

2021年版トップ10の変更点 Copy Chapter

2021年版トップ10では、3つの新しいカテゴリー、4つのカテゴリーの名称とスコープの変更がありました。統合されたものもいくつかあります。

• A01:2021-アクセス制御の不備 は、5位から最も深刻なWebアプリケーションのセキュリティリスクへと順位を上げました。貢献されたデータから、平均でテストされたアプリケーションの3.81%が1つ以上の共通脆弱性タイプ一覧（CWE）を持っており、このリスクカテゴリに該当するCWEは 318,000 件以上存在していたことがわかりました。他のカテゴリーに比べ、「アクセス制御の欠陥」にあたる34件のCWEがアプリケーション内で多く発生していました。
• A02:2021-暗号化の失敗 は、ひとつ順位を上げて2位になっています。以前は、A3:2017-機微な情報の露出 と呼ばれていましたが、これは根本的な原因というより幅広くみられる症状と言えます。ここでは、機密データの漏えいやシステム侵害に多く関連する、暗号技術にまつわる失敗に焦点を当てています。
• A03:2021-インジェクション は、3位に下がっています。94%のアプリケーションで何らかのインジェクションに関する問題が確認されています。最大発生率は19%、平均発生率は3.37%であり、このカテゴリにあたる33のCWEは、アプリケーションでの発生数が2番目に多く見られます。発生数は27万4千件でした。今回から、クロスサイトスクリプティングは、このカテゴリに含まれています。
• A04:2021-安全が確認されない不安な設計 は、2021年に新設されたカテゴリーで、設計上の欠陥に関するリスクに焦点を当てています。一業界として、我々が純粋に「シフトレフト」することを望むのであれば、脅威モデリングや、安全な設計パターンと原則、また、リファレンス・アーキテクチャをもっと利用していくことが必要です。 安全が確認されない不安な設計は完璧な実装によって修正されることはありません。定義上、(つまり設計自体が問題なので)特定の攻撃に対して必要なセキュリティ対策が作られることがありえないからです。
• A05:2021-セキュリティの設定ミス は、前回の6位から順位を上げました。アプリケーションの90％に何らかの設定ミスが見られ、インシデントの平均発生率としては4.5%、このリスクカテゴリに該当するCWEは 208,000 件以上存在していたことがわかりました。 高度な設定が可能なソフトウェアへの移行が進む中で、このカテゴリーの順位が上がったことは当然と言えます。以前の、A4:2017-XML 外部エンティティ参照 (XXE) のカテゴリーは、このカテゴリーに含まれています。
• A06:2021-脆弱で古くなったコンポーネント は、以前は「既知の脆弱性のあるコンポーネントの使用」というタイトルでした。この問題は、Top 10コミュニティの調査では2位であり、データ分析によってトップ10に入るだけのデータもありました。このカテゴリーは2017年の9位から順位を上げました。これは、テストやリスク評価に苦労する、よく知られた問題です。また、含まれるCWEにあたる共通脆弱性識別子 (CVE)のない、唯一のカテゴリであるため、デフォルトのエクスプロイトとインパクトの重みは5.0としてスコアに反映されています。
• A07:2021-識別と認証の失敗 は以前、「認証の不備」と呼ばれていましたが、この版では第2位から順位を落とし、識別の失敗に関連するCWEをより多く含む意味合いのカテゴリとなっています。このカテゴリーは依然としてトップ10に示すべき重要な項目ですが、標準化されたフレームワークの利用が進んだことが功を奏しているようです。
• A08:2021-ソフトウェアとデータの整合性の不具合 は、2021年に新設されたカテゴリーで、ソフトウェアの更新、重要なデータを、CI/CDパイプラインにおいて整合性を検証せずに見込みで進めることによる問題にフォーカスしています。共通脆弱性識別子/共通脆弱性評価システム (CVE/CVSS) のデータから最も重大な影響を受けたものの1つが、このカテゴリーの10のCWEにマッピングされています。A8:2017-安全でないデシリアライゼーション は、このカテゴリーの一部となりました。
• A09:2021-セキュリティログとモニタリングの失敗 は、従来はA10:2017-不十分なロギングとモニタリングでしたが、Top 10コミュニティの調査（第3位）から追加され、従来の第10位からランクアップしました。このカテゴリは、より多くの種類の失敗を含むように拡張されています。これは、テストが困難なものであり、かつ、CVE/CVSSのデータにはあまり反映されないものです。とはいえ、このカテゴリーで失敗が起きると、可視性、インシデントアラート、フォレンジックなどに直接影響を与える可能性があります。
• A10:2021-サーバーサイドリクエストフォージェリ(SSRF) は、Top 10コミュニティの調査（第1位）から追加されたものです。調査データからわかることは、よくあるテストより広範な範囲において、問題の発生率は比較的低いものの、問題が起きた場合のエクスプロイトとインパクトは平均以上のものとなり得ます。このカテゴリは、現時点でデータとして現れるものではありませんでしたが、複数の業界の専門家により重要との示唆を得たシナリオとして反映しています。

方法論 Copy Chapter

今回のトップ10は、これまで以上にデータを重視していますが、やみくもにデータを重視しているわけではありません。10項目のうち8項目は提供されたデータから、2項目はTop 10コミュニティの調査から高いレベルで選びました。こうすることにはひとつの根本的な理由があります。提供されたデータを見ることは、過去を見ることを意味している、ということです。アプリケーションセキュリティのリサーチャーが新しい脆弱性や、それをテストする新しい方法を見つけるのには時間がかかります。これらのテストをツールやプロセスに組み込むには時間がかかります。こうした弱点を広く確実にテストできるようになるまでには、何年もかかってしまうことでしょう。そこで、データではわからないような本質的な弱点は何かということについては、業界の第一線で活躍されている方々にお聞きすることでバランスをとる、というわけです。

トップ10を継続的に成熟させるために私たちが採用した、重要な変更点がいくつかあります。

カテゴリの構成について Copy Chapter

前回のOWASP Top 10からいくつかのカテゴリーが変更されています。以下に今回のカテゴリーの変更点を大まかにまとめます。

前回のデータ収集活動は、約30個のCWEからなる規定のサブセットに焦点を当て、追加として現場での調査結果を求めていました。この方法では、現場の組織は、主にこのリクエストした30のCWEだけに焦点を当てて報告をくれることになり、実際に観察したCWEを追加してくれることはまれだということがわかりました。そこで今回は、リクエストするCWEに制限を設けずに、データを提供してもらうことにしました。ある年に（今回は2017年以降）テストしたアプリケーションの数と、テストでCWE登録されている例が1つ以上見つかったアプリケーションの数を出してくれるよう依頼しました。これにより、アプリケーション全体を母集団としてとった上で、それぞれのCWEがどの程度蔓延しているかを把握することができます。

目的を踏まえて、当該CWEの発見頻度については無視しました。頻度は他の状況では必要性があるかもしれませんが、アプリケーションの母集団においては、現実の蔓延率を隠すことになってしまいます。例えば、あるアプリケーションに、ある特定のCWEの脆弱性が4例見つかることもあれば、4,000例見つかることもあるかもしれませんが、その発生頻度はトップ10の計算に影響させないというわけです。こうして、データセットで分析できたCWEは約30個から約400個になりました。今後、私たちは追加のデータ解析を行い、Top 10に補足する計画です。このようにCWEの数が大幅に増えたことで、カテゴリーの構成方法を変更する必要があります。

CWEのグループ化と分類に数ヶ月を費やしました。さらに数ヶ月続けることもできたかもしれませんが、どこかの時点で止めなければなりません。CWEには「根本原因」と「症状」があり、「根本原因」には「暗号の欠陥」や「設定ミス」などがあり、「症状」には「機密データの漏えい」や「サービス妨害」などがあります。そこで私たちは、可能な限り根本的な原因に焦点を当てることにしました。識別と修復のためのガイダンスを提供するのに適しているからです。「症状」ではなく「根本原因」に焦点を当てることは、今に始まったコンセプトではありません。どの版のTop 10も、症状と原因が混在してきました。CWEもまた、「症状」と「根本原因」が混在しています。私たちはそのことをより慎重に考え、呼びかけています。今回のカテゴリごとに含まれるCWE数は平均19.6件で、最少で A10:2021-サーバーサイドリクエストフォージェリ(SSRF) の1件、そして最多のものは A04:2021-安全が確認されない不安な設計 の40件となっています。このカテゴリー構造の変更はトレーニングにさらなる効果をもたらします。たとえば企業は、利用している言語やフレームワークにとって意味のあるCWEに集中して教えることができるでしょう。

カテゴリ選定にデータがどのように使用されたか Copy Chapter

2017年では、発生率よりカテゴリーを選定して可能性を判断し、数十年の経験に基づき、悪用のしやすさ、検出のしやすさ(および 可能性)、技術面への影響についてチームの議論によりランク付けしました。2021年については、可能であれば悪用のしやすさと*(技術面の) 影響*のデータを使用したいと思います。

OWASP Dependency Checkをダウンロードし、CVSS Exploit、およびImpactのスコアを、関連するCWEでグループ化して抽出しました。CVSSv2にはCVSSv3で対処されるであろう欠陥があるにもかかわらず、すべてのCVEはCVSSv2のスコアを持っていたため、かなりの調査と労力を要しました。ですがある時点から、すべてのCVEにCVSSv3のスコアも割り当てられるようになりました。なお、CVSSv2とCVSSv3の間では、スコアの範囲と計算式が更新されています。

CVSSv2 では、悪用性 と (技術面の) 影響 の両方が 10.0 まで可能でしたが、計算式によって 悪用性 は 60%、影響 は 40% に調整されました。CVSSv3では、理論的な最大値がExploitが6.0、Impactが4.0に制限されています。この重み付けにより、CVSSv3ではインパクトのスコアが平均でほぼ1.5ポイント高くなり、悪用性のスコアは平均でほぼ0.5ポイント低くなりました。

OWASP Dependency Checkから抽出されたNVD（National Vulnerability Database）データには、CWEがマッピングされたCVEのレコードは125,000件あり、これらの中に一意のCWEは241件確認されました。CWEがマップされた 6,200件がCVSSv3スコアを持っており、これはデータセットの母数の約半分に相当します。

2021年版Top10では、以下の方法で平均悪用性スコアと影響スコアを算出しました。CVSSスコアを持つすべてのCVEをCWEでグループ化し、悪用性と影響の両スコアを、CVSSv3スコアを持つ母集団の割合 + CVSSv2スコアを持つ残りの母集団で重み付けして全体の平均値を算出しました。この平均値をデータセットのCWEにマッピングし、リスク方程式のうち半分の悪用性および*(技術面の) 影響*スコアとして使用しました。

なぜ純粋な統計データだけではないのか Copy Chapter

データからの結果は、主に自動化された方法でテストできるものからに限られています。しかし、経験豊富なAppSecの専門家に話を聞けば、まだデータにはない発見や傾向について教えてくれるでしょう。とはいえ特定の脆弱性タイプに対するテスト手法を開発するのには時間が必要です。そのテストを自動化し、多くのアプリケーションに対して自動的に実行できるようにするのは、さらに時間がかかります。つまり、データから過去を振り返るだけでは限界があり、データにはない昨年のトレンドを見落としている可能性があります。

そのため、不完全ともいえるデータの結果からのカテゴリ選定は10項目のうち8項目に留めています。残りの2つのカテゴリーは、トップ10コミュニティ調査によって選びました。これは、最前線で実際に活躍されている方々が、最も高いリスクにもかかわらず、データには現れないであろう（データでは表しようもない）と思われるものを選んでくれたものです。

頻度ではなく、発生率を基準とした理由 Copy Chapter

データソースは主に3つあります。ここでは、HaT（Human-assisted Tooling:人間援助型自動テスト）、TaH（Tool-assisted Human:ツールを利用した手動テスト）、そしてRaw Tooling:完全自動テストと名付けました。

自動テストとHaTは高頻度発見生成機です。これらは、特定の脆弱性に対して、その脆弱性を持つすべてのインスタンスをできる限り見つけようとします。このため、いくつかの脆弱性のタイプについて高い発見数を出力します。クロスサイトスクリプティングを例にしますと、この脆弱性は通常、軽微で孤立したミスによるものとシステム的な問題によるもの、の2種類があります。システム的な問題である場合、単一のアプリケーションで発見数が数千になることがあります。このようなデータで他のレポートやデータから発見された他のほとんどの脆弱性が埋もれてしまいます。

一方、TaHでは、より幅広い種類の脆弱性を発見しますが、時間の制約上、発見頻度はかなり低くなります。人間がアプリケーションをテストしてクロスサイトスクリプティングといったものを発見した場合、通常3つか4つのインスタンスを発見して切り上げます。この時点でシステム的な発見を判断し、アプリケーション全体のスケールで修正するための推奨事項とともに、レポートを書き上げることができます。すべてのインスタンスを見つけることは(それにかける時間も)必要ありません。

この2つの異なるデータセットを取り出して、頻度の観点でマージしようとしたとします。その場合、自動テストとHaTのデータで、より正確で（ただし広く薄い）TaHのデータを埋もれてしまうでしょう。これがクロスサイトスクリプティングのように、影響は一般的に小さいか中程度であるようなものが、多くのリストにおいて高い順位に挙げられている理由の一つです。つまりまさしく発見が非常に多いからです。(クロスサイトスクリプティングはテストもしやすいので、それに対するテストも多く行われています）。

2017年には、データを改めて見直し自動テスト及びHaTのデータをTaHのデータときれいに統合するために、代わりに発生率を用いることを導入しました。発生率とは、ある脆弱性タイプのインスタンスを一つ以上持っていたものが、アプリケーションの母集団のうち何％いたかを確認したものです。単発的なものかシステム的なものかは気にしません。それは私たちの目的に影響しないからです。つまり少なくとも1つのインスタンスを持つアプリケーションの数が分かればよいだけなのです。これは、高頻度の結果でデータを埋もれさせることなく、複数のテストタイプにまたがるテストの所見をより明確に示すのに役立ちます。リスク分析観点として、攻撃者はたった1つの脆弱なインスタンスがありさえすれば、カテゴリを経由してアプリケーション攻撃成功できる、ということにもあたります。

データの収集と分析のプロセスについて Copy Chapter

2017年のオープンセキュリティサミットでOWASP Top 10のデータ収集プロセスを正式化しました。OWASP Top 10のリーダーとコミュニティは、2日間かけて透明性のあるデータ収集プロセスを正式化することに取り組みました。2021年版は、このプロセスを利用した2回目の取り組みになります。

私たちは、ソーシャルメディアのチャンネルを通じて、OWASPプロジェクトとOWASPのGithub両方でデータの募集を公表しています。OWASPプロジェクトのページでは、私たちが求めているデータの要素や構造、そして提出方法をリストアップしています。GitHubプロジェクトでは、テンプレートとなるサンプルファイルを用意しています。必要に応じて組織と協力し、構造の解析やCWEへのマッピングを行っています。

ベンダーのテスト業務を生業とする組織、バグバウンティベンダー、社内のデータテスト結果を提供してくれた組織などからデータを入手します。データを入手したら、それを読み込んで、どのようなCWEがどのリスクカテゴリにマッピングされるかを根本的に分析します。CWEの中にはリスクカテゴリが重複しているものもあれば、非常に密接に別のリスクカテゴリに関連しているものもあります（例：暗号の脆弱性）。提出された生データに関する決定はすべて文書化され、オープンとなるよう公開し、データをどのように正規化したかについて透明性のあるものとしています。

トップ10に含めるために、発生率の高い8つのカテゴリーを調べます。また、トップ10のコミュニティアンケート結果を見て、すでにデータとして確認できているであろうものを確認します。そうしてデータからは確認できなかった上位2つを、Top10の残りの2箇所に選びます。10個すべてが選ばれたら、トップ10をリスクに基づく順序でランク付けするのに役立てるべく、悪用のしやすさと影響に関する一般要素をあてはめました。

用語集 Copy Chapter

トップ10カテゴリーのそれぞれの中にある下記用語について、意味を記載します。

• CWEs Mapped(カテゴリにあたるCWEの数): Top10チームがカテゴリーにマッピングしたCWEの数です。
• Incidence Rate(発生率): 発生率とは、当年に機関によってテストされた母集団のうち、カテゴリにマップされたCWEに脆弱なアプリケーションの割合を示します。
• (Testing) Coverage(テスト)網羅範囲: カテゴリにマップされたCWEに対して、機関がテストできたアプリケーションの範囲。
• Weighted Exploit(重み付けされた悪用性): CVEに割り当てられているCVSSv2およびCVSSv3スコアの悪用性サブスコアを正規化し、10ptのスケールで表示したものです。
• Weighted Impact(重み付けされた影響度): CVEに割り当てられているCVSSv2およびCVSSv3スコアの影響サブスコアを正規化し、10ptのスケールで表示したものです。
• Total Occurrences(総発生数): カテゴリにマッピングされたCWEを持つことが判明したアプリケーションの総数です。
• Total CVEs(CVE合計数): カテゴリにマッピングされたCWEに該当する、NVD DB内のCVEの総数です。

データ提供者への謝辞 Copy Chapter

この最も大規模で包括的なアプリケーションセキュリティのデータセットを作り上げるために、（何名かの匿名の提供者とともに）以下の組織には 50,000 を超えるアプリケーションに関するデータを提供いただきました。 これは皆様のご協力なくしては成し得ませんでした。

• AppSec Labs
• Cobalt.io
• Contrast Security
• GitLab
• HackerOne
• HCL Technologies
• Micro Focus
• PenTest-Tools
• Probely
• Sqreen
• Veracode
• WhiteHat (NTT)

スポンサーへの謝辞 Copy Chapter

{ width="256" }

{ width="256" }

2021 Docs Pt BR Index (`2021/docs/pt-BR/index.md`) Copy Section

Introdução

Bem-vindo ao OWASP Top 10 - 2021 Copy Chapter

{:class="img-responsive"}

Bem-vindo à última edição do OWASP Top 10! O OWASP Top 10 2021 é totalmente novo, com um novo design gráfico e um infográfico disponível que você pode imprimir ou obter em nossa página inicial.

Um grande obrigado a todos que contribuíram com seu tempo e dados para esta iteração. Sem você, esta parcela não aconteceria. OBRIGADO.

O que mudou no Top 10 para 2021 Copy Chapter

Existem três novas categorias, quatro categorias com alterações em nomenclaturas e escopo, e alguma consolidação no Top 10 para 2021.

• A01:2021-Quebra de Controle de Acesso sobe da quinta posição; 94% das aplicação foram testados para alguma forma de controle de acesso quebrado. O 34 CWEs mapeados para Quebra de Controle de Acesso tiveram mais ocorrências em aplicações do que qualquer outra categoria.
• A02:2021-Falhas Criptográficas sobe uma posição para #2, anteriormente conhecido como Exposição de Dados Sensíveis, que era um sintoma amplo em vez de uma causa raiz. O foco renovado aqui está nas falhas relacionadas à criptografia, que muitas vezes leva à exposição de dados confidenciais ou sistema comprometido.
• A03:2021-Injeção foi rebaixado para terceira posição. 94% das aplicações foram testadas para alguma forma de injeção com uma taxa de incidência máxima de 19%, uma taxa de incidência média de 3,37% e os 33 CWEs mapeados nesta categoria têm o segundo maior número de ocorrências em aplicações, com 274k ocorrências. Cross-site Scripting (Scripts Inter-site) agora faz parte desta categoria nesta edição.
• A04:2021-Design Inseguro é uma nova categoria para 2021, com foco em riscos relacionados a falhas de projeto. Se quisermos genuinamente "mover para a esquerda (shift left)" como setor, precisamos de mais modelagem de ameaças, padrões e princípios de design seguros e arquiteturas de referência. Um design inseguro não pode ser corrigido por uma implementação perfeita, pois, por definição, os controles de segurança necessários nunca foram criados para a defesa contra ataques específicos.
• A05:2021-Configuração Insegura subiu para sexta posição em comparação a edição anterior. 90% dos aplicativos foram testados para alguma conforma de configuração insegura, com uma taxa de incidência média de 4,5% e mais de 208 mil ocorrências de CWEs mapeados para esta categoria de risco. Com mais mudanças em software altamente configurável, não é surpreendente ver essa categoria subir.
• A06:2021-Componente Desatualizado e Vulnerável foi anteriormente intitulado "Usar componente com vulnerabilidade conhecida" e é o número 2 na pesquisa da comunidade Top 10, mas também tinha dados suficientes para chegar ao Top 10 por meio de análise de dados. Esta categoria subiu da 9ª posição em 2017 e é um problema conhecido que temos dificuldade em testar e avaliar o risco. É a única categoria a não ter nenhuma Vulnerabilidade e Exposições Comuns (CVEs) mapeada para os CWEs incluídos, portanto, uma exploração padrão e pesos de impacto de 5,0 são considerados em suas pontuações.
• A07:2021-Falha de Identificação e Autenticação era conhecida anteriormente como Falha de Autenticação e caiu da terceira posição para essa, e foram incluídas as CWEs que mais se relacionam com as falhas na identificação. Essa categoria ainda é parte integrante do Top 10, mas a maior disponibilidade de estruturas (frameworks) padronizadas parece estar ajudando a reduzir.
• A08:2021-Falha na Integridade de Dados e Software é uma nova categoria em 2021, focadas em fazer premissas relacionadas a atualização de software, dados críticos, e linhas de CI/CD que não verificam a integridade. Um dos maiores pesos dos dados nessa categoria são CVE/CVSS mapeados para os 10 CWEs nesta categoria. A categoria A8:2017-Desserialização Insegura agora faz parte dessa categoria.
• A09:2021-Monitoramento de Falhas e Registros de Segurança anteriormente chamado de A10:2017-Registro e Monitoramentos Insuficientes e foi adicionado pela pesquisa da comunidade de Top 10, ficando em terceiro lugar, passando da 10° posição anterior. Essa categoria foi expandida para incluir um maior número de falhas, sendo um desafio para testar e não está bem representada nos dados de CVE/CVSS. No entanto falhas nessa categoria podem impactar diretamente a visibilidade, o alerta de incidente e a perícia.
• A10:2021-Falsificação de Solicitação do Lado do Servidor foi adicionada a partir da pesquisa da comunidade, sendo a primeira da classificação. Os dados mostram uma taxa de incidência relativamente baixa com cobertura de teste acima da média, junto com classificações acima da média para potencial de exploração e impacto. Esta categoria representa o cenário em que os membros da comunidade de segurança estão nos dizendo que isso é importante, embora não esteja ilustrado nos dados neste momento.

Metodologia Copy Chapter

Esta edição do Top 10 é mais baseada em dados do que nunca, mas não cegamente baseada em dados. Selecionamos oito das dez categorias de dados fornecidos e duas categorias da pesquisa da comunidade Top 10 em um alto nível. Fazemos isso por uma razão fundamental: olhar para os dados de contribuição é olhar para o passado. Os pesquisadores do segurança de aplicação levam tempo para encontrar novas vulnerabilidades e novas maneiras de testá-las. Leva tempo para integrar esses testes em ferramentas e processos. No momento em que podemos testar com segurança uma fraqueza em escala, provavelmente já se passaram anos. Para equilibrar essa visão, usamos uma pesquisa da comunidade para perguntar a especialistas em segurança e desenvolvimento de aplicativos na linha de frente o que eles veem como fraquezas essenciais que os dados podem não mostrar ainda.

Existem algumas mudanças críticas que adotamos para continuar a amadurecer o Top 10.

Como as categorias são estruturadas Copy Chapter

Os esforços anteriores de coleta de dados concentraram-se em um subconjunto prescrito de aproximadamente 30 CWEs com um campo solicitando descobertas adicionais. Aprendemos que as organizações se concentrariam principalmente nesses 30 CWEs e raramente acrescentariam outros CWEs que vissem. Nesta iteração, nós abrimos e apenas pedimos os dados, sem restrição de CWEs. Pedimos o número de aplicativos testados para um determinado ano (começando em 2017) e o número de aplicativos com pelo menos uma instância de um CWE encontrado em teste. Esse formato nos permite rastrear a prevalência de cada CWE na população de aplicativos. Ignoramos a frequência para nossos propósitos; embora possa ser necessário para outras situações, ele apenas oculta a prevalência real na população de aplicação. Se um aplicativo tem quatro instâncias de um CWE ou 4.000 instâncias não faz parte do cálculo para os 10 principais. Passamos de aproximadamente 30 CWEs para quase 400 CWEs para analisar no conjunto de dados. Planejamos fazer análises de dados adicionais como um suplemento no futuro. Este aumento significativo no número de CWEs exige mudanças na forma como as categorias são estruturadas.

Passamos vários meses agrupando e categorizando os CWEs e poderíamos ter continuado por mais tempo. Tivemos que parar em algum ponto. Existem os tipos de causa raiz e sintoma dos CWEs, em que os tipos de causa raiz são como "Falha criptográfica" e "Configuração incorreta" em contraste com os tipos sintoma como "Exposição de dados confidenciais" e "Negação de serviço". Decidimos nos concentrar na causa raiz sempre que possível, pois é mais lógico para fornecer orientação de identificação e correção. Focar na causa raiz em vez do sintoma não é um conceito novo; o Top 10 foi uma mistura de sintoma e causa raiz. Os CWEs também são uma mistura de sintoma e causa raiz; estamos simplesmente sendo mais deliberados sobre isso e convocando-o. Há uma média de 19,6 CWEs por categoria nesta parcela, com os limites inferiores e superiores em 1 CWE para A10: 2021-Server-Side Request Forgery (SSRF) a 40 CWEs em A04: 2021-Design inseguro. Essa estrutura de categorias atualizada oferece benefícios adicionais de treinamento, pois as empresas podem se concentrar em CWEs que façam sentido para uma linguagem/estrutura.

Como os dados são usados para selecionar categorias Copy Chapter

Em 2017, selecionamos categorias por taxa de incidência para determinar a probabilidade e, em seguida, as classificamos em discussões de equipe com base em décadas de experiência em Explorabilidade, Detectabilidade (também probabilidade) e Impacto técnico. Para 2021, queremos usar os dados para Explorabilidade e Impacto (técnico), se possível.

Baixamos o OWASP Dependency Check e extraímos a pontuação de exploração do CVSS e as pontuações de impacto agrupadas por CWEs relacionados. Foi necessário um pouco de pesquisa e esforço, pois todos os CVEs têm pontuações CVSSv2, mas há falhas no CVSSv2 que o CVSSv3 deve corrigir. Após um determinado momento, todos os CVEs também recebem uma pontuação CVSSv3. Além disso, os intervalos de pontuação e fórmulas foram atualizados entre CVSSv2 e CVSSv3.

Em CVSSv2, Exploração e Impacto (Técnico) podem ser até 10,0, mas a fórmula os derrubaria para 60% para Exploração e 40% para Impacto. No CVSSv3, o máximo teórico foi limitado a 6,0 para Exploração e 4,0 para Impacto. Com a ponderação considerada, a pontuação de impacto aumentou, quase um ponto e meio em média no CVSSv3, e a explorabilidade caiu quase meio ponto abaixo em média.

Existem 125k registros de um CVE mapeado para um CWE nos dados do National Vulnerability Database (NVD) extraídos do OWASP Dependency Check, e há 241 CWEs exclusivos mapeados para um CVE. 62k dos CWEs têm uma pontuação CVSSv3, que é aproximadamente metade da população do conjunto de dados.

Para os dez primeiros 2021, calculamos as pontuações médias de exploração e impacto da seguinte maneira. Agrupamos todos os CVEs com pontuações CVSS por CWE e ponderamos exploração e impacto marcados pela porcentagem da população que tinha CVSSv3 + a população restante de pontuações CVSSv2 para obter uma média geral. Mapeamos essas médias para os CWEs no conjunto de dados para usar como pontuação Exploração e Impacto (Técnico) para a outra metade da equação de risco.

Por que não apenas dados puramente estatísticos? Copy Chapter

Os resultados nos dados são limitados principalmente ao que podemos testar de maneira automatizada. Fale com um profissional experiente da segurança de aplicações, e ele lhe contará sobre as coisas que encontrou e as tendências que viu e que ainda não constaram dos dados. Leva tempo para as pessoas desenvolverem metodologias de teste para certos tipos de vulnerabilidade e mais tempo para que esses testes sejam automatizados e executados em uma grande quantidade de aplicativos. Tudo o que encontramos é uma retrospectiva e pode estar faltando tendências do ano passado, que não estão presentes nos dados.

Portanto, escolhemos apenas oito das dez categorias dos dados porque estão incompletos. As outras duas categorias são da pesquisa da comunidade Top 10. Ele permite que os profissionais nas linhas de frente votem naquilo que consideram os maiores riscos que podem não estar nos dados (e podem nunca ser expressos nos dados).

Por que taxa de incidência em vez de frequência? Copy Chapter

Existem três fontes principais de dados. Nós os identificamos como Ferramentas Assistidas por Humanos (HaT), Humanos Assistidos por Ferramentas (TaH) e Ferramentas.

Ferramentas e HaT são geradores de alta-frequência. As ferramentas procurarão vulnerabilidades específicas e tentarão incansavelmente encontrar todas as instâncias dessa vulnerabilidade, gerando contagens de descobertas altas para alguns tipos de vulnerabilidade. Observe o Cross-Site Scripting, que normalmente é um de dois tipos: é um erro menor e isolado ou um problema sistêmico. Quando é um problema sistêmico, a contagem de descobertas pode chegar à casa dos milhares para um único aplicativo. Essa alta frequência abafa a maioria das outras vulnerabilidades encontradas em relatórios ou dados.

TaH, por outro lado, encontrará uma gama mais ampla de tipos de vulnerabilidade, mas em uma frequência muito menor devido a restrições de tempo. Quando os humanos testam um aplicativo e veem algo como Cross-Site Scripting, eles normalmente encontram três ou quatro instâncias e param. Eles podem determinar um achado sistêmico e escrevê-lo com uma recomendação para corrigir em uma escala de aplicativo. Não há necessidade (ou tempo) para encontrar todas as instâncias.

Suponha que pegemos esses dois conjuntos de dados distintos e tentemos mesclá-los na frequência. Nesse caso, os dados de Ferramentas e HaT irão afogar os dados TaH mais precisos (mas amplos) e é uma boa parte do motivo pelo qual algo como Cross-Site Scripting foi tão bem classificado em muitas listas quando o impacto é geralmente de baixo a moderado. É por causa do grande volume de descobertas. (Cross-Site Scripting também é razoavelmente fácil de testar, portanto, há muitos outros testes para ele também).

Em 2017, introduzimos o uso da taxa de incidência para dar uma nova olhada nos dados e mesclar os dados de Ferramentas e HaT com os dados TaH. A taxa de incidência pergunta qual porcentagem da população do aplicativo tinha pelo menos uma instância de um tipo de vulnerabilidade. Não nos importamos se foi pontual ou sistêmico. Isso é irrelevante para nossos propósitos; só precisamos saber quantos aplicativos tiveram pelo menos uma instância, o que ajuda a fornecer uma visão mais clara dos resultados de teste em vários tipos de teste, sem afogar os dados em resultados de alta frequência. Isso corresponde a uma visão relacionada ao risco, pois um invasor precisa de apenas uma instância para atacar um aplicativo com êxito por meio da categoria.

Qual é o processo de coleta e análise de dados? Copy Chapter

Formalizamos o processo de coleta de dados OWASP Top 10 no Open Security Summit em 2017. No OWASP Top 10 líderes e a comunidade passaram dois dias trabalhando na formalização de um processo transparente de coleta de dados. A edição de 2021 é a segunda vez que usamos essa metodologia.

Publicamos uma chamada de dados através dos canais de mídia social disponíveis para nós. Na página do Projeto OWASP, listamos os elementos de dados e a estrutura que estamos procurando e como enviá-los. No projeto GitHub, temos arquivos de exemplo que servem como modelos. Trabalhamos com as organizações conforme necessário para ajudar a descobrir a estrutura e o mapeamento para os CWEs.

Obtemos dados de organizações que estão no negócio de ferramentas de teste, programas de recompenças de erros (Bug Bounty) e organizações que contribuem com dados de teste internos. Assim que tivermos os dados, nós os carregamos juntos e executamos uma análise fundamental do que os CWEs mapeiam para as categorias de risco. Há sobreposição entre alguns CWEs e outros estão intimamente relacionados (por exemplo, vulnerabilidades criptográficas). Quaisquer decisões relacionadas aos dados brutos enviados são documentadas e publicadas para serem abertas e transparentes com a forma como normalizamos os dados.

Examinamos as oito categorias com as taxas de incidência mais altas para inclusão no Top 10. Também olhamos os resultados da pesquisa da comunidade Top 10 para ver quais já podem estar presentes nos dados. Os dois primeiros votos que ainda não estão presentes nos dados serão selecionados para os outros dois lugares no Top 10. Uma vez que todos os dez foram selecionados, aplicamos fatores generalizados para explorabilidade e impacto; para ajudar a classificar os Top 10 2021 em uma ordem baseada no risco.

Fatores dos Dados Copy Chapter

Existem fatores nos dados listados para cada uma das 10 principais categorias, eis o que eles significam:

• CWEs mapeados: o número de CWEs mapeados para uma categoria pela equipe dos 10 principais.
• Taxa de incidência: a taxa de incidência é a porcentagem de aplicativos vulneráveis a esse CWE da população testada por essa organização naquele ano.
• (Teste) Cobertura: a porcentagem de aplicativos testados por todas as organizações para um determinado CWE.
• Peso de exploração: a sub-pontuação do Exploração das pontuações CVSSv2 e CVSSv3 atribuídas aos CVEs mapeados para CWEs, normalizados e colocados em uma escala de 10 pontos.
• Impacto ponderado: a sub-pontuação de impacto das pontuações CVSSv2 e CVSSv3 atribuídas aos CVEs mapeados para CWEs, normalizados e colocados em uma escala de 10 pontos.
• Total de ocorrências: número total de aplicativos encontrados com os CWEs mapeados para uma categoria.
• Total de CVEs: número total de CVEs no banco de dados NVD que foram mapeados para os CWEs mapeados para uma categoria.

Parabéns aos fornecedores de dados Copy Chapter

As organizações a seguir (junto com alguns doadores anônimos) gentilmente doaram dados para mais de 500.000 aplicativos para tornar este o maior e mais abrangente conjunto de dados de segurança de aplicativos. Sem vocês, isso não seria possível.

• AppSec Labs
• Cobalt.io
• Contrast Security
• GitLab
• HackerOne
• HCL Technologies
• Micro Focus
• PenTest-Tools
• Probely
• Sqreen
• Veracode
• WhiteHat (NTT)

Obrigado aos nossos patrocinadores Copy Chapter

A equipe OWASP Top 10 2021 agradece o apoio financeiro do Secure Code Warrior e Just Eat.

{ width="256" }

{ width="256" }

2021 Docs Tr Index (`2021/docs/tr/index.md`) Copy Section

Giriş

OWASP Top 10 - 2021’e Hoş Geldiniz Copy Chapter

{:class="img-responsive"}

OWASP Top 10’un en güncel sürümüne hoş geldiniz! OWASP Top 10 2021 tamamen yenilendi; yeni bir grafik tasarım ve ana sayfamızdan indirebileceğiniz ya da çıktısını alabileceğiniz tek sayfalık bir infografik ile geliyor.

Bu sürüme zamanını ve verisini katan herkese kocaman teşekkürler. Siz olmadan bu sürüm mümkün olmazdı. TEŞEKKÜRLER!

2021 Top 10’da neler değişti Copy Chapter

Bu sürümde üç yeni kategori, isimlendirme ve kapsam değişiklikleri olan dört kategori ve bazı konsolidasyonlar var. Gerekli olduğunda isimleri, semptom yerine kök nedene odaklanacak şekilde değiştirdik.

• A01:2021-Broken Access Control beşinci sıradan, en ciddi web uygulaması güvenlik riski kategorisine yükseliyor; katkı sağlanan veriler ortalama olarak test edilen uygulamaların %3,81’inde bu risk kategorisindeki Common Weakness Enumeration (CWE)lerden bir ya da daha fazlasının bulunduğunu ve bu risk kategorisinde 318 binden fazla CWE olayı olduğunu gösteriyor. Broken Access Control ile eşlenen 34 CWE, diğer tüm kategorilerden daha fazla sayıda uygulamada görülmüş durumda.
• A02:2021-Cryptographic Failures bir sıra yükselerek #2’ye çıkıyor; önceki adı A3:2017-Sensitive Data Exposure idi; bu daha çok bir semptomdu, kök neden değil. Yenilenen ad, daha önce de örtük olarak olduğu gibi kriptografiyle ilgili başarısızlıklara odaklanıyor. Bu kategori sıklıkla hassas veri ifşasına veya sistemin ele geçirilmesine yol açar.
• A03:2021-Injection üçüncü sıraya geriliyor. Uygulamaların %94’ünde bir tür injection için test yapıldı; maksimum insidans oranı %19, ortalama insidans oranı %3,37 ve bu kategoriye eşlenen 33 CWE, uygulamalarda 274 bin olay ile ikinci en yüksek görünüme sahip. Cross-site Scripting bu sürümde artık bu kategorinin bir parçası.
• A04:2021-Insecure Design 2021 için yeni bir kategori; tasarım kusurlarıyla ilişkili risklere odaklanır. Endüstri olarak gerçekten “sola kaymak” istiyorsak daha fazla threat modeling, güvenli tasarım pattern’leri ve prensipleri ile referans mimarilere ihtiyaç var. Güvensiz bir tasarım, ne kadar kusursuz uygulanırsa uygulansın düzeltilemez; tanım gereği, belirli saldırılara karşı gerekli güvenlik kontrolleri hiç oluşturulmamıştır.
• A05:2021-Security Misconfiguration önceki sürümde #6’dan yükseliyor; uygulamaların %90’ı bir tür yanlış yapılandırma için test edildi, ortalama insidans oranı %4,5 ve bu risk kategorisine eşlenen 208 binden fazla CWE olayı var. Yüksek derecede konfigüre edilebilir yazılımlara geçiş arttıkça bu kategorinin yükselmesi şaşırtıcı değil. Önceki A4:2017-XML External Entities (XXE) kategorisi artık bu risk kategorisinin bir parçası.
• A06:2021-Vulnerable and Outdated Components önceki adı Using Components with Known Vulnerabilities idi ve Top 10 community survey’de #2 oldu; ayrıca veri analizine göre de Top 10’a girecek kadar veri vardı. Bu kategori 2017’deki #9’dan yükseliyor ve test etmekte ve riski değerlendirmekte zorlandığımız bilinen bir konu. Dahil edilen CWE’lere eşlenen herhangi bir CVE’nin bulunmadığı tek kategori; bu nedenle skorlamaya varsayılan exploit ve impact ağırlıkları 5.0 olarak dahil edildi.
• A07:2021-Identification and Authentication Failures önceki Broken Authentication kategorisidir; ikinci sıradan geriliyor ve artık kimlik tespitiyle (identification) daha ilişkili CWE’leri de içeriyor. Bu kategori hâlâ Top 10’un ayrılmaz bir parçası, ancak standart framework’lerin artan kullanılabilirliği yardımcı oluyor gibi görünüyor.
• A08:2021-Software and Data Integrity Failures 2021 için yeni bir kategoridir; doğrulama yapılmadan software update’ler, kritik data ve CI/CD pipeline’larıyla ilgili varsayımlara odaklanır. Bu kategoriye eşlenen 10 CWE’den CVE/CVSS verilerinde en yüksek ağırlıklı impact’lerden bazıları geliyor. A8:2017-Insecure Deserialization artık bu daha geniş kategorinin bir parçası.
• A09:2021-Security Logging and Monitoring Failures önceki A10:2017-Insufficient Logging & Monitoring kategorisidir; Top 10 community survey (#3) ile eklendi ve önceki #10’dan yükseliyor. Bu kategori daha fazla failure türünü içerecek şekilde genişletildi, test edilmesi zorlu ve CVE/CVSS verilerinde iyi temsil edilmiyor. Ancak bu kategorideki başarısızlıklar doğrudan görünürlüğü, incident alerting’i ve adli analizleri etkileyebilir.
• A10:2021-Server-Side Request Forgery Top 10 community survey (#1) ile eklendi. Veriler, ortalamanın üzerinde test kapsamıyla birlikte nispeten düşük bir insidans oranı ve Exploit ile Impact potansiyeli için ortalamanın üzerinde puanlar gösteriyor. Bu kategori, güvenlik topluluğu üyelerinin bunun önemli olduğunu söylediği, ancak şu an için verilerde tam yansımayan bir senaryoyu temsil ediyor.

Metodoloji Copy Chapter

Bu sürüm her zamankinden daha veri odaklı, ancak körü körüne veri odaklı değil. On kategorinin sekizini katkı verilerinden, ikisini de yüksek seviyede Top 10 community survey’den seçtik. Bunu temel bir nedenle yapıyoruz: katkı verilerine bakmak geçmişe bakmaktır. AppSec araştırmacılarının yeni zafiyetler ve onları test etmenin yeni yollarını bulması zaman alır. Bu testlerin araçlara ve süreçlere entegre edilmesi de zaman alır. Bir zayıflığı ölçekli şekilde güvenilir biçimde test edebildiğimiz zamana kadar yıllar geçmiş olabilir. Bu bakışı dengelemek için, application security ve development uzmanlarına, verilerin henüz göstermeyebileceği ama sahada gördükleri temel zayıflıkların neler olduğunu sormak üzere bir community survey kullanıyoruz.

Top 10’u olgunlaştırmaya devam etmek için benimsediğimiz birkaç kritik değişiklik var.

Kategoriler nasıl yapılandırıldı Copy Chapter

OWASP Top Ten’in önceki sürümüne göre bazı kategoriler değişti. İşte değişikliklerin yüksek seviyeli özeti.

Önceki veri toplama çabaları, yaklaşık 30 CWE’nin belirlenmiş bir alt kümesine odaklanıyordu ve ek bulgular için bir alan vardı. Organizasyonların çoğunlukla yalnızca bu 30 CWE’ye odaklandığını ve gördükleri ek CWE’leri nadiren eklediklerini öğrendik. Bu sürümde konuyu serbest bıraktık ve herhangi bir kısıtlama olmaksızın yalnızca veri istedik. 2017’den başlayarak belirli bir yıl için test edilen uygulama sayısını ve testlerde en az bir CWE örneği bulunan uygulama sayısını istedik. Bu format, her bir CWE’nin uygulama popülasyonu içinde ne kadar yaygın olduğunu izlememizi sağlıyor. Bizim amaçlarımız için frekansı görmezden geliyoruz; başka durumlarda önemli olabilse de uygulama popülasyonundaki gerçek yaygınlığı gizliyor. Bir uygulamada bir CWE’nin dört örneği ya da 4.000 örneği olması Top 10 hesaplamasına dahil değil. Yaklaşık 30 CWE’den veri setinde analiz etmek üzere neredeyse 400 CWE’ye geçtik. Gelecekte ek veri analizi yapmayı planlıyoruz. CWE sayısındaki bu önemli artış, kategorilerin nasıl yapılandırıldığına ilişkin değişiklikleri gerektiriyor.

CWE’leri gruplamak ve kategorize etmek için birkaç ay harcadık ve birkaç ay daha devam edebilirdik. Bir noktada durmak zorundaydık. CWE’lerin hem kök neden hem de semptom tipleri vardır; kök neden tiplerine “Cryptographic Failure” ve “Misconfiguration” örnek verilebilirken, semptom tiplerine “Sensitive Data Exposure” ve “Denial of Service” örnek verilebilir. Mümkün olduğunda kök nedene odaklanmaya karar verdik; çünkü tanımlama ve iyileştirme rehberi sağlamak açısından daha mantıklı. Kök nedene semptomdan daha fazla odaklanmak yeni bir konsept değil; Top Ten zaten semptom ve kök neden karışımıydı. CWE’ler de bir karışımdır; biz sadece bunu daha kasıtlı hale getiriyor ve vurguluyoruz. Bu sürümde kategori başına ortalama 19,6 CWE var; alt sınırlar A10:2021-Server-Side Request Forgery (SSRF) için 1 CWE ve A04:2021-Insecure Design için 40 CWE. Bu güncellenmiş kategori yapısı, şirketlerin dillerine/framework’lerine uygun CWE’lere odaklanabilmesi açısından ek eğitim faydaları sunuyor.

Kategorilerin seçimi için veriler nasıl kullanıldı Copy Chapter

2017’de kategorileri olasılığı belirlemek için insidans oranına göre seçtik, ardından onlarca yıllık deneyime dayanan ekip tartışmalarıyla Exploitability, Detectability (aynı zamanda likelihood) ve Technical Impact temelinde sıraladık. 2021 için mümkünse Exploitability ve (Technical) Impact için veri kullanmak istiyoruz.

OWASP Dependency Check’i indirdik ve CVE’lere eşlenen CWE’lere göre gruplanmış CVSS Exploit ve Impact skorlarını çıkardık. Oldukça fazla araştırma ve çaba gerektirdi; tüm CVE’lerin CVSSv2 skorları var, ancak CVSSv2’deki kusurların CVSSv3 ile ele alınması gerekiyordu. Belirli bir noktadan sonra tüm CVE’lere ayrıca bir CVSSv3 skoru da atandı. Ek olarak, puan aralıkları ve formüller CVSSv2 ile CVSSv3 arasında güncellendi.

CVSSv2’de hem Exploit hem (Technical) Impact 10,0’a kadar çıkabiliyordu, ancak formül Exploit için %60’a, Impact için %40’a düşürüyordu. CVSSv3’te teorik maksimum Exploit için 6,0 ve Impact için 4,0 ile sınırlandırıldı. Ağırlıklar dikkate alındığında, CVSSv3’te Impact skoru ortalama olarak neredeyse bir buçuk puan yukarı kaydı ve exploitability ortalama olarak neredeyse yarım puan aşağı kaydı.

National Vulnerability Database (NVD) verilerinde CWE’ye eşlenen bir CVE’nin 125 bin kaydı var ve bir CVE’ye eşlenen 241 benzersiz CWE bulunuyor. 62 bin CWE eşlemesi bir CVSSv3 skoruna sahip; bu, veri seti popülasyonunun yaklaşık yarısıdır.

Top Ten 2021 için ortalama exploit ve impact skorlarını şu şekilde hesapladık. Tüm CVSS skorlarına sahip CVE’leri CWE’ye göre grupladık ve hem exploit hem impact skorlarını, popülasyonun CVSSv3 sahibi yüzdesine + kalan CVSSv2 popülasyonuna göre ağırlıklandırarak genel bir ortalama elde ettik. Bu ortalamaları, risk denkleminin diğer yarısı için Exploit ve (Technical) Impact puanlaması olarak kullanmak üzere veri setindeki CWE’lere eşledik.

Neden saf istatistiksel veri değil? Copy Chapter

Verilerdeki sonuçlar, esasen otomatik olarak test edebildiklerimizle sınırlıdır. Deneyimli bir AppSec profesyoneli ile konuşursanız, verilerde henüz bulunmayan ama buldukları şeylerden ve gördükleri trendlerden bahsederler. Belirli zafiyet türleri için test metodolojilerinin geliştirilmesi zaman alır ve bu testlerin otomatikleştirilip çok sayıda uygulamaya karşı çalıştırılması daha da zaman alır. Bulduğumuz her şey geçmişe bakmaktadır ve verilerde olmayan son yılın trendlerini kaçırıyor olabilir.

Bu nedenle veriler eksik olduğu için on kategoriden yalnızca sekizini verilerden seçiyoruz. Diğer iki kategori Top 10 community survey’den geliyor. Bu, sahada çalışan uygulayıcıların, verilerde olmayabilecek (ve belki de hiç veriye yansımayacak) en yüksek riskleri oylamasına olanak tanır.

Neden frekans yerine insidans oranı? Copy Chapter

Üç birincil veri kaynağı vardır: Human-assisted Tooling (HaT), Tool-assisted Human (TaH) ve ham Tooling.

Tooling ve HaT, yüksek frekanslı bulgu üreticileridir. Araçlar belirli zafiyetleri arar, yorulmadan bu zafiyetin her örneğini bulmaya çalışır ve bazı zafiyet türleri için yüksek bulgu sayıları üretir. Cross-Site Scripting’e bakın; genellikle iki çeşittir: daha küçük, izole bir hata ya da sistemik bir sorun. Sistemik olduğunda tek bir uygulama için bulgu sayıları binlere ulaşabilir. Bu yüksek frekans, raporlardaki ya da verilerdeki diğer çoğu zafiyeti bastırır.

Öte yandan TaH, daha geniş bir zafiyet türü yelpazesi bulur ancak zaman kısıtları nedeniyle çok daha düşük frekanstadır. İnsanlar bir uygulamayı test edip Cross-Site Scripting gibi bir şey gördüğünde genellikle üç dört örnek bulur ve durur. Sistemik bir bulgu olup olmadığını belirleyebilir ve uygulama genelinde düzeltme önerisi ile yazabilirler. Her örneği bulmaya gerek (ve zaman) yoktur.

Bu iki farklı veri setini frekansa göre birleştirmeye çalıştığımızı varsayalım; Tooling ve HaT verileri daha doğru (ama geniş) TaH verilerini boğar ve bunun önemli bir kısmı, Cross-Site Scripting gibi şeylerin çoğu listede çok yüksek sıralarda olmasının nedenidir; genellikle etkisi düşük ile orta arasında olmasına rağmen. Bunun nedeni salt bulgu hacmidir. (Cross-Site Scripting’i test etmek de nispeten kolaydır, bu nedenle onun için daha fazla test vardır.)

2017’de, verilere taze bir bakış atmak ve Tooling ile HaT verilerini TaH verileriyle temiz şekilde birleştirmek için insidans oranını kullanmaya başladık. İnsidans oranı, uygulama popülasyonunun yüzde kaçında bir zafiyet türünün en az bir örneğinin bulunduğunu sorar. Tekil mi yoksa sistemik mi olduğuna aldırmayız. Bizim amaçlarımız için bu ilgisizdir; sadece en az bir örnek bulunan uygulama sayısını bilmeye ihtiyacımız var; bu da, yüksek frekanslı sonuçlarla verileri boğmadan, farklı test türleri arasında bulguların daha net bir görünümünü sağlar. Bu, bir saldırganın bir kategoriyi başarıyla istismar etmek için yalnızca bir örneğe ihtiyaç duyduğu gerçeğiyle ilişkili risk temelli bir bakışa karşılık gelir.

Veri toplama ve analiz süreciniz nedir? Copy Chapter

Veri toplama sürecini 2017’de Open Security Summit’te resmileştirdik. OWASP Top 10 liderleri ve topluluk, şeffaf bir veri toplama süreci oluşturmak için iki gün harcadı. 2021 sürümü, bu metodolojiyi ikinci kez kullandığımız sürümdür.

Sosyal medya kanalları üzerinden (hem proje hem OWASP) veri çağrısı yayınlıyoruz. OWASP Proje sayfasında aradığımız veri öğelerini ve yapılarını ve bunların nasıl gönderileceğini listeliyoruz. GitHub projesinde şablon görevi gören örnek dosyalarımız var. CWE’lere yapı ve eşlemeyi anlamak için gerektiğinde organizasyonlarla birlikte çalışıyoruz.

Verileri, işi gereği test vendor’ı olan organizasyonlardan, bug bounty vendor’larından ve iç test verilerini katkılayan organizasyonlardan alıyoruz. Veriyi aldıktan sonra bir araya yüklüyor ve CWE’lerin risk kategorilerine nasıl eşlendiğine dair temel bir analiz çalıştırıyoruz. Bazı CWE’ler arasında örtüşme var ve diğerleri birbirine çok yakındır (örn. kriptografik zafiyetler). Gönderilen ham verilerle ilgili alınan her karar, verileri nasıl normalize ettiğimizi açık ve şeffaf olmak için belgelenir ve yayımlanır.

Top 10’a dahil edilmek üzere en yüksek insidans oranına sahip sekiz kategoriye bakıyoruz. Ayrıca Top 10 community survey sonuçlarına bakıyor ve hangilerinin verilerde zaten mevcut olabileceğini görüyoruz. Verilerde henüz yer almayan en çok oyu alan iki kategori, Top 10’daki diğer iki yer için seçilir. Tüm on kategori seçildikten sonra, Top 10 2021’i risk bazlı bir sıraya koymaya yardımcı olmak için genelleştirilmiş exploitability ve impact faktörlerini uyguladık.

Veri Faktörleri Copy Chapter

Top 10’daki her kategori için listelenen veri faktörleri ve anlamları şunlardır:

• CWEs Mapped: Top 10 ekibi tarafından bir kategoriye eşlenen CWE sayısı.
• Incidence Rate: Belirli bir yıl için, o organizasyon tarafından test edilen popülasyondaki uygulamaların, ilgili CWE’ye karşı zafiyetli olan yüzdesi.
• (Testing) Coverage: Belirli bir CWE için tüm organizasyonlar tarafından test edilen uygulamaların yüzdesi.
• Weighted Exploit: CWE’lere eşlenen CVE’lerden gelen CVSSv2 ve CVSSv3 Exploit alt-skoru, normalize edilerek 10 puanlık ölçeğe yerleştirilmiş hali.
• Weighted Impact: CWE’lere eşlenen CVE’lerden gelen CVSSv2 ve CVSSv3 Impact alt-skoru, normalize edilerek 10 puanlık ölçeğe yerleştirilmiş hali.
• Total Occurrences: Bir kategoriye eşlenen CWE’lerin bulunduğu uygulamaların toplam sayısı.
• Total CVEs: Bir kategoriye eşlenen CWE’lere NVD veritabanında eşlenen toplam CVE sayısı.

Veri katkıcılarımıza teşekkürler Copy Chapter

Aşağıdaki organizasyonlar (ve bazı anonim bağışçılar), bu sürümü en büyük ve en kapsamlı uygulama güvenliği veri seti hâline getiren 500.000’den fazla uygulamaya ait verileri cömertçe bağışladı. Siz olmadan bu mümkün olmazdı.

• AppSec Labs
• Cobalt.io
• Contrast Security
• GitLab
• HackerOne
• HCL Technologies
• Micro Focus
• PenTest-Tools
• Probely
• Sqreen
• Veracode
• WhiteHat (NTT)

Sponsorlarımıza teşekkürler Copy Chapter

OWASP Top 10 2021 ekibi, Secure Code Warrior ve Just Eat’in finansal desteğini minnetle kabul eder.

{ width="256" }

{ width="256" }

2021 Docs Zh Hant Index (`2021/docs/zh-Hant/index.md`) Copy Section

OWASP Top 10 2021 介紹

欢迎來到最新版本的 OWASP Top 10！! OWASP Top 10 2021 是一个全新的名单，包含了你可以打印下來的新图示说明，若有需要的话，你可以从我们的网页上面下载。

在此我们想对所有贡献了他们时间和资料的人給予极大的感谢。没有你们，这一个新版本不会产生。谢谢。

Top 10 for 2021 有什么新的变化？ Copy Chapter

这次在 OWASP Top 10 for 2021 有三个全新的分类，有四个分类有做名称和范围的修正，并有将一些类别做合并。

A01:2021-权限控制失效 从第五名移上來; 94% 被测试的应用程式都有验证到某种类别权限控制失效的问题。在权限控制失效这个类别中被对应到的 34 个 CWEs 在验测资料中出现的次数都高于其他的弱点类别。

A02:2021-加密机制失效 提升一名到第二名，在之前为 敏感资料外曝，在此定义下比较类似于一个广泛的问题而非根本原因。在此重新定义并将问题核心定义在加密机制的失败，并因此造成敏感性资料外泄或是系統被破坏。

A03:2021-注入式攻击 下滑到第三名。94% 被测试的应用程式都有验测到某种类別注入式攻击的问题。在注入式攻击这个类別中被对应到的 33 个 CWEs 在验测资料中出现的次数为弱点问题的第二高。跨站脚本攻击现在在新版本属于这个类別。

A04:2021-不安全设计 这是 2021 年版本的新类別，并特別聚焦在设计相关的缺陷。如果我们真的希望让整个产业"向左移动"＊注一＊，那我们必须进一步的往威胁建模，安全设计模块的观念，和安全參考架构前进。

＊注一: Move Left 于英文原文中代表在软件开发及交付过程中，在早期找出及处理相关问题，同 Shift Left Testing。＊

A05:2021-安全设定缺陷 从上一版本的第六名移动上來。90% 被测试的应用程式都有验测到某种类別的安全设定缺陷。在更多的软件往更高度和有弹性的设定移动，我们并不意外这个类別的问题往上移动。在前版本中的 XML 外部实体注入攻击 （XML External Entities）现在属于这个类別。

A06:2021-危险或过旧的组件 在之前标题为 使用有已知弱点的组件。在本次版本中于业界问卷中排名第二，但也有足够的统计资料让它可以进入 Top 10。这个类別从 2017 版本的第九名爬升到第六，也是我们持续挣扎做测试和评估风险的类別。这也是唯一一个沒有任何 CVE 能被对应到 CWE 內的类別，所以预设的威胁及影响权重在这类別的分数上被预设为 5.0。

A07:2021-认证及验证机制失效 在之前标题为 错误的认证机制。在本次版本中由第二名下滑至此，并同时包含了将认证相关缺失的 CWE 包含在內。这个类別仍是 Top 10 不可缺少的一环，但同时也有发现现在标准化的架构有协助降低次风险发生机率。

A08:2021-软件及资料完整性失效 这是 2021 年版本全新的类別，并在软件更新，敏感及重要资料，和 CI/CD 管道中并沒有做完整性的确认为前提做假设并进行评估。在评估中影响权重最高分的 CVE/CVSS 资料都与这类別中的 10 个 CWE 对应到。2017 年版本中不安全的反序列化现在被合并至此类別。

A09:2021-安全记录及监控失效 在之前为不完整的记录及监控并纳入在业界问卷中在本次列名为第三名并从之前的第十名上移。这个类別将扩充去纳入更多相关的缺失，但这也是相当难去验证，并沒有相当多的 CVE/CVSS 资料可以佐证。但是在这个类別中的缺失会直接影响到整体安全的可视性，事件告警及取证。

A10:2021-服务器端请求伪造 这个类別是在业界问卷排名第一名，并在此版本內纳入。由资料显示此问题有较低被验测次数和范围，但有高于平均的威胁及影响权重比率。这个类別的出现也是因为业界专家重复申明这类別的问题相当重要，即使在本次资料中并沒有足够的资料去显示这个问题。

分析方法 Copy Chapter

本次 Top 10 的选择方式比以往更重视资料分析，但并不是完全以资料分析为主。我们从资料分析中挑选了八个风险类別，然后由业界问卷中挑选两个风险类別。我们从过往的分享资料中去了解，并有我们一个基本的理由。原因是所有的资安研究人员都不断的在找新的弱点并找出方法去验证弱点，但会需要时间才能将这些验测方法纳入到既有的工具和测试流程中。当我们能有效的大量测试这个弱点时，有可能已经过了多年的时间。为了要让两者之间有平衡，我们使用业界问卷请教在前线的资安研究专家们并了解他们觉得有哪些是他们觉得严重但尚未出现在测试资料中的漏洞及问题。

这是几个我们为了要让 OWASP Top 10 更加成熟的重要改变。

如何建构风险类別 Copy Section

有別于上一个版本，在这次的 OWASP Top 10 有一些风险类別的修改。我们在此以比较高的角度说明一下这次的类別修改。

在上一次的资料收集当中，我们将资料收集的重心放在预先定义好的约 30 个 CWEs 并纳入一个领域以求其他的发现。从这里我们看到绝大多数的组织都只会专注在这 30 个 CWEs 而不常加入其他他们可能发现的 CWEs。在这次的改版中，我们将所有的问题都以开放式的方法处理，并沒有限制在任何一个 CWEs。我们请教了从 2017 年开始所测试的网页应用程式数量，然后在这些程式中至少有一个 CWE 被发现的数量。这个格式让我们能够追踪每个 CWE 跟所有被验测及统计的应用程式的数量跟关系。我们也忽略了 CWE 出现的频率，虽然在某些状况下这也许是必须的，但这却隐藏了风险类別本身与应用程式数量整体的关系。所以一个应用程式有 4 个或是 4,000 个弱点并不是被计算在 Top 10 的基础。但同时我们也从原本的 30 多个 CWEs 增长到快 400 多个 CWEs 去进行分析。我们因此也计划未來做更多的资料分析，并在对此版本进行补充说明。而这些增加的 CWEs 也同时影响了这次风险类別的规划。

我们花了好几个月将 CWEs 进行分组跟分类，而且其实可以一直花更多时间去做这件事情。但我们必须在某一个时间点停住。在 CWEs 当中，同时有 根本原因 以及 症状 的问题，而像是 "加密机制失效" 和 "设定问题" 这类型的 原因 与 "敏感资料外泄" 和 "阻断服务" 这类型的 症状 是对立的。因此我们决定在可以的时候要更专注于底层的原因，因为这是可以有效指出问题的本体跟同时提供问题的解决大方向。专注在问题核心而不将重心放在症状并不是一个新的概念 ，Top Ten 有史以來一直是症状跟问题核心的綜合体，只是这次我们更刻意的将他突显出來。在这次的新版本中，每一个类別內的平均有 19.6 个 CWE，而最低的 A10:2021-服务器端请求伪造 有一个 CWE 到 A04:2021-不安全设计 有四十个 CWE。这个新的类別架构能提供企业更多的资安训练的好处，因为在新的架构下可以更专注在某个语系或平台上的 CWE。

选择类別时资料的使用方式 Copy Section

在 2017 年，我们用事件发生次数去判断可能发生的机率去选择类別，然后透过一群在业界拥有数十年经验的专家团对讨论并依照 可发生性，可发现性（同可能性），和 技术影响力 去做排名。在 2021 年，我们希望如果可以的话用资料证明可发生性和技术影响性。

我们下载了 OWASP Depndency Check 并取出了 CVSS 漏洞，并将相关的 CWE 用影响力分数分群。这花了一些时间和力气去研究因为所有的 CVEs 都有 CVSSv2 分数，但是在其中因为 CVSSv2 跟 CVSSv3 之间有一些缺失是必须被修正的。经过了一段时间后，所有的 CVEs 都会有对应的 CVSSv3 的分数。再者，分数的范围和计算的公式在 CVSSv2 和 CVSSv3 之间也做了更新。

在 CVSSv2 中，漏洞和影响力两者都可达到 10.0 分，但是公式本身会将两者调整为漏洞占 60%，然后影响力占 40%。在 CVSSv3 中，理论上的最高值将漏洞限制在 6.0 分而影响力在 4.0 分。当考率到权重比率时，影响力的分数会偏高，在 CVSSv3 中几乎平均会多出 1.5 分，而漏洞分数却会平均少 0.5 分。

从 OWASP Dependcy Check 翠取出的 NVD 资料当中有将近 12.5 万笔 CVE 资料有对应到 CWE，而有 241 笔独特的 CWEs 有对应到 CVE。6.2 万笔 CWE 有对应到 CVSSv3 分数，所以大约是整体资料中一半的部分。

而在 Top Ten，我们计算漏洞和影响力的平均分数的方式如下。我们将所有有 CVSS 分数的 CVE 依照 CWE 分组，然后依照有 CVSSv3 的漏洞和影响力在所有资料中的百分比作权重，在加上资料中有 CVSSv2 的资料去做平均。我们将这些平均后的 CWEs 对应到资料中，然后将他的漏洞和引想力分数使用在另一半的风险公式中。

为什么就不纯粹做统计分析？ Copy Chapter

这些资料的結果最主要是被限制在能使用自动工具测试出來的結果。可是当你跟一位有经验的应用程式安全专家聊的时候，他们会跟你说绝大多数他们找到的问题都不在这些资料里面。原因是一个测试要被自动化的时候，需要花时间去开发这些弱点测试的方法论，当你需要将这个测试自动化并能对大量的应用程式去验证时，又会花上更多的时间。当我们回头看去年或以前有可能沒出现的一些问题的趋势，我们发现其实都沒有在这些资料当中。

因此，由于资料不完全的关系，我们只有从资料中选出 8 个类別，而并不是 10 个。剩下的两个类別是从业界问卷中所选出的。这会允许在前线的參与者去选出他们认为的高风险，而不是纯粹依据资料去判断（甚至可能资料永远都不会有出现的踪跡）。

为什么用事故率而不是用发生次数 Copy Chapter

There are three primary sources of data. We identify them as
Human-assisted Tooling (HaT), Tool-assisted Human (TaH), and raw
Tooling.

Tooling and HaT are high-frequency finding generators. Tools will look
for specific vulnerabilities and tirelessly attempt to find every
instance of that vulnerability and will generate high finding counts for
some vulnerability types. Look at Cross-Site Scripting, which is
typically one of two flavors: it's either a more minor, isolated mistake
or a systemic issue. When it's a systemic issue, the finding counts can
be in the thousands for an application. This high frequency drowns out
most other vulnerabilities found in reports or data.

TaH, on the other hand, will find a broader range of vulnerability types
but at a much lower frequency due to time constraints. When humans test
an application and see something like Cross-Site Scripting, they will
typically find three or four instances and stop. They can determine a
systemic finding and write it up with a recommendation to fix on an
application-wide scale. There is no need (or time) to find every
instance.

Suppose we take these two distinct data sets and try to merge them on
frequency. In that case, the Tooling and HaT data will drown the more
accurate (but broad) TaH data and is a good part of why something like
Cross-Site Scripting has been so highly ranked in many lists when the
impact is generally low to moderate. It's because of the sheer volume of
findings. (Cross-Site Scripting is also reasonably easy to test for, so
there are many more tests for it as well).

In 2017, we introduced using incidence rate instead to take a fresh look
at the data and cleanly merge Tooling and HaT data with TaH data. The
incidence rate asks what percentage of the application population had at
least one instance of a vulnerability type. We don't care if it was
one-off or systemic. That's irrelevant for our purposes; we just need to
know how many applications had at least one instance, which helps
provide a clearer view of the testing is findings across multiple
testing types without drowning the data in high-frequency results.

What is your data collection and analysis process? Copy Chapter

We formalized the OWASP Top 10 data collection process at the Open
Security Summit in 2017. OWASP Top 10 leaders and the community spent
two days working out formalizing a transparent data collection process.
The 2021 edition is the second time we have used this methodology.

We publish a call for data through social media channels available to
us, both project and OWASP. On the OWASP Project
page, we list the
data elements and structure we are looking for and how to submit them.
In the GitHub
project, we have
example files that serve as templates. We work with organizations as
needed to help figure out the structure and mapping to CWEs.

We get data from organizations that are testing vendors by trade, bug
bounty vendors, and organizations that contribute internal testing data.
Once we have the data, we load it together and run a fundamental
analysis of what CWEs map to risk categories. There is overlap between
some CWEs, and others are very closely related (ex. Cryptographic
vulnerabilities). Any decisions related to the raw data submitted are
documented and published to be open and transparent with how we
normalized the data.

We look at the eight categories with the highest incidence rates for
inclusion in the Top 10. We also look at the industry survey results to
see which ones may already be present in the data. The top two votes
that aren't already present in the data will be selected for the other
two places in the Top 10. Once all ten were selected, we applied
generalized factors for exploitability and impact; to help rank the Top
10 in order.

Data Factors Copy Chapter

There are data factors that are listed for each of the Top 10
Categories, here is what they mean:

• CWEs Mapped: The number of CWEs mapped to a category by the Top 10
  team.

• Incidence Rate: Incidence rate is the percentage of applications
  vulnerable to that CWE from the population tested by that org for
  that year.

• (Testing) Coverage: The percentage of applications tested by all
  organizations for a given CWE.

• Weighted Exploit: The Exploit sub-score from CVSSv2 and CVSSv3
  scores assigned to CVEs mapped to CWEs, normalized, and placed on a
  10pt scale.

• Weighted Impact: The Impact sub-score from CVSSv2 and CVSSv3
  scores assigned to CVEs mapped to CWEs, normalized, and placed on a
  10pt scale.

• Total Occurrences: Total number of applications found to have the
  CWEs mapped to a category.

• Total CVEs: Total number of CVEs in the NVD DB that were mapped to
  the CWEs mapped to a category.

Category Relationships from 2017 Copy Chapter

There has been a lot of talk about the overlap between the Top Ten
risks. By the definition of each (list of CWEs included), there really
isn't any overlap. However, conceptually, there can be overlap or
interactions based on the higher-level naming. Venn diagrams are many
times used to show overlap like this.

The Venn diagram above represents the interactions between the Top Ten
2017 risk categories. While doing so, a couple of essential points
became obvious:

1. One could argue that Cross-Site Scripting ultimately belongs within
   Injection as it's essentially Content Injection. Looking at the 2021
   data, it became even more evident that XSS needed to move into
   Injection.

2. The overlap is only in one direction. We will often classify a
   vulnerability by the end manifestation or "symptom," not the
   (potentially deep) root cause. For instance, "Sensitive Data
   Exposure" may have been the result of a "Security Misconfiguration";
   however, you won't see it in the other direction. As a result,
   arrows are drawn in the interaction zones to indicate which
   direction it occurs.

3. Sometimes these diagrams are drawn with everything in A06:2021
   Using Components with Known Vulnerabilities. While some of these
   risk categories may be the root cause of third-party
   vulnerabilities, they are generally managed differently and with
   different responsibilities. The other types are typically
   representing first-party risks.

Thank you to our data contributors

The following organizations (along with some anonymous donors) kindly
donated data for over 500,000 applications to make this the largest and
most comprehensive application security data set. Without you, this
would not be possible.

Thank you to our sponsors Copy Chapter

The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior and Just Eat.

{ width="256" }

{ width="256" }

2021 Docs Zh TW Index (`2021/docs/zh-TW/index.md`) Copy Section

OWASP Top 10 2021 介紹

歡迎來到最新版本的 OWASP Top 10！! OWASP Top 10 2021 是一個全新的名單，包含了你可以列印下來的新圖示說明，若有需要的話，你可以從我們的網頁上面下載。

在此我們想對所有貢獻了他們時間和資料的人給予一個極大的感謝。沒有你們，這一個新版本是不會出現的。謝謝。

Top 10 for 2021 有什麼新的變化？ Copy Chapter

這次在 OWASP Top 10 for 2021 有三個全新的分類，有四個分類有做名稱和範圍的修正，並有將一些類別做合併。

A01:2021-權限控制失效 從第五名移上來; 94% 被測試的應用程式都有驗測到某種類別權限控制失效的問題。在權限控制失效這個類別中被對應到的 34 個 CWEs 在驗測資料中出現的次數都高於其他的弱點類別。

A02:2021-加密機制失效 提升一名到第二名，在之前為 敏感資料外曝，在此定義下比較類似於一個廣泛的問題而非根本原因。在此重新定義並將問題核心定義在加密機制的失敗，並因此造成敏感性資料外洩或是系統被破壞。

A03:2021-注入式攻擊 下滑到第三名。94% 被測試的應用程式都有驗測到某種類別注入式攻擊的問題。在注入式攻擊這個類別中被對應到的 33 個 CWEs 在驗測資料中出現的次數為弱點問題的第二高。跨站腳本攻擊現在在新版本屬於這個類別。

A04:2021-不安全設計 這是 2021 年版本的新類別，並特別針注在與設計相關的缺失。如果我們真的希望讓整個產業"向左移動"＊註一＊，那我們必須進一步的往威脅建模，安全設計模塊的觀念，和安全參考架構前進。

＊註一: Move Left 於英文原文中代表在軟體開發及交付過程中，在早期找出及處理相關問題，同 Shift Left Testing。＊

A05:2021-安全設定缺陷 從上一版本的第六名移動上來。90% 被測試的應用程式都有驗測到某種類別的安全設定缺陷。在更多的軟體往更高度和有彈性的設定移動，我們並不意外這個類別的問題往上移動。在前版本中的 XML 外部實體注入攻擊 （XML External Entities）現在屬於這個類別。

A06:2021-危險或過舊的元件 在之前標題為 使用有已知弱點的元件。在本次版本中於業界問卷中排名第二，但也有足夠的統計資料讓它可以進入 Top 10。這個類別從 2017 版本的第九名爬升到第六，也是我們持續掙扎做測試和評估風險的類別。這也是唯一一個沒有任何 CVE 能被對應到 CWE 內的類別，所以預設的威脅及影響權重在這類別的分數上被預設為 5.0。

A07:2021-認證及驗證機制失效 在之前標題為 錯誤的認證機制。在本次版本中油第二名下滑至此，並同時包含了將認證相關缺失的 CWE 包含在內。這個類別仍是 Top 10 不可缺少的一環，但同時也有發現現在標準化的架構有協助降低次風險發生機率。

A08:2021-軟體及資料完整性失效 這是 2021 年版本全新的類別，並在軟體更新，機敏及重要資料，和 CI/CD 管道中並沒有做完整性的確認為前提做假設並進行評估。在評估中影響權重最高分的 CVE/CVSS 資料都與這類別中的 10 個 CWE 對應到。2017 年版本中不安全的反序列化現在被合併至此類別。

A09:2021-資安記錄及監控失效 在之前為不完整的紀錄及監控並納入在業界問卷中在本次列名為第三名並從之前的第十名上移。這個類別將擴充去納入更多相關的缺失，但這也是相當難去驗證，並沒有相當多的 CVE/CVSS 資料可以佐證。但是在這個類別中的缺失會直接影響到整體安全的可視性，事件告警及鑑識。

A10:2021-伺服端請求偽造 這個類別是在業界問卷排名第一名，並在此版本內納入。由資料顯示此問題有較低被驗測次數和範圍，但有高於平均的威脅及影響權重比率。這個類別的出現也是因為業界專家重複申明這類別的問題相當重要，即使在本次資料中並沒有足夠的資料去顯示這個問題。

分析方法 Copy Chapter

本次 Top 10 的選擇方式比以往更重視資料分析，但並不是完全以資料分析為主。我們從資料分析中挑選了八個風險類別，然後由業界問卷中挑選兩個風險類別。我們從過往的分享資料中去瞭解，並有我們一個基本的理由。原因是所有的資安研究人員都不斷的在找新的弱點並找出方法去驗證弱點，但會需要時間才能將這些驗測方法納入到既有的工具和測試流程中。當我們能有效的大量測試這個弱點時，有可能已經過了多年的時間。為了要讓兩者之間有平衡，我們使用業界問卷請教在前線的資安研究專家們並瞭解他們覺得有哪些是他們覺得嚴重但尚未出現在測試資料中的漏洞及問題。

這是幾個我們為了要讓 OWASP Top 10 更加成熟的重要改變。

如何建構風險類別 Copy Section

有別於上一個版本，在這次的 OWASP Top 10 有一些風險類別的修改。我們在此以比較高的角度說明一下這次的類別修改。

在上一次的資料收集當中，我們將資料收集的重心放在預先定義好的約 30 個 CWEs 並納入一個欄位徵求其他的發現。從這裡我們看到決多數的組織都只會專注在這 30 個 CWEs 而不常加入其他他們可能發現的 CWEs。在這次的改版中，我們將所有的問題都以開放式的方法處理，並沒有限制在任何一個 CWEs。我們請教了從 2017 年開始所測試的網頁應用程式數量，然後在這些程式中至少有一個 CWE 被發現的數量。這個格式讓我們能夠追蹤每個 CWE 跟所有被驗測及統計的應用程式的數量跟關係。我們也忽略了 CWE 出現的頻率，雖然在某些狀況下這也許是必須的，但這卻隱藏了風險類別本身與應用程式數量整體的關係。所以一個應用程式有 4 個或是 4,000 個弱點並不是被計算在 Top 10 的基礎。但同時我們也從原本的 30 多個 CWEs 增長到快 400 多個CWEs 去進行分析。我們因此也計畫未來做更多的資料分析，並在對此版本進行補充說明。而這些增加的 CWEs 也同時影響了這次風險類別的規劃。

我們花了好幾個月將 CWEs 進行分組跟分類，而且其實可以一直花更多個月去做這件事情。但我們必須在某一個時間點停住。在 CWEs 當中，同時有 原因 以及 症狀 的問題，而像是 "加密機制失效" 和 "設定問題" 這類型的 原因 與 "機敏資料外洩" 和 "阻斷服務" 這類型的 症狀 是對立的。因此我們決定在可以的時候要更專注於底層的原因，因為這是可以有效指出問題的本體跟同時提供問題的解決方向。專注在問題核心而不將重心放在症狀並不是一個新的概念，Top Ten 有史以來一直是症狀跟問題核心的綜合體，只是這次我們更刻意的將他突顯出來。在這次的新版本中，每一個類別內的平均有 19.6 個 CWE，而最低的 A10:2021-伺服端請求偽造 有一個 CWE 到 A04:2021-不安全設計 有四十個 CWE。這個新的類別架構能提供企業更多的資安訓練的好處，因為在新的架構下可以更專注在某個語系或平台上的 CWE。

選擇類別時資料的使用方式 Copy Section

在 2017 年，我們用事件發生次數去判斷可能發生的機率去選擇類別，然後透過一群在業界擁有數十年經驗的專家團對討論並依照 可發生性，可發現性（同可能性），和 技術影響力 去做排名。在 2021 年，我們希望如果可以的話用資料證明可發生性和技術影響性。

我們下載了 OWASP Depndency Check 並取出了 CVSS 漏洞，並將相關的 CWE 用影響力分數分群。這花了一些時間和力氣去研究因為所有的 CVEs 都有 CVSSv2 分數，但是在其中因為 CVSSv2 跟 CVSSv3 之間有一些缺失是必須被修正的。經過了一段時間後，所有的 CVEs 都會有對應的 CVSSv3 的分數。再者，分數的範圍和計算的公式在 CVSSv2 和 CVSSv3 之間也做了更新。

在 CVSSv2 中，漏洞和影響力兩者都可達到 10.0 分，但是公式本身會將兩者調整為漏洞佔 60%，然後影響力佔 40%。在 CVSSv3 中，理論上的最高值將漏洞限制在 6.0 分而影響力在 4.0 分。當考慮到權重比率時，影響力的分數會偏高，在 CVSSv3 中幾乎平均會多出 1.5 分，而漏洞分數卻會平均少 0.5 分。

從 OWASP Dependcy Check 翠取出的 NVD 資料當中有將近 12.5 萬筆 CVE 資料有對應到 CWE，而有 241 筆獨特的 CWEs 有對應到 CVE。6.2萬筆 CWE 有對應到 CVSSv3 分數，所以大約是整體資料中一半的部分。

而在 Top Ten，我們計算漏洞和影響力的平均分數的方式如下。我們將所有有 CVSS 分數的 CVE 依照 CWE 分組，然後依照有 CVSSv3 的漏洞和影響力在所有資料中的百分比作權重，在加上資料中有 CVSSv2 的資料去做平均。我們將這些平均後的 CWEs 對應到資料中，然後將他的漏洞和引想力分數使用在另一半的風險公式中。

為什麼就不純粹做統計分析？ Copy Chapter

這些資料的結果最主要是被限制在能使用自動工具測試出來的結果。可是當你跟一位有經驗的應用程式安全專家聊的時候，他們會跟你說絕大多數他們找到的問題都不在這些資料裡面。原因是一個測試要被自動化的時候，需要花時間去開發這些弱點測試的方法論，當你需要將這個測試自動化並能對大量的應用程式去驗證時，又會花上更多的時間。當我們回頭看去年獲以前有可能沒出現的一些問題的趨勢，我們發現其實都沒有在這些資料當中。

因此，由於資料不完全的關係，我們只有從資料中選出 8 個類別，而並不是 10 個。剩下的兩個類別是從業界問卷中所選出的。這會允許在前線的參與者去選出他們認為的高風險，而不是純粹依據資料去判斷（甚至可能資料永遠都不會有出現的蹤跡）。

為什麼用事故率而不是用發生次數 Copy Chapter

There are three primary sources of data. We identify them as
Human-assisted Tooling (HaT), Tool-assisted Human (TaH), and raw
Tooling.

Tooling and HaT are high-frequency finding generators. Tools will look
for specific vulnerabilities and tirelessly attempt to find every
instance of that vulnerability and will generate high finding counts for
some vulnerability types. Look at Cross-Site Scripting, which is
typically one of two flavors: it's either a more minor, isolated mistake
or a systemic issue. When it's a systemic issue, the finding counts can
be in the thousands for an application. This high frequency drowns out
most other vulnerabilities found in reports or data.

TaH, on the other hand, will find a broader range of vulnerability types
but at a much lower frequency due to time constraints. When humans test
an application and see something like Cross-Site Scripting, they will
typically find three or four instances and stop. They can determine a
systemic finding and write it up with a recommendation to fix on an
application-wide scale. There is no need (or time) to find every
instance.

Suppose we take these two distinct data sets and try to merge them on
frequency. In that case, the Tooling and HaT data will drown the more
accurate (but broad) TaH data and is a good part of why something like
Cross-Site Scripting has been so highly ranked in many lists when the
impact is generally low to moderate. It's because of the sheer volume of
findings. (Cross-Site Scripting is also reasonably easy to test for, so
there are many more tests for it as well).

In 2017, we introduced using incidence rate instead to take a fresh look
at the data and cleanly merge Tooling and HaT data with TaH data. The
incidence rate asks what percentage of the application population had at
least one instance of a vulnerability type. We don't care if it was
one-off or systemic. That's irrelevant for our purposes; we just need to
know how many applications had at least one instance, which helps
provide a clearer view of the testing is findings across multiple
testing types without drowning the data in high-frequency results.

What is your data collection and analysis process? Copy Chapter

We formalized the OWASP Top 10 data collection process at the Open
Security Summit in 2017. OWASP Top 10 leaders and the community spent
two days working out formalizing a transparent data collection process.
The 2021 edition is the second time we have used this methodology.

We publish a call for data through social media channels available to
us, both project and OWASP. On the OWASP Project
page, we list the
data elements and structure we are looking for and how to submit them.
In the GitHub
project, we have
example files that serve as templates. We work with organizations as
needed to help figure out the structure and mapping to CWEs.

We get data from organizations that are testing vendors by trade, bug
bounty vendors, and organizations that contribute internal testing data.
Once we have the data, we load it together and run a fundamental
analysis of what CWEs map to risk categories. There is overlap between
some CWEs, and others are very closely related (ex. Cryptographic
vulnerabilities). Any decisions related to the raw data submitted are
documented and published to be open and transparent with how we
normalized the data.

We look at the eight categories with the highest incidence rates for
inclusion in the Top 10. We also look at the industry survey results to
see which ones may already be present in the data. The top two votes
that aren't already present in the data will be selected for the other
two places in the Top 10. Once all ten were selected, we applied
generalized factors for exploitability and impact; to help rank the Top
10 in order.

Data Factors Copy Chapter

There are data factors that are listed for each of the Top 10
Categories, here is what they mean:

• CWEs Mapped: The number of CWEs mapped to a category by the Top 10
  team.

• Incidence Rate: Incidence rate is the percentage of applications
  vulnerable to that CWE from the population tested by that org for
  that year.

• (Testing) Coverage: The percentage of applications tested by all
  organizations for a given CWE.

• Weighted Exploit: The Exploit sub-score from CVSSv2 and CVSSv3
  scores assigned to CVEs mapped to CWEs, normalized, and placed on a
  10pt scale.

• Weighted Impact: The Impact sub-score from CVSSv2 and CVSSv3
  scores assigned to CVEs mapped to CWEs, normalized, and placed on a
  10pt scale.

• Total Occurrences: Total number of applications found to have the
  CWEs mapped to a category.

• Total CVEs: Total number of CVEs in the NVD DB that were mapped to
  the CWEs mapped to a category.

Category Relationships from 2017 Copy Chapter

There has been a lot of talk about the overlap between the Top Ten
risks. By the definition of each (list of CWEs included), there really
isn't any overlap. However, conceptually, there can be overlap or
interactions based on the higher-level naming. Venn diagrams are many
times used to show overlap like this.

The Venn diagram above represents the interactions between the Top Ten
2017 risk categories. While doing so, a couple of essential points
became obvious:

1. One could argue that Cross-Site Scripting ultimately belongs within
   Injection as it's essentially Content Injection. Looking at the 2021
   data, it became even more evident that XSS needed to move into
   Injection.

2. The overlap is only in one direction. We will often classify a
   vulnerability by the end manifestation or "symptom," not the
   (potentially deep) root cause. For instance, "Sensitive Data
   Exposure" may have been the result of a "Security Misconfiguration";
   however, you won't see it in the other direction. As a result,
   arrows are drawn in the interaction zones to indicate which
   direction it occurs.

3. Sometimes these diagrams are drawn with everything in A06:2021
   Using Components with Known Vulnerabilities. While some of these
   risk categories may be the root cause of third-party
   vulnerabilities, they are generally managed differently and with
   different responsibilities. The other types are typically
   representing first-party risks.

Thank you to our data contributors

The following organizations (along with some anonymous donors) kindly
donated data for over 500,000 applications to make this the largest and
most comprehensive application security data set. Without you, this
would not be possible.

Thank you to our sponsors Copy Chapter

The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior and Just Eat.

{ width="256" }

{ width="256" }

2025 Docs Cs Index (`2025/docs/cs/index.md`) Copy Section

OWASP Top 10:2025

Vítejte u vydání OWASP Top 10:2025.

OWASP Top 10 je referenční dokument pro zvyšování povědomí určený vývojářům a odborníkům na bezpečnost webových aplikací. Představuje široce sdílený konsenzus o nejkritičtějších bezpečnostních rizicích webových aplikací.

O tomto vydání Copy Chapter

Toto je verze OWASP Top 10 pro rok 2025. Obsahuje aktualizace vycházející z nejnovějších dat a bezpečnostních trendů.

Main Project Page Copy Chapter

Hlavní stránka projektu obsahuje informace o starších verzích a metadata o tomto projektu.

Začínáme Copy Chapter

Začněte Úvodem kde se dozvíte, co je ve verzi 2025 nového.

Navigace Copy Chapter

• Úvod
• O OWASP
• Co jsou bezpečnostní rizika aplikací??
• Zavedení moderního programu bezpečnosti aplikací

Top 10:2025 List Copy Section

1. A01:2025 - Narušené řízení přístupu (Broken Access Control)
2. A02:2025 - Chybná bezpečnostní konfigurace (Security Misconfiguration)
3. A03:2025 - Selhání dodavatelského řetězce softwaru (Software Supply Chain Failures)
4. A04:2025 - Kryptografická selhání (Cryptographic Failures)
5. A05:2025 - Injekce (Injection)
6. A06:2025 - Nezabezpečený návrh (Insecure Design)
7. A07:2025 - Selhání autentizace (Authentication Failures)
8. A08:2025 - Selhání integrity softwaru nebo dat (Software or Data Integrity Failures)
9. A09:2025 - Selhání bezpečnostního logování a upozorňování (Security Logging & Alerting Failures)
10. A10:2025 - Nesprávné zpracování výjimečných stavů (Mishandling of Exceptional Conditions)

Poznámka: Překlady budou doplňovány, jakmile budou k dispozici.

2025 Docs De Index (`2025/docs/de/index.md`) Copy Section

OWASP Top 10:2025

Willkommen bei den OWASP Top 10:2025.

Die OWASP Top 10 ist ein Standarddokument zur Sensibilisierung von Entwickler:innen für die Sicherheit von Webanwendungen. Sie spiegelt einen breiten Konsens über die kritischsten Sicherheitsrisiken für Webanwendungen wider.

Über diese Veröffentlichung Copy Chapter

Dies ist die 2025-Version der OWASP Top 10. Diese Version enthält Aktualisierungen auf der Grundlage der neuesten Daten und Sicherheitstrends.

Hauptseite des Projekts Copy Chapter

Auf der Hauptseite des Projekts finden Sie Informationen zu älteren Versionen sowie Metadaten zu diesem Projekt.

Erste Schritte Copy Chapter

Beginnen Sie mit der Einführung, um mehr über die Neuerungen in der Version 2025 zu erfahren.

Navigation Copy Chapter

• Einführung
• Über OWASP
• Was sind Sicherheitsrisiken für die Anwendungen?
• Aufbau eines modernen Programms zur Anwendungssicherheit

Liste der Top 10:2025 Copy Section

1. A01:2025 - Mangelhafte Zugriffskontrolle
2. A02:2025 - Sicherheitsrelevante Fehlkonfiguration
3. A03:2025 - Schwachstellen in der Software-Lieferkette
4. A04:2025 - Fehlerhafter Einsatz von Kryptografie
5. A05:2025 - Injection
6. A06:2025 - Unsicheres Design
7. A07:2025 - Fehlerhafte Authentifizierung
8. A08:2025 - Fehler bei der Software- oder Datenintegrität
9. A09:2025 - Unzureichendes Sicherheitslogging und Alarmierung
10. A10:2025 - Fehlerhafte Behandlung von Ausnahmezuständen

2025 Docs En Index (`2025/docs/en/index.md`) Copy Section

OWASP Top 10:2025

Welcome to the OWASP Top 10:2025 Release.

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.

About This Release Copy Chapter

This is the 2025 version of the OWASP Top 10. This version includes updates based on the latest data and security trends.

Main Project Page Copy Chapter

The main project page has information about older versions and metadata about this project.

Getting Started Copy Chapter

Start with the Introduction to learn about what's new in the 2025 version.

Navigation Copy Chapter

• Introduction
• About OWASP
• What are Application Security Risks?
• Establishing a Modern Application Security Program

Top 10:2025 List Copy Section

1. A01:2025 - Broken Access Control
2. A02:2025 - Security Misconfiguration
3. A03:2025 - Software Supply Chain Failures
4. A04:2025 - Cryptographic Failures
5. A05:2025 - Injection
6. A06:2025 - Insecure Design
7. A07:2025 - Authentication Failures
8. A08:2025 - Software or Data Integrity Failures
9. A09:2025 - Security Logging and Alerting Failures
10. A10:2025 - Mishandling of Exceptional Conditions

Note: Translations will be added as they become available.

2025 Docs Es Index (`2025/docs/es/index.md`) Copy Section

OWASP Top 10:2025

Bienvenido al lanzamiento de OWASP Top 10:2025.

El OWASP Top 10 es un documento estándar de concienciación para desarrolladores y seguridad de aplicaciones web. Representa un amplio consenso sobre los riesgos de seguridad más críticos para las aplicaciones web.

Sobre este lanzamiento Copy Chapter

Esta es la versión 2025 del OWASP Top 10. Esta versión incluye actualizaciones basadas en los últimos datos y tendencias de seguridad.

Página principal del proyecto Copy Chapter

La página principal del proyecto contiene información sobre versiones anteriores y metadatos sobre este proyecto.

Primeros pasos Copy Chapter

Comience con la Introducción para conocer las novedades de la versión 2025.

Navegación Copy Chapter

• Introducción
• Sobre OWASP
• ¿Qué son los riesgos de seguridad de las aplicaciones?
• Establecimiento de un programa moderno de seguridad de aplicaciones

Lista Top 10:2025 Copy Section

1. A01:2025 - Pérdida de Control de Acceso
2. A02:2025 - Configuración de Seguridad Incorrecta
3. A03:2025 - Fallas en la Cadena de Suministro de Software
4. A04:2025 - Fallas Criptográficas
5. A05:2025 - Inyección
6. A06:2025 - Diseño Inseguro
7. A07:2025 - Fallas de Autenticación
8. A08:2025 - Fallas en la Integridad del Software o de los Datos
9. A09:2025 - Fallas en el Registro, Alerta y Monitoreo de Seguridad
10. A10:2025 - Manejo Inadecuado de Condiciones Excepcionales

Nota: Las traducciones se añadirán a medida que estén disponibles.

2025 Docs It Index (`2025/docs/it/index.md`) Copy Section

OWASP Top 10:2025

Benvenuto nella versione OWASP Top 10:2025.

L'OWASP Top 10 è un documento di riferimento per la sensibilizzazione di sviluppatori e professionisti della sicurezza delle applicazioni web. Rappresenta un ampio consenso sui rischi di sicurezza più critici per le applicazioni web.

Informazioni su questa versione Copy Chapter

Questa è la versione 2025 dell'OWASP Top 10. Questa versione include aggiornamenti basati sui dati più recenti e sulle ultime tendenze in materia di sicurezza.

Pagina principale del progetto Copy Chapter

La pagina principale del progetto contiene informazioni sulle versioni precedenti e metadati su questo progetto.

Per iniziare Copy Chapter

Inizia dall'Introduzione per scoprire le novità della versione 2025.

Navigazione Copy Chapter

• Introduzione
• Informazioni su OWASP
• Cosa sono i Rischi di Sicurezza delle Applicazioni?
• Stabilire un Programma Moderno di Sicurezza Applicativa

Lista Top 10:2025 Copy Section

1. A01:2025 - Broken Access Control
2. A02:2025 - Security Misconfiguration
3. A03:2025 - Software Supply Chain Failures
4. A04:2025 - Cryptographic Failures
5. A05:2025 - Injection
6. A06:2025 - Insecure Design
7. A07:2025 - Authentication Failures
8. A08:2025 - Software or Data Integrity Failures
9. A09:2025 - Security Logging and Alerting Failures
10. A10:2025 - Mishandling of Exceptional Conditions

Nota: Le traduzioni verranno aggiunte man mano che saranno disponibili.

2025 Docs Ja Index (`2025/docs/ja/index.md`) Copy Section

OWASP Top 10:2025

OWASP Top 10:2025 リリースへようこそ。

OWASP Top 10 は、開発者やウェブアプリケーションセキュリティに関わる人々のための、標準的な啓発資料 (Awareness document) です。これは、ウェブアプリケーションに対する最も深刻なセキュリティリスクについて、広く認められた見解を表しています。

本リリースについて (About This Release) Copy Chapter

これは OWASP Top 10 の 2025年 版です。このバージョンには、最新のデータとセキュリティ動向に基づいた更新が含まれています。

メインプロジェクトページ (Main Project Page) Copy Chapter

メインプロジェクトページ (GitHub) には、旧バージョンに関する情報や、本プロジェクトのメタデータが掲載されています。

はじめに (Getting Started) Copy Chapter

イントロダクション (Introduction) から、2025年版での新要素について確認してください。

ナビゲーション (Navigation) Copy Chapter

• イントロダクション (Introduction)
• OWASP について (About OWASP)
• アプリケーションセキュリティリスクとは何か？ (What are Application Security Risks?)
• 今日求められるアプリケーションセキュリティプログラムの確立 (Establishing a Modern Application Security Program)

Top 10:2025 リスト (Top 10:2025 List) Copy Section

1. A01:2025 - アクセス制御の不備 (Broken Access Control)
2. A02:2025 - セキュリティ設定の不備 (Security Misconfiguration)
3. A03:2025 - ソフトウェアサプライチェーンの不備 (Software Supply Chain Failures)
4. A04:2025 - 暗号化の不備 (Cryptographic Failures)
5. A05:2025 - インジェクション (Injection)
6. A06:2025 - 安全性を欠いた設計 (Insecure Design)
7. A07:2025 - 認証の不備 (Authentication Failures)
8. A08:2025 - ソフトウェアまたはデータの完全性の不備 (Software or Data Integrity Failures)
9. A09:2025 - セキュリティログとアラートの不備 (Security Logging and Alerting Failures)
10. A10:2025 - 例外的な状況への不適切な対応 (Mishandling of Exceptional Conditions)

注記： 翻訳版は、利用可能になり次第随時追加されます。

2025 Docs Ko Index (`2025/docs/ko/index.md`) Copy Section

OWASP Top 10:2025

OWASP Top 10:2025 버전에 오신 것을 환영합니다.

OWASP Top 10은 개발자와 웹 애플리케이션 보안을 위한 인식 제고용 자료이며, 웹 애플리케이션의 가장 중대한 보안 위험에 대한 업계의 폭넓은 합의를 반영한다.

이번 버전 소개 Copy Chapter

이 문서는 OWASP Top 10의 2025년 버전이다. 최신 데이터와 보안 동향을 반영하여 업데이트되었다.

메인 프로젝트 페이지 Copy Chapter

메인 프로젝트 페이지에는 과거 자료를 포함한, 해당 프로젝트의 메타데이터가 정리되어 있다.

시작하기 Copy Chapter

2025년 버전에서 변경되거나 추가된 내용을 파악하려면 소개 페이지를 획인하라.

목차 Copy Chapter

• 소개
• OWASP 소개
• 애플리케이션 보안 위험이란 무엇인가?
• 현대적 애플리케이션 보안 체계 수립

Top 10:2025 목록 Copy Section

1. A01:2025 - 충분한 접근 제어
2. A02:2025 - 보안 설정 오류
3. A03:2025 - 소프트웨어 공급망 실패
4. A04:2025 - 암호 체계 실패
5. A05:2025 - 인젝션
6. A06:2025 - 안전하지 않은 설계
7. A07:2025 - 인증 실패
8. A08:2025 - 소프트웨어 또는 데이터 무결성 실패
9. A09:2025 - 보안 로깅 및 알림 실패
10. A10:2025 - 부적절한 예외 처리

참고: 번역은 준비되는 대로 순차적으로 추가될 예정이다.

2025 Docs Pt BR Index (`2025/docs/pt-BR/index.md`) Copy Section

OWASP Top 10:2025

Bem-vindo ao lançamento do OWASP Top 10:2025.

O OWASP Top 10 é um documento padrão de conscientização para desenvolvedores e segurança de aplicações web. Ele representa um amplo consenso sobre os riscos de segurança mais críticos para aplicações web.

Sobre este Lançamento Copy Chapter

Esta é a versão 2025 do OWASP Top 10. Esta versão inclui atualizações baseadas nos dados e tendências de segurança mais recentes.

Página Principal do Projeto Copy Chapter

A página principal do projeto contém informações sobre versões anteriores e metadados sobre este projeto.

Primeiros Passos Copy Chapter

Comece pela Introdução para saber o que há de novo na versão 2025.

Navegação Copy Chapter

• Introdução
• Sobre a OWASP
• O que são Riscos de Segurança de Aplicações?
• Estabelecendo um Programa Moderno de Segurança de Aplicações

Lista do Top 10:2025 Copy Section

1. A01:2025 - Controle de Acesso Quebrado
2. A02:2025 - Configuração Insegura
3. A03:2025 - Falhas na Cadeia de Suprimentos de Software
4. A04:2025 - Falhas Criptográficas
5. A05:2025 - Injeção
6. A06:2025 - Design Inseguro
7. A07:2025 - Falhas de Autenticação
8. A08:2025 - Falhas de Integridade de Software ou de Dados
9. A09:2025 - Falhas de Registro e Monitoramento de Segurança
10. A10:2025 - Tratamento Incorreto de Condições Excepcionais

Nota: As traduções serão adicionadas conforme estiverem disponíveis.

2025 Docs Zh Hant Index (`2025/docs/zh-Hant/index.md`) Copy Section

OWASP Top 10:2025

欢迎阅读 OWASP Top 10:2025 发布版。

OWASP Top 10 是面向开发人员和 Web 应用安全从业者的标准安全意识文档。它代表了业界对 Web 应用最关键安全风险的广泛共识。

关于本次发布 Copy Chapter

这是 OWASP Top 10 的 2025 版本。本版本根据最新数据和安全趋势进行了更新。

主项目页面 Copy Chapter

主项目页面 包含旧版本信息以及本项目的元数据。

开始阅读 Copy Chapter

建议从引言开始，了解 2025 版本的新变化。

导航 Copy Chapter

• 引言
• 关于 OWASP
• 什么是应用安全风险？
• 建立现代应用安全计划

Top 10:2025 列表 Copy Section

1. A01:2025 - 失效的访问控制
2. A02:2025 - 安全配置错误
3. A03:2025 - 软件供应链失效
4. A04:2025 - 加密机制失效
5. A05:2025 - 注入
6. A06:2025 - 不安全设计
7. A07:2025 - 认证失效
8. A08:2025 - 软件或数据完整性失效
9. A09:2025 - 安全日志和告警失效
10. A10:2025 - 异常条件处理不当

注意： 翻译会在可用时逐步加入。

Osib Docs A00 2021 Introduction (`osib/docs/A00_2021_Introduction.md`) Copy Section

source: "https://owasp.org/Top10/A00_2021_Introduction/" title: "A00_2021_Introduction" id: "introduction" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".index" -%}
{%- set parent_2017 = extra.osib.document ~ ".2017" -%}

Introduction

Welcome to the OWASP Top 10 - 2021 Copy Chapter

{:class="img-responsive"}

Welcome to the latest installment of the OWASP Top 10! The OWASP Top 10 2021 is all-new, with a new graphic design and an available one-page infographic you can print or obtain from our home page.

A huge thank you to everyone that contributed their time and data for this iteration. Without you, this installment would not happen. THANK YOU!

What's changed in the Top 10 for 2021 Copy Chapter

There are three new categories, four categories with naming and scoping changes, and some consolidation in the Top 10 for 2021. We've changed names when necessary to focus on the root cause over the symptom.

• A01:2021-Broken Access Control moves up from the {{ osib_link(link=parent_2017 ~ ".5", text="fifth position", doc="", latest=0) }} to the category with the most serious web application security risk; the contributed data indicates that on average, 3.81% of applications tested had one or more Common Weakness Enumerations (CWEs) with more than 318k occurrences of CWEs in this risk category. The 34 CWEs mapped to Broken Access Control had more occurrences in applications than any other category.
• A02:2021-Cryptographic Failures shifts up one position to #2, previously known as {{ osib_link(link=parent_2017 ~ ".3", doc="", latest=0) }}, which was broad symptom rather than a root cause. The renewed name focuses on failures related to cryptography as it has been implicitly before. This category often leads to sensitive data exposure or system compromise.
• A03:2021-Injection slides {{ osib_link(link=parent_2017 ~ ".1", text="down", doc="", latest=0) }} to the third position. 94% of the applications were tested for some form of injection with a max incidence rate of 19%, an average incidence rate of 3.37%, and the 33 CWEs mapped into this category have the second most occurrences in applications with 274k occurrences. Cross-site Scripting is now part of this category in this edition.
• A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to "move left" as an industry, we need more threat modeling, secure design patterns and principles, and reference architectures. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.
• A05:2021-Security Misconfiguration moves up from {{ osib_link(link=parent_2017 ~ ".6", text="#6 in the previous edition", doc="", latest=0) }}; 90% of applications were tested for some form of misconfiguration, with an average incidence rate of 4.5%, and over 208k occurrences of CWEs mapped to this risk category. With more shifts into highly configurable software, it's not surprising to see this category move up. The former category for {{ osib_link(link=parent_2017 ~ ".4", doc="", latest=0) }} is now part of this risk category.
• A06:2021-Vulnerable and Outdated Components was previously titled Using Components with Known Vulnerabilities and is #2 in the Top 10 community survey, but also had enough data to make the Top 10 via data analysis. This category moves up from {{ osib_link(link=parent_2017 ~ ".9", text="#9 in 2017", doc="", latest=0) }} and is a known issue that we struggle to test and assess risk. It is the only category not to have any Common Vulnerability and Exposures (CVEs) mapped to the included CWEs, so a default exploit and impact weights of 5.0 are factored into their scores.
• A07:2021-Identification and Authentication Failures was previously Broken Authentication and is sliding down from the {{ osib_link(link=parent_2017 ~ ".2", text="second position", doc="", latest=0) }}, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping.
• A08:2021-Software and Data Integrity Failures is a new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data mapped to the 10 CWEs in this category. {{ osib_link(link=parent_2017 ~ ".8", doc="", latest=0) }} is now a part of this larger category.
• A09:2021-Security Logging and Monitoring Failures was previously {{ osib_link(link=parent_2017 ~ ".10", doc="", latest=0) }} and is added from the Top 10 community survey (#3), moving up from #10 previously. This category is expanded to include more types of failures, is challenging to test for, and isn't well represented in the CVE/CVSS data. However, failures in this category can directly impact visibility, incident alerting, and forensics.
• A10:2021-Server-Side Request Forgery is added from the Top 10 community survey (#1). The data shows a relatively low incidence rate with above average testing coverage, along with above-average ratings for Exploit and Impact potential. This category represents the scenario where the security community members are telling us this is important, even though it's not illustrated in the data at this time.

Methodology Copy Chapter

This installment of the Top 10 is more data-driven than ever but not blindly data-driven. We selected eight of the ten categories from contributed data and two categories from the Top 10 community survey at a high level. We do this for a fundamental reason, looking at the contributed data is looking into the past. AppSec researchers take time to find new vulnerabilities and new ways to test for them. It takes time to integrate these tests into tools and processes. By the time we can reliably test a weakness at scale, years have likely passed. To balance that view, we use a community survey to ask application security and development experts on the front lines what they see as essential weaknesses that the data may not show yet.

There are a few critical changes that we adopted to continue to mature the Top 10.

How the categories are structured Copy Chapter

A few categories have changed from the previous installment of the OWASP Top Ten. Here is a high-level summary of the category changes.

Previous data collection efforts were focused on a prescribed subset of approximately 30 CWEs with a field asking for additional findings. We learned that organizations would primarily focus on just those 30 CWEs and rarely add additional CWEs that they saw. In this iteration, we opened it up and just asked for data, with no restriction on CWEs. We asked for the number of applications tested for a given year (starting in 2017), and the number of applications with at least one instance of a CWE found in testing. This format allows us to track how prevalent each CWE is within the population of applications. We ignore frequency for our purposes; while it may be necessary for other situations, it only hides the actual prevalence in the application population. Whether an application has four instances of a CWE or 4,000 instances is not part of the calculation for the Top 10. We went from approximately 30 CWEs to almost 400 CWEs to analyze in the dataset. We plan to do additional data analysis as a supplement in the future. This significant increase in the number of CWEs necessitates changes to how the categories are structured.

We spent several months grouping and categorizing CWEs and could have continued for additional months. We had to stop at some point. There are both root cause and symptom types of CWEs, where root cause types are like "Cryptographic Failure" and "Misconfiguration" contrasted to symptom types like "Sensitive Data Exposure" and "Denial of Service." We decided to focus on the root cause whenever possible as it's more logical for providing identification and remediation guidance. Focusing on the root cause over the symptom isn't a new concept; the Top Ten has been a mix of symptom and root cause. CWEs are also a mix of symptom and root cause; we are simply being more deliberate about it and calling it out. There is an average of 19.6 CWEs per category in this installment, with the lower bounds at 1 CWE for A10:2021-Server-Side Request Forgery to 40 CWEs in A04:2021-Insecure Design. This updated category structure offers additional training benefits as companies can focus on CWEs that make sense for a language/framework.

How the data is used for selecting categories Copy Chapter

In 2017, we selected categories by incidence rate to determine likelihood, then ranked them by team discussion based on decades of experience for Exploitability, Detectability (also likelihood), and Technical Impact. For 2021, we want to use data for Exploitability and (Technical) Impact if possible.

We downloaded OWASP Dependency Check and extracted the CVSS Exploit, and Impact scores grouped by related CWEs. It took a fair bit of research and effort as all the CVEs have CVSSv2 scores, but there are flaws in CVSSv2 that CVSSv3 should address. After a certain point in time, all CVEs are assigned a CVSSv3 score as well. Additionally, the scoring ranges and formulas were updated between CVSSv2 and CVSSv3.

In CVSSv2, both Exploit and (Technical) Impact could be up to 10.0, but the formula would knock them down to 60% for Exploit and 40% for Impact. In CVSSv3, the theoretical max was limited to 6.0 for Exploit and 4.0 for Impact. With the weighting considered, the Impact scoring shifted higher, almost a point and a half on average in CVSSv3, and exploitability moved nearly half a point lower on average.

There are 125k records of a CVE mapped to a CWE in the National Vulnerability Database (NVD) data extracted from OWASP Dependency Check, and there are 241 unique CWEs mapped to a CVE. 62k CWE maps have a CVSSv3 score, which is approximately half of the population in the data set.

For the Top Ten 2021, we calculated average exploit and impact scores in the following manner. We grouped all the CVEs with CVSS scores by CWE and weighted both exploit and impact scored by the percentage of the population that had CVSSv3 + the remaining population of CVSSv2 scores to get an overall average. We mapped these averages to the CWEs in the dataset to use as Exploit and (Technical) Impact scoring for the other half of the risk equation.

Why not just pure statistical data? Copy Chapter

The results in the data are primarily limited to what we can test for in an automated fashion. Talk to a seasoned AppSec professional, and they will tell you about stuff they find and trends they see that aren't yet in the data. It takes time for people to develop testing methodologies for certain vulnerability types and then more time for those tests to be automated and run against a large population of applications. Everything we find is looking back in the past and might be missing trends from the last year, which are not present in the data.

Therefore, we only pick eight of ten categories from the data because it's incomplete. The other two categories are from the Top 10 community survey. It allows the practitioners on the front lines to vote for what they see as the highest risks that might not be in the data (and may never be expressed in data).

Why incidence rate instead of frequency? Copy Chapter

There are three primary sources of data. We identify them as Human-assisted Tooling (HaT), Tool-assisted Human (TaH), and raw Tooling.

Tooling and HaT are high-frequency finding generators. Tools will look for specific vulnerabilities and tirelessly attempt to find every instance of that vulnerability and will generate high finding counts for some vulnerability types. Look at Cross-Site Scripting, which is typically one of two flavors: it's either a more minor, isolated mistake or a systemic issue. When it's a systemic issue, the finding counts can be in the thousands for a single application. This high frequency drowns out most other vulnerabilities found in reports or data.

TaH, on the other hand, will find a broader range of vulnerability types but at a much lower frequency due to time constraints. When humans test an application and see something like Cross-Site Scripting, they will typically find three or four instances and stop. They can determine a systemic finding and write it up with a recommendation to fix on an application-wide scale. There is no need (or time) to find every instance.

Suppose we take these two distinct data sets and try to merge them on frequency. In that case, the Tooling and HaT data will drown the more accurate (but broad) TaH data and is a good part of why something like Cross-Site Scripting has been so highly ranked in many lists when the impact is generally low to moderate. It's because of the sheer volume of findings. (Cross-Site Scripting is also reasonably easy to test for, so there are many more tests for it as well).

In 2017, we introduced using incidence rate instead to take a fresh look at the data and cleanly merge Tooling and HaT data with TaH data. The incidence rate asks what percentage of the application population had at least one instance of a vulnerability type. We don't care if it was one-off or systemic. That's irrelevant for our purposes; we just need to know how many applications had at least one instance, which helps provide a clearer view of the testing is findings across multiple testing types without drowning the data in high-frequency results. This corresponds to a risk related view as an attacker needs only one instance to attack an application successfully via the category.

What is your data collection and analysis process? Copy Chapter

We formalized the OWASP Top 10 data collection process at the Open Security Summit in 2017. OWASP Top 10 leaders and the community spent two days working out formalizing a transparent data collection process. The 2021 edition is the second time we have used this methodology.

We publish a call for data through social media channels available to us, both project and OWASP. On the OWASP Project page, we list the data elements and structure we are looking for and how to submit them. In the GitHub project, we have example files that serve as templates. We work with organizations as needed to help figure out the structure and mapping to CWEs.

We get data from organizations that are testing vendors by trade, bug bounty vendors, and organizations that contribute internal testing data. Once we have the data, we load it together and run a fundamental analysis of what CWEs map to risk categories. There is overlap between some CWEs, and others are very closely related (ex. Cryptographic vulnerabilities). Any decisions related to the raw data submitted are documented and published to be open and transparent with how we normalized the data.

We look at the eight categories with the highest incidence rates for inclusion in the Top 10. We also look at the Top 10 community survey results to see which ones may already be present in the data. The top two votes that aren't already present in the data will be selected for the other two places in the Top 10. Once all ten were selected, we applied generalized factors for exploitability and impact; to help rank the Top 10 2021 in a risk based order.

Data Factors Copy Chapter

There are data factors that are listed for each of the Top 10 Categories, here is what they mean:

• CWEs Mapped: The number of CWEs mapped to a category by the Top 10 team.
• Incidence Rate: Incidence rate is the percentage of applications vulnerable to that CWE from the population tested by that org for that year.
• Weighted Exploit: The Exploit sub-score from CVSSv2 and CVSSv3 scores assigned to CVEs mapped to CWEs, normalized, and placed on a 10pt scale.
• Weighted Impact: The Impact sub-score from CVSSv2 and CVSSv3 scores assigned to CVEs mapped to CWEs, normalized, and placed on a 10pt scale.
• (Testing) Coverage: The percentage of applications tested by all organizations for a given CWE.
• Total Occurrences: Total number of applications found to have the CWEs mapped to a category.
• Total CVEs: Total number of CVEs in the NVD DB that were mapped to the CWEs mapped to a category.

Thank you to our data contributors Copy Chapter

The following organizations (along with some anonymous donors) kindly donated data for over 500,000 applications to make this the largest and most comprehensive application security data set. Without you, this would not be possible.

• AppSec Labs
• Cobalt.io
• Contrast Security
• GitLab
• HackerOne
• HCL Technologies
• Micro Focus
• PenTest-Tools
• Probely
• Sqreen
• Veracode
• WhiteHat (NTT)

Thank you to our sponsors Copy Chapter

The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior and Just Eat.

{ width="256" }

{ width="256" }

Osib Docs A01 2021 Broken Access Control (`osib/docs/A01_2021-Broken_Access_Control.md`) Copy Section

source: "https://owasp.org/Top10/A01_2021-Broken_Access_Control/" title: "A01:2021 – Broken Access Control" id: "A01:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".1" -%}

A01:2021 – Broken Access Control {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Broken Access Control", lang=lang, source=source, parent=parent, predecessor=extra.osib.document ~ ".2017.5" ) }}

Factors {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Moving up from the fifth position, 94% of applications were tested for
some form of broken access control with the average incidence rate of 3.81%, and has the most occurrences in the contributed dataset with over 318k. Notable Common Weakness Enumerations (CWEs) included are CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201:
Insertion of Sensitive Information Into Sent Data, and CWE-352:
Cross-Site Request Forgery.

Description {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Description", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Access control enforces policy such that users cannot act outside of
their intended permissions. Failures typically lead to unauthorized
information disclosure, modification, or destruction of all data or
performing a business function outside the user's limits. Common access
control vulnerabilities include:

• Violation of the principle of least privilege or deny by default,
  where access should only be granted for particular capabilities,
  roles, or users, but is available to anyone.

• Bypassing access control checks by modifying the URL (parameter
  tampering or force browsing), internal application state, or the
  HTML page, or by using an attack tool modifying API requests.

• Permitting viewing or editing someone else's account, by providing
  its unique identifier (insecure direct object references)

• Accessing API with missing access controls for POST, PUT and DELETE.

• Elevation of privilege. Acting as a user without being logged in or
  acting as an admin when logged in as a user.

• Metadata manipulation, such as replaying or tampering with a JSON
  Web Token (JWT) access control token, or a cookie or hidden field
  manipulated to elevate privileges or abusing JWT invalidation.

• CORS misconfiguration allows API access from unauthorized/untrusted
  origins.

• Force browsing to authenticated pages as an unauthenticated user or
  to privileged pages as a standard user.

How to Prevent {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Access control is only effective in trusted server-side code or
server-less API, where the attacker cannot modify the access control
check or metadata.

• Except for public resources, deny by default.

• Implement access control mechanisms once and re-use them throughout
  the application, including minimizing Cross-Origin Resource Sharing (CORS) usage.

• Model access controls should enforce record ownership rather than
  accepting that the user can create, read, update, or delete any
  record.

• Unique application business limit requirements should be enforced by
  domain models.

• Disable web server directory listing and ensure file metadata (e.g.,
  .git) and backup files are not present within web roots.

• Log access control failures, alert admins when appropriate (e.g.,
  repeated failures).

• Rate limit API and controller access to minimize the harm from
  automated attack tooling.

• Stateful session identifiers should be invalidated on the server after logout.
  Stateless JWT tokens should rather be short-lived so that the window of
  opportunity for an attacker is minimized. For longer lived JWTs it's highly recommended to
  follow the OAuth standards to revoke access.

Developers and QA staff should include functional access control unit
and integration tests.

Example Attack Scenarios {{ osib_anchor(osib=osib ~ ".example attack scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Example Attack Scenarios", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Scenario #1: The application uses unverified data in a SQL call that
is accessing account information:

pstmt.setString(1, request.getParameter("acct"));
 ResultSet results = pstmt.executeQuery( );

An attacker simply modifies the browser's 'acct' parameter to send
whatever account number they want. If not correctly verified, the
attacker can access any user's account.

https://example.com/app/accountInfo?acct=notmyacct

Scenario #2: An attacker simply force browses to target URLs. Admin
rights are required for access to the admin page.

https://example.com/app/getappInfo
 https://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, it's a flaw. If a
non-admin can access the admin page, this is a flaw.

References {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.opc.3." ~ "7", osib=osib) }}
• {{ osib_link(link="osib.owasp.asvs.4-0." ~ "4", osib=osib) }}
• {{ osib_link(link="osib.owasp.wstg.4-2.4.5", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Authorization", osib=osib) }}
• {{ osib_link(link="osib.portswigger.research.articles.exploiting cors misconfigurations for bitcoins and bounties", osib=osib) }}
• {{ osib_link(link="osib.oauth.oauth2 servers.listing authorizations.revoking access", osib=osib) }}

List of Mapped CWEs {{ osib_anchor(osib=osib ~ ".mapped cwes", id=id ~ "-mapped_cwes", name=title ~ ": List of Mapped CWEs", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.22", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.23", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.35", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.59", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.200", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.201", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.219", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.264", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.275", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.276", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.284", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.285", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.352", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.359", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.377", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.402", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.425", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.441", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.497", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.538", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.540", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.548", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.552", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.566", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.601", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.639", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.651", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.668", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.706", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.862", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.863", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.913", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.922", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.1275", doc="", osib=osib) }}

Osib Docs A02 2021 Cryptographic Failures (`osib/docs/A02_2021-Cryptographic_Failures.md`) Copy Section

source: "https://owasp.org/Top10/A02_2021-Cryptographic_Failures/" title: "A02:2021 – Cryptographic Failures" id: "A02:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".2" -%}
#A02:2021 – Cryptographic Failures {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Cryptographic Failures", lang=lang, source=source, parent=parent, predecessor=extra.osib.document ~ ".2017.3") }}

Factors {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Shifting up one position to #2, previously known as Sensitive Data
Exposure, which is more of a broad symptom rather than a root cause,
the focus is on failures related to cryptography (or lack thereof).
Which often lead to exposure of sensitive data. Notable Common Weakness Enumerations (CWEs) included
are CWE-259: Use of Hard-coded Password, CWE-327: Broken or Risky
Crypto Algorithm, and CWE-331 Insufficient Entropy.

Description {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Description", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

The first thing is to determine the protection needs of data in transit
and at rest. For example, passwords, credit card numbers, health
records, personal information, and business secrets require extra
protection, mainly if that data falls under privacy laws, e.g., EU's
General Data Protection Regulation (GDPR), or regulations, e.g.,
financial data protection such as PCI Data Security Standard (PCI DSS).
For all such data:

• Is any data transmitted in clear text? This concerns protocols such
  as HTTP, SMTP, FTP also using TLS upgrades like STARTTLS. External
  internet traffic is hazardous. Verify all internal traffic, e.g.,
  between load balancers, web servers, or back-end systems.

• Are any old or weak cryptographic algorithms or protocols used either
  by default or in older code?

• Are default crypto keys in use, weak crypto keys generated or
  re-used, or is proper key management or rotation missing?
  Are crypto keys checked into source code repositories?

• Is encryption not enforced, e.g., are any HTTP headers (browser)
  security directives or headers missing?

• Is the received server certificate and the trust chain properly validated?

• Are initialization vectors ignored, reused, or not generated
  sufficiently secure for the cryptographic mode of operation?
  Is an insecure mode of operation such as ECB in use? Is encryption
  used when authenticated encryption is more appropriate?

• Are passwords being used as cryptographic keys in absence of a
  password base key derivation function?

• Is randomness used for cryptographic purposes that was not designed
  to meet cryptographic requirements? Even if the correct function is
  chosen, does it need to be seeded by the developer, and if not, has
  the developer over-written the strong seeding functionality built into
  it with a seed that lacks sufficient entropy/unpredictability?

• Are deprecated hash functions such as MD5 or SHA1 in use, or are
  non-cryptographic hash functions used when cryptographic hash functions
  are needed?

• Are deprecated cryptographic padding methods such as PKCS number 1 v1.5
  in use?

• Are cryptographic error messages or side channel information
  exploitable, for example in the form of padding oracle attacks?

See {{ osib_link(link="osib.owasp.asvs.4-0.6", prefix="ASVS ", doc="", osib=osib) }}, {{ osib_link(link= "osib.owasp.asvs.4-0.8", doc="", osib=osib) }}, {{ osib_link(link= "osib.owasp.asvs.4-0.9", doc="", osib=osib) }}

How to Prevent {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Do the following, at a minimum, and consult the references:

• Classify data processed, stored, or transmitted by an application.
  Identify which data is sensitive according to privacy laws,
  regulatory requirements, or business needs.

• Don't store sensitive data unnecessarily. Discard it as soon as
  possible or use PCI DSS compliant tokenization or even truncation.
  Data that is not retained cannot be stolen.

• Make sure to encrypt all sensitive data at rest.

• Ensure up-to-date and strong standard algorithms, protocols, and
  keys are in place; use proper key management.

• Encrypt all data in transit with secure protocols such as TLS with
  forward secrecy (FS) ciphers, cipher prioritization by the
  server, and secure parameters. Enforce encryption using directives
  like HTTP Strict Transport Security (HSTS).

• Disable caching for response that contain sensitive data.

• Apply required security controls as per the data classification.

• Do not use legacy protocols such as FTP and SMTP for transporting
  sensitive data.

• Store passwords using strong adaptive and salted hashing functions
  with a work factor (delay factor), such as Argon2, scrypt, bcrypt or
  PBKDF2.

• Initialization vectors must be chosen appropriate for the mode of
  operation. For many modes, this means using a CSPRNG (cryptographically
  secure pseudo random number generator). For modes that require a
  nonce, then the initialization vector (IV) does not need a CSPRNG. In all cases, the IV
  should never be used twice for a fixed key.

• Always use authenticated encryption instead of just encryption.

• Keys should be generated cryptographically randomly and stored in
  memory as byte arrays. If a password is used, then it must be converted
  to a key via an appropriate password base key derivation function.

• Ensure that cryptographic randomness is used where appropriate, and
  that it has not been seeded in a predictable way or with low entropy.
  Most modern APIs do not require the developer to seed the CSPRNG to
  get security.

• Avoid deprecated cryptographic functions and padding schemes, such as
  MD5, SHA1, PKCS number 1 v1.5 .

• Verify independently the effectiveness of configuration and
  settings.

Example Attack Scenarios {{ osib_anchor(osib=osib ~ ".example attack scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Example Attack Scenarios", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Scenario #1: An application encrypts credit card numbers in a
database using automatic database encryption. However, this data is
automatically decrypted when retrieved, allowing a SQL injection flaw to
retrieve credit card numbers in clear text.

Scenario #2: A site doesn't use or enforce TLS for all pages or
supports weak encryption. An attacker monitors network traffic (e.g., at
an insecure wireless network), downgrades connections from HTTPS to
HTTP, intercepts requests, and steals the user's session cookie. The
attacker then replays this cookie and hijacks the user's (authenticated)
session, accessing or modifying the user's private data. Instead of the
above they could alter all transported data, e.g., the recipient of a
money transfer.

Scenario #3: The password database uses unsalted or simple hashes to
store everyone's passwords. A file upload flaw allows an attacker to
retrieve the password database. All the unsalted hashes can be exposed
with a rainbow table of pre-calculated hashes. Hashes generated by
simple or fast hash functions may be cracked by GPUs, even if they were
salted.

References {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.opc.3." ~ "8", osib=osib) }}
• {{ osib_link(link="osib.owasp.asvs.4-0.6", osib=osib) }}, {{ osib_link(link= "osib.owasp.asvs.4-0.8", doc="", osib=osib) }}, {{ osib_link(link= "osib.owasp.asvs.4-0.9", doc="", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Transport Layer Protection", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "User Privacy Protection", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Password Storage", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Cryptographic Storage", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "HSTS", osib=osib) }}
• {{ osib_link(link="osib.owasp.wstg.4-2.4.9", osib=osib) }}

List of Mapped CWEs {{ osib_anchor(osib=osib ~ ".mapped cwes", id=id ~ "-mapped_cwes", name=title ~ ": List of Mapped CWEs", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.261", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.296", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.310", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.319", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.321", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.322", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.323", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.324", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.325", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.326", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.327", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.328", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.329", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.330", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.331", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.335", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.336", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.337", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.338", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.340", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.347", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.523", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.720", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.757", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.759", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.760", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.780", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.818", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.916", doc="", osib=osib) }}

Osib Docs A03 2021 Injection (`osib/docs/A03_2021-Injection.md`) Copy Section

source: "https://owasp.org/Top10/A03_2021-Injection/" title: "A03:2021 – Injection" id: "A03:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".3" -%}
#A03:2021 – Injection {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Injection", lang=lang, source=source, parent=parent, merged_from=[extra.osib.document ~ ".2017.1", extra.osib.document ~ ".2017.7"] ) }}

Factors {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Injection slides down to the third position. 94% of the applications
were tested for some form of injection with a max incidence rate of 19%, an average incidence rate of 3%, and 274k occurrences. Notable Common Weakness Enumerations (CWEs) included are
CWE-79: Cross-site Scripting, CWE-89: SQL Injection, and CWE-73:
External Control of File Name or Path.

Description {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Description", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

An application is vulnerable to attack when:

• User-supplied data is not validated, filtered, or sanitized by the
  application.

• Dynamic queries or non-parameterized calls without context-aware
  escaping are used directly in the interpreter.

• Hostile data is used within object-relational mapping (ORM) search
  parameters to extract additional, sensitive records.

• Hostile data is directly used or concatenated. The SQL or command
  contains the structure and malicious data in dynamic queries,
  commands, or stored procedures.

Some of the more common injections are SQL, NoSQL, OS command, Object
Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object
Graph Navigation Library (OGNL) injection. The concept is identical
among all interpreters. Source code review is the best method of
detecting if applications are vulnerable to injections. Automated
testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML
data inputs is strongly encouraged. Organizations can include
static (SAST), dynamic (DAST), and interactive (IAST) application security testing tools into the CI/CD
pipeline to identify introduced injection flaws before production
deployment.

How to Prevent {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Preventing injection requires keeping data separate from commands and queries:

• The preferred option is to use a safe API, which avoids using the
  interpreter entirely, provides a parameterized interface, or
  migrates to Object Relational Mapping Tools (ORMs).
  Note: Even when parameterized, stored procedures can still introduce
  SQL injection if PL/SQL or T-SQL concatenates queries and data or
  executes hostile data with EXECUTE IMMEDIATE or exec().

• Use positive server-side input validation. This is
  not a complete defense as many applications require special
  characters, such as text areas or APIs for mobile applications.

• For any residual dynamic queries, escape special characters using
  the specific escape syntax for that interpreter.
  Note: SQL structures such as table names, column names, and so on
  cannot be escaped, and thus user-supplied structure names are
  dangerous. This is a common issue in report-writing software.

• Use LIMIT and other SQL controls within queries to prevent mass
  disclosure of records in case of SQL injection.

Example Attack Scenarios {{ osib_anchor(osib=osib ~ ".example attack scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Example Attack Scenarios", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Scenario #1: An application uses untrusted data in the construction
of the following vulnerable SQL call:

String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Scenario #2: Similarly, an application’s blind trust in frameworks
may result in queries that are still vulnerable, (e.g., Hibernate Query
Language (HQL)):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

In both cases, the attacker modifies the ‘id’ parameter value in their
browser to send: ' UNION SLEEP(10);--. For example:

http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

This changes the meaning of both queries to return all the records from
the accounts table. More dangerous attacks could modify or delete data
or even invoke stored procedures.

References {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.opc.3." ~ "3", osib=osib) }}
• {{ osib_link(link="osib.owasp.asvs.4-0.5", osib=osib) }}
• {{ osib_link(link="osib.owasp.wstg.4-2.4.7.5", osib=osib) }}, {{ osib_link(link="osib.owasp.wstg.4-2.4.7.12", doc="", osib=osib) }},
  {{ osib_link(link="osib.owasp.wstg.4-2.4.7.5.7", doc="", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Injection Prevention", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "SQL Injection Prevention", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Injection Prevention in Java", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Query Parameterization", osib=osib) }}
• {{ osib_link(link="osib.owasp.oat.0.14", osib=osib) }}
• {{ osib_link(link="osib.portswigger.kb.issues.serversidetemplateinjection", doc="osib.portswigger.kb.issues", osib=osib) }}

List of Mapped CWEs {{ osib_anchor(osib=osib ~ ".mapped cwes", id=id ~ "-mapped_cwes", name=title ~ ": List of Mapped CWEs", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.20", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.74", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.75", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.77", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.78", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.79", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.80", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.83", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.87", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.88", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.89", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.90", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.91", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.93", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.94", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.95", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.96", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.97", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.98", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.99", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.100", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.113", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.116", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.138", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.184", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.470", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.471", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.564", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.610", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.643", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.644", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.652", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.917", doc="", osib=osib) }}

Osib Docs A04 2021 Insecure Design (`osib/docs/A04_2021-Insecure_Design.md`) Copy Section

source: "https://owasp.org/Top10/A04_2021-Insecure_Design/" title: "A04:2021 – Insecure Design" id: "A04:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".4" -%}
#A04:2021 – Insecure Design {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Insecure Design", lang=lang, source=source, parent=parent) }}

Factors {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

A new category for 2021 focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures. As a community we need to move beyond "shift-left" in the coding space to pre-code activities that are critical for the principles of Secure by Design. Notable Common Weakness Enumerations (CWEs) include CWE-209: Generation of Error Message Containing Sensitive Information, CWE-256: Unprotected Storage of Credentials, CWE-501: Trust Boundary Violation, and CWE-522: Insufficiently Protected Credentials.

Description {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Description", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.” Insecure design is not the source for all other Top 10 risk categories. There is a difference between insecure design and insecure implementation. We differentiate between design flaws and implementation defects for a reason, they have different root causes and remediation. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks. One of the factors that contribute to insecure design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required.

Requirements and Resource Management Copy Section

Collect and negotiate the business requirements for an application with the business, including the protection requirements concerning confidentiality, integrity, availability, and authenticity of all data assets and the expected business logic. Take into account how exposed your application will be and if you need segregation of tenants (additionally to access control). Compile the technical requirements, including functional and non-functional security requirements. Plan and negotiate the budget covering all design, build, testing, and operation, including security activities.

Secure Design Copy Section

Secure design is a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods. Threat modeling should be integrated into refinement sessions (or similar activities); look for changes in data flows and access control or other security controls. In the user story development determine the correct flow and failure states, ensure they are well understood and agreed upon by responsible and impacted parties. Analyze assumptions and conditions for expected and failure flows, ensure they are still accurate and desirable. Determine how to validate the assumptions and enforce conditions needed for proper behaviors. Ensure the results are documented in the user story. Learn from mistakes and offer positive incentives to promote improvements. Secure design is neither an add-on nor a tool that you can add to software.

Secure Development Lifecycle Copy Section

Secure software requires a secure development lifecycle, some form of secure design pattern, paved road methodology, secured component library, tooling, and threat modeling. Reach out for your security specialists at the beginning of a software project throughout the whole project and maintenance of your software. Consider leveraging the OWASP Software Assurance Maturity Model (SAMM) to help structure your secure software development efforts.

How to Prevent {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• Establish and use a secure development lifecycle with AppSec
  professionals to help evaluate and design security and
  privacy-related controls

• Establish and use a library of secure design patterns or paved road
  ready to use components

• Use threat modeling for critical authentication, access control,
  business logic, and key flows

• Integrate security language and controls into user stories

• Integrate plausibility checks at each tier of your application
  (from frontend to backend)

• Write unit and integration tests to validate that all critical flows
  are resistant to the threat model. Compile use-cases and misuse-cases
  for each tier of your application.

• Segregate tier layers on the system and network layers depending on the
  exposure and protection needs

• Segregate tenants robustly by design throughout all tiers

• Limit resource consumption by user or service

Example Attack Scenarios {{ osib_anchor(osib=osib ~ ".example attack scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Example Attack Scenarios", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Scenario #1: A credential recovery workflow might include “questions
and answers,” which is prohibited by NIST 800-63b, the OWASP ASVS, and
the OWASP Top 10. Questions and answers cannot be trusted as evidence of
identity as more than one person can know the answers, which is why they
are prohibited. Such code should be removed and replaced with a more
secure design.

Scenario #2: A cinema chain allows group booking discounts and has a
maximum of fifteen attendees before requiring a deposit. Attackers could
threat model this flow and test if they could book six hundred seats and
all cinemas at once in a few requests, causing a massive loss of income.

Scenario #3: A retail chain’s e-commerce website does not have
protection against bots run by scalpers buying high-end video cards to
resell auction websites. This creates terrible publicity for the video
card makers and retail chain owners and enduring bad blood with
enthusiasts who cannot obtain these cards at any price. Careful anti-bot
design and domain logic rules, such as purchases made within a few
seconds of availability, might identify inauthentic purchases and
rejected such transactions.

References {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Secure Product Design", osib=osib) }}
• {{ osib_link(link="osib.owasp.samm.2-0." ~ "Design.Security Architecture", osib=osib) }}
• {{ osib_link(link="osib.owasp.samm.2-0." ~ "Design.Threat Assessment", osib=osib) }}
• {{ osib_link(link="osib.nist.publications.guidelines minimum standards developer verification software", osib=osib) }}
• {{ osib_link(link="osib.threatmodelingmanifesto", doc="", osib=osib) }}
• {{ osib_link(link="osib.hysnsec.awesome threat modelling", doc="", osib=osib) }}

List of Mapped CWEs {{ osib_anchor(osib=osib ~ ".mapped cwes", id=id ~ "-mapped_cwes", name=title ~ ": List of Mapped CWEs", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.73", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.183", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.209", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.213", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.235", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.256", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.257", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.266", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.269", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.280", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.311", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.312", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.313", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.316", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.419", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.430", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.434", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.444", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.451", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.472", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.501", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.522", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.525", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.539", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.579", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.598", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.602", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.642", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.646", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.650", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.653", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.656", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.657", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.799", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.807", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.840", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.841", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.927", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.1021", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.1173", doc="", osib=osib) }}

Osib Docs A05 2021 Security Misconfiguration (`osib/docs/A05_2021-Security_Misconfiguration.md`) Copy Section

source: "https://owasp.org/Top10/A05_2021-Security_Misconfiguration/" title: "A05:2021 – Security Misconfiguration" id: "A05:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".5" -%}
#A05:2021 – Security Misconfiguration {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Security Misconfiguration", lang=lang, source=source, parent=parent, merged_from=[extra.osib.document ~ ".2017.4", extra.osib.document ~ ".2017.6"]) }}

Factors {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Moving up from #6 in the previous edition, 90% of applications were
tested for some form of misconfiguration, with an average incidence rate of 4.5%, and over 208k occurrences of a Common Weakness Enumeration (CWE) in this risk category. With more shifts into highly configurable software, it's not surprising to see this category move up.
Notable CWEs included are CWE-16 Configuration and CWE-611 Improper
Restriction of XML External Entity Reference.

Description {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Description", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

The application might be vulnerable if the application is:

• Missing appropriate security hardening across any part of the
  application stack or improperly configured permissions on cloud
  services.

• Unnecessary features are enabled or installed (e.g., unnecessary
  ports, services, pages, accounts, or privileges).

• Default accounts and their passwords are still enabled and
  unchanged.

• Error handling reveals stack traces or other overly informative
  error messages to users.

• For upgraded systems, the latest security features are disabled or
  not configured securely.

• The security settings in the application servers, application
  frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases,
  etc., are not set to secure values.

• The server does not send security headers or directives, or they are
  not set to secure values.

• The software is out of date or vulnerable (see A06:2021-Vulnerable and Outdated Components).
  Without a concerted, repeatable application security configuration
  process, systems are at a higher risk.

How to Prevent {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Secure installation processes should be implemented, including:

• A repeatable hardening process makes it fast and easy to deploy
  another environment that is appropriately locked down. Development,
  QA, and production environments should all be configured
  identically, with different credentials used in each environment.
  This process should be automated to minimize the effort required to
  set up a new secure environment.

• A minimal platform without any unnecessary features, components,
  documentation, and samples. Remove or do not install unused features
  and frameworks.

• A task to review and update the configurations appropriate to all
  security notes, updates, and patches as part of the patch management
  process (see A06:2021-Vulnerable and Outdated Components). Review cloud storage permissions (e.g., S3 bucket permissions).

• A segmented application architecture provides effective and secure
  separation between components or tenants, with segmentation,
  containerization, or cloud security groups (ACLs).

• Sending security directives to clients, e.g., Security Headers.

• An automated process to verify the effectiveness of the
  configurations and settings in all environments.

Example Attack Scenarios {{ osib_anchor(osib=osib ~ ".example attack scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Example Attack Scenarios", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Scenario #1: The application server comes with sample applications
not removed from the production server. These sample applications have
known security flaws attackers use to compromise the server. Suppose one
of these applications is the admin console, and default accounts weren't
changed. In that case, the attacker logs in with default passwords and
takes over.

Scenario #2: Directory listing is not disabled on the server. An
attacker discovers they can simply list directories. The attacker finds
and downloads the compiled Java classes, which they decompile and
reverse engineer to view the code. The attacker then finds a severe
access control flaw in the application.

Scenario #3: The application server's configuration allows detailed
error messages, e.g., stack traces, to be returned to users. This
potentially exposes sensitive information or underlying flaws such as
component versions that are known to be vulnerable.

Scenario #4: A cloud service provider (CSP) has default sharing
permissions open to the Internet by other CSP users. This allows
sensitive data stored within cloud storage to be accessed.

References {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.wstg.4-2.4.2", osib=osib) }}
• {{ osib_link(link="osib.owasp.wstg.4-2.4.8", osib=osib) }}
• {{ osib_link(link="osib.owasp.asvs.4-0.14", osib=osib) }}
• {{ osib_link(link="osib.nist.csrc.sp.800-123", osib=osib) }}
• {{ osib_link(link="osib.cis.benchmarks", osib=osib) }}
• {{ osib_link(link="osib.websecurify.aws s3 bucket discovery", doc="osib.websecurify", osib=osib) }}

List of Mapped CWEs {{ osib_anchor(osib=osib ~ ".mapped cwes", id=id ~ "-mapped_cwes", name=title ~ ": List of Mapped CWEs", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.2", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.11", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.13", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.15", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.16", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.260", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.315", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.520", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.526", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.537", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.541", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.547", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.611", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.614", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.756", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.776", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.942", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.1004", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.1032", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.1174", doc="", osib=osib) }}

Osib Docs A06 2021 Vulnerable And Outdated Components (`osib/docs/A06_2021-Vulnerable_and_Outdated_Components.md`) Copy Section

source: "https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/" title: "A06:2021 – Vulnerable and Outdated Components" id: "A06:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".6" -%}
#A06:2021 – Vulnerable and Outdated Components {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Vulnerable and Outdated Components", lang=lang, source=source, parent=parent, predecessor=extra.osib.document ~ ".2017.9") }}

Factors {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

It was #2 from the Top 10 community survey but also had enough data to make the
Top 10 via data. Vulnerable Components are a known issue that we
struggle to test and assess risk and is the only category to not have
any Common Vulnerability and Exposures (CVEs) mapped to the included CWEs, so a default exploits/impact
weight of 5.0 is used. Notable CWEs included are CWE-1104: Use of
Unmaintained Third-Party Components and the two CWEs from Top 10 2013
and 2017.

Description {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Description", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

You are likely vulnerable:

• If you do not know the versions of all components you use (both
  client-side and server-side). This includes components you directly
  use as well as nested dependencies.

• If the software is vulnerable, unsupported, or out of date. This
  includes the OS, web/application server, database management system
  (DBMS), applications, APIs and all components, runtime environments,
  and libraries.

• If you do not scan for vulnerabilities regularly and subscribe to
  security bulletins related to the components you use.

• If you do not fix or upgrade the underlying platform, frameworks,
  and dependencies in a risk-based, timely fashion. This commonly
  happens in environments when patching is a monthly or quarterly task
  under change control, leaving organizations open to days or months
  of unnecessary exposure to fixed vulnerabilities.

• If software developers do not test the compatibility of updated,
  upgraded, or patched libraries.

• If you do not secure the components’ configurations (see
  A05:2021-Security Misconfiguration).

How to Prevent {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

There should be a patch management process in place to:

• Remove unused dependencies, unnecessary features, components, files,
  and documentation.

• Continuously inventory the versions of both client-side and
  server-side components (e.g., frameworks, libraries) and their
  dependencies using tools like versions, OWASP Dependency Check,
  retire.js, etc. Continuously monitor sources like Common Vulnerability and
  Exposures (CVE) and National Vulnerability Database (NVD) for
  vulnerabilities in the components. Use software composition analysis
  tools to automate the process. Subscribe to email alerts for
  security vulnerabilities related to components you use.

• Only obtain components from official sources over secure links.
  Prefer signed packages to reduce the chance of including a modified,
  malicious component (See A08:2021-Software and Data Integrity
  Failures).

• Monitor for libraries and components that are unmaintained or do not
  create security patches for older versions. If patching is not
  possible, consider deploying a virtual patch to monitor, detect, or
  protect against the discovered issue.

Every organization must ensure an ongoing plan for monitoring, triaging,
and applying updates or configuration changes for the lifetime of the
application or portfolio.

Example Attack Scenarios {{ osib_anchor(osib=osib ~ ".example attack scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Example Attack Scenarios", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Scenario #1: Components typically run with the same privileges as
the application itself, so flaws in any component can result in serious
impact. Such flaws can be accidental (e.g., coding error) or intentional
(e.g., a backdoor in a component). Some example exploitable component
vulnerabilities discovered are:

• CVE-2017-5638, a Struts 2 remote code execution vulnerability that
  enables the execution of arbitrary code on the server, has been
  blamed for significant breaches.

• While the internet of things (IoT) is frequently difficult or
  impossible to patch, the importance of patching them can be great
  (e.g., biomedical devices).

There are automated tools to help attackers find unpatched or
misconfigured systems. For example, the Shodan IoT search engine can
help you find devices that still suffer from Heartbleed vulnerability
patched in April 2014.

References {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.asvs.4-0." ~ "1", osib=osib) }}
• {{ osib_link(link="osib.owasp.dependency check", osib=osib) }}
• {{ osib_link(link="osib.owasp.wstg.4-2.4.1.10", osib=osib) }}
• {{ osib_link(link="osib.owasp.community.0.other.virtual patching best practices", osib=osib) }}
• {{ osib_link(link="osib.contrast.insecure libraries.2014", doc="osib.contrast", osib=osib) }}
• {{ osib_link(link="osib.cvedetails.search", osib=osib) }}
• {{ osib_link(link="osib.nist.nvd", osib=osib) }}
• {{ osib_link(link="osib.retirejs", osib=osib) }}
• {{ osib_link(link="osib.github.advisories", osib=osib) }}
• {{ osib_link(link="osib.rubysec", osib=osib) }}
• {{ osib_link(link="osib.safecode.publications.Software Integrity Controls.0.pdf", doc="osib.safecode", osib=osib) }}

List of Mapped CWEs {{ osib_anchor(osib=osib ~ ".mapped cwes", id=id ~ "-mapped_cwes", name=title ~ ": List of Mapped CWEs", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.937", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.1035", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.1104", doc="", osib=osib) }}

Osib Docs A07 2021 Identification And Authentication Failures (`osib/docs/A07_2021-Identification_and_Authentication_Failures.md`) Copy Section

source: "https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/" title: "A07:2021 – Identification and Authentication Failures" id: "A07:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".7" -%}
#A07:2021 – Identification and Authentication Failures {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Identification and Authentication Failures", lang=lang, source=source, parent=parent, predecessor=extra.osib.document ~ ".2017.2") }}

Factors {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Previously known as Broken Authentication, this category slid down
from the second position and now includes Common Weakness
Enumerations (CWEs) related to identification
failures. Notable CWEs included are CWE-297: Improper Validation of
Certificate with Host Mismatch, CWE-287: Improper Authentication, and
CWE-384: Session Fixation.

Description {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Description", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Confirmation of the user's identity, authentication, and session
management is critical to protect against authentication-related
attacks. There may be authentication weaknesses if the application:

• Permits automated attacks such as credential stuffing, where the
  attacker has a list of valid usernames and passwords.

• Permits brute force or other automated attacks.

• Permits default, weak, or well-known passwords, such as "Password1"
  or "admin/admin".

• Uses weak or ineffective credential recovery and forgot-password
  processes, such as "knowledge-based answers", which cannot be made
  safe.

• Uses plain text, encrypted, or weakly hashed passwords data stores (see
  A02:2021-Cryptographic Failures).

• Has missing or ineffective multi-factor authentication.

• Exposes session identifier in the URL.

• Reuse session identifier after successful login.

• Does not correctly invalidate Session IDs. User sessions or
  authentication tokens (mainly single sign-on (SSO) tokens) aren't
  properly invalidated during logout or a period of inactivity.

How to Prevent {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• Where possible, implement multi-factor authentication to prevent
  automated credential stuffing, brute force, and stolen credential
  reuse attacks.

• Do not ship or deploy with any default credentials, particularly for
  admin users.

• Implement weak password checks, such as testing new or changed
  passwords against the top 10,000 worst passwords list.

• Align password length, complexity, and rotation policies with
  National Institute of Standards and Technology (NIST)
  800-63b's guidelines in section 5.1.1 for Memorized Secrets or other
  modern, evidence-based password policies.

• Ensure registration, credential recovery, and API pathways are
  hardened against account enumeration attacks by using the same
  messages for all outcomes.

• Limit or increasingly delay failed login attempts, but be careful not to create a denial of service scenario. Log all failures
  and alert administrators when credential stuffing, brute force, or
  other attacks are detected.

• Use a server-side, secure, built-in session manager that generates a
  new random session ID with high entropy after login. Session identifier
  should not be in the URL, be securely stored, and invalidated after
  logout, idle, and absolute timeouts.

Example Attack Scenarios {{ osib_anchor(osib=osib ~ ".example attack scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Example Attack Scenarios", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Scenario #1: Credential stuffing, the use of lists of known
passwords, is a common attack. Suppose an application does not implement
automated threat or credential stuffing protection. In that case, the
application can be used as a password oracle to determine if the
credentials are valid.

Scenario #2: Most authentication attacks occur due to the continued
use of passwords as a sole factor. Once considered best practices,
password rotation and complexity requirements encourage users to use
and reuse weak passwords. Organizations are recommended to stop these
practices per NIST 800-63 and use multi-factor authentication.

Scenario #3: Application session timeouts aren't set correctly. A
user uses a public computer to access an application. Instead of
selecting "logout", the user simply closes the browser tab and walks
away. An attacker uses the same browser an hour later, and the user is
still authenticated.

References {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.opc.3.6", osib=osib) }}
• {{ osib_link(link="osib.owasp.asvs.4-0.2", osib=osib) }}
• {{ osib_link(link="osib.owasp.asvs.4-0.3", osib=osib) }}
• {{ osib_link(link="osib.owasp.wstg.4-2.4.3", osib=osib) }}, {{ osib_link(link= "osib.owasp.wstg.4-2.4.4", doc="", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0.Authentication", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0.Credential Stuffing Prevention", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0.Forgot Password", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0.Session Management", osib=osib) }}
• {{ osib_link(link="osib.owasp.oat", osib=osib) }}
• {{ osib_link(link="osib.nist.csrc.sp.800-63b.5.1.1", doc="osib.nist.csrc.sp.800-63b", osib=osib) }}

List of Mapped CWEs {{ osib_anchor(osib=osib ~ ".mapped cwes", id=id ~ "-mapped_cwes", name=title ~ ": List of Mapped CWEs", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.255", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.259", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.287", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.288", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.290", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.294", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.295", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.297", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.300", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.302", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.304", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.306", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.307", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.346", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.384", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.521", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.613", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.620", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.640", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.798", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.940", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.1216", doc="", osib=osib) }}

Osib Docs A08 2021 Software And Data Integrity Failures (`osib/docs/A08_2021-Software_and_Data_Integrity_Failures.md`) Copy Section

source: "https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/" title: "A08:2021 – Software and Data Integrity Failures" id: "A08:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".8" -%}
#A08:2021 – Software and Data Integrity Failures {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Software and Data Integrity Failures", lang=lang, source=source, parent=parent, predecessor=extra.osib.document ~ ".2017.8") }}

Factors {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

A new category for 2021 focuses on making assumptions related to
software updates, critical data, and CI/CD pipelines without verifying
integrity. One of the highest weighted impacts from
Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS)
data. Notable Common Weakness Enumerations (CWEs) include
CWE-829: Inclusion of Functionality from Untrusted Control Sphere,
CWE-494: Download of Code Without Integrity Check, and
CWE-502: Deserialization of Untrusted Data.

Description {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Description", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Software and data integrity failures relate to code and infrastructure
that does not protect against integrity violations. An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content
delivery networks (CDNs). An insecure CI/CD pipeline can introduce the
potential for unauthorized access, malicious code, or system compromise.
Lastly, many applications now include auto-update functionality, where
updates are downloaded without sufficient integrity verification and
applied to the previously trusted application. Attackers could
potentially upload their own updates to be distributed and run on all
installations. Another example is where
objects or data are encoded or serialized into a structure that an
attacker can see and modify is vulnerable to insecure deserialization.

How to Prevent {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• Use digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered.

• Ensure libraries and dependencies, such as npm or Maven, are
  consuming trusted repositories. If you have a higher risk profile, consider hosting an internal known-good repository that's vetted.

• Ensure that a software supply chain security tool, such as OWASP
  Dependency Check or OWASP CycloneDX, is used to verify that
  components do not contain known vulnerabilities

• Ensure that there is a review process for code and configuration changes to minimize the chance that malicious code or configuration could be introduced into your software pipeline.

• Ensure that your CI/CD pipeline has proper segregation, configuration, and access
  control to ensure the integrity of the code flowing through the
  build and deploy processes.

• Ensure that unsigned or unencrypted serialized data is not sent to
  untrusted clients without some form of integrity check or digital
  signature to detect tampering or replay of the serialized data

Example Attack Scenarios {{ osib_anchor(osib=osib ~ ".example attack scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Example Attack Scenarios", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Scenario #1 Update without signing: Many home routers, set-top
boxes, device firmware, and others do not verify updates via signed
firmware. Unsigned firmware is a growing target for attackers and is
expected to only get worse. This is a major concern as many times there
is no mechanism to remediate other than to fix in a future version and
wait for previous versions to age out.

Scenario #2 SolarWinds malicious update: Nation-states have been
known to attack update mechanisms, with a recent notable attack being
the SolarWinds Orion attack. The company that develops the software had
secure build and update integrity processes. Still, these were able to
be subverted, and for several months, the firm distributed a highly
targeted malicious update to more than 18,000 organizations, of which
around 100 or so were affected. This is one of the most far-reaching and
most significant breaches of this nature in history.

Scenario #3 Insecure Deserialization: A React application calls a
set of Spring Boot microservices. Being functional programmers, they
tried to ensure that their code is immutable. The solution they came up
with is serializing the user state and passing it back and forth with
each request. An attacker notices the "rO0" Java object signature (in base64) and
uses the Java Serial Killer tool to gain remote code execution on the
application server.

References {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.cheatsheetseries.0.software supply chain security", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0.Secure build and deployment", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0.Infrastructure as Code Security", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0.deserialization", osib=osib) }}
• {{ osib_link(link="osib.safecode.publication.software integrity controls.pdf", osib=osib) }}
• {{ osib_link(link="osib.npr.news.SolarWinds Hack", osib=osib) }}
• {{ osib_link(link="osib.codecov.bash uploader compromise", doc="osib.codecov", osib=osib) }}
• {{ osib_link(link="osib.julien vehent.securing devops", doc="osib.julien vehent", osib=osib) }}

List of Mapped CWEs {{ osib_anchor(osib=osib ~ ".mapped cwes", id=id ~ "-mapped_cwes", name=title ~ ": List of Mapped CWEs", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.345", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.353", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.426", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.494", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.502", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.565", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.784", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.829", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.830", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.915", doc="", osib=osib) }}

Osib Docs A09 2021 Security Logging And Monitoring Failures (`osib/docs/A09_2021-Security_Logging_and_Monitoring_Failures.md`) Copy Section

source: "https://owasp.org/Top10/09_2021-Security_Logging_and_Monitoring_Failures/" title: "A09:2021 – Security Logging and Monitoring Failures" id: "A09:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".9" -%}
#A09:2021 – Security Logging and Monitoring Failures {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Security Logging and Monitoring Failures", lang=lang, source=source, parent=parent, predecessor=extra.osib.document ~ ".2017.10") }}

Factors {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Security logging and monitoring came from the Top 10 community survey (#3), up
slightly from the tenth position in the OWASP Top 10 2017. Logging and
monitoring can be challenging to test, often involving interviews or
asking if attacks were detected during a penetration test. There isn't
much CVE/CVSS data for this category, but detecting and responding to
breaches is critical. Still, it can be very impactful for accountability, visibility,
incident alerting, and forensics. This category expands beyond CWE-778
Insufficient Logging to include CWE-117 Improper Output Neutralization
for Logs, CWE-223 Omission of Security-relevant Information, and
CWE-532 Insertion of Sensitive Information into Log File.

Description {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Description", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Returning to the OWASP Top 10 2021, this category is to help detect,
escalate, and respond to active breaches. Without logging and
monitoring, breaches cannot be detected. Insufficient logging,
detection, monitoring, and active response occurs any time:

• Auditable events, such as logins, failed logins, and high-value
  transactions, are not logged.

• Warnings and errors generate no, inadequate, or unclear log
  messages.

• Logs of applications and APIs are not monitored for suspicious
  activity.

• Logs are only stored locally.

• Appropriate alerting thresholds and response escalation processes
  are not in place or effective.

• Penetration testing and scans by dynamic application security testing (DAST) tools (such as OWASP ZAP) do
  not trigger alerts.

• The application cannot detect, escalate, or alert for active attacks
  in real-time or near real-time.

You are vulnerable to information leakage by making logging and alerting
events visible to a user or an attacker (see A01:2021-Broken Access Control).

How to Prevent {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Developers should implement some or all the following controls,
depending on the risk of the application:

• Ensure all login, access control, and server-side input validation
  failures can be logged with sufficient user context to identify
  suspicious or malicious accounts and held for enough time to allow
  delayed forensic analysis.

• Ensure that logs are generated in a format that log management
  solutions can easily consume.

• Ensure log data is encoded correctly to prevent injections or
  attacks on the logging or monitoring systems.

• Ensure high-value transactions have an audit trail with integrity
  controls to prevent tampering or deletion, such as append-only
  database tables or similar.

• DevSecOps teams should establish effective monitoring and alerting
  such that suspicious activities are detected and responded to
  quickly.

• Establish or adopt an incident response and recovery plan, such as
  National Institute of Standards and Technology (NIST) 800-61r2 or later.

There are commercial and open-source application protection frameworks
such as the OWASP ModSecurity Core Rule Set, and open-source log
correlation software, such as the Elasticsearch, Logstash, Kibana (ELK)
stack, that feature custom dashboards and alerting.

Example Attack Scenarios {{ osib_anchor(osib=osib ~ ".example attack scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Example Attack Scenarios", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Scenario #1: A children's health plan provider's website operator
couldn't detect a breach due to a lack of monitoring and logging. An
external party informed the health plan provider that an attacker had
accessed and modified thousands of sensitive health records of more than
3.5 million children. A post-incident review found that the website
developers had not addressed significant vulnerabilities. As there was
no logging or monitoring of the system, the data breach could have been
in progress since 2013, a period of more than seven years.

Scenario #2: A major Indian airline had a data breach involving more
than ten years' worth of personal data of millions of passengers,
including passport and credit card data. The data breach occurred at a
third-party cloud hosting provider, who notified the airline of the
breach after some time.

Scenario #3: A major European airline suffered a GDPR reportable
breach. The breach was reportedly caused by payment application security
vulnerabilities exploited by attackers, who harvested more than 400,000
customer payment records. The airline was fined 20 million pounds as a
result by the privacy regulator.

References {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.opc.3." ~ "9", osib=osib) }}
• {{ osib_link(link="osib.owasp.asvs.4-0." ~ "7", osib=osib) }}
• {{ osib_link(link="osib.owasp.wstg.4-2.4.8.1", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Logging Vocabulary", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Logging", osib=osib) }}
• {{ osib_link(link="osib.nist.csrc.sp.1800-11", osib=osib) }}
• {{ osib_link(link="osib.nist.csrc.sp.1800-25", osib=osib) }}
• {{ osib_link(link="osib.nist.csrc.sp.1800-26", osib=osib) }}

List of Mapped CWEs {{ osib_anchor(osib=osib ~ ".mapped cwes", id=id ~ "-mapped_cwes", name=title ~ ": List of Mapped CWEs", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.117", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.223", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.532", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.778", doc="", osib=osib) }}

Osib Docs A10 2021 Server Side Request Forgery (SSRF) (`osib/docs/A10_2021-Server-Side_Request_Forgery_(SSRF).md`) Copy Section

source: "https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_(SSRF)/" title: "A10:2021 – Server-Side Request Forgery (SSRF)" id: "A10:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".10" -%}
#A10:2021 – Server-Side Request Forgery (SSRF) {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Server-Side Request Forgery (SSRF)", lang=lang, source=source, parent=parent) }}

Factors {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

This category is added from the Top 10 community survey (#1). The data shows a
relatively low incidence rate with above average testing coverage and
above-average Exploit and Impact potential ratings. As new entries are
likely to be a single or small cluster of Common Weakness Enumerations (CWEs)
for attention and
awareness, the hope is that they are subject to focus and can be rolled
into a larger category in a future edition.

Description {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Description", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

SSRF flaws occur whenever a web application is fetching a remote
resource without validating the user-supplied URL. It allows an attacker
to coerce the application to send a crafted request to an unexpected
destination, even when protected by a firewall, VPN, or another type of
network access control list (ACL).

As modern web applications provide end-users with convenient features,
fetching a URL becomes a common scenario. As a result, the incidence of
SSRF is increasing. Also, the severity of SSRF is becoming higher due to
cloud services and the complexity of architectures.

How to Prevent {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Developers can prevent SSRF by implementing some or all the following
defense in depth controls:

**From Network layer** Copy Section

• Segment remote resource access functionality in separate networks to
  reduce the impact of SSRF

• Enforce “deny by default” firewall policies or network access
  control rules to block all but essential intranet traffic.
  Hints:
  ~ Establish an ownership and a lifecycle for firewall rules based on applications.
  ~ Log all accepted and blocked network flows on firewalls
  (see A09:2021-Security Logging and Monitoring Failures).

**From Application layer:** Copy Section

• Sanitize and validate all client-supplied input data

• Enforce the URL schema, port, and destination with a positive allow
  list

• Do not send raw responses to clients

• Disable HTTP redirections

• Be aware of the URL consistency to avoid attacks such as DNS
  rebinding and “time of check, time of use” (TOCTOU) race conditions

Do not mitigate SSRF via the use of a deny list or regular expression.
Attackers have payload lists, tools, and skills to bypass deny lists.

**Additional Measures to consider:** Copy Section

• Don't deploy other security relevant services on front systems (e.g. OpenID).
  Control local traffic on these systems (e.g. localhost)

• For frontends with dedicated and manageable user groups use network encryption (e.g. VPNs)
  on independent systems to consider very high protection needs

Example Attack Scenarios {{ osib_anchor(osib=osib ~ ".example attack scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Example Attack Scenarios", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Attackers can use SSRF to attack systems protected behind web
application firewalls, firewalls, or network ACLs, using scenarios such
as:

Scenario #1: Port scan internal servers – If the network architecture
is unsegmented, attackers can map out internal networks and determine if
ports are open or closed on internal servers from connection results or
elapsed time to connect or reject SSRF payload connections.

Scenario #2: Sensitive data exposure – Attackers can access local
files or internal services to gain sensitive information such
as file:///etc/passwd and http://localhost:28017/.

Scenario #3: Access metadata storage of cloud services – Most cloud
providers have metadata storage such as http://169.254.169.254/. An
attacker can read the metadata to gain sensitive information.

Scenario #4: Compromise internal services – The attacker can abuse
internal services to conduct further attacks such as Remote Code
Execution (RCE) or Denial of Service (DoS).

References {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.cheatsheetseries.0.server side request forgery prevention", osib=osib) }}
• {{ osib_link(link="osib.portswigger.web security.ssrf", osib=osib) }}
• {{ osib_link(link="osib.acunetix.blog.ssrf", osib=osib) }}
• {{ osib_link(link="osib.wallarm.ssrf bible.pdf", doc="osib.wallarm", osib=osib) }}
• {{ osib_link(link="osib.blackhat.us-17.ssrf.pdf", osib=osib) }}

List of Mapped CWEs {{ osib_anchor(osib=osib ~ ".mapped cwes", id=id ~ "-mapped_cwes", name=title ~ ": List of Mapped CWEs", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.918", doc="", osib=osib) }}

Osib Docs A11 2021 Next Steps (`osib/docs/A11_2021-Next_Steps.md`) Copy Section

source: "https://owasp.org/Top10/A11_2021-Next_Steps.md/" title: "A11:2021 – Next Steps" id: "A11:2021" lang: "en" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".11" -%}
#A11:2021 – Next Steps
{{ osib_anchor(osib=osib, id=id, name="Next Steps", lang=lang, source=source, parent=parent) }}

By design, the OWASP Top 10 is innately limited to the ten most
significant risks. Every OWASP Top 10 has “on the cusp” risks considered
at length for inclusion, but in the end, they didn’t make it. No matter
how we tried to interpret or twist the data, the other risks were more
prevalent and impactful.

Organizations working towards a mature appsec program or security
consultancies or tool vendors wishing to expand coverage for their
offerings, the following four issues are well worth the effort to
identify and remediate.

Code Quality issues Copy Chapter

• Description. Code quality issues include known security defects
  or patterns, reusing variables for multiple purposes, exposure of
  sensitive information in debugging output, off-by-one errors, time
  of check/time of use (TOCTOU) race conditions, unsigned or signed
  conversion errors, use after free, and more. The hallmark of this
  section is that they can usually be identified with stringent
  compiler flags, static code analysis tools, and linter IDE plugins.
  Modern languages by design eliminated many of these issues, such as
  Rust’s memory ownership and borrowing concept, Rust’s threading
  design, and Go’s strict typing and bounds checking.

• How to prevent. Enable and use your editor and language’s static
  code analysis options. Consider using a static code analysis tool.
  Consider if it might be possible to use or migrate to a language or
  framework that eliminates bug classes, such as Rust or Go.

• Example attack scenarios. An attacker might obtain or update
  sensitive information by exploiting a race condition using a
  statically shared variable across multiple threads.

• References

  • {{ osib_link(link="osib.owasp.code review guide.2-0.pdf", osib=osib) }}
  • {{ osib_link(link="osib.google.eng practices.review", osib=osib) }}

Denial of Service Copy Chapter

• Description. Denial of service is always possible given
  sufficient resources. However, design and coding practices have a
  significant bearing on the magnitude of the denial of service.
  Suppose anyone with the link can access a large file, or a
  computationally expensive transaction occurs on every page. In that
  case, denial of service requires less effort to conduct.

• How to prevent. Performance test code for CPU, I/O, and memory
  usage, re-architect, optimize, or cache expensive operations.
  Consider access controls for larger objects to ensure that only
  authorized individuals can access huge files or objects or serve
  them by an edge caching network.

• Example attack scenarios. An attacker might determine that an
  operation takes 5-10 seconds to complete. When running four
  concurrent threads, the server seems to stop responding. The
  attacker uses 1000 threads and takes the entire system offline.

• References

  • {{ osib_link(link= "osib.owasp.cheatsheetseries.0.denial of service", osib=osib) }}

  • {{ osib_link(link= "osib.owasp.community.0.attacks.denial of service", osib=osib) }}

Memory Management Errors Copy Chapter

• Description. Web applications tend to be written in managed
  memory languages, such as Java, .NET, or node.js (JavaScript or
  TypeScript). However, these languages are written in systems
  languages that have memory management issues, such as buffer or heap
  overflows, use after free, integer overflows, and more. There have
  been many sandbox escapes over the years that prove that just
  because the web application language is nominally memory “safe,” the
  foundations are not.

• How to prevent. Many modern APIs are now written in memory-safe
  languages such as Rust or Go. In the case of Rust, memory safety is
  a crucial feature of the language. For existing code, the use of
  strict compiler flags, strong typing, static code analysis, and fuzz
  testing can be beneficial in identifying memory leaks, memory, and
  array overruns, and more.

• Example attack scenarios. Buffer and heap overflows have been a
  mainstay of attackers over the years. The attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function’s return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker’s data.

• References

  • {{ osib_link(link="osib.owasp.community.0.vulnerabilities.buffer overflow", osib=osib) }}
  • {{ osib_link(link="osib.owasp.community.0.attacks.buffer overflow attack", osib=osib) }}
  • {{ osib_link(link="osib.sciencedirect.computer science.integer overflow", osib=osib) }}

2021 Docs Ar 0x00 2021 Notice (`2021/docs/ar/0x00_2021-notice.md`) Copy Section

الاصدار

24th September 2021

المؤلفون الرئيسيون Copy Chapter

• Andrew van der Stock (twitter: @vanderaj)
• Brian Glas (twitter: @infosecdad)
• Neil Smithline (twitter: @appsecneil)
• Torsten Gigler (twitter: @torsten_tweet)

المساهمين Copy Chapter

• Orange Tsai @orange_8361, Author of A10-2021: Server Side Request Forgery
• Jim Manico @manicode and Jakub Maćkowski @kubamackowski - OWASP CheatSheets Coordination

المترجمين Copy Chapter

• Malek Aldossary, Mohammed Alsuhaymi,Thamer Alshammeri, Yara Eissa Abdu Ajeebi, Wesal Majeed Alobaidi, Amal Almutairi, Noura Abdulmohsen Alsubaie, Mohammed Ibrahem Alsheky, Zainab Hussain Al Hussain, FAHAD ALOTAIFEE, Nowayer, Saja Alqurashi, Raghad Aljabr, Majed alrhyel, Almaha, Mohammed AL Busaidi, Aljohara Alsubaie, Rana Gharmallah Alzahrani, Haniya, Fahdah Alhadayan , Ibtisam AlTuraif, Abeer Alwelaie , Nasser bin Hasen , Mubark Allaghbi, Roaa Aljohani

كيف تقوم بمساعدتنا Copy Chapter

في هذه المراحل، نطلب مساعدتك فيما يلي:

• علماء البيانات: يرجى مراجعة التحليلات التي قمنا بها.
• مصمّمو الويب: نحتاج إلى إنشاء نسخة متوافقة مع الأجهزة المحمولة.
• المترجمون: يرجى مراجعة النص باللغة الإنجليزية والتأكد أنه قابل للترجمة.

طلبات الرفع وتسجيل التذاكر Copy Chapter

في حال وجود أي مشكلة أو تعديل، يرجى زيارة الرابط التالي:

• https://github.com/OWASP/Top10/issues

2021 Docs Ar 0x01 2021 About Owasp (`2021/docs/ar/0x01_2021-about-owasp.md`) Copy Section

عن أواسب

مشروع أمان تطبيق الويب المفتوح أواسب (OWASP) هو مجتمع مفتوح المصدر ويركز على تمكين المؤسسات من تطوير وشراء وصيانة التطبيقات وواجهات برمجة التطبيقات (APIs) التي يمكن الوثوق بها.

في أواسب ستجد:

• أدوات ومعايير أمان التطبيق
• الأبحاث المتطورة
• الضوابط الأمنية الأساسية المبنية على افضل السياسات.
• كتب كاملة عن اختبار أمن التطبيقات، وتطوير ومراجعة النص البرمجي الآمن.
• العروض التقديمية و مقاطع الفيديو
• Cheat sheets حول العديد من الموضوعات الشائعة
• اجتماعات المجموعات
• الأحداث والتدريب والمؤتمرات.
• مجموعات قوقل

اعرف المزيد على: https://owasp.org.

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

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

أواسب نوع جديد من التنظيم. يسمح لنا بالتحرّر من الضغوط التجارية بتقديم معلومات غير متحيزة وعملية وفعالة من حيث التكلفة حول أمن التطبيقات.

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

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

حقوق النشر والترخيص Copy Chapter

حقوق النشر © مؤسسة أواسب 2003-2025. تم إصدار هذا المستند بموجب ترخيص الإبداعي الترخيص بالمثل 4.0. لأي إعادة استخدام أو توزيع، يجب أن توضح للآخرين شروط ترخيص هذا العمل.

2021 Docs Ar A00 2021 How To Start An AppSec Program With The OWASP Top 10 (`2021/docs/ar/A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10.md`) Copy Section

كيف تبدأ برنامج أمن التطبيقات مع أواسب – أعلى عشرة مخاطر

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

المرحلة الأولى: تحديد الثغرات والأهداف الخاصة ببرنامج أمن التطبيقات Copy Chapter

تحاول العديد من برامج أمن التطبيقات (AppSec) الجري قبل أن تتمكن من الزحف أو المشي. هذه الجهود محكوم عليها بالفشل. نحن نشجّع بشدّة مدراء أمن المعلومات CISOs وكبار مختصّي أمن التطبيقات على استخدام نموذج أواسب لنضج وضمان البرامج SAMM لتحديد نقاط الضعف ومجالات التحسين على مدى فترة تتراوح ما بين 1-3 سنوات. تتمثّل الخطوة الأولى في تقييم وضعك الحالي، وتحديد الثغرات في الحوكمة والتصميم والتنفيذ والتحقق والعمليات التي تحتاج إلى حلّها على الفور مقابل تلك التي يمكن أن تنتظر، وتحديد أولويات تنفيذ أو تحسين الخمسة عشر لنموذج أواسب لنضج وضمان البرامج (SAMM). يمكن أن يساعدك نموذج أواسب (SAMM) في بناء وقياس التحسينات في البرنامج لضمان الجهود.

المرحلة الثانية: التخطيط لمفهوم الطريق المُمهد في دورة حياة تطوير البرمجيات بطريقة آمنة Copy Chapter

تقليديًا، الحفاظ على ما يسمى "أحادي القرن"، مفهوم الطريق المُمهد هو أسهل طريقة لتحقيق أكبر قدر من التأثير وتوسيع نطاق موارد أمن التطبيقات مع سرعة فرق التطوير، والتي تزيد كل عام فقط.

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

قد يبدو أن الطريق المُمهد يتطلّب الكثير من الوقت، ولكن يجب أن يتم بناؤه تدريجيًا مع مرور الوقت. هناك أشكال أخرى من برامج أمن التطبيقات، لاسيما دورة حياة التطوير الآمن أجايل مايكروسوفت Microsoft Agile. ليست بالضرورة أن تناسب منهجيّة برنامج أمن التطبيقات كل الأعمال.

المرحلة الثالثة: تنفيذ مفهوم الطريق الممهد مع فرق التطوير الخاصة بك Copy Chapter

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

المرحلة الرابعة: ترحيل جميع التطبيقات الحالية والقادمة إلى منهجية الطريق الممهد Copy Chapter

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

المرحلة الخامسة: اختبار مفهوم الطريق المُمهد إن كان قد خفّف من المشاكل الموجودة في أواسب – أعلى عشرة مخاطر Copy Chapter

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

المرحلة السادسة: قم ببناء برنامجك في بيئة برمجية آمنة Copy Chapter

يجب ألا يقتصر اعتمادك على أواسب- اعلى عشرة مخاطر فقط. فهو يغطي فقط 10 فئات من المخاطر. نحن نشجع المؤسسات بشدة على اعتماد معيار التحقق من أمن التطبيقات وإضافة مكونات منهجية الطرق الممهدة واختبارات المستوى 1 و2 و3 تدريجيًا، اعتمادًا على مستوى مخاطر التطبيقات المطورة.

الذهاب إلى أبعد من ذلك Copy Chapter

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

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

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

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

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

2021 Docs Ar A00 2021 How To Use The OWASP Top 10 As A Standard (`2021/docs/ar/A00_2021-How_to_use_the_OWASP_Top_10_as_a_standard.md`) Copy Section

كيف تستخدم إطار أعلى عشرة مخاطر من أواسب كنموذج معياري.

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

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

فيما يلي توصياتنا لاستخدام (أواسب – أعلى عشرة مخاطر) عندما يكون ذلك متاحًا

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

معيار التحقق من أمن التطبيقات (ASVS) هو الخيار الوحيد المقبول لمزودي الأدوات. لا يمكن للأدوات الكشف الشامل أو الاختبار أو الحماية ضد (أواسب – أعلى عشرة مخاطر) نظرًا لطبيعة العديد من مخاطر (أواسب –اعلى عشرة مخاطر )، مع الإشارة إلى A04: 2021-التصميم الغير آمن. لا تتفق أواسب مع أي ادعاءات بالتغطية الكاملة لـ (أواسب – أعلى عشرة مخاطر )، لأنها ببساطة غير صحيحة.

2021 Docs Ar A00 2021 Introduction (`2021/docs/ar/A00_2021-Introduction.md`) Copy Section

مقدمة

مرحباً بكم في أعلى عشرة مخاطر لعام 2021 Copy Chapter

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

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

ما هي التغييرات التي طرأت على أعلى عشرة مخاطر لعام 2021 Copy Chapter

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

A01:2021-تخطي صلاحيات الوصولاحتل (تخطي صلاحيات الوصول) المرتبة الأولى بعد أن كان في الترتيب الخامس، حيث أنه تم إجراء اختبار لنقاط الضعف وكانت النسبة هي 94% من التطبيقات مصابه بتخطي صلاحيات الوصول إن تخطي صلاحيات الوصول والمرتبط بـ 34 CWEs هو من أكثر الثغرات التي تحدث على مستوى التطبيقات.

A02:2021-فشل آلية التشفير يأتي فشل آلية التشفير في المرتبة رقم #2 والتي كانت تعرف بالبيانات الحساسة الغير محمية أو المكشوفة، والتي قد تكون أسبابها متعددة دون أن تعود جميعها لسبب جذري واحد، ويأتي التركيز هنا بشكل متجدد على حالات الفشل في الطرق المتعلقة بالتشفير والتي غالبًا ما تؤدي إلى كشف غير مصرّح به إلى بيانات حساسة أو اختراق الأنظمة.

A03:2021-الحقن تتراجع الحقن الى الخطر رقم 3. حيث انه تم اجراء اختبار لنقاط الضعف وكانت النسبة هي 94% من التطبيقات مصابه بثغرات الحقن. ان ثغرة الحقن والمرتبطة بـ 33 CWEs تعتبر ثاني اعلى ثغرة من الثغرات التي من الممكن إصابة التطبيقات بها. والجدير بالذكر ان ثغرات XSS تم دمجها هنا مع ثغرة الحقن في هذه النسخة.

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

A05:2021- الإعدادات الأمنية الخاطئة بعد أن كان هو الخطر رقم #6 الآن نراه في المرتبة #4، حيث أنه تم إجراء اختبار لنقاط الضعف وكانت النسبة هي 90% من التطبيقات يوجد بها أخطاء في طريقة الإعدادات الصحيحة. وهذا يحدث مع البرمجيات الحديثة والتي تستلزم تغيير الإعدادات بشكل مستمر مما يجعل نسبة الخطأ في ارتفاع، وهذا الذي جعل (الإعدادات الخاطئة) ترتفع من المرتبة السادسة إلى الرابعة. والجدير بالذكر أنه تم ضم " XML External Entities XXE" لهذا النوع من الإعدادات الخاطئة.

A06:2021-الثغرات و المكونات الغير المحدثة سابقًا كانت تعرف بـ “استخدام الأنظمة والمنتجات ذات ثغرات معروفة". وبناءً على على استطلاع في أمن التطبيقات كانت هي #2 أعلى ثغرة على مستوى خطر المنتجات. ومن خلال تحليل البيانات وبعد أن كانت هي الخطر رقم #9 في الإصدار السابق لعام #2017 ارتفعت في إصدار #2021 إلى الخطر رقم #6. وعند النظر إلى معايير CVEs أو CWEs لا نرى لها أي تصنيف بالخطورة. ولذلك يتم تصنيف خطورتها بشكل افتراضي بناءً على مستوى التأثير وهو 5.0.

A07:2021-الهوية و فشل عملية التحقق والتي كانت تعرف في الإصدارات السابقة "ضعف التحقق من الهوية" وبعد أن كانت كذلك هي الخطر رقم #2. وبعد عملية ربطها مع إطار CWEs وتسميتها بـ “فشل عملية التحقق. وكما نقول أن زيادة المعايير أدّت إلى تقليل المخاطر ولكن ليس بشكل كامل لذلك نراها هنا من ضمن أعلى عشرة مخاطر.

A08:2021- فشل سلامة البيانات والبرمجيات تمت إضافتها حديثًا في هذا الإصدار 2021. والتي تركّز بشكل كبير على تحديث البرمجيات والبيانات مع التأكد على عدم تأثر سلامة دورة حياة CI/CD. وعند النظر إلى تقييم المخاطر المحتملة حسب تصنيف CVE/CVSS وارتباطها مع CWEs نجد أن تقييم الخطر هو 10 ويعتبر مرتفع جدًا. الجدير بالذكر أن "Insecure Deserialization" أصبحت جزء من هذا التصنيف.

A09:2021-فشل في تسجيل السجلات الأمنية والمراقبة والتي كانت تعرف سابقًا بـ “تسجيل الأحداث والمراقبة بشكل غير صحيح. وبعد عمل الاستطلاع التي تم اجراءها في أمن التطبيقات احتلت المرتبة رقم 3 في عملية الاستطلاع. والذي جعلها تصعد مرتبة واحدة بعد أن كانت في المرتبة 10. الجدير بالذكر أن هناك العديد من عمليات الفشل التي تحدث في المراقبة وتسجيل الأحداث التي تم ضمها هنا. وحينما نرى CVE/CVSS لا نرى لها أي تصنيف واضح ولكن مع القصور في عمليات المراقبة وتسجيل الأحداث والتي تشكل تأثيرًا بالغًا في عملية التغطية على مستوى الأنظمة، والتنبيه في حال وجود حوادث أو الاستفادة منها في عمليات التحقيق الجنائي الرقمي.

A10:2021-تزوير الطلبات من جانب الخادم SSRF تم إضافة هذا التصنيف بناءً على الاستطلاع رقم #1. وتظهر البيانات حسب الاختبارات التي تم إجراؤها أن هذا التصنيف معدل الإصابة به فوق المتوسط مع ارتفاع منخفض. ومدى ارتباطه بمعدل التأثير وإمكانية الاستغلال. ويفيد المختصين في المجال أن وجود هذا التصنيف من ضمن المخاطر هو أمر مهم جدًا حتى وإن كانت البيانات الحالية غير مكتملة في الوقت الحالي.

المنهجية Copy Chapter

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

وكما أن هناك بعض التغييرات الجوهرية التي تم اعتمادها من قبل منظمة أواسب لمواصلة المنهجية المتّبعة في تصنيف أعلى عشرة مخاطر.

كيف يتم تنظيم التصنيفات Copy Section

تم تغيير بعض التصنيفات من الإصدار السابق لأعلى عشر مخاطر وهنا ملخص لما تم تغيره على مستوى التصنيفات

تركز الجهود المبذولة في جمع البيانات على مجموعات فرعية من CWEs بعدد 30 مجال مع الاخذ بالاعتبار ان بعض التصنيفات الفرعية تحتاج الى بيانات ونتائج إضافية.
لذلك قرّرت المنظمة أنها ستقوم بالتركيز على 30 تصنيف من CWEs بشكل أساسي وقد يتطلّب التركيز في بعض الأحيان النظر في التصنيفات المتفرعة منها وسيكون في نطاق محدود وضيّق. وتبعًا للإجراءات المعتادة قمنا بطلب البيانات وبدون أي قيود على CWEs. وقمنا بطلب عدد من التطبيقات التي تم اختبارها لسنوات محددة (بدءًا من عام 2017)، و التطبيقات التي تم تقييمها بإصابتها بأحد CWEs على الأقل. وتسمح لنا هذه الطريقة معرفة مدى ارتباط التطبيقات بتصنيفات CWEs. مع الأخذ بعين الاعتبار أننا تجاهلنا التكرار لأسباب معيّنة، وأن في بعض الحالات يكون ضروريًا الأخذ به والذي قد يؤثر في بعض الأحيان في حال كان التطبيق منتشر ومشهور ومستخدم بكثرة. والجدير بالذكر أن مهما كان التطبيق مصاب بـ 4 من CWEs أو 4,000 فهذا لا يؤثر على آلية احتساب أعلى عشرة مخاطر لدينا. ولقد كان لدينا حوالي 400 CWEs تقريبًا وقمنا بحصرها وتقليلها إلى 30 CWEs وذلك من خلال تحليل مجموعة من البيانات. وكما نخطط في المستقبل في إجراء تحليلات إضافية والتي بدورها ستنعكس على إضافة بعض من CWEs وقد يكون هناك تغيير كذلك على هيكلة وتصنيف أعلى عشرة مخاطر.

لقد أمضينا عدة أشهر في تجميع وتصنيف CWEs وكان من الممكن أن نستمر لأشهر إضافية. ولكن كان علينا التوقف عند نقطة ما. كما أن هناك أنواع في CWEs ما يسمى بـ “سبب جذري" و "الأعراض". وعلى سبيل المثال على "سبب جذري" كفشل التشفير أو الإعدادات الخاطئة والذي يتم إقرانه بالأعراض مثل بيانات حساسة مكشوفة أو حجب الخدمة. لذلك قرّرنا أن نركز على "السبب الجذري" قدر الإمكان وذلك لتوفّر التوصيات والإرشادات وطرق تلافي تلك الأسباب. كما أن التركيز على الأسباب الجذرية أكثر من الأعراض ليس مفهوم جديد، كما أن أعلى عشرة مخاطر جاءت بشكل مختلط ما بين "الأسباب الجذرية" و "الأعراض" وهو الأسلوب المتّبع في CWEs كذلك. وهدفنا أن نكون على توازن بينهم. إن متوسط التصنيفات حسب CWEs هو 19.6 حيث حصلت A10 تزوير الطلبات من جانب الخادم SSRF على 1 CWEs و 40 CWEs لصالح A04:2021- التصميم الغير آمن . إن التحديث الذي جرى على التصنيفات مفيد جدًا للمنظمات من ناحية التركيز على منافع الاستفادة من التدريب على CWEs واستخدمها كلغة عمل وإطار.

كيف يتم استخدام البيانات لبعض التصنيفات المختارة Copy Section

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

قمنا بتنزيل " OWASP Dependency Check" واستخرجنا نتائج CVSS للاختراق والآثار التي تم جمعها سابقاً من CWEs ذات العلاقة. ولا يخفى عليكم ان هذا الجهد من البحث اخذ قدر لا باس به لان جميع CVEs لديها درجات من CVSSv2 كذلك. ولكن هنا بعض الخلل ما بين CVSSv2 وCVSSv3 والذي يجب معالجته. وسنرى في القريب ان جميع CVEs ستقوم باستخدام CVSSv3. ونود ان نلفت الانتباه ان معادلة CVSSv2 وCVSSv3 والدرجات متغيرة ومتحدثة.

في CVSSv2، من الممكن ان يصل الأثر و الاستغلال الى 10.0، ولكن بعد استخدام المعادلة قد تنخفض الى 60% لاستغلال و 40% للتأثير. وفي CVSSv3 كان الحد الأعلى هو 6.0 للاستغلال و 4.0 للأثر. مع الاخذ بالاعتبار مدى ثقل أحدهما. وعند النظر الى CVSSv3 نرى ان الأثر ارتفع حوالي نقطة ونصف، والاستغلال انخفض بمقدار النصف نقطة تقريباً.

هناك أكثر من 125 ألف سجل من CVE تم ربطها مع CWEs في منصة NVD والتي تم استخدمها في " OWASP Dependency Check". وهناك أكثر من 241 تصنيف فرعي فريد في CWEs تم ربطها في أكثر من CVE. وهناك أكثر من 62 ألف من CWE تم ربطها في CVSSv3. والتي تمثل نصف البيانات التي تم حصرها.

في قائمة أعلى عشر مخاطر، قمنا بحساب متوسط نقاط الاستغلال والأثر بالطرق التالية. قمنا بتجميع درجات CVEs مع CVSS بواسطة CWE وقمنا بتقييم كل من الأثر والاستغلال باستخدام النسبة المئوية الموجودة في CVSSv3 بالإضافة الى جميع ما يوجد في CVSSv2 لاحتساب المتوسط الإجمالي. وبعد ذلك قمنا بربط المتوسط بـ CWEs في قاعدة البيانات وذلك لاستخدمها لتقييم درجات الأثر والاستغلال والاستفادة منها كذلك في احتساب المخاطر بناء على المعادلة المستخدمة.

لماذا لا تكون مجرد بيانات إحصائية بحتة؟ Copy Chapter

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

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

لماذا معدل الحدوث بدلا من التكرار؟ Copy Chapter

هناك ثلاثة مصادر أساسية للبيانات. نحددها على أنها الانسان يساعد الأدوات (HaT) ، او الأدوات تساعد الإنسان (TaH) ، او الأدوات من غير أي تعديلات.

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

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

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

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

ما هي عملية جمع البيانات وتحليلها؟ Copy Chapter

تم إضفاء الطابع الرسمي على عملية جمع بيانات أعلى عشر مخاطر في قمة Open Security Summit في عام 2017. وبعد ذلك أمضى المسؤولين في منظمة آواسب يومين في العمل على جعل عملية جمع البيانات مبنية على سياسة واضحة وشفافة. تعد نسخة 2021 هي المرة الثانية التي نستخدم فيها هذه المنهجية.

قمنا بدعوة للحصول على البيانات من خلال قنوات التواصل الاجتماعي المتاحة لنا، لكلًّا من المشروع و OWASP. وفي صفحة مشروع OWASP, نقوم بإدراج عناصر وهيكل البيانات التي نبحث عنها وكيفية إرسالها.
وفي مشروع GitHub, لدينا أمثلة لملفات تعمل كقوالب. نعمل مع المنظمات الأخرى حسب الحاجة للمساعدة في تحديد الهيكلورسمه وربطه بـ CWEs.

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

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

العوامل المستخدمة مع البيانات Copy Chapter

هناك عوامل بيانات مدرجة لكل تصنيف من تصنيفات أعلى عشر مخاطر، وإليك ما تعنيه:

• ربط بـ CWEs: عدد CWEs الذي تم ربطها بواسطة الفريق.

• معدل الحدوث/الحوادث: معدل الحدوث وهو النسبة المئوية للتطبيقات المعرضة لثغرات ومعرفة مدى ارتباطها بمعيار CWE خلال الاختبارات التي. أجرتها المؤسسات في سنة محددة.

• (الاختبارات) والتغطية:النسبة المئوية للتطبيقات التي تم اختبارها من قبل جميع المنظمات لـ CWE مُعيّن.

• خطورة الاستغلال: معرفة الاستغلال و النقاط الفرعية له من CVSSv2 و CVSSv3 والتي لديها CVEs ومرتبطة بـ CWEs، ،موائمتها ، ووضعها على مقياس 10pt.

• التأثير المتوقع: تأثير النقاط الفرعية من CVSSv2 و CVSSv3 والتي لديها CVEs ومرتبطة بـ CWEs، ،موائمتها ، ووضعها على مقياس 10pt.

• إجمالي التكرار/الحوادث: إجمالي عدد التطبيقات التي تم ربطها بـ CWEs وتم وضع تصنيف محدد لها.

• إجمالي CVEs: إجمالي عدد CVEs في NVD DB التي تم ربطها بـ CWEs وتم وضع تصنيف محدد لها.

علاقات التصنيفات لعام 2021 مع تصنيفات عام 2017 Copy Chapter

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

يمثل مخطط Venn أعلاه الترابط بين التصنيفات في أعلى عشر مخاطر لعام 2017. وأثناء القيام بذلك، أصبحت بضع نقاط أساسية واضحة:

1. كان يُرى بأن هجوم - ثغرات XSS تنتمي في حقيقة الأمر إلى ثغرات الحقن(Injection) لأنها في الأساس عبارة عن حقن المحتوى. بالنظر إلى بيانات عام 2021 ، أصبح من الواضح أن ( XSS )بحاجة إلى الانتقال إلى الحقن(Injection).

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

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

شكراً لكل من ساهم معنا في جمع هذه البيانات

ساهمت المنظمات التالية (جنبًا إلى جنب مع بعض المساهمين-المتبرعين المجهولين) لبيانات لأكثر من 500,000 تطبيق وجعلها هي القائمة الأكبر والأكثر والأشمل من التطبيقات التي تم إجراء اختبارات الأمان عليها وجعلها في قاعدة بيانات. وتأكد أنه من غير اسهاماتك لن يكون هذا ممكن.

{ width="256" }

{ width="256" }

2021 Docs Ar A01 2021 Broken Access Control (`2021/docs/ar/A01_2021-Broken_Access_Control.md`) Copy Section

A01:2021 – تخطي صلاحيات الوصول

العوامل Copy Chapter

نظرة عامة Copy Chapter

صعد هذا المعيار من المركز الخامس في الإصدار السابق إلى الأول في هذا الإصدار بعد اختبار ثغرات "تخطي صلاحيات التحكم بالوصول" على 94% من التطبيقات وقد لوحظ أنها تعاني من نقاط الضعف الشائعة "CWEs” تشمل : CWE-200 و CWE-201 و CWE-352

الوصف Copy Chapter

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

• تجاوز إجراءات التحقق من التحكم في الوصول من خلال تعديل محدد فيURL، او تعديل الكائنات “objects” المرتبطة بالبرنامج داخل الذاكرة أو تعديل صفحة الـ HTML، أو ببساطة استخدام أداة هجوم مخصصة لمهاجمة API

• السماح بالتبديل بين مفتاح رئيسي “primary key” وسجلات مستخدم آخر “users record”، مما قد يسمح باستعراض أو التعديل على حسابات أخرى

• تصعيد الصلاحيات: التصرف كمستخدم من دون تسجيل الدخول او التصرف كمدير عند تسجيل الدخول بصلاحيات كمستخدم.

• التلاعب في البيانات الوصفية "meta data” كإعادة إدخال أو التلاعب برمز التوثيق "JSON Web Token (JWT)،" أو التلاعب في ملفات الارتباط أو الحقول المخفية لغرض تصعيد الصلاحيات أو إساءة استخدام الـ JWT

• التهيئة الغير صحيحة لـ CORS تسمح بالدخول الغير مصرح به لواجهة برمجة التطبيقات API.

• استعراض صفحات "تستلزم المصادقة" عبر مستخدمين "غير مصادق عليهم" أو الوصول الى صفحات ذات امتيازات عليا باستخدام صلاحيات “حساب مستخدم “، أو الوصول الى واجهة برمجة التطبيقات "API” بوجود قصور في "التحكم في صلاحيات الوصول" مما يؤدي الى تنفيذ طلباتPOST، PUT، DELETE.

كيفية الحماية منها Copy Chapter

يكون "التحكم بصلاحيات الوصول" فعالا فقط عندما عند تطبيقه على الشفرة المصدرية من جهة الخوادم الموثوقة- trusted server-side code، أو الخوادم التي لا تملك واجهة برمجة تطبيقات والتي يطلق عليها (server-less API)، حيث لا يستطيع المهاجم تعديل "صلاحيات التحكم بالوصول" أو التلاعب في البيانات الوصفية.

• باستثناء طلبات الوصول "للموارد المتاحة للعامة" يتم حظر جميع الطلبات بشكل افتراضي.

• وضع الأليات التي تتحكم بالوصول لمرة واحدة في البرنامج/التطبيق مع إعادة استخدامها -هي نفسها- عند الحاجة، وأيضا تقليل استخدام CORS.

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

• متطلّبات حدود تطبيقات الأعمال الفريدة من نوعها "Unique application business limit" يجب أن يتم فرضها خلال استخدام نماذج المجال (domain models).

• تعطيل استعراض مجلدات خادم الويب والتأكد بأن ملف البيانات الوصفية "Meta Data” وملفات النسخ الاحتياطي لا يتم الوصول اليها من خلال مجلد المسار الرئيسي "Root".

• توثيق سجلات فشل التحكم في صلاحيات الوصول وتنبيه المسؤولين عند وقوع هذه الأخطاء.

• تقييم حد الوصول إلى واجهة برمجة التطبيقات API ووضع حد لمعدّل الطلبات لتقليل الضرر الناجم عن أدوات الهجوم الآلي.

• يجب التخلص من رموز JWT على الخادم بعد تسجيل الخروج.

يجب على فرق المطوّرين وموظفين قسم ضمان الجودة "QA" أن تتضمّن وحدة فعالة للتحكم في الوصول وإجراء اختبارات التكامل .

أمثلة على سيناريوهات الهجوم Copy Chapter

سيناريو #1: يستخدم التطبيق بيانات لم يتم التحقق منها في استدعاء SQL التي بدورها تصل الى معلومات الحساب:

pstmt.setString(1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

ببساطة يقوم المهاجم بتعديل browser's 'acct' parameter لأرسال أي رقم حساب يريده. وإذا لم يتم التحقق منه بشكل صحيح، يستطيع المهاجم الوصول لأي حساب مستخدم.

https://example.com/app/accountInfo?acct=notmyacct

سيناريو #2: : ببساطة يجبر المهاجم المتصفحات على زيارة العناوين الـ URLsالمستهدفة. والتي لا يستطيع الوصول اليها الا بصلاحيات المسؤول.

https://example.com/app/getappInfo

https://example.com/app/admin_getappInfo

يعتبر خللا اذا كان يمكن للمستخدم غير المصرح له الوصول الى اي من الصفحتين. يعتبر خللا اذا كان يمكن لغير المسؤول الوصول لصفحة المسؤول.

المصادر Copy Chapter

• OWASP Proactive Controls: Enforce Access Controls

• OWASP Application Security Verification Standard: V4 Access Control

• OWASP Testing Guide: Authorization Testing

• OWASP Cheat Sheet: Authorization

• PortSwigger: Exploiting CORS
  misconfiguration

• OAuth: Revoking Access

قائمة الربط مع إطار CWEs Copy Chapter

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

CWE-23 Relative Path Traversal

CWE-35 Path Traversal: '.../...//'

CWE-59 Improper Link Resolution Before File Access ('Link Following')

CWE-200 Exposure of Sensitive Information to an Unauthorized Actor

CWE-201 Exposure of Sensitive Information Through Sent Data

CWE-219 Storage of File with Sensitive Data Under Web Root

CWE-264 Permissions, Privileges, and Access Controls (should no longer be used)

CWE-275 Permission Issues

CWE-276 Incorrect Default Permissions

CWE-284 Improper Access Control

CWE-285 Improper Authorization

CWE-352 Cross-Site Request Forgery (CSRF)

CWE-359 Exposure of Private Personal Information to an Unauthorized Actor

CWE-377 Insecure Temporary File

CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak')

CWE-425 Direct Request ('Forced Browsing')

CWE-441 Unintended Proxy or Intermediary ('Confused Deputy')

CWE-497 Exposure of Sensitive System Information to an Unauthorized Control Sphere

CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory

CWE-540 Inclusion of Sensitive Information in Source Code

CWE-548 Exposure of Information Through Directory Listing

CWE-552 Files or Directories Accessible to External Parties

CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key

CWE-601 URL Redirection to Untrusted Site ('Open Redirect')

CWE-639 Authorization Bypass Through User-Controlled Key

CWE-651 Exposure of WSDL File Containing Sensitive Information

CWE-668 Exposure of Resource to Wrong Sphere

CWE-706 Use of Incorrectly-Resolved Name or Reference

CWE-862 Missing Authorization

CWE-863 Incorrect Authorization

CWE-913 Improper Control of Dynamically-Managed Code Resources

CWE-922 Insecure Storage of Sensitive Information

CWE-1275 Sensitive Cookie with Improper SameSite Attribute

2021 Docs Ar A02 2021 Cryptographic Failures (`2021/docs/ar/A02_2021-Cryptographic_Failures.md`) Copy Section

A02:2021 – فشل آلية التشفير

العوامل Copy Chapter

نظرة عامة Copy Chapter

يأتي فشل آلية التشفير في المرتبة رقم #2 والتي كانت تعرف “بالبيانات الحساسة الغير محمية أو المكشوفة" والتي قد تكون أسبابها متعدّدة أكثر من كونها ناتجة عن سبب جذري واحد، ويأتي التركيز هنا على حالات الفشل في التشفير والتي غالبًا ما تؤدي إلى كشف غير مصرّح به للبيانات الحساسة. تم ملاحظة أن نقاط الضعف الشائعة CWEs تشمل: CWE-259: استخدام كلمة المرور المضمنة مسبقًا "" ، CWE-327: خوارزمية تشفير مُعطّلة أو محفوفة بالمخاطر، و CWE-331 التشتت الغير فعّال أو بعبارة أخرى -عشوائية بشكل غير كافي-” Insufficient Entropy”.

الوصف Copy Chapter

أولًا، تحديد احتياجات حماية البيانات أثناء النقل (Data in transit) وأثناء التخزين (Data at rest). على سبيل المثال، تتطلّب كل من (كلمات المرور وأرقام بطاقات الائتمان والسجلات الصحيّة والمعلومات الشخصية وأسرار العمل) تتطلّب حماية إضافية ولا سيّما إذا كانت تلك البيانات تندرج تحت قوانين الخصوصية مثل اللائحة العامة لحماية البيانات في الاتحاد الأوروبي (GDPR)، أو التنظيمات، و على سبيل المثال تنظيمات حماية البيانات المالية مثل معيار PCI لأمان البيانات أو معيار (PCI DSS) لجميع البيانات المالية.

• هل يتم نقل أي بيانات من غير تشفير؟ يعتمد هذا على البروتوكولات مثل HTTP وSMTP وFTP. كذلك لابد من التحقق من مسار تدفّق البيانات و حركتها داخل الشبكة الداخلية، على سبيل المثال، حركة البيانات بين موازنات التحميل"load balancers" أو خوادم الويب أو الأنظمة الخلفية "Back-end systems" .

• هل يتم استخدام أي خوارزميات تشفير قديمة أو ضعيفة إما بشكل افتراضي أو في التعليمات البرمجية القديمة؟

• هل مفاتيح التشفير الافتراضية قيد الاستخدام؟ هل يتم توليد مفاتيح تشفير ضعيفة أو يتم إعادة استخدام مفاتيح من شفرة مصدرية افتراضية أو من شفرة مصدرية قديمة؟ هل تتم إدارة المفاتيح و إعادة تدويرها بشكل جيد؟ (rotation missing)؟

• هل التشفير غير مفروض؟ على سبيل المثال، هل يتم إرسال واستخدام عناوين "Headers" الصحيحة والمطلوبة فقط عند إرسال البيانات الحساسة أو عند استقبالها من قِبل المتصفّح؟

• هل وكيل المستخدم (مثل المتصفّح أو برمجية استخدام البريد الإلكتروني) لا يتحقّق ما إذا كانت شهادة الخادم المستلمة صالحة وفعّالة؟

هناك الكثير من المشاكل التي يجب تجنّبها، انظر ASVS Crypto (V7) , Data Protection (V9), and SSL/TLS (V10)

كيفية الحماية منها Copy Chapter

يجب عمل ما يلي على الأقل لحماية البيانات الحساسة:

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

• تطبيق الضوابط بناءً على التصنيف.

• لا تقم بتخزين بيانات حساسة غير مطلوبة، قم بتجاهلها والتخلّص منها في أقرب وقت ممكن لأن البيانات التي لا تملكها لا يمكن سرقتها.

• تأكّد من تشفير جميع البيانات الحساسة المخزنة.

• ضمان استخدام خوارزميات وبروتوكولات ومفاتيح تشفير محدّثة وذات معايير صارمة كذلك إدارة المفاتيح بشكل جيد ومناسب.

• قم بتشفير جميع البيانات أثناء النقل باستخدام بروتوكولات آمنة مثل TLS مع شفرة الـ Perfect Forward Secrecy (PFS)، وتحديد أولويات التشفير والمعطيات الآمنة بواسطة الخادم و كذلك فرض التشفير باستخدام التوجيهات مثل HTTP Strict Transport Security (HSTS).

• تعطيل خاصية التخزين المؤقت في الصفحات "caching" للردود التي تحتوي على بيانات حساسة.

• قم بتخزين كلمات المرور باستخدام دوال اختزال متكيّفة وقوية مع بيانات عشوائية إضافية " salted " ، مثل Argon2 أو scrypt أو bcrypt أو PBKDF2.

• تحقق بشكل مستقل من فعالية التكوين والإعدادات.

أمثلة على سيناريوهات الهجوم Copy Chapter

سيناريو #1: تطبيق يقوم بتشفير أرقام البطاقات الائتمانية باستخدام التشفير الآلي المتوفر مع قاعدة البيانات. لكن هذا يعني أنه بإمكان قاعدة البيانات فكّ التشفير آليًا عند طلب البيانات منها، مما قد يُعرّض أرقام البطاقات الائتمانية للسّرقة عند استغلال ثغرة حقن "SQL”، لذلك، يجب تشفير أرقام البطاقات الائتمانية باستخدام مفتاح عام "Public Key" والسماح فقط للبنية التحتية للتطبيق بفكّ التشفير باستخدام المفتاح الخاص "Private Key".

سيناريو #2:الموقع الذي لا يستخدم بروتوكول TLS لكافة الصفحات أو أن الموقع يدعم التشفير الضعيف، حيث يراقب المهاجم حركة مرور البيانات في الشبكة (على سبيل المثال، في الشبكات اللاسلكية الغير آمنة) ينخفض مستوى الاتصال من HTTPS إلى HTTP، ويعترض الطلبات و يستطيع السطو على بيانات جلسات الاتصالات "Session Cookie" للمستخدم، ثم يعيد المهاجم إرسال واستخدام بيانات جلسة اتصال المستخدم ( التي سبق و تم المصادقة عليها) فيتمكن من الوصول إلى بيانات المستخدم الخاصة أو تعديلها و يمكن استبدالها مما يؤدي إلى تغيير أي من البيانات المنقولة، مثل الجهة المتلقية لتحويل الأموال.

سيناريو #3: قاعدة بيانات كلمات المرور لا تستخدم بيانات عشوائية إضافية "salted “أو إضافة بيانات عشوائية ذات نمط بسيط غير عشوائي بالقدر الكافي استخدام دوال اختزال غير مُضاف لها بيانات عشوائية "unsalted hashes " لتخزين كلمات مرور جميع المستخدمين. عندما توجد ثغرة في خاصية رفع الملفات والتي تسمح للمهاجم باستعادة وتحميل قاعدة بيانات كلمات المرور. و بالتالي تتعرّض جميع كلمات المرور التي تم الكشف عنها لكسر حماية خوارزمياتها باستخدام جداول تحتوي على كلمات سرية مُعدّة مسبقًا "rainbow table of pre-calculated hashes". قد يتم كسر الـ"hashes" التي تم إنشاؤها بشكل بسيط وسريع، في حال استخدمت بطاقات المعالجة الرسومية"GPUs" حتى وإن تم إضافة بيانات عشوائية "salt".

المصادر Copy Chapter

• OWASP Proactive Controls: Protect Data
  Everywhere

• OWASP Application Security Verification Standard (V7,
  9, 10)

• OWASP Cheat Sheet: Transport Layer
  Protection

• OWASP Cheat Sheet: User Privacy
  Protection

• OWASP Cheat Sheet: Password and Cryptographic Storage

• OWASP Cheat Sheet:
  HSTS

• OWASP Testing Guide: Testing for weak cryptography

قائمة الربط مع إطار CWEs Copy Chapter

CWE-261 Weak Encoding for Password

CWE-296 Improper Following of a Certificate's Chain of Trust

CWE-310 Cryptographic Issues

CWE-319 Cleartext Transmission of Sensitive Information

CWE-321 Use of Hard-coded Cryptographic Key

CWE-322 Key Exchange without Entity Authentication

CWE-323 Reusing a Nonce, Key Pair in Encryption

CWE-324 Use of a Key Past its Expiration Date

CWE-325 Missing Required Cryptographic Step

CWE-326 Inadequate Encryption Strength

CWE-327 Use of a Broken or Risky Cryptographic Algorithm

CWE-328 Reversible One-Way Hash

CWE-329 Not Using a Random IV with CBC Mode

CWE-330 Use of Insufficiently Random Values

CWE-331 Insufficient Entropy

CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator
(PRNG)

CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)

CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)

CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator
(PRNG)

CWE-340 Generation of Predictable Numbers or Identifiers

CWE-347 Improper Verification of Cryptographic Signature

CWE-523 Unprotected Transport of Credentials

CWE-720 OWASP Top Ten 2007 Category A9 - Insecure Communications

CWE-757 Selection of Less-Secure Algorithm During Negotiation
('Algorithm Downgrade')

CWE-759 Use of a One-Way Hash without a Salt

CWE-760 Use of a One-Way Hash with a Predictable Salt

CWE-780 Use of RSA Algorithm without OAEP

CWE-818 Insufficient Transport Layer Protection

CWE-916 Use of Password Hash With Insufficient Computational Effort

2021 Docs Ar A03 2021 Injection (`2021/docs/ar/A03_2021-Injection.md`) Copy Section

A03:2021 – الحقن

العوامل Copy Chapter

نظرة عامة Copy Chapter

هجمات الحقن تحتل المركز الثالث، حيث أن 94٪ من التطبيقات التي تم فحصها مهدّدة بصنف واحد أو أكثر من هجمات الحقن المرتبطة مع CWE-79، CWE-89، CWE-73

الوصف Copy Chapter

يكون البرنامج معرض للإصابة بهذه الهجمات عندما:

• إذا كانت المدخلات المزوّدة من المستخدم غير مُتحقّق منها أو غير موثوقة، أو لم يتم تصفيتها من قِبل البرنامج.

• تمرير طلبات الاستعلامات الديناميكية أو استدعاء بيانات غير محدّدة المعاملات (Non-Parameterized) بشكل مباشر إلى مترجم الأوامر بدون استخدام آلية واعية تضمن تهرب المدخلات من التفاعل مع مترجم الأوامر "Context-aware escaping".

• المدخلات الضَّارة التي يتم استخدامها والبحث عنها في (Object-relational mapping ORM) والتي قد تقوم بتسريب بيانات إضافية غير مطلوبة أو بيانات حساسة.

• تمرير المدخلات الضَّارة بشكل مباشر أو بشكل متسلسل غير مباشر، قواعد البيانات العلائقية "SQL" أو الأوامر التي تحتوي على هياكل وبيانات مشبوهة في طلبات الاستعلام الديناميكية "dynamic queries” أو الأوامر أو الإجراءات المخزّنة

من أشهر أنواع الحقن : الـ SQL، NoSQL، سطر الأوامر في أنظمة التشغيل، خرائط ربط الكائنات بقواعد البيانات العلائقية "Object-relational mapping”، LDAP، ولغات البرمجة التعبيرية "EL"، مكتبات التنقّل خلال مخططات الكائنات"OGNL". مبدأ "الحقن" مُتطابق في جميع لغات البرمجة وفي جميع المفسّرات، مراجعة مصدر الشّفرة المصدرية هي أفضل طريقة لاكتشاف ما إذا كان التطبيق البرمجي عُرضة للإصابة بثغرة الحقن. يوصَّى بشدّة بالفحص التلقائي لكل المعاملات تروسيات صفحات الويب، الروابط التشعبيّة "URL"، وملفات تعريف الارتباط "Cookies"، و JSONو الـ SOAP ومدخلات معطيات الـ XML. المنظمات بإمكانها إضافة أدوات الفحص ثابتة المصدر"SAST" وأدوات الفحص الديناميكية للتطبيقات البرمجية "DAST"واستخدامها في مسارات CI/CD، لتحديد العيوب الموجودة من قبل عملية طرح المنتج للاستخدام.

كيفية الحماية منها Copy Chapter

• لتفادي هجمات الحقن يجب الفصل والتفّريق بين كل من البيانات والأوامر والاستعلامات.

• ُفضّل استخدام واجهات برمجة تطبيقات (API) ** آمنة، وذلك لتفادي استخدام ** مفسّر الأوامر كُلّيًا، و توفير واجهة إدخال ذات معاملات " Parametrized Interface " أو الانتقال إلى استخدام كائنات الـ "Relational Mapping Tools (ORMs)".

• ملاحظة: حتى في حال استخدام المعاملات" Parameterized” الإجراءات المخزّنة قد لا تزال قاعدة البيانات مُعرّضة لهجمات الحقن في حال كانت الـ PL/SQL أو T-SQL قابلة لتنفيذ الاستعلامات المتسلسلة "الغير مباشرة " أو تنفيذ تعليمات برمجية ضارّة من خلال EXECUTE IMMEDIATE أو exec ().

• استخدام عمليات التحقّق من المدخلات الإيجابية و المرتبطة ب "قوائم السماح/القوائم البيضاء" من طرف الخادم. لكن هذه لا تعتبر حماية متكاملة حيث أن هناك العديد من البرامج تتطّلب رموز خاصة "Special Characters" مثل حقل النص (TextArea) أو واجهات تطبيقات البرامج (APIs) لتطبيقات الهواتف.

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

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

• ضع حدودا و أو ضوابط تحكّم أخرى عند استخدام الاستعلامات داخل SQL، لتجنّب كشف السجلات الحساسة في حال وجود هجمات حقن الـ SQL

أمثلة على سيناريوهات الهجوم Copy Chapter

سيناريو #1: برنامج يستخدم بيانات غير موثقة في بناء الاستعلام في قاعدة بيانات الSQL والتي قد يعرضها للحقن:

String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") + "'";

سيناريو #2: الثقة العمياء للبرنامج في إطار العمل (Framework) وقد تؤدي تلك الاستعلامات إلى ثغرات الحقن مثل Hibernate Query Language (HQL):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" +
request.getParameter("id") + "'");

في كلتا الحالتين السابقتين، المُخترق قام بتعديل قيمة متغيّر الـ id في المتصفح لإرسال ‘ UNION SELECT SLEEP(10);-- . مثلاً:

http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

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

المصادر Copy Chapter

• OWASP Proactive Controls: Secure Database Access

• OWASP ASVS: V5 Input Validation and Encoding

• OWASP Testing Guide: SQL Injection, Command Injection,
  and ORM Injection

• OWASP Cheat Sheet: Injection Prevention

• OWASP Cheat Sheet: SQL Injection Prevention

• OWASP Cheat Sheet: Injection Prevention in Java

• OWASP Cheat Sheet: Query Parameterization

• OWASP Automated Threats to Web Applications – OAT-014

• PortSwigger: Server-side template injection

قائمة الربط مع إطار CWEs Copy Chapter

CWE-20 Improper Input Validation

CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

CWE-75 Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)

CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')

CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

CWE-83 Improper Neutralization of Script in Attributes in a Web Page

CWE-87 Improper Neutralization of Alternate XSS Syntax

CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

CWE-91 XML Injection (aka Blind XPath Injection)

CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')

CWE-94 Improper Control of Generation of Code ('Code Injection')

CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')

CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page

CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')

CWE-99 Improper Control of Resource Identifiers ('Resource Injection')

CWE-100 Deprecated: Was catch-all for input validation issues

CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')

CWE-116 Improper Encoding or Escaping of Output

CWE-138 Improper Neutralization of Special Elements

CWE-184 Incomplete List of Disallowed Inputs

CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

CWE-471 Modification of Assumed-Immutable Data (MAID)

CWE-564 SQL Injection: Hibernate

CWE-610 Externally Controlled Reference to a Resource in Another Sphere

CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')

CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax

CWE-652 Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')

CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')

2021 Docs Ar A04 2021 Insecure Design (`2021/docs/ar/A04_2021-Insecure_Design.md`) Copy Section

A04:2021 – التصميم الغير آمن

العوامل Copy Chapter

نظرة عامة Copy Chapter

هو تصنيف جديد تمت إضافته في هذه النسخة لعام 2021 والذي يركّز على المخاطر المتعلقة بعيوب وأخطاء التصميم، مما يدعو إلى المزيد من استخدام نمذجة التهديدات، وأنماط التصميم الآمنة وبنية تحتية مبنيّة على أفضل الامتثالات. الجدير بالذكر أن إطار CWE تضمن الـ CWEs التالية: CWE-209، CWE-256، CWE-501، CWE-522.

الوصف Copy Chapter

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

كيفية الحماية منها Copy Chapter

• إنشاء واستخدام دورة حياة تطوير آمنة مع الاستعانة بأخصائي أمن تطبيقات لتقييم وتصميم عناصر التحكّم المتعلقة بالأمان والخصوصية.

• إنشاء واستخدام مكتبة تحتوي على أنماط التصميم الآمن ومكونات مُسبقة وجاهزة للاستخدام.

• نمذجة التهديدات لعمليات المصادقة "التحقّق من الهوية" الحساسة، والتحكّم في الوصول، والتسلسل المنطقي التطبيق، والمسارات الأساسية للتطبيق.

• وحدة للكتابة ولاختبارات التكامل للتحقّق من أن جميع المسارات الحرجة مقاومة لنموذج التهديد المتوقّع.

أمثلة على سيناريوهات الهجوم Copy Chapter

سيناريو #1: قد يتضمّن مسار عملية استرداد عناصر اعتماد المصداقية" أسئلة وإجابات"، الذي يحظره إطار NIST 800-63b وOWASP ASVS وOWASP Top 10، فلا يمكن الوثوق في الأسئلة والإجابات كأدلّة على صحة هوية المستخدم حيث يمكن لأكثر من شخص معرفة الإجابات، وهذا هو سبب حظره. يجب إزالة الشّفرة المصدرية تلك واستبدالها بتصميم أكثر أمانًا.

سيناريو #2: تقوم دور سينما بعمل خصومات لعمليات الحجز الجماعي لـ١٥ شخص كحد أقصى قبل الدفع. هذا المسار قد يُشكّل خطرًا ويسمح للمهاجم باختبار ما إذا كان بإمكانه حجز ٦٠٠ مقعد دفعة واحدة من خلال طلبات قليلة، مما يتسبّب في خسارة هائلة للدخل.

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

المصادر Copy Chapter

• OWASP Cheat Sheet: Secure Design Principles

• OWASP SAMM: Design:Security Architecture

• OWASP SAMM: Design:Threat Assessment

• NIST – Guidelines on Minimum Standards for Developer Verification of Software

• The Threat Modeling Manifesto

• Awesome Threat Modeling

قائمة الربط مع إطار CWEs Copy Chapter

CWE-73 External Control of File Name or Path

CWE-183 Permissive List of Allowed Inputs

CWE-209 Generation of Error Message Containing Sensitive Information

CWE-213 Exposure of Sensitive Information Due to Incompatible Policies

CWE-235 Improper Handling of Extra Parameters

CWE-256 Unprotected Storage of Credentials

CWE-257 Storing Passwords in a Recoverable Format

CWE-266 Incorrect Privilege Assignment

CWE-269 Improper Privilege Management

CWE-280 Improper Handling of Insufficient Permissions or Privileges

CWE-311 Missing Encryption of Sensitive Data

CWE-312 Cleartext Storage of Sensitive Information

CWE-313 Cleartext Storage in a File or on Disk

CWE-316 Cleartext Storage of Sensitive Information in Memory

CWE-419 Unprotected Primary Channel

CWE-430 Deployment of Wrong Handler

CWE-434 Unrestricted Upload of File with Dangerous Type

CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')

CWE-451 User Interface (UI) Misrepresentation of Critical Information

CWE-472 External Control of Assumed-Immutable Web Parameter

CWE-501 Trust Boundary Violation

CWE-522 Insufficiently Protected Credentials

CWE-525 Use of Web Browser Cache Containing Sensitive Information

CWE-539 Use of Persistent Cookies Containing Sensitive Information

CWE-579 J2EE Bad Practices: Non-serializable Object Stored in Session

CWE-598 Use of GET Request Method With Sensitive Query Strings

CWE-602 Client-Side Enforcement of Server-Side Security

CWE-642 External Control of Critical State Data

CWE-646 Reliance on File Name or Extension of Externally-Supplied File

CWE-650 Trusting HTTP Permission Methods on the Server Side

CWE-653 Insufficient Compartmentalization

CWE-656 Reliance on Security Through Obscurity

CWE-657 Violation of Secure Design Principles

CWE-799 Improper Control of Interaction Frequency

CWE-807 Reliance on Untrusted Inputs in a Security Decision

CWE-840 Business Logic Errors

CWE-841 Improper Enforcement of Behavioral Workflow

CWE-927 Use of Implicit Intent for Sensitive Communication

CWE-1021 Improper Restriction of Rendered UI Layers or Frames

CWE-1173 Improper Use of Validation Framework

2021 Docs Ar A05 2021 Security Misconfiguration (`2021/docs/ar/A05_2021-Security_Misconfiguration.md`) Copy Section

A05:2021 – الإعدادات الأمنية الخاطئة

العوامل Copy Chapter

نظرة عامة Copy Chapter

بعد أن كان هذا التهديد في المرتبة السادسة في الإصدار السابق لعام 2017 الآن نجده في المرتبة الخامسة، حيث أنه تم إجراء اختبار على %90 من البرامج والتطبيقات للتأكد إن كانت تحتوي على أيّة أخطاء في طريقة الإعدادات والتكوين الصحيحة، فليس من المُستغرب انتقال هذا التهديد من المرتبة السادسة إلى الخامسة. كذلك تم ضم "XML External Entities XXE" لهذا النوع من الإعدادات والتكوين الخاطئة. تضمن الـ CWEs التالية CWE-16 (Configuration), CWE-611 (Improper Restriction of XML External Entity).

الوصف Copy Chapter

من المحتمل ان يكون التطبيق ضعيف امنياً إذا احتوى على النقاط التالية:

• عدم مراجعة التكوين والضبط الآمن لإعدادات التطبيق أو في أي جزء من أجزاء التطبيق أو تكوين أذونات خاطئة في الخدمات السحابيّة.

• تثبيت وإتاحة خدمات ومِيزات غير ضرورية (منافذ غير ضرورية، الخدمات، الصفحات، الحسابات، والصلاحيات).

• تفعيل الحسابات الافتراضية أو عدم تغييرها أو عدم تغيير كلمات المرور الخاصة بها.

• كشف رسائل معالجة الأخطاء (Error Handling) عن معلومات قابلة للتتبّع (Stack Traces) أو عرض رسائل الخطأ التي تحتوي على معلومات تفصيلية يمكن أن تُستغل من قِبل المستخدم.

• تكون الميزات الأمنية الأحدث مُعطّلة أو لم يتم تكوينها بشكل آمن في الأنظمة التي تمت ترقيتها.

• عدم تعيين إعدادات الأمان في خوادم التطبيقات وإطار التطبيقات على سبيل المثال (Struts, Spring, ASP.NET) والمكتبات وقواعد البيانات وما إلى ذلك إلى قيم آمنة.

• لا يرسل أو يستخدم الخادم عناوين "Headers" عند نقل البيانات الحساسة للمتصفح أو عند تقديمها من قِبل المتصفح.

• لم يعد البرنامج مدعومًا من قبل مزوّدي الخدمات أو ضعيف أمنيًا لاحتوائه على ثغرات أمنية (انظر إلى - A06:2021 الثغرات والأنظمة الغير قابلة للتحديث).

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

كيفية الحماية منها Copy Chapter

يجب تطبيق آلية آمنة لتكوين البرامج أو الأجهزة، تشمل على:

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

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

• مراجعة وتحديث الإعدادات بما يتناسب مع كافة ملاحظات الأمان والتحديثات والإصلاحات كجزء من عملية إدارة حِزم الإصلاحات والترقيات. (انظر إلى- A06:2021 الثغرات والأنظمة الغير قابلة للتحديثات). بالإضافة إلى مراجعة أذونات التخزين السحابيّة على سبيل المثال (S3 Bucket Permissions).

• تتيح بنية التطبيق المقسّمة فصلًا فعّالًا وآمنًا بين المكونات، مع التجزئة في مجموعات أمان السحابة (ACLs).

• إرسال توجيهات الأمان إلى المستخدمين على سبيل المثال Security Headers.

• أتمتة عملية التحقق من التحديثات الآمنة للتحقّق من فعاليّة التكوينات والإعدادات في جميع البيئات.

• تشغيل أدوات الفحص للتحقّق من فعاليّة التكوينات والإعدادات في جميع البيئات للكشف عن الإعدادات الخاطئة.

أمثلة على سيناريوهات الهجوم Copy Chapter

سيناريو #1: عندما يحتوي احد الخوادم على تطبيق من التطبيقات غير محدث وما يزال يُستخدم في بيئة الإنتاج "Production Server" هذه العيّنات من التطبيقات قد تحتوي على ثغرات أمنية يمكن أن يستخدمها المهاجم في اختراق الخادم ، وبافتراض أن أحد هذه البرامج هي وحدة تحكّم لإدارة الخادم وتحتوي على الاعدادات الافتراضية والرقم السري الافتراضي، في هذه الحالة فإن المهاجم سوف يُسجّل الدخول باستخدام الرقم السري الافتراضي ويتحكّم بالخادم.

سيناريو #2: عندما تكون قائمة الدليل "Directory Listing" غير معطّلة في الخادم الخاص بك، قد يكتشف المهاجم أن بإمكانه سرد قائمة الملفات المخزنة على الخادم وبعد ذلك بإمكانه العثور وتثبيت جميع فئات جافا (Compiled Java Classes) ومن ثم يقوم بفكّها وتطبيق الهندسة العكسية لعرض الشّفرة المصدرية، سوف يحاول المهاجم بعد ذلك إيجاد خطأ أمني للتحكّم في الوصول إلى الخادم.

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

سيناريو #4: أن يكون مقدّم الخدمة السحابيّة لديه أذونات مشاركة افتراضية مفتوحة على الإنترنت من قِبل مستخدمي CSP الآخرين، يسمح هذا بالوصول إلى البيانات الحساسة المخزّنة في سحابة التخزين.

المصادر Copy Chapter

• OWASP Testing Guide: Configuration Management

• OWASP Testing Guide: Testing for Error Codes

• Application Security Verification Standard V19 Configuration

• NIST Guide to General Server Hardening

• CIS Security Configuration Guides/Benchmarks

• Amazon S3 Bucket Discovery and Enumeration

قائمة الربط مع إطار CWEs Copy Chapter

CWE-2 7PK - Environment

CWE-11 ASP.NET Misconfiguration: Creating Debug Binary

CWE-13 ASP.NET Misconfiguration: Password in Configuration File

CWE-15 External Control of System or Configuration Setting

CWE-16 Configuration

CWE-260 Password in Configuration File

CWE-315 Cleartext Storage of Sensitive Information in a Cookie

CWE-520 .NET Misconfiguration: Use of Impersonation

CWE-526 Exposure of Sensitive Information Through Environmental Variables

CWE-537 Java Runtime Error Message Containing Sensitive Information

CWE-541 Inclusion of Sensitive Information in an Include File

CWE-547 Use of Hard-coded, Security-relevant Constants

CWE-611 Improper Restriction of XML External Entity Reference

CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

CWE-756 Missing Custom Error Page

CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')

CWE-942 Permissive Cross-domain Policy with Untrusted Domains

CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag

CWE-1032 OWASP Top Ten 2017 Category A6 - Security Misconfiguration

CWE-1174 ASP.NET Misconfiguration: Improper Model Validation

2021 Docs Ar A06 2021 Vulnerable And Outdated Components (`2021/docs/ar/A06_2021-Vulnerable_and_Outdated_Components.md`) Copy Section

A06:2021 الثغرات و الانظمة الغير قابلة للتحديثات

العوامل Copy Chapter

نظرة عامة Copy Chapter

كانت تحتل المرتبة الثانية في عملية الاستطلاع التي تم إجراؤها في قطاع أمن التطبيقات ولكنها أيضًا تمتلك بيانات كافية لتُصبح من أعلى عشرة مخاطر من خلال تحليل البيانات. يُعتبر تصنيف " الثغرات والمكوّنات الغير مُحدّثة" من المشاكل المعروفة التي تواجه صعوبات من أجل اختبارها وتقييم مخاطرها ويُعتبر التصنيف الوحيد الذي لا يتضمّن CVEs ومرتبط بـ CWEs. لذلك تم استخدام المعيار الافتراضي للاستغلال أو الأثر وهو 5.0، ونجد أن هناك ارتباط وحيد في هذا التصنيف وهو CWE-1104.

الوصف Copy Chapter

من المحتمل ان تكون عرضة للاختراق:

• إذا كنت لا تعرف إصدارات جميع المكونات التي تستخدمها (من جانب المستخدم أو من جانب الخادم). وهذا يتضمّن المكونات التي تستخدمها بشكل مُباشر بالإضافة إلى المكونات الغير مباشرة.

• إذا كانت المكونات او البرمجيات معرضه للاختراق بسبب انها غير مدعومة أو قديمة. ويتضمن ذلك نظام التشغيل وخادم الويب أو التطبيقات ونظام إدارة قواعد البيانات (DBMS) والتطبيقات وواجهات برمجة التطبيقاتAPI وجميع المكونات وبيئات التي تعمل مع بدء التشغيل .(runtime)

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

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

• إذا لم يقم مطورو البرامج باختبار توافق المكتبات المحدثة أو التي تم اجراء إصلاحات عليها.

• إذا لم تقم بتأمين الاعدادات بالشكل الصحيح. (انظر A05: 2021 – الإعدادات الأمنية الخاطئة ).

كيفية الحماية منها Copy Chapter

يجب أن تكون هناك آلية لإدارة اغلاق الثغرات وذلك لتلبية ما يلي:

• إزالة المكونات الغير مستخدمة والمميزات والملفات والوثائق الغير ضرورية.

• عمل جرد بشكل دوري للإصدارات من جانب المستخدم ومن جانب الخادم (على سبيل المثال، إطار العمل والمكتبات) ومكوناتها باستخدام أدوات مثل Versions, OWASP Dependency Check, Retire.JS وما إلى ذلك، مراقبة المصادر الخاصة بالثغرات باستمرار مثل CVE و NVD بحثًا عن الثغرات التي في المكونات. وقم باستخدام الأدوات الخاصة بتحليل الإعدادات وذلك من أجل أتمتة العملية. وأخيرًا، قم بالاشتراك في تنبيهات البريد الإلكتروني الخاصة بالثغرات الأمنية المتعلقة بالمكونات التي تستخدمها.

• الحصول على المكونات من المصادر الرسمية فقط عبر الروابط الآمنة. يفضل التأكد من ان الحزم موقعه رقمياً لتقليل فرصة تثبيت مكونات معدلة وضارة (انظر A08: 2021- فشل سلامة البيانات والبرمجيات).

• مراقبة المكتبات والمكونات التي لا يتم صيانتها أو التي لا تقوم بعمل تحديثات الأمان للإصدارات القديمة. إذا لم تكن عملية سدّ الثغرات مُمكنة، فكّر في إنشاء آلية افتراضية لمراقبة تلك المكونات ورصد المحاولات الضَّارة والحماية منها

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

أمثلة على سيناريوهات الهجوم Copy Chapter

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

• نظرة على ثغرة CVE-2017-5638، وهي ثغرة أمنية تقوم بتنفيذ تعليمات برمجية عن بُعد لـ Struts 2 والتي تُتيح تنفيذ تعليمات برمجية عشوائية على الخادم، والتي تُسبّب اختراقات خطيرة.

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

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

المصادر Copy Chapter

• OWASP Application Security Verification Standard: V1 Architecture,
  design and threat modelling

• OWASP Dependency Check (for Java and .NET libraries)

• OWASP Testing Guide - Map Application Architecture (OTG-INFO-010)

• OWASP Virtual Patching Best Practices

• The Unfortunate Reality of Insecure Libraries

• MITRE Common Vulnerabilities and Exposures (CVE) search

• National Vulnerability Database (NVD)

• Retire.js for detecting known vulnerable JavaScript libraries

• Node Libraries Security Advisories

• Ruby Libraries Security Advisory Database and Tools

• https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf

قائمة الربط مع إطار CWEs Copy Chapter

CWE-937 OWASP Top 10 2013: Using Components with Known Vulnerabilities

CWE-1035 2017 Top 10 A9: Using Components with Known Vulnerabilities

CWE-1104 Use of Unmaintained Third Party Components

2021 Docs Ar A07 2021 Identification And Authentication Failures (`2021/docs/ar/A07_2021-Identification_and_Authentication_Failures.md`) Copy Section

A07:2021 – الهوية و فشل عملية التحقق

العوامل Copy Chapter

نظرة عامة Copy Chapter

هذ التصنيف يُعرف سابقًا باسم ضعف التحقّق من الهوية (Broken Authentication) وكانت هي الخطر رقم #2 في الإصدار السابق. وحاليًا تشمل على العديد من CWEs المتعلقة بفشل عملية التحقّق. يتضمّن هذا التصنيف كل من (CWE-384,CWE-297,CWE-287).

الوصف Copy Chapter

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

• يسمح بالهجمات الآلية مثل هجمات بيانات الاعتماد (Credential Stuffing)، حيث يكون لدى المهاجم قائمة بأسماء المستخدمين وكلمات المرور.

• يسمح باستغلال هجوم كسر كلمات المرور (Brute Force) أو الهجمات الآلية الأخرى.

• يسمح بهجمات كلمات المرور الافتراضية أو الضعيفة أو المعروفة ، مثل "Password1" أو " Admin / Admin".

• يستخدم عوامل ضعيفة وغير فعّالة لاستعادة كلمات المرور واسترجاع بيانات الاعتماد والتي يجعلها آمنة، مثل "الأجوبة المستندِة على المعرفة".

• يستخدم كلمات مرور غير مشفّرة، أو مشفّرة بشكل مُجزّأ أو بشكل ضعيف (راجع A3:2017- البيانات الحساسة الغير محميّة أو المكشوفة).

• عدم تفعيل التحقّق الثنائي أو تكون غير فعّالة.

• يعرض معرّفات الجلسة (Session IDs) في عنوان URL

• لا يقوم بإعادة إنشاء معرّفات الجلسة بعد تسجيل الدخول بنجاح.

• لا ينهي معرّفات الجلسة بشكل صحيح. لا يتم إنهاء جلسات المستخدم أو رموز المصادقة (Authentication Tokens) وخاصة رموز الدخول الموحّد (SSO) بشكل صحيح خلال تسجيل الخروج أو في فترة الخمول.

كيفية الحماية منها Copy Chapter

• حيثما أمكن ذلك، قم بتفعيل التحقّق الثنائي لمنع الهجمات الآلية لبيانات الاعتماد(Credential Stuffing)، وهجوم كسر كلمات المرور (Brute Force) وهجمات إعادة استخدام بيانات الاعتماد المسروقة.

• لا ترسل أو تضع بيانات اعتماد افتراضية، خاصة بالنسبة لمدراء النظام (المسؤولين)

• نفِّذ عمليات التحقّق من كلمات المرور الضعيفة، مثل اختبار كلمات المرور الجديدة أو التي تم تغييرها ومقارنتها بقائمة أسوأ 10,000 كلمة مرور.

• اضبط طول كلمة المرور وصعوبتها وقم باتباع السياسات والإرشادات الواردة في NIST 800-63b في القسم 5.1.1 "تذكّر كلمات السر المحفوظة أو سياسات كلمة المرور".

• تأكد من أن مسارات كُلًا من التسجيل واستعادة بيانات الاعتماد وواجهة برمجة التطبيقات (API) محميّة ضد هجمات فحص الحسابات (Account Enumeration) ، قم بإظهار نفس رسائل الخطأ لجميع عمليات تسجيل الدخول.

• الحد من محاولات تسجيل الدخول الفاشلة. وقم بتسجيل جميع حالات فشل عملية تسجيل الدخول وقم بتنبيه المسؤولين عند اكتشاف محاولة هجمات كسر بيانات الاعتماد (Credential Stuffing) أو هجوم كسر كلمات المرور (Brute Force) أو أي هجمات أخرى.

• استخدم مدير جلسة مُدمج وآمن من جانب الخادم، يقوم بإنشاء معرّف جلسة عشوائية جديدة مع (Entropy) عالية بعد تسجيل الدخول، معرّفات الجلسات يجب ألا تكون موجودة في عنوان URL، ويجب تخزينها بشكل آمن و إنهاء صلاحيتها بعد تسجيل الخروج، أو الخمول، والانتهاء المُطلق (انتهاء أو نفاذ الوقت).

أمثلة على سيناريوهات الهجوم Copy Chapter

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

سيناريو #2: تحدث معظم هجمات المصادقة بسبب الاستخدام المستمر لكلمات المرور كعامل وحيد لتسجيل الدخول حتى وإن تم اعتماد أفضل الممارسات والتغيير المستمر لكلمات المرور حيث جعل سياسة كلمة المرور معقّدة، يُشجّع المستخدمين على إعادة استخدام كلمة المرور. لذلك ننصح المؤسسات بإيقاف هذه المُمارسات وفقًا لـ NIST 800-63 واستخدام التحقّق الثنائي.

سيناريو #3: لا يتم تعيين مدة انتهاء الجلسة (Timeouts) للتطبيق بشكل صحيح، يقوم المستخدم باستخدام أحد الأجهزة الموجودة في الأماكن العامة للوصول إلى أحد التطبيقات بدلًا من اختيار "تسجيل الخروج"، يقوم المستخدم ببساطة بإغلاق علامة تبويب المتصفح، فيقوم المهاجم باستخدام نفس المتصفح بعد ساعات قليلة ليجد أنه لا يزال المستخدم قيد تسجيل الدخول (Authenticated).

المصادر Copy Chapter

• OWASP Proactive Controls: Implement Digital Identity

• OWASP Application Security Verification Standard: V2 authentication

• OWASP Application Security Verification Standard: V3 Session Management

• OWASP Testing Guide: Identity, Authentication

• OWASP Cheat Sheet: Authentication

• OWASP Cheat Sheet: Credential Stuffing

• OWASP Cheat Sheet: Forgot Password

• OWASP Cheat Sheet: Session Management

• OWASP Automated Threats Handbook

• NIST 800-63b: 5.1.1 Memorized Secrets

قائمة الربط مع إطار CWEs Copy Chapter

CWE-255 Credentials Management Errors

CWE-259 Use of Hard-coded Password

CWE-287 Improper Authentication

CWE-288 Authentication Bypass Using an Alternate Path or Channel

CWE-290 Authentication Bypass by Spoofing

CWE-294 Authentication Bypass by Capture-replay

CWE-295 Improper Certificate Validation

CWE-297 Improper Validation of Certificate with Host Mismatch

CWE-300 Channel Accessible by Non-Endpoint

CWE-302 Authentication Bypass by Assumed-Immutable Data

CWE-304 Missing Critical Step in Authentication

CWE-306 Missing Authentication for Critical Function

CWE-307 Improper Restriction of Excessive Authentication Attempts

CWE-346 Origin Validation Error

CWE-384 Session Fixation

CWE-521 Weak Password Requirements

CWE-613 Insufficient Session Expiration

CWE-620 Unverified Password Change

CWE-640 Weak Password Recovery Mechanism for Forgotten Password

CWE-798 Use of Hard-coded Credentials

CWE-940 Improper Verification of Source of a Communication Channel

CWE-1216 Lockout Mechanism Errors

2021 Docs Ar A08 2021 Software And Data Integrity Failures (`2021/docs/ar/A08_2021-Software_and_Data_Integrity_Failures.md`) Copy Section

A08:2021 – فشل سلامة البرامج والبيانات

العوامل Copy Chapter

نظرة عامة Copy Chapter

تمت إضافة هذا التصنيف في عام 2021 حيث يُركّز على وضع افتراضات تتعلّق بتحديثات البرامج والبيانات الحساسة أو تطبيق معايير CI/CD pipeline من دون التحقّق من سلامتها. إن أحد أكبر التأثيرات الكبيرة والموجودة في قواعد بيانات الثغرات CVE /CVSS والمرتبطة مع إطار CWEs وهم: CWE-502، CWE-829، CWE-494.

الوصف Copy Chapter

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

كيفية الحماية منها Copy Chapter

• تأكد من عدم إرسال البيانات الغير مشفّرة أو الغير موقّعة إلى عملاء غير موثوقين بدون شكل من أشكال التحقق من سلامة أو وجود توقيع رقمي وذلك من أجل اكتشاف التلاعب بالبيانات.

• التحقّق من سلامة البرامج أو البيانات من المصادر الرسمية والمتوقعة، عبر التأكد من وجود التواقيع أو آليات مُشابهة لضمان سلامة البيانات

• تأكد من أن المكتبات والمكونات، مثل Npm أو Maven، تستخدم مصادر موثوقة.

• تأكد من استخدام أدوات الحماية عند استخدام برمجيات الطرف الثالث، مثل OWASP Dependency Check أو OWASP CycloneDX ، والتي تقوم بالتأكد من عدم وجود أي ثغرات أمنية

• تأكد من أن CI / CD لديه الإعدادات المناسبة والتحكّم المناسب للوصول للبرامج والبيانات للتأكد من سلامتها خلال آلية الإنشاء والنشر.

أمثلة على سيناريوهات الهجوم Copy Chapter

سيناريو #1 إلغاء التسلسل الغير آمن: يستدعي تطبيق React مجموعة من الخدمات المصغّرة لـ Spring Boot. فقد حاول المبرمجين بالتأكد من أن الشّفرة المصدرية الخاصة بهم غير قابلة للتغيير. والحل الذي توصلوا إليه هو إجراء تسلسل لحالة المستخدم وتمريرها ذهابًا وإيابًا مع كل طلب. فقد لاحظ المهاجم توقيع كائن جافا R00 يمكنه من استخدام أداة Java Serial Killer للحصول على إمكانية التنفيذ عن بعد.

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

سيناريو #3 التحديثات التي استهدفت SolarWinds: يقوم المهاجمون المتقدمون باستهداف آلية التحديث للأنظمة. ومن خلال ملاحظة الهجمة الحديثة التي استهدفت SolarWinds Orion. حيث قامت الشركة بتطوير آلية وسياسة للتأكد من سلامة عملية التحديث وأمنها. ومع ذلك فقد يستطيع المهاجمون استغلالها، وقد حدث ذلك واستغلوا المهاجمين تلك الآلية ولمدة أشهر، حيث قاموا بحقن برمجيات التحديثات للأنظمة التي أثّرت على أكثر من 18,000 نظام لأكثر من 100 منظمة حول العالم. حيث يُعتبر هذا الهجوم من أخطر الهجمات التي حدثت حتى يومنا هذا.

المصادر Copy Chapter

• [OWASP Cheat Sheet: Software Supply Chain Security](Coming Soon)

• [OWASP Cheat Sheet: Secure build and deployment](Coming Soon)

• OWASP Cheat Sheet: Infrastructure as Code

• OWASP Cheat Sheet: Deserialization

• SAFECode Software Integrity Controls

• A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack

• CodeCov Bash Uploader Compromise

• Securing DevOps by Julien Vehent

قائمة الربط مع إطار CWEs Copy Chapter

CWE-345 Insufficient Verification of Data Authenticity

CWE-353 Missing Support for Integrity Check

CWE-426 Untrusted Search Path

CWE-494 Download of Code Without Integrity Check

CWE-502 Deserialization of Untrusted Data

CWE-565 Reliance on Cookies without Validation and Integrity Checking

CWE-784 Reliance on Cookies without Validation and Integrity Checking in a Security Decision

CWE-829 Inclusion of Functionality from Untrusted Control Sphere

CWE-830 Inclusion of Web Functionality from an Untrusted Source

CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes

2021 Docs Ar A09 2021 Security Logging And Monitoring Failures (`2021/docs/ar/A09_2021-Security_Logging_and_Monitoring_Failures.md`) Copy Section

A09:2021 – فشل عملية تسجيل الاحداث والمراقبة

العوامل Copy Chapter

نظرة عامة Copy Chapter

شهد " فشل في تسجيل السجلات الأمنية والمراقبة " ارتفاع بسيط من المرتبة العاشرة في أعلى عشرة مخاطر لعام 2017 إلى المرتبة التاسعة في الاستطلاع الذي تم إجراؤه في قطاع أمن التطبيقات. حيث يُشكّل " فشل في تسجيل السجلات الأمنية والمراقبة " تحدّيًا لإيجاد طريقة لاختباره، غالبًا ما يتطلّب ‏مقابلات أو استفسارات ما إذا كانت الهجمات تم اكتشافها أثناء عمليات اختبار الاختراق. ومع ذلك لا يوجد لهذا التصنيف الكثير من البيانات في قاعدة البيانات CVE/CVSS,، ولكن عمليات الاكتشاف والرصد والاستجابة لهذا التصنيف أمر في غاية الأهمية. و يمكن أن يكون مؤثرًا على عدم فعاليّة المراقبة للأحداث وعلى الانتباه للإنذارات والتي قد تُسبّب الحوادث، أو عدم وجود أدلة كافية عند القيام بالتحاليل الجنائية وهذا التصنيف يرتبط بـ
CWE-778 وكذلك CWE-117 و CWE-223 و CWE-532.

الوصف Copy Chapter

عند العودة إلى أعلى عشرة مخاطر لعام 2021، نجد أن هذا التصنيف يقوم بالمساعدة على رصد واكتشاف واستجابة الثغرات النشِطة أو لعمليات الاختراق التي تحدث، ومن غير عملية تسجيل الأحداث ومراقبتها، لن تستطيع اكتشاف ورصد أو حتى الاستجابة للاختراقات، لذلك وجود عملية تسجيل الأحداث ومراقبتها يساعد على الاستجابة في الوقت المناسب:

• الأحداث القابلة لإجراءات التدقيق والمتابعة، مثل عمليات تسجيل الدخول الفاشلة وكذلك عمليات النقل للملفات ذات الأحجام العالية التي لم يتم تسجيلها.

• التنبيهات والإنذارات التي لم يتم تسجيلها أو يتم تسجيلها من دون وصف واضح.

• لا يتم متابعة وتسجيل الأحداث ومراقبتها للتطبيقات أو واجهة برمجة التطبيقات API أي أنشطة ضارّة.

• يتم تخزين سجلات الأحداث محلّيًا فقط

• وضع معايير مناسبة للتنبيهات الأمنية مثل (حد عمليات تسجيل الدخول) ، وكذلك إيجاد سياسة واضحة لعملية تصعيد التنبيهات الأمنية والعمل عليها بالشكل الصحيح.

• عدم وجود أي إنذارات عند إجراء اختبارات الاختراق أو الفحص بواسطة أداة DAST مثل OWASP ZAP

• التطبيقات لا تستطيع اكتشاف أو التنبيه عند وجود أنشطة ضارّة تحدث في الوقت الحالي.

أنت مُعرّض لتسريب البيانات والمعلومات في حال عدم ضبط عملية تسجيل الأحداث والتنبيهات بالشكل الصحيح والتي قد تسمح للمستخدم أو حتى المهاجم من مشاهدتها انظر إلى (A02- تخطّي صلاحيات الوصول.)

كيفية الحماية منها Copy Chapter

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

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

• التأكد أن عمليات تسجيل الأحداث تتم بشكل منسّق وصحيح وذلك لكي يتم إدارتها بشكل صحيح.

• التأكد من أن البيانات مشفّرة بالشكل الصحيح وذلك للحماية من عمليات الحقن أو الهجمات التي قد تحدث على أنظمة المراقبة

• التأكد من أن عمليات نقل البيانات الحساسة تتم مراقبتها والتأكد من سلامتها، وذلك للتأكد من عدم تعرّضها لتخريب أو تلاعب أو أي حذف.

• يجب أن يكون لدى فريق DevSecOps آلية فعّالة لعملية المراقبة والتي تقوم بعملية الاكتشاف والاستجابة للتنبيهات، مثل الأنشطة الضارّة. ومن أهم المرتكزات هي سرعة الاكتشاف والاستجابة لها.

• قم بإيجاد خطة للاستجابة للحوادث السيبرانية وتستطيع الاعتماد على NIST 800-61r2 أو النسخ الأحدث إن توفّرت.

هناك تطبيقات وإطارات مفتوحة المصدر وتجارية مثل (OWASP ModSecurity Core Rule Set,، Open-Source Log) وهنا كذلك منصّات تقوم بعملية جمع وربط سجلات الأحداث مثل منصّة ELK Stack والتي تُتيح لك مميزات إضافية منها لوح للمراقبة وكذلك تنبيهات.

أمثلة على سيناريوهات الهجوم Copy Chapter

سيناريو #1: ‎المشغّل لموقع تابع لشركة تؤمّن خطط التأمين الطبي للأطفال لم يتمكن من اكتشاف ثغرة امنية لعدم توفر أدوات تسجيل الاحداث الأمنية ومراقبتها. حيث قام أحد الأطراف الخارجية بإبلاغ شركة التأمين الطبي عن وجود هجمة سيبرانية تضمنت الدخول والتعديل على آلاف السجلات الصحية لأكثر من 3.5 مليون طفل. وفي التقرير المعدّ بعد الهجمة وُجِد أن مطوّري موقع الويب أهملوا نقاط ضعف امنية مهمّة. ولعدم وجود أدوات تسجيل الاحدث الأمنية ومراقبتها، قد يكون تسريب البيانات قد حدث من بداية عام 2013 وامتد الى أكثر من 7 سنوات.

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

سيناريو #3: ‎عانت شركة طيران أوروبية كبرى من تسريب ضمن لائحة النظام العام لحماية البيانات (GDPR). وقد عُلم أن التسريب حدث بسبب ثغرات في نظام الدفع تم استغلالها من قبل منفذي الهجوم والذين جمعوا سجلات الدفع لأكثر من 400,000 عميل. نتيجة لذلك، قام مشرّع الخصوصية بتغريم شركة الطيران 20 مليون باوند.

المصادر Copy Chapter

• OWASP Proactive Controls: Implement Logging and Monitoring

• OWASP Application Security Verification Standard: V8 Logging and Monitoring

• OWASP Testing Guide: Testing for Detailed Error Code

• OWASP Cheat Sheet: Application Logging Vocabulary

• OWASP Cheat Sheet: Logging)

• Data Integrity: Recovering from Ransomware and Other Destructive Events

• Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events

• Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events

قائمة الربط مع إطار CWEs Copy Chapter

CWE-117 Improper Output Neutralization for Logs

CWE-223 Omission of Security-relevant Information

CWE-532 Insertion of Sensitive Information into Log File

CWE-778 Insufficient Logging

2021 Docs Ar A10 2021 Server Side Request Forgery (SSRF) (`2021/docs/ar/A10_2021-Server-Side_Request_Forgery_(SSRF).md`) Copy Section

A10:2021 – تزوير الطلبات من جانب الخادم SSRF

العوامل Copy Chapter

نظرة عامة Copy Chapter

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

الوصف Copy Chapter

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

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

كيفية الحماية منها Copy Chapter

يستطيع المُطوّرين منع تزوير طلبات الخادم بتنفيذ بعض أو كل وسائل الدفاع التالية في ضوابط الدفاع العميق (Defense in Depth) :

**من خلال طبقات الشبكة** Copy Chapter

• تقسيم وظائف الوصول إلى الموارد عن بعد في شبكات مُنفصلة لتقليل تأثير تزوير طلبات الخادم.

• فرض سياسات جدار الحماية "الرفض افتراضيًا" أو ضبط آليات التحكّم في الوصول إلى الشبكة لحظر جميع حركات المرور للشبكة الداخلية باستثناء حركات المرور الأساسية.

**من خلال طبقات التطبيقات** Copy Chapter

• التصّفية والتحقّق من صحة جميع بيانات الإدخال المقدّمة من قِبل المستخدم.

• استخدام عناوين محدّدة في الروابط، URL استخدام منافذ محدّدة مع تحديد قائمة من العناوين المحدّدة مسبقًا في قائمة مسموح بها.

• لا تقم برد الطلبات للعميل على شكل بيانات خام

• قم بتعطيل إعادة التوجيه إلى HTTP.

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

لا تقم بتخفيف المخاطر على هجمات SSRF من خلال استخدام سياسة المنع المبنيّة على قائمة التعبيرات المنطقية أو (Regular Expression). حيث أن المهاجمين لديهم قوائم مُعدّة مسبقًا ومتعدّدة لمحاولة تخطّي عمليات الحجب تلك.

أمثلة على سيناريوهات الهجوم Copy Chapter

يستطيع المهاجمين استخدام تزوير طلبات الخادم لمهاجمة الأنظمة المحميّة خلف جدران حماية تطبيقات الويب(WAF)، وجدران الحماية أو قائمة التحكّم للوصول للشبكة باستخدام سيناريو مثل:

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

سيناريو #2: بيانات حساسة غير محميّة والتي يستطيع المهاجم الوصول إليها:
يستطيع المهاجم الوصول للبيانات الحساسة الداخلية مثل ملف ( file:///etc/passwd)أو حتى للخدمات الداخلية من خلال استغلال هذه الثغرة

سيناريو #3: الوصول إلى تخزين البيانات الوصفيّة للخدمات السحابيّة :
يمتلك معظم موفرّي السحابة تخزين البيانات الوصفيّة مثل http://169.254.169.254 ويمكن للمهاجم قراءة تلك البيانات الوصفيّة للحصول على معلومات حساسة منها.

سيناريو #4: اختراق الخدمات الداخلية وإساءة استخدامها من قِبل المهاجم:
يمكن للمهاجم إساءة استخدام الخدمات الداخلية لإجراء مزيد من الهجمات مثل تنفيذ التعليمات البرمجية عن بُعد (RCE) أو هجوم حجب الخدمة (DoS).

المصادر Copy Chapter

• OWASP - Server-Side Request Forgery Prevention Cheat Sheet

• PortSwigger - Server-side request forgery (SSRF)

• Acunetix - What is Server-Side Request Forgery (SSRF)?

• SSRF bible

• A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!

قائمة الربط مع إطار CWEs Copy Chapter

CWE-918 Server-Side Request Forgery (SSRF)

2021 Docs Ar A11 2021 Next Steps (`2021/docs/ar/A11_2021-Next_Steps.md`) Copy Section

A11:2021 – الخطوات المقبلة

المنظمات التي تعمل لبناء برنامج أمني متكامل للتطبيقات أو تقديم استشارات أمنية أو خلق أدوات برمجية؛ تأمل في توسيع نطاق خدماتها. خلال ذلك قد تواجه هذه المشكلات الأربعة التالية التي تستحق الالتفات لها وتحديدها ومعالجتها:

مشكلات جودة الشفرة المصدرية Copy Chapter

• الوصف. تتضمن مشكلات جودة الشفرة المصدرية: عيوبًا أمنية، أو انماطًا معروفة، أو إعادة استخدام المتغيرات لأغراض متعددة، ظهور معلومات حساسة في نمط التصحيح “debugging output”، تكون سلسلة من الأخطاء المتتابعة، ظهور خطأ برمجي بسبب تغير في للنظام ما بين عملية فحص الشرط البرمجي/استخدام مخرجات هذا الشرط، ظهور unassigned أو signed conversion والتي يقوم بها البرنامج باسم” use after free errors”، ومشكلات أخرى.
  ما يميز هذه المشاكل أنها يمكن تحديدها عادةً بأدوات تحليل التعليمات البرمجية الثابتة وstringent compiler flags وlinter IDE plugins، ألغت اللغات الحديثة العديد من هذه المشكلات، مثل ملكية الذاكرة او (memory ownership) او مفهوم (borrowing concept) او مفهوم (Rust’s threading design) وتطبيق مفاهيم أخرى تطبق في آلية الكتابة.

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

• مثال على سيناريو هجوم. قد يقوم المهاجم بالحصول على معلومات حساسة او يقوم بالتغير الغير مصرح به على المعلومات من خلال استغلال ما يسمى (race condition) عبر مؤشرات مترابطة ومتعددة

• المصادر

  • OWASP Code Review Guide

  • Google Code Review Guide

حجب الخدمة Copy Chapter

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

• كيفية الحماية منها. - قم بعمل اختبار الشفرة المصدرية لوحدة المعالجة المركزيةCPU، والمدخلات / المخرجات، والذاكرة المستخدمة. قم بإعادة هندسة العمليات التي تستهلك المصادر أو تحسينها أو تخزينها مؤقتًا. ضع في اعتبارك ضوابط الوصول للأشياء ذات الاحجام الكبيرة لضمان أن الأفراد المصرح لهم فقط يمكنهم الوصول إلى ملفات أو أشياء ضخمة أو قم بخدمتهم عن طريق شبكة تخزين مؤقت.

• مثال على سيناريو هجوم. - قد يتوقع المهاجم أن كل عملية تستغرق لتنفيذها من 5 إلى 10 ثوانٍ حتى تكتمل. لذلك يقوم بتشغيل أربع عمليات في نفس الوقت ولها (thread) محدد، سيبدو لك أن الخادم قد يتوقف عن الاستجابة بسبب عملية الضغط. لذلك يعود المهاجم (1000 thread ) لكي يتعطل النظام ولا يستجيب بشكل كامل

• المصادر

  • OWASP Cheat Sheet: Denial of Service

  • OWASP Attacks: Denial of Service

ادارة اخطاء الذاكرة Copy Chapter

• الوصف. غالبًا ما تتم كتابة تطبيقات الويب بلغات يمكن التحكم بذاكرتها، مثل Java أو .NET أو node.js (JavaScript أو TypeScript). ومع ذلك، تتم كتابة هذه اللغات بلغات الأنظمة التي بها مشكلات في إدارة الذاكرة، مثل (buffer or heap overflows، use after free، integer overflows، ومشكلات أخرى)، كما ان هناك العديد من حالات التهرب من وضع الحماية (Sandbox) على مر السنين، والتي تثبت ان لغة تطبيق الويب اساساً ليست امنه كما تم وصفها.

• كيفية الحماية منها. تتم الآن كتابة العديد من واجهات برمجة التطبيقات الحديثة بلغات آمنة للذاكرة مثل Rust أو Go. بالنسبة لـRust، تعتبر سلامة الذاكرة سمة أساسية للغة. بالنسبة للشفرة المصدرية الحالية، يمكن أن يكون استخدام علامات المترجم “strict compiler flags” و (strong typing, static code analysis, ، fuzz testing) مفيدًا في تحديد تسرب الذاكرة والذاكرة وتجاوز الوقت المحدد وغير ذلك

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

• المصادر

  • OWASP Vulnerabilities: Buffer Overflow

  • OWASP Attacks: Buffer Overflow

  • Science Direct: Integer Overflow

2021 Docs De 0x00 2021 Notice (`2021/docs/de/0x00_2021-notice.md`) Copy Section

Erscheinungsdatum Copy Chapter

Das englische Original wurde am 24. September 2021 veröffentlicht

Hauptautoren Copy Chapter

• Andrew van der Stock (twitter: @vanderaj)
• Brian Glas (twitter: @infosecdad)
• Neil Smithline (Twitter: @appsecneil)
• Torsten Gigler (twitter: @torsten_tweet)

Gastautoren Copy Chapter

• Orange Tsai @orange_8361, Autor von A10-2021: Server Side Request Forgery
• Jim Manico @manicode und Jakub Maćkowski @kubamackowski – OWASP CheatSheets Coordination

Vorwort der deutschen Version Copy Chapter

„Ist es nicht sonderbar, dass eine wörtliche Übersetzung fast immer eine schlechte ist? Und doch lässt sich alles gut übersetzen. Man sieht hieraus, wie viel es sagen will, eine Sprache ganz verstehen; es heißt, das Volk ganz kennen, das sie spricht.“ (G.C. Lichtenberg, „Sudelbücher“, 1800-1806).

Die deutsche Version der OWASP Top 10 war genau das: eine Herausforderung, dem Ziel und dem Geist der Top 10 in deutscher Sprache gerecht zu werden. Hierbei wurden bei Bedarf auch kleinere Präzisierungen vorgenommen, die das Verständnis erleichtern. Wir verwenden daher bewusst nicht den Begriff „Übersetzung“, auch wenn es zu weiten Teilen genau das ist. Dinge ständig weiterzutreiben und kontinuierlich zu verbessern ist eben auch OWASP.
So haben wir in dieser Version auch die Namen der Top 10 Risiken angepasst oder Namens-Ergänzungen des Originals nur dann übernommen, wenn uns dies nach Abwägung sinnvoll erschien:

• A01:2021–Mangelhafte Zugriffskontrolle ex: A5:2017-Fehler in der Zugriffskontrolle
• A07:2021–Fehlerhafte Authentifizierung ex: A2:2017-Fehler in der Authentifizierung; Hier haben wir den neuen Teilaspekt 'Identification' bewusst nicht übernommen, da er im englischen Original im Risiko nicht weiter behandelt wird
• A09:2021–Unzureichendes Logging und Sicherheitsmonitoring ex: A10:2017-Unzureichendes Logging & Monitoring

Wir möchten alle, die in der Geschäftsführung, im Management, in der IT-Sicherheitsberatung, im Anwendungs-Management, in der Software-Entwicklung und in der Anwendungs-Prüfung arbeiten, für Webanwendungssicherheit sensibilisieren und Ihnen den Einstieg in diese Thematik erleichtern.

Dieses Dokument hilft Ihnen, eine neue Perspektive auf Ihre Anwendungen zu erhalten, um Sicherheitsfehler zu vermeiden und Risiken minimieren zu können. Einige englische Fachbegriffe wurden dabei beibehalten, weil sie auch im deutschen gebräuchlich sind.

Wir wünschen Neueinsteigerinnen, Neueinsteigern und Profis ein kurzweiliges Lesevergnügen und die (Bestätigung der) Erkenntnis, dass die IT-Sicherheit ein kritischer Erfolgsfaktor für (Web-)Anwendungen ist.

Die deutsche Version der OWASP Top 10:2021 finden Sie unter https://owasp.org/Top10/de/.

Ihr deutschsprachiges Top 10-Team:

• Torsten Gigler
• Daniel Grahl
• Tobias Heide
• Thomas Herzog
• Jasmin Mair
• Florian Schmid
• Jan Wolff

Stammtisch-Initiative des OWASP German Chapter Copy Section

In mehreren deutschen Städten gibt es OWASP-Stammtische, bei denen man sich in lockerer Runde trifft, um sich auszutauschen, nette Leute kennenzulernen oder ernsthafte Sicherheitsthemen zu diskutieren – meistens mit Vortrag.

Aktive Stammtische gibt es (Stand Juni 2024) in Augsburg, Berlin, Dresden, Frankfurt, Hamburg, Hannover, Heilbronn-Franken, Karlsruhe, Köln, München und Stuttgart.

Wie können Sie uns unterstützen Copy Chapter

Zum jetzigen Zeitpunkt bitten wir um Unterstützung bei folgenden Themenbereiche:

• Datenanalye – bitte überprüfen Sie unsere Analyse

• Übersetzung – Bitte überprüfen Sie diese Version und das englische Original, um sicherzustellen, dass diese Version verständlich ist und den Sinn des Originals widerspiegelt

• Projektleitung von ASVS, Testing Guide und Code Review Guide – bitte nutzen Sie unsere Daten und helfen Sie uns, unsere Dokumente und Standards miteinander zu verknüpfen

Senden Sie uns Ihre Vorschläge und Pull-Anfragen in Github Copy Chapter

Bitte informieren Sie uns über Ergänzungs- und Verbesserungsvorschläge:

• https://github.com/OWASP/Top10/issues

2021 Docs De 0x01 2021 About Owasp (`2021/docs/de/0x01_2021-about-owasp.md`) Copy Section

source: "https://owasp.org/Top10/A00-about-owasp/" title: "A00_2021 Über OWASP" id: "Über OWASP" lang: "de" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".index" -%}
{%- set parent_20217 = extra.osib.document ~ ".2017" -%}

Über OWASP

Das Open Worldwide Application Security Project (OWASP) ist eine offene Community. OWASP möchte Organisationen in die Lage versetzen, sichere und vertrauenswürdige Anwendungen zu entwickeln, zu kaufen und zu betreiben.

Von OWASP kann man folgendes erwarten; stets frei verfügbar und für jedermann zugänglich:

• Werkzeuge und Standards für sichere Anwendungen.
• Bücher zu den Themen Prüfungen, Entwicklung und Quellcodeanalyse im Bereich der Anwendungssicherheit.
• Vorträge und Videos.
• "Cheat sheets" zu vielen sicherheitsrelevanten Themen.
• Standard Security-Controls und Programm-Bibliotheken.
• Lokale "Chapter" auf der ganzen Welt und zusätzlich Stammtische in Deutschland.
• Neueste Forschung.
• Große und häufige Konferenzen auf der ganzen Welt.
• Mailinglisten.

Alle Informationen auf https://www.owasp.org bzw. https://www.owasp.de.

Alle OWASP Werkzeuge, Dokumente, Videos, Präsentationen und Chapter sind frei verfügbar und stehen jedem offen, der Anwendungssicherheit weiterentwickeln möchte.

Mangelnde Anwendungssicherheit begreifen wir als ein personen-, prozess- und technologie-bezogenes Problem, da die meisten wirksamen Ansätze für Anwendungssicherheit Verbesserungen in diesen Feldern erfordern.

OWASP ist eine neue Art von Organisation. Wir unterliegen keinem kommerziellen Druck. Das erlaubt uns unvoreingenommene, praktikable und kosteneffiziente Informationen über Anwendungssicherheit bereitzustellen.

OWASP ist nicht von Dritten abhängig, wenngleich wir die sachkundige Verwendung freier und kommerzieller Technologien unterstützen. OWASP erstellt viele unterschiedliche Materialien auf Basis eines kollaborativen, transparenten und offenen Ansatzes.

Die OWASP Foundation ist die gemeinnützige Organisation, die den langfristigen Erfolg des Projektes sicher stellt. Fast jeder bei OWASP ist ehrenamtlich tätig. Das schließt das Board, Chapter- und Projekt-Leiter, sowie Mitglieder ein. Wir unterstützen innovative Sicherheitsforschung mit Spenden, Förderungen und Infrastruktur.

Machen Sie mit!

Copyright und Lizenz Copy Chapter

Copyright © 2003-2023 The OWASP™ Foundation. Dieses Dokument ist unter der Creative Commons Attribution Share-Alike 4.0 Lizenz veröffentlicht. Bei Weiterverwendung oder Weitergabe muss die Lizenz erhalten bleiben.

2021 Docs De A00 2021 How To Start An AppSec Program With The OWASP Top 10 (`2021/docs/de/A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10.md`) Copy Section

Wie man ein Programm für Anwendungssicherheit mit den OWASP Top 10 aufbaut

Die OWASP Top 10 war nie als Grundlage für ein Programm zur Anwendungssicherheit (AppSec) gedacht.
Für viele Organisationen, die sich gerade am Anfang ihrer Reise in die Anwendungssicherheit befinden, ist es jedoch wichtig, irgendwo anzufangen.
Die OWASP Top 10 2021 bilden einen guten Ausgangspunkt für Checklisten usw., sind aber an sich nicht ausreichend.

Schritt 1. Identifizieren Sie die Lücken und Ziele Ihres AppSec-Programms Copy Chapter

Viele Anwendungssicherheitsprogramme (AppSec) übernehmen sich häufig und versuchen in zu großen Schritten ihr Ziel zu erreichen. Diese Bemühungen sind zum Scheitern verurteilt. Wir empfehlen CISOs und AppSec-Führungskräften dringend, das OWASP Software Assurance Maturity Model (SAMM) einzusetzen, um Schwachstellen und Verbesserungspotenziale über einen Zeitraum von 1-3 Jahren zu identifizieren. Der erste Schritt besteht darin, den aktuellen Stand der Dinge zu bewerten: Jene Schwächen in den Bereichen Governance, Design, Implementierung, Verifizierung und Betrieb zu identifizieren, die sofort behoben werden müssen, und jene, die noch warten können, und die Implementierung oder Verbesserung der 15 OWASP SAMM-Sicherheitspraktiken zu priorisieren. OWASP SAMM kann beim Aufbau und Messen von Verbesserungen bei Ihren Software Assurance-Bemühungen hilfreich sein.

Schritt 2. Ebnen Sie den Weg für einen sicheren Entwicklungs-Lebenszyklus (SDLC) Copy Chapter

Das Konzept des geebneten Weges, das traditionell den sogenannten "Einhörnern" vorbehalten war, ist der einfachste Weg, um die größte Wirkung zu erzielen und die AppSec-Ressourcen mit der Geschwindigkeit des Entwicklungsteams zu skalieren, die von Jahr zu Jahr zunimmt.

Das Konzept des geebneten Weges lautet: "Der einfachste Weg ist auch der sicherste Weg" und sollte eine Kultur tiefer Partnerschaften zwischen dem Entwicklungsteam und dem Sicherheitsteam beinhalten, vorzugsweise so, dass sie ein und dasselbe Team sind. Der geebnete Weg hat zum Ziel, unsichere Alternativen kontinuierlich zu verbessern, zu messen, zu erkennen und zu ersetzen, indem eine unternehmensweite Bibliothek von sicheren Ersatzlösungen zur Verfügung gestellt wird, mit Werkzeugen, die dabei helfen zu erkennen, wo Verbesserungen durch die Übernahme des geebneten Weges möglich sind. Auf diese Weise können vorhandene Entwicklungstools unsichere Builds aufzeigen und den Entwicklungsteams helfen, sich selbst von unsicheren Alternativen zu lösen.

Der geebnete Weg mag anstrengend erscheinen, aber er sollte im Laufe der Zeit schrittweise aufgebaut werden. Es gibt noch andere Formen von Appsec-Programmen, insbesondere den Agile Secure Development Lifecycle von Microsoft. Nicht jede Appsec-Programm-Methodik passt zu jedem Unternehmen.

Stufe 3. Realisierung des geebneten Wegs mit Ihren Entwicklungsteams Copy Chapter

Der geebnete Weg wird mit dem Einverständnis und der direkten Beteiligung der zuständigen Entwicklungs- und Betriebsteams umgesetzt. Der Weg sollte strategisch auf das Unternehmen abgestimmt sein und dazu beitragen, sichere Anwendungen schneller bereitzustellen. Die Entwicklung des Weges sollte eine ganzheitliche Maßnahme sein, die das gesamte Unternehmens- oder Anwendungsökosystem abdeckt, und nicht nur ein einzelnes anwendungsbezogenes Notpflaster wie in vergangenen Zeiten.

Stufe 4. Migrieren Sie alle zukünftigen und bestehenden Anwendungen auf den geebneten Weg Copy Chapter

Fügen Sie Tools zur Erkennung von geebneten Wegen hinzu, während Sie sie entwickeln, und stellen Sie den Entwicklungsteams Informationen zur Verfügung, damit sie die Sicherheit ihrer Anwendungen verbessern können, indem sie Elemente des geebneten Weges direkt übernehmen können. Sobald ein Aspekt des geebneten Weges übernommen wurde, sollten Unternehmen Prüfungen zur kontinuierlichen Integration implementieren, die bestehenden und Check-Ins von neuem Code auf verbotene Alternativen untersuchen und beim Build oder Check-In Warnungen ausgeben oder diese ablehnen. Auf diese Weise wird verhindert, dass sich im Laufe der Zeit unsichere Optionen in den Code einschleichen, wodurch technische Altlasten und eine fehlerhafte, unsichere Anwendung vermieden werden. Solche Warnhinweise sollten auf die sichere Alternative verweisen, damit das Entwicklungsteam sofort die richtige Antwort erhält. So kann das Entwicklungsteam sofort die Korrektur vornehmen und die Komponente für den geebneten Weg rasch übernehmen.

Schritt 5. Nachprüfen, ob der geebnete Weg die in den OWASP Top 10 genannten Probleme behoben hat Copy Chapter

Die Komponenten des geebneten Weges sollten sich mit einem wichtigen Aspekt der OWASP Top 10 befassen, z. B. mit der automatischen Erkennung oder Beseitigung von Sicherheitslücken in Komponenten, mit einem IDE-Plugin für die statische Codeanalyse zur Erkennung von Injections oder - noch besser - mit der Verwendung einer Bibliothek, die als sicher gegen Injections bekannt ist. Je mehr dieser sicheren Drop-in-Ersatzlösungen den Teams zur Verfügung gestellt werden, desto besser. Eine wichtige Aufgabe des Appsec-Teams ist es, dafür zu sorgen, dass die Sicherheit dieser Komponenten kontinuierlich bewertet und verbessert wird. Sobald die Sicherheit verbessert wurde, sollte eine Kommunikation mit den Nutzende der Komponente stattfinden, die darauf aufmerksam macht, dass ein Upgrade durchgeführt werden sollte, vorzugsweise automatisch, aber wenn nicht, sollte dies zumindest auf einem Dashboard oder ähnlichem deutlich gemacht werden.

Stufe 6. Bauen Sie Ihr Programm zu einem ausgereiften AppSec-Programm aus Copy Chapter

Sie dürfen nicht bei den OWASP Top 10 aufhören. Diese decken nur 10 Risikokategorien ab. Wir empfehlen Unternehmen dringend, den Application Security Verification Standard zu übernehmen und schrittweise Komponenten und Tests für die Stufen 1, 2 und 3 hinzuzufügen, je nach Risikoniveau der entwickelten Anwendungen.

Weitere Schritte Copy Chapter

Alle guten Programme zur Anwendungssicherheit gehen über das Minimum hinaus.
Alle Beteiligten müssen weiterarbeiten, um die Schwachstellen in den Anwendungen jemals in den Griff zu bekommen.

• Konzeptuelle Integrität. Ausgereifte AppSec-Programme müssen über ein Konzept sicherer Architektur verfügen,
  egal ob eine formale Cloud- oder Enterprise-Architektur oder Bedrohungsanalyse.

• Automatisierung und Skalierung.
  Ausgereifte AppSec-Programme versuchen möglichst viele Liefergegenstände zu automatisieren:
  Skripte um komplexe Penetrationstest-Schritte zu emulieren,
  Statische Codeanalyse direkt den Entwicklungsteams bereitstellen,
  Unterstützung für Entwicklungsteams um sicherheitsspezifische Unit- und Integrationstests zu verfassen, etc.

• Kultur.
  Ausgereifte AppSec-Programme versuchen, unsicheres Design auszuschließen
  und technische Schulden in Bestands-Code dadurch zu eliminieren,
  dass sie Bestandteil der Entwicklung sind und nicht daneben stehen.
  AppSec-Teams, die Entwicklungsteams als "die" und "wir" betrachten, sind zum Scheitern verurteilt.

• Kontinuierliche Verbesserung.
  Ausgereifte AppSec-Programme versuchen, sich ständig zu verbessern. Wenn etwas nicht funktioniert, dann beenden Sie es. Wenn etwas klobig ist oder nicht skaliert , muss es verbessert werden. Falls etwas von den Entwicklungsteams nicht verwendet wird und keine oder nur geringe Auswirkungen hat, sollte etwas anderes gemacht werden. Nur weil wir seit den 1970er Jahren Tests wie Schreibtischchecks durchgeführt haben, heißt das nicht, dass es eine gute Idee ist. Messen und bewerten Sie, und entwickeln oder verbessern Sie dann.

2021 Docs De A00 2021 How To Use The OWASP Top 10 As A Standard (`2021/docs/de/A00_2021_How_to_use_the_OWASP_Top_10_as_a_standard.md`) Copy Section

Wie man die OWASP Top 10 als Standard verwendet

Die OWASP Top 10 sind in erster Linie ein Sensibilisierungsdokument.
Dies hat Unternehmen jedoch nicht davon abgehalten, sie seit ihrer Einführung im Jahr 2003 als De-facto-Standard für Anwendungssicherheit (AppSec) zu verwenden.
Wenn Sie die OWASP Top 10 als Coding- oder Teststandard verwenden möchten,
sollten Sie wissen, dass es sich um das absolute Minimum und nur um einen Anfang handelt.

Eine der Schwierigkeiten bei der Verwendung der OWASP Top 10 als Standard besteht darin, dass wir AppSec-Risiken dokumentieren und nicht unbedingt leicht testbare Probleme.
Beispielsweise liegt A04:2021 Unsicheres Anwendungsdesign außerhalb des Rahmens der meisten Testverfahren.
Ein weiteres Beispiel ist das Testen, ob eine wirksame Protokollierung und Überwachung implementiert und operativ ist, was nur durch Befragungen und Stichproben wirksamer Behandlungen von Incidents möglich ist.
Ein Tool zur statischen CodeAnalyse kann nach fehlender Protokollierung suchen,
es wird jedoch unmöglich sein, festzustellen, ob die Geschäftslogik oder die Zugriffskontrolle kritische Sicherheitsverstöße protokolliert. Penetrationstests werden möglicherweise nur in einer Testumgebung stattfinden, die selten in der gleichen Weise wie die Produktion überwacht ist, dabei ist es schwierig feststellen ob eine Reaktion auf die Vorfälle ausgelöst wurde.

Hier sind unsere Empfehlungen, wann es sinnvoll ist, die OWASP Top 10 zu verwenden:

Wir empfehlen jedem, der einen Anwendungssicherheitsstandard übernehmen möchte,
den OWASP Application Security Verification Standard (ASVS) zu verwenden,
da er entworfen wurde, um überprüfbar und testbar zu sein und in allen Teilen eines sicheren Entwicklungslebenszyklus verwendet werden kann.

Für Tool-Anbieter ist der ASVS die einzig akzeptable Wahl.
Aufgrund der Beschaffenheit mehrerer Top-10-Risiken, insbesondere A04:2021 – Unsicheres Anwendungsdesign,
können Tools die OWASP Top 10 nicht umfassend erkennen, testen oder davor schützen.
OWASP rät davon ab, eine vollständige Abdeckung der OWASP Top 10 zu behaupten, da dies schlichtweg unwahr ist.

2021 Docs De A00 2021 Introduction (`2021/docs/de/A00_2021_Introduction.md`) Copy Section

source: "https://owasp.org/Top10/A00_2021_Introduction/" title: "A00_2021_Einführung" id: "Einführung" lang: "de" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".index" -%}
{%- set parent_2017 = extra.osib.document ~ ".2017" -%}

Einführung

Willkommen bei den OWASP Top 10 – 2021 Copy Chapter

{:class="img-responsive"}

Willkommen zur neuesten Ausgabe der OWASP Top 10! Die OWASP Top 10:2021 sind völlig neu, mit einem neuen Grafikdesign mit Piktogrammen je Risiko und Mobilgeräte-freundlichen Webseiten.

Ein großes Dankeschön an alle, die mit ihrer Zeit und Daten für diese Ausgabe beigetragen haben. Ohne Sie wäre diese Version nicht zustande gekommen. HERZLICHEN DANK!

Was sich in den Top 10 für 2021 geändert hat Copy Chapter

Es gibt drei neue Kategorien, vier Kategorien mit Änderungen im Namen und teilweise auch im Umfang (im englischen Original, siehe auch Vorwort der deutschen Version) und eine gewisse Konsolidierung in den Top 10 für 2021. Wir haben bei Bedarf Namen geändert, um uns auf die jeweilige Grundursache statt auf Symptome zu konzentrieren.

• A01:2021-Mangelhafte Zugriffskontrolle steigt von der {{ osib_link(link=parent_2017 ~ ".5", text= "fünften Position", doc="", Latest=0) }} in die Kategorie mit dem schwerwiegendsten Sicherheitsrisiko für Webanwendungen auf. Die uns zur Verfügung gestellten Daten zeigen, dass im Durchschnitt 3,81% der getesteten Anwendungen eine oder mehrere Common Weakness Enumerations (CWEs) dieser Kategorie aufweisen. Insgesamt wurden mehr als 318.000 CWEs in dieser Risikokategorie genannt. Die 34 CWE-Typen, die wir der 'mangelhaften Zugriffskontrolle' zuordneten, traten in Anwendungen häufiger auf, als die jeder anderen Kategorie.
• A02:2021-Fehlerhafter Einsatz von Kryptographie steigt mit neuem Namen um eine Position auf Nummer 2 auf. Bisher hieß diese Kategorie {{ osib_link(link=parent_2017 ~ ".3", doc="", Latest=0) }}, was eher ein (allgemeines) Symptom, als die Grundursache war. Der neue Name fokussiert auf Fehler im Zusammenhang mit der Kryptographie, wie dies bereits implizit der Fall war. Diese Kategorie führt häufig zur Offenlegung vertraulicher Daten oder zur Kompromittierung des Systems.
• A03:2021-Injection {{ osib_link(link=parent_2017 ~ ".1", text="steigt von der ersten", doc= "", Latest=0) }} auf die dritte Position ab. 94% der Anwendungen wurden auf eine Art von 'Injection' getestet, mit einer maximalen Inzidenzrate von 19% und einer durchschnittlichen Rate von 3,37%. Die 33 CWE-Typen dieser Kategorie weisen mit einem Vorkommen von insgesamt 274.000 Nennungen die zweithäufigsten Vorfälle bei Webanwendungen auf. 'Cross-Site Scripting' (XSS) wurde in dieser Ausgabe der Top 10 nun Teil dieser Kategorie.
• A04:2021-Unsicheres Anwendungsdesign ist eine neue Kategorie dieser Ausgabe, die sich mit Risiken im Zusammenhang mit Designfehlern bei Anwendungen beschäftigt. Um die IT-Sicherheit früher im Software-Entwicklungsprozess zu berücksichtigen, brauchen wir mehr Bedrohungsmodellierung, sichere Entwurfsmuster und -prinzipien sowie Referenzarchitekturen. Ein unsicheres Design kann nicht durch eine perfekte Implementierung behoben werden, da die erforderlichen Sicherheitsmaßnahmen definitionsgemäß nie zur Abwehr bestimmter Angriffe berücksichtigt und implementiert wurden.
• A05:2021-Sicherheitsrelevante Fehlkonfiguration wechselt von {{ osib_link(link=parent_2017 ~ ".6", text="Position 6 in der vorherigen Ausgabe", doc="", Latest=0) }} einen Platz nach oben. 90% der Anwendungen wurden auf irgendeine Art von Fehlkonfiguration getestet, mit einer durchschnittlichen Inzidenzrate von 4,5% und über 208.000 CWEs, die dieser Risikokategorie zugeordnet wurden. Angesichts der zunehmenden Verlagerung zu hoch konfigurierbarer Software, ist es nicht verwunderlich, dass diese Kategorie aufsteigt. Die frühere Kategorie für {{ osib_link(link=parent_2017 ~ ".4", doc="", Latest=0) }} ist jetzt auch Teil dieses Riikos.
• A06:2021-Unsichere oder veraltete Komponenten trug zuvor den Titel "{{ osib_link(link=parent_2017 ~ ".9", doc="", Latest=0) }}" und ist Nr. 2 in der Top-10-Community-Umfrage, verfügte jedoch über genügend Nennungen in den gespendeten Daten, um es bereits darüber in die Top 10 zu schaffen. Diese Kategorie steigt von {{ osib_link(link=parent_2017 ~ ".9", text="Position 9 im Jahr 2017", doc="", Latest=0) }} auf Position 6 auf. Es handelt sich hierbei um ein bekanntes Problem, dessen Risiko wir nur schwer testen und bewerten können. Es ist die einzige Kategorie, bei der die zugeordneten CWEs von keiner 'Common Vulnerability and Exposure' (CVE) referenziert wird, sodass in ihren Bewertungen ein mittlerer Standard-Score von 5,0 für Exploit und in der Auswirkung berücksichtigt werden.
• A07:2021-Fehlerhafte Authentifizierung fällt von der {{ osib_link(link=parent_2017 ~ ".2", text="zweiten Position", doc="", Latest=0) }} auf Platz 7 zurück. Das Risiko enthält jetzt CWEs, die eher mit Identifikationsfehlern zusammenhängen. Diese Kategorie ist immer noch ein fester Bestandteil der Top 10, aber die zunehmende Verfügbarkeit standardisierter Frameworks scheint hier zu helfen.
• A08:2021-Fehlerhafte Prüfung der Software- und Datenintegrität ist eine weitere, neue Kategorie für die Ausgabe von 2021, die sich auf Annahmen im Zusammenhang mit Software-Updates, kritischen Daten und CI/CD-Pipelines ohne Überprüfung der Integrität befasst. Die 10 CWE-Typen dieser Kategorie werden von 'Common Vulnerability and Exposures' (CVEs) mit den höchsten 'Common Vulnerability Scoring System' (CVSS)-Scores referenziert. {{ osib_link(link=parent_2017 ~ ".8", doc="", Latest=0) }} ist jetzt ein Teil dieser umfangreicher gewordenen Kategorie.
• A09:2021-Unzureichendes Logging und Sicherheitsmonitoring hieß früher {{ osib_link(link=parent_2017 ~ ".10", doc="", Latest=0) }}, wurde auf Basis der Top-10-Community-Umfrage (Nr. 3) hinzugefügt und rückt von Platz 10 auf. Diese Kategorie wurde erweitert, um mehr Fehlertypen abzudecken, ist schwierig zu testen und ist in den CVE/CVSS-Daten nicht gut vertreten. Fehler in dieser Kategorie können sich jedoch direkt auf die Sichtbarkeit, Alarmierung bei Vorfällen und Forensik der Anwendung auswirken.
• A10:2021-Server-Side Request Forgery wurde aus der Top-10-Community-Umfrage (Nr. 1) hinzugefügt. Die Daten zeigen eine relativ niedrige Inzidenzrate bei einer überdurchschnittlichen Testabdeckung sowie überdurchschnittlichen Bewertungen für Exploit- und Impact-Potenzial. Diese Kategorie entspricht dem Szenario, bei dem die Mitglieder der Sicherheits-Community uns mitteilen, dass dies wichtig ist, auch wenn es in den Daten zu diesem Zeitpunkt nicht abgebildet wird.

Methodik Copy Chapter

Diese Ausgabe der Top 10 ist datengestützter denn je, aber nicht mit blindem Vertrauen. Wir haben acht der zehn Kategorien aus den Datenbeiträgen und zwei Kategorien aus der Experten-Umfrage in der OWASP-Community mit den höchsten Bewertungen ausgewählt. Wir tun dies aus einer grundsätzlichen, methodischen Überlegung: Der Blick auf die erhaltenen Daten ist ein Blick in die Vergangenheit. IT-Sicherheitsforschende nehmen sich Zeit, um neue Schwachstellen und neue Möglichkeiten zu finden, diese zu testen. Es braucht Zeit, diese Tests in Tools und Prozesse zu integrieren. Bis eine Schwachstelle in großem Maßstab zuverlässig getestet wird, sind wahrscheinlich Jahre vergangen. Um diesen Umstand auszugleichen, nutzen wir eine Community-Umfrage, um Expertinnen und Experten für Anwendungssicherheit und Software-Entwicklung an vorderster Front zu befragen, was ihrer Meinung nach wesentliche Schwachstellen sind, die die Auswertung der Datenstatistik möglicherweise noch nicht aufzeigt.

Wir haben einige, wichtige Änderungen vorgenommen, um die Top 10 weiterzuentwickeln.

Wie die Kategorien aufgebaut sind Copy Chapter

Einige Kategorien haben sich gegenüber der vorherigen Ausgabe der OWASP Top Ten von 2017 geändert. Im Folgenden finden Sie eine Zusammenfassung der Änderungen in den einzelnen Kategorien.

Frühere Datenerhebungen konzentrierten sich auf eine vorgegebene Teilmenge von etwa 30 CWE-Typen. In einem Freitextfeld wurde nach zusätzlichen Erkenntnissen gefragt. Wir haben gelernt, dass sich Unternehmen in erster Linie auf diese 30 CWE-Typen konzentrieren und nur selten weitere CWEs ergänzten, die sie gefunden hatten. In dieser Ausgabe haben wir das Verfahren geöffnet und nur nach Daten gefragt, ohne Einschränkung auf bestimmte CWE-Typen. Wir fragten nach der Anzahl der getesteten Anwendungen für ein bestimmtes Jahr (ab 2017) und nach der Anzahl der Anwendungen, bei denen mindestens ein CWE im Test gefunden wurde. Mit dieser Vorgehensweise können wir erkennen, wie oft die einzelnen CWE-Typen jeweils in den Anwendungen vorkommen. Wir ignorieren dabei für unsere Zwecke bewusst die Häufigkeit von Schwachstellen je Anwendung. Während es in anderen Situationen sinnvoll und notwendig sein kann, würde sie hier nur das tatsächliche Vorkommen in der Anwendungspopulation verschleiern. Ob in einer Anwendung ein CWE-Typ viermal vorkommt oder 4.000 Mal, ist für die Risikoberechnung der Top 10 nicht relevant. Durch dieses Vorgehen ist die Datenbasis von etwa 30 CWE-Typen auf fast 400 gestiegen, die wir für diese Ausgabe analysiert haben. Wir planen, in Zukunft weitere zusätzliche Datenanalysen durchzuführen. Dieser deutliche Anstieg der CWE-Typen erfordert Änderungen in der Strukturierung der Kategorien.

Wir haben mehrere Monate damit verbracht, CWE-Typen zu gruppieren und zu kategorisieren, und hätten noch weitere Monate damit fortfahren können. Irgendwann mussten wir zu einem Ergebnis kommen. Es gibt sowohl CWEs, die sich auf Grundursachen beziehen, als auch solche, die sich auf Symptome beziehen. Beispiele für Grundursache-Typen sind „Kryptografischer Fehler“ und „Fehlkonfiguration“, für Symptomtypen können „Sensitive Data Exposure“ (Verlust der Vertraulichkeit sensibler Daten) und „Denial of Service“ (mutwillige Dienstblockade) genannt werden. Wir haben uns entschieden, uns - wann immer möglich - auf die Grundursache zu konzentrieren, da dies sinnvoller ist, um Hinweise zur Identifizierung und Behebung zu geben. Sich auf die Grundursache statt auf das Symptom zu konzentrieren, ist kein neues Konzept. Die Top Ten waren bisher eine Mischung aus Symptomen und Grundursachen. CWEs sind ebenfalls eine Mischung aus Symptomen und Grundursachen. Wir gehen einfach bewusster damit um und benennen sie.In dieser Version gibt es durchschnittlich 19,6 CWE-Typen pro Top10-Kategorie, wobei das Minimum bei 1 CWE für A10:2021-Server-Side Request Forgery und das Maximum bei 40 CWEs in A04:2021-Unsicheres Anwendungsdesign liegt. Diese aktualisierte Kategoriestruktur bietet zusätzliche Vorteile bei Schulungen, da sich Unternehmen jeweils auf die CWEs konzentrieren können, die für eine Programmiersprache/ein Framework besonders sinnvoll erscheinen.

Wie die Daten zur Auswahl und Priorisierung der Kategorien verwendet werden Copy Chapter

Im Jahr 2017 haben wir die Top10-Kategorien zunächst nach der Häufigkeit ihres Vorkommens in den Daten klassifiziert, um die Verbreitung zu bestimmen. Die weiteren Risikofaktoren Ausnutzbarkeit, Auffindbarkeit und technische Auswirkungen haben wir dann durch Teamdiskussionen basierend auf CVSS-Scores und jahrzehntelanger Erfahrung eingestuft. In 2021 wollten wir neben der, aus den aktuellen Daten abgeleiteten Verbreitung, nach Möglichkeit auch zur Einwertung der Faktoren Ausnutzbarkeit und (technische) Auswirkungen ausschließlich Daten verwenden.

Wir haben OWASP Dependency Check heruntergeladen, die CVSS-Exploit- und Impact-Scores extrahiert und sie nach den verwandten CWE-Typen gruppiert. Es war einiges an Recherche und Aufwand erforderlich, da zwar alle CVEs über CVSSv2-Einwertungen verfügen, bei den jedoch teilweise noch Mängel vorhanden sind, die erst durch CVSSv3 beheben wurden. Ab einem bestimmten Zeitpunkt haben alle CVEs auch ein CVSSv3-Score erhalten. Darüber hinaus wurden die Bewertungsskalen und Formeln zwischen CVSSv2 und CVSSv3 verändert.

In CVSSv2 konnten sowohl die Kategorie Exploit als auch (Technical) Impact Werte bis zu 10,0 betragen, aber die Formel würde sie auf 60% für Exploit und 40% für Impact begrenzen. In CVSSv3 ist das theoretische Maximum für Exploit auf 6,0 und für Impact auf 4,0 begrenzt. Unter Berücksichtigung der Gewichtung in der Formel von CVSSv3 erhöhte sich der Einfluss der Impact-Bewertung, im Durchschnitt um fast eineinhalb Punkte, der für Exploit sank im Durchschnitt um fast einen halben Punkt.

Im OWASP Dependency Check gibt es 125.000 Datensätze der National Vulnerability Database (NVD) in der CVEs, einer CWE zugeordnet sind, und es gibt 241 CWEs, die mindestens einer CVE zugeordnet sind. 62.000 CWEs haben einen CVSSv3-Score, was in etwa der Hälfte des Datenbestands entspricht.

Für die Top Ten 2021 haben wir die durchschnittlichen Exploit- und Impact-Werte wie folgt berechnet. Wir haben alle CVEs mit CVSS-Scores nach CWE gruppiert und sowohl die Exploit- als auch die Impact-Scores jeweils getrennt für die CVEs mit CVSSv3 und die mit ausschließlich CVSSv2-Einwertungen berechnet. Die Einzelwerte wurden normalisiert und zu einem Gesamt-Mittelwert zusammengefasst, der die Anzahl der jeweiligen CVSS-Bewertungen berücksichtigt. Die Ergebnisse haben wir als (gewichtete) 'durchschnittliche Ausnutzbarkeit' bzw. (gewichtete) 'durchschnittliche Auswirkung' bezeichnet und als Risikofaktoren verwendet.

Warum nicht nur reine statistische Daten? Copy Chapter

Die Ergebnisse in den zur Verfügung gestellten Daten beschränken sich in erster Linie auf das, was automatisiert getestet werden kann. Sprechen Sie mit erfahrenen AppSec-Expertinnen und Experten und sie werden Ihnen von Dingen erzählen, die sie gefunden haben, und von Trends, die sie sehen, die jedoch noch nicht in den Daten enthalten sind. Es braucht Zeit, um Testmethoden für bestimmte Schwachstellentypen zu entwickeln, und dann noch mehr Zeit, bis diese Tests automatisiert und für eine große Anzahl von Anwendungen ausgeführt werden. Alles, was wir finden, blickt zurück in die Vergangenheit und könnte Trends aus dem letzten Jahr übersehen, die in den Daten nicht vorhanden sind.

Daher wählen wir aus den Daten nur acht von zehn Kategorien aus, da sie unvollständig sind. Die anderen beiden Kategorien stammen aus der Top-10-Community-Umfrage. Sie ermöglicht den Praktikerinnen und Praktikern an vorderster Front für die, aus ihrer Sicht größten Risiken zu stimmen, die möglicherweise noch nicht in den Daten enthalten sind oder darüber nie abgeleitet werden können.

Warum Inzidenzrate statt Häufigkeit? Copy Chapter

Es gibt drei Hauptdatenquellen. Wir bezeichnen sie als Human-Assisted Tooling (HaT), Tool-Assisted Human (TaH) und Raw Tooling.

Raw Tooling und HaT sind Massen-Suchgeneratoren. Die Tools suchen nach bestimmten Schwachstellen und versuchen unermüdlich, jedes Vorkommen dieser Schwachstelle zu finden. Dabei werden für einige Schwachstellentypen hohe Fundzahlen generiert. Bei Cross-Site Scripting gibt es in der Regel zwei Arten von Schwachstellen: Entweder handelt es sich um einen kleineren, isolierten Fehler oder um ein systemisches Problem. Wenn es sich um ein systemisches Problem handelt, kann die Zahl der Befunde bei einer einzigen Anwendung in die Tausende gehen. Diese hohe Häufigkeit übertönt die meisten anderen, in Berichten oder in Daten gefundenen Schwachstellen.

TaH hingegen wird ein breiteres Spektrum an Schwachstellentypen finden, diese jedoch aus Zeitgründen viel seltener. Wenn Menschen eine Anwendung testen und so etwas wie Cross-Site Scripting sehen, ermitteln sie normalerweise drei oder vier Vorkommen und brechen die weitere Suche dann ab. Sie können ein systemisches Problem erkennen und die Schwachstelle mit einer Empfehlung zur anwendungsweiten Behebung versehen. Es ist weder die Notwendigkeit noch die Zeit vorhanden, jedes (einzelne) Vorkommen zu finden.

Angenommen, wir nehmen diese beiden unterschiedlichen Datensätze und versuchen, sie nach Häufigkeit zusammenzuführen. In diesem Fall würden die Tooling- und HaT-Daten die genaueren (aber weit gefassten) TaH-Daten übertönen, und das ist ein guter Grund dafür, warum etwas wie Cross-Site Scripting in vielen Listen so hoch eingestuft wird, obwohl die Auswirkungen im Allgemeinen gering bis moderat sind. Das liegt an der schieren Menge an Fundstellen (Cross-Site Scripting lässt sich auch relativ einfach testen, daher gibt es auch viel mehr Tests dafür).

Im Jahr 2017 haben wir stattdessen die Verwendung der Inzidenzrate eingeführt, um einen neuen Blick auf die Daten zu werfen und Raw Tooling- und HaT-Daten angemessen mit TaH-Daten zusammenzuführen. Die Inzidenzrate bewertet, wie viele Prozent der Anwendungen mindestens ein Vorkommen eines Schwachstellentyps aufweist. Es ist uns egal, ob es einmalig oder systemisch war. Das ist für unsere Zwecke irrelevant. Wir müssen lediglich wissen, wie viele Anwendungen mindestens ein Vorkommen hatte, was dazu beiträgt, einen klareren Überblick über die Testergebnisse über mehrere, unterschiedliche Testtypen hinweg zu erhalten, ohne dass die Daten von Massen-Suchgeneratoren die Ergebnisse dominieren. Dies entspricht auch einer risikoorientierten Sichtweise, da Angreifende nur ein einziges Auftreten einer Schwachstelle benötigen, um eine Anwendung über die Kategorie erfolgreich anzugreifen.

Wie sieht Ihr Datenerfassungs- und Analyseprozess aus? Copy Chapter

Wir haben den OWASP-Top-10-Datenerfassungsprozess auf dem Open Security Summit 2017 formalisiert. OWASP Top 10 Co-Leader und die Community haben zwei Tage damit verbracht, einen transparenten Datenerfassungsprozess zu formalisieren. Die aktuelle Ausgabe 2021 ist die zweite Edition, in der wir diese Methodik verwenden.

Wir haben zunächst einen Aufruf zur Datenerhebung über die uns zur Verfügung stehenden Social-Media-Kanäle veröffentlicht, sowohl über Projekt- als auch über OWASP-Kanäle. Auf der OWASP-Projektseite listen wir die Datenelemente und die Struktur auf, die wir benötigten, und wie die Daten erfasst und eingereicht werden konnten. Im GitHub-Projekt hatten wir Beispieldaten als Vorlage zur Verfügung gestellt. Bei Bedarf haben wir die Organisationen unterstützt, um die Struktur und Zuordnung zu CWEs herauszufinden.

Die Datenspenden stammen von den unterschiedlichsten Organisationen, darunter welche, die Anbieter nach Branchen testen, Bug-Bounty-Anbietern und Organisationen, die interne Testergebnisse beigesteuert haben. Die eingereichten Daten wurden zuerst grundlegend analysiert und hinsichtlich der zugeordneten CWEs auf Plausibilität geprüft und den Risikokategorien zugeordnet. Es gibt Überschneidungen zwischen einigen CWEs und andere sind sehr eng miteinander verbunden (z. B. kryptografische Schwachstellen). Alle Entscheidungen im Zusammenhang mit der Analyse der übermittelten Rohdaten wurden dokumentiert und veröffentlicht, um offen und transparent zu machen, wie wir die Daten normalisiert haben.

Die acht Kategorien mit den höchsten Inzidenzraten wurden in die Top 10 aufgenommen. Wir schauen uns auch die Ergebnisse der Top 10-Community-Umfrage an, um zu sehen, welche davon möglicherweise bereits in den Daten vorhanden waren. Die beiden Kategorien mit den meisten Stimmen, die nicht in den acht datengestützten Kategorien vorhanden waren, wurden für die beiden verbliebenen Plätze der Top 10 ausgewählt. Für die zehn ausgewählten Kategorien wurden jeweils neben der Inzidenzrate die weiteren Faktoren für Ausnutzbarkeit, Expolit und die (technische) Auswirkung, Impact berücksichtigt, um die Top 10:2021 in nach ihren Risiken zu ordnen.

Datenfaktoren Copy Chapter

Für die Top-10-Kategorien sind jeweils Datenfaktoren aufgeführt, die im Folgenden erläutert werden:

• Zugeordnete CWEs: Die Anzahl der CWEs, die der Kategorie vom Top-10-Team zugeordnet wurden.
• Häufigkeit: Die Inzidenzrate ist der Prozentsatz der Anwendungen, die für CWEs der Kategorie anfällig sind, bezogen auf die Summe aller Anwendungen, die von einer Organisation im jeweiligen Jahr getestet wurden.
• Durchschn. Ausnutzbarkeit: Der Exploit-Subscore aus CVSSv2- und CVSSv3-Scores von CVEs, die die CWEs der Kategorie referenziert haben, normalisiert auf eine 10-Punkte-Skala.
• Durchschn. Auswirkungen: Der Impact-Subscore aus CVSSv2- und CVSSv3-Scores von CVEs, die die CWEs der Kategorie referenziert haben, normalisiert auf eine 10-Punkte-Skala
• (Test-)Abdeckung: Der Prozentsatz der Anwendungen, die von allen Organisationen, die auf die CWEs der Kategorie getestet wurden.
• Gesamtanzahl: Gesamtzahl der Anwendungen, bei denen CWEs der Kategorie zugeordnet wurden.
• CVEs insgesamt: Gesamtzahl der CVEs in der NVD-Datenbank, die den CWEs der Kategorie zugeordnet wurden.

Vielen Dank an unsere Daten-Spender Copy Chapter

Die folgenden Organisationen (und weitere anonyme Spender) haben freundlicherweise Daten für über 500.000 Anwendungen gespendet, um dies zum größten und umfassendsten Datensatz zur Anwendungssicherheit zu machen. Ohne Sie wären diese Top 10 nicht möglich gewesen.

• AppSec Labs
• Cobalt.io
• Contrast Security
• GitLab
• HackerOne
• HCL Technologies
• Micro Focus
• PenTest-Tools
• Probely
• Sqreen
• Veracode
• WhiteHat (NTT)

Vielen Dank an unsere weiteren Sponsoren Copy Chapter

Das OWASP Top 10 2021-Team dankt Secure Code Warrior und Just Eat für die finanzielle Unterstützung.

{ width="256" }

{ width="256" }

2021 Docs De A01 2021 Broken Access Control (`2021/docs/de/A01_2021-Broken_Access_Control.md`) Copy Section

source: "https://owasp.org/Top10/A01_2021-Broken_Access_Control/" title: "A01:2021 – Mangelhafte Zugriffskontrolle" id: "A01:2021" lang: "de" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".1" -%}
#A01:2021 – Mangelhafte Zugriffskontrolle {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Broken Access Control", lang=lang, source=source, parent=parent, predecessor=extra.osib.document ~ ".2017.5" ) }}

Beurteilungskriterien {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Übersicht", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Copy Chapter

94 % der Anwendungen wurden auf irgendeine Form fehlerhafter Zugriffskontrolle getestet.
Vom fünften Platz aufgestiegen, weist die fehlerhafte Zugriffskontrolle mit einer durchschnittlichen Inzidenzrate von 3,81 % und mit über 318.000 die meisten Vorkommnisse im vorliegenden Datensatz auf.
Bemerkenswerte Common Weakness Enumerations (CWEs) sind CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201: Insertion of Sensitive Information Into Sent Data und CWE-352: Cross-Site Request Forgery.

Beschreibung {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Beschreibung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Copy Chapter

Die Zugriffskontrolle erzwingt Richtlinien, sodass Nutzende nicht außerhalb ihrer vorgesehenen Berechtigungen handeln können. Fehler führen in der Regel zur unbefugten Offenlegung, Änderung oder Zerstörung aller Daten oder zur Ausführung einer Geschäftsfunktion außerhalb der Verfügungen der anwendenden Person. Zu den häufigsten Schwachstellen bei der Zugriffskontrolle gehören:

• Verstoß gegen die Prinzipien der geringsten Rechte oder der standardmäßigen Verweigerung, bei dem der Zugriff nur für bestimmte Fähigkeiten, Rollen oder Nutzende gewährt werden sollte, aber für jedermann verfügbar ist.

• Umgehen von Zugriffskontrollprüfungen durch Ändern der URL (Parametermanipulation oder erzwungenes Durchsuchen), des internen Anwendungsstatus oder der HTML-Seite oder durch Verwendung eines Angriffstools zur Änderung von API-Anfragen.

• Ermöglichen, das Konto einer anderen Person anzuzeigen oder zu bearbeiten, indem dessen eindeutige Kennung angegeben wird (unsichere direkte Objektreferenzen).

• Zugriff auf die API mit fehlenden Zugriffskontrollen für POST, PUT und DELETE.

• Erhöhung der Privilegien. Als Nutzerin/Nutzer fungieren, ohne angemeldet zu sein oder als Administrator fungieren, wenn man als Standard-Nutzerin/Nutzer angemeldet ist.

• Manipulation von Metadaten, wie z. B. das Abfangen oder Manipulieren eines JSON Web Token (JWT)-Zugriffskontrolltokens oder die Manipulation eines Cookies oder eines versteckten Felds, um Berechtigungen zu erhöhen oder die Ungültigerklärung von JWTs zu missbrauchen.

• CORS-Fehlkonfiguration ermöglicht API-Zugriff von nicht autorisierten/nicht vertrauenswürdigen Quellen.

• Erzwingen des Zugriffs auf authentifizierte Seiten als nicht authentifizierte Person oder zu privilegierten Seiten als Standard-Nutzerin/Nutzer.

Prävention und Gegenmaßnahmen {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": How to Prevent", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Die Zugriffskontrolle ist nur wirksam bei vertrauenswürdigem serverseitigem Code oder serverlosen APIs, bei denen Angreifende die Zugriffskontrollprüfung oder Metadaten nicht ändern können.

• Verweigern Sie standardmäßig den Zugriff, mit Ausnahme öffentlicher Ressourcen.

• Implementieren Sie Zugriffskontrollmechanismen einmalig und verwenden Sie diese in der gesamten Anwendung wieder, einschließlich der Minimierung der Nutzung von Cross-Origin Resource Sharing (CORS).

• Modellzugriffskontrollen sollten die Datensatzeigentümerschaft erzwingen, anstatt zu akzeptieren, dass Nutzerinnen/Nutzer Datensätze erstellen, lesen, aktualisieren oder löschen können.

• Durch Domänenmodelle sollten eindeutige Geschäftslimitanforderungen für Anwendungen durchgesetzt werden.

• Deaktivieren Sie die Verzeichnisliste des Webservers und stellen Sie sicher, dass Dateimetadaten (z. B. .git) und Sicherungsdateien nicht in Web-Roots vorhanden sind.

• Protokollieren Sie Fehler bei der Zugriffskontrolle und benachrichtigen Sie Administratoren bei Bedarf (z. B. wiederholte Fehler).

• Setzen Sie Ratenbegrenzung für API- und Controller-Zugriff, um den Schaden durch automatisierte Angriffstools zu minimieren.

• Statusbehaftete Sitzungskennungen sollten nach dem Abmelden auf dem Server ungültig gemacht werden. Zustandslose JWT-Token sollten eher kurzlebig sein, damit das Zeitfenster für Angreifende minimiert wird. Für langlebigere JWTs wird dringend empfohlen, die OAuth-Standards zu befolgen, um den Zugriff zu widerrufen.

Entwickler und QA-Mitarbeiter sollten funktionale Zugriffskontrolleinheiten und Integrationstests durchführen.

Beispielhafte Angriffsszenarien {{ osib_anchor(osib=osib ~ ".example attack Scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Beispiel-Angriffsszenarien", lang=lang, source=source ~ "# " ~ id, parent=osib) }} Copy Chapter

Szenario Nr. 1: Die Anwendung verwendet nicht überprüfte Daten in einem SQL-Aufruf, der auf Kontoinformationen zugreift:

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

Angreifende ändern einfach den „acct“-Parameter des Browsers, um die gewünschte Kontonummer zu senden. Bei nicht korrekter Überprüfung kann die angreifende Person auf das Konto einer beliebigen Nutzerin/Nutzers zugreifen.

https://example.com/app/accountInfo?acct=notmyacct

Szenario Nr. 2: Eine angreifende Person erzwingt einfach die Suche nach Ziel-URLs. Für den Zugriff auf die Admin-Seite sind Admin-Rechte erforderlich.

https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

Wenn eine nicht authentifizierte Benutzerin/Benutzer auf eine der Seiten zugreifen kann, liegt ein Fehler vor. Wenn ein Benutzerin/Benutzer ohne Administrationsrechte auf die Admin-Seite zugreifen kann, handelt es sich um einen Fehler.

Referenzen {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.opc.3." ~ "7", osib=osib) }}
• {{ osib_link(link="osib.owasp.asvs.4-0." ~ "4", osib=osib) }}
• {{ osib_link(link="osib.owasp.wstg.4-2.4.5", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Authorization", osib=osib) }}
• {{ osib_link(link="osib.portswigger.research.articles.exploiting cors misconfigurations for bitcoins and bounties", osib=osib) }}
• {{ osib_link(link="osib.oauth.oauth2 Servers.listing Authorizations.Revoking Access", osib=osib) }}

Liste der zugeordneten CWEs {{ osib_anchor(osib=osib~".mapped cwes", id=id~"-mapped_cwes", name=title~":List of Mapped CWEs", lang=lang, source=source~" #" ~id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.22", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.23", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.35", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.59", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.200", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.201", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.219", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.264", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.275", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.276", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.284", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.285", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.352", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.359", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.377", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.402", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.425", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.441", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.497", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.538", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.540", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.548", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.552", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.566", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.601", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.639", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.651", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.668", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.706", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.862", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.863", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.913", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.922", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.1275", doc="", osib=osib) }}

2021 Docs De A02 2021 Cryptographic Failures (`2021/docs/de/A02_2021-Cryptographic_Failures.md`) Copy Section

source: "https://owasp.org/Top10/A02_2021-Cryptographic_Failures/" title: "A02:2021 – Fehlerhafter Einsatz von Kryptographie" id: "A02:2021" lang: "de" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".2" -%}
#A02:2021 – Fehlerhafter Einsatz von Kryptographie {: style="height:80px;width:80px" align="right"}
{{ osib_anchor(osib=osib, id=id, name ="Kryptografische Fehler", lang=lang, source=source, parent=parent, previous=extra.osib.document ~ ".2017.3") }}

Beurteilungskriterien {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Bezug / Kontext / Auswertung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Copy Chapter

Dieses Thema ist um eine Position auf Platz 2 vorgerückt und war früher bekannt als Verlust der Vertraulichkeit sensibler Daten, bei dem es sich eher um ein allgemeines Symptom als um eine Grundursache handelt. Nun liegt der Schwerpunkt mehr auf Fehlern im Zusammenhang mit Kryptografie oder dass diese nicht zur Anwendung kommt, was häufig zur Offenlegung sensibler Daten führt. Bemerkenswerte Common Weakness Enumerations (CWEs) sind CWE-259: Use of Hard-coded Password, CWE-327: Broken or Risky Crypto Algorithm und CWE-331 Insufficient Entropy.

Beschreibung {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Beschreibung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Copy Chapter

Zunächst gilt es, den Schutzbedarf der Daten während der Übermittlung und der Speicherung zu ermitteln. Beispielsweise erfordern Passwörter, Kreditkartennummern, Gesundheitsakten, persönliche Informationen und Geschäftsgeheimnisse zusätzlichen Schutz, vor allem dann, wenn diese Daten unter Datenschutzgesetze, z. B. die Datenschutz-Grundverordnung (DSGVO) der EU, oder andere Vorschriften fallen, beispielsweise dem Payment Card Industry Data Security Standard (PCI-DSS).

Folgendes ist zu klären:

• Werden Daten im Klartext übermittelt? Das betrifft Protokolle wie HTTP, SMTP, und FTP unter Umständen auch bei Verwendung von TLS-Upgrades wie STARTTLS. Das Internet ist hier besonders gefährlich. Überprüfen Sie auch internen Datenverkehr, z. B. zwischen Load Balancer, Webservern oder Back-End-Systemen.

• Werden alte oder schwache kryptografische Algorithmen oder Protokolle verwendet, z. B. per Default-Einstellung oder in älterem Code?

• Werden vordefinierte kryptografische Schlüssel verwendet, schwache Schlüssel generiert oder Schlüssel wiederverwendet? Fehlt eine Schlüsselverwaltung oder Schlüsselrotation? Werden kryptografische Schlüssel in Quellcode-Repositories eingecheckt?

• Wird Verschlüsselung nicht verbindlich erzwungen, z. B. fehlen bei Web Anwendungen Vorgaben für den Browser in den entsprechenden HTTP-Headern?

• Werden empfangene Serverzertifikate und die Zertifikatskette korrekt validiert?

• Werden Initialisierungsvektoren ignoriert, wiederverwendet oder nicht ausreichend sicher für den kryptografischen Betriebsmodus generiert? Ist ein unsicherer Betriebsmodus wie ECB im Einsatz? Wird ein Betriebsmodus verwendet, der nur verschlüsselt, obwohl ein AEAD Betriebsmodus angebracht wäre, der auch die Integrität schützt?

• Werden Passwörter direkt als kryptografische Schlüssel verwendet ohne eine Schlüsselableitung mittels Key Derivation Function?

• Werden Zufallszahlen für kryptografische Zwecke genutzt, die nicht auf kryptografische Anforderungen ausgelegt sind? Selbst wenn die richtige Funktion genutzt wird, muss diese eventuell vom Entwickler korrekt initialisiert werden. Wurde eine integrierte starke Initialisierung eventuell durch einen Entwickler mit einem schwachen Wert überschrieben, dem es an ausreichender Entropie und Nichtvorhersehbarkeit mangelt?

• Werden Hash-Funktionen mit bekannten Schwächen wie MD5 oder SHA1 verwendet oder werden nicht-kryptografische Hash-Funktionen verwendet, wenn kryptografische Hash-Funktionen benötigt werden?

• Werden veraltete kryptografische Padding Methoden verwendet, z. B. PKCS#1 v1.5?

• Sind kryptografische Fehlermeldungen oder Seitenkanäle ausnutzbar, beispielsweise in Form von Padding-Oracle-Angriffen?

Siehe {{ osib_link(link="osib.owasp.asvs.4-0.6", prefix="ASVS ", doc="", osib=osib) }}, {{ osib_link(link= "osib.owasp.asvs.4-0.8", doc="", osib=osib) }}, {{ osib_link(link= "osib.owasp.asvs.4-0.9", doc="", osib=osib) }}

Prävention und Gegenmaßnahmen {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": Prävention und Gegenmaßnahmen", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Gehen Sie als Minimum wie folgt vor und konsultieren Sie die Referenzen:

• Klassifizieren Sie die Daten, die von einer Anwendung verarbeitet, gespeichert oder übermittelt werden
  nach ihrem Schutzbedarf. Berücksichtigen Sie dabei auch Datenschutzgesetze, regulatorische und Geschäfts-Anforderungen.

• Speichern Sie sensible Daten nicht unnötig. Löschen Sie sensible Daten auf sichere Weise sobald wie möglich oder verwenden Sie Techniken wie PCI-DSS-konformes Speichern von Ersatzwerten (tokenization) oder gar gekürzten (truncation) Werten.
  Daten, die es nicht mehr gibt, können auch nicht gestohlen werden.

• Stellen Sie sicher, dass alle vertraulichen Daten bei Speicherung verschlüsselt werden.

• Stellen Sie sicher, dass aktuelle, starke, standardisierte Algorithmen, Protokolle und Schlüssel, z. B. gemäß BSI TR-02102, verwendet werden. Etablieren Sie wirksames
  Schlüsselmanagement für kryptografische Schlüssel.

• Verschlüsseln Sie alle Daten während der Übertragung mit sicheren Protokollen wie TLS. Priorisieren Sie dabei durch serverseitig Cipher-Suiten, die Forward Secrecy (FS) bieten, und sichere Parameter.
  Erzwingen Sie die Verschlüsselung wenn möglich, z. B. durch Einführung von HTTP Strict Transport Security (HSTS).

• Deaktivieren Sie das Caching für den Empfang vertraulicher Daten.

• Wenden Sie die Sicherheitsmaßnahmen gemäß dem Schutzbedarf der Datenklassifizierung an.

• Verwenden Sie keine veralteten Protokolle wie FTP und SMTP für den Transport sensibler Daten.

• Verwenden Sie spezielle Hash-Funktionen für das Hashen von Passwörtern, bei denen für jedes Passwort ein Salt-Wert (salted hash) zum Einsatz kommt und durch Parametrisierung der Rechenaufwand adaptiv gesteuert werden kann (work-factor). Beispiele sind: Argon2, scrypt, bcrypt oder PBKDF2.

• Initialisierungsvektoren müssen passend zum kryptografischen Betriebsmodus gewählt werden. In vielen Fällen bedeutet dies, dass ein CSPRNG (kryptografisch sicherer Pseudozufallszahlengenerator) für die Generierung des Initialisierungsvektors verwendet wird. Für Modi, die eine Nonce erfordern, benötigt der Initialisierungsvektor nicht notwendigerweise einen CSPRNG. In allen Fällen darf der gleiche Initialisierungsvektor niemals zweimal für den gleichen Schlüssel verwendet werden.

• Verwenden Sie immer eine authentifizierte Verschlüsselung statt nur einer Verschlüsselung.

• Schlüssel sollten kryptografisch zufällig generiert und als Byte-Arrays im Speicher gehalten werden. Wenn ein Passwort zur Verschlüsselung verwendet werden soll, muss über eine Funktion zur Schlüsselableitung ein Schlüssel generiert werden.

• Stellen Sie sicher, dass an den notwendigen Stellen kryptografisch sichere, unvorhersagbare Zufallszahlen verwendet werden, und dass der Pseudozufallszahlengenerator nicht auf vorhersehbare Weise oder nur mit geringer Entropie initialisiert wurde. Bei den meisten modernen APIs muss der Entwickler die Initialisierung des Pseudozufallszahlengenerators (CSPRNG) nicht manuell durchführen.

• Vermeiden Sie veraltete kryptografische Funktionen und Padding-Verfahren wie MD5, SHA1, PKCS Nummer 1 v1.5.

• Lassen Sie die Wirksamkeit der Einstellungen unabhängig überprüfen.

Beispielhafte Angriffsszenarien {{ osib_anchor(osib=osib ~ ".example attack Scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Beispielhafte Angriffsszenarien", lang=lang, source=source ~ "# " ~ id, parent=osib) }} Copy Chapter

Szenario Nr. 1:: Eine Anwendung verschlüsselt Kreditkartendaten automatisch bei der Speicherung in einer Datenbank. Das bedeutet aber auch, dass durch SQL-Injection erlangte Kreditkartendaten in diesem Fall automatisch entschlüsselt werden.

Szenario Nr. 2:: Eine Webseite benutzt kein TLS,
erzwingt dies nicht auf allen Seiten oder lässt schwache Verschlüsselung zu.
Die angreifende Person liest die Kommunikation mit (z. B. in einem offenen WLAN), ersetzt HTTPS- durch HTTP-Verbindungen, hört diese ab und stiehlt das Sitzungscookie.
Durch Wiedereinspielen dieses Cookies übernimmt die angreifende Person die (authentifizierte) Sitzung des Nutzers und erlangt Zugriff auf dessen private Daten.
Anstatt dessen kann die angreifende Person auch die übertragenen Daten ändern, z. B. den Empfänger einer Überweisung.

Szenario Nr. 3:: Die Passwortdatenbank benutzt einfache Hashwerte oder Hashes ohne Salt zur Speicherung der Passwörter. Eine Schwachstelle in der Downloadfunktion erlaubt Angreifenden den Zugriff auf die Passwortdatei. Zu Hashes ohne Salt kann über vorausberechnete Rainbow-Tabellen der Klartext gefunden werden. Hashes, die über einfache oder schnelle Funktionen berechnet wurden, können effizient mit Grafikkarten gebrochen werden.

Referenzen {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": Referenzen", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.opc.3." ~ "8", osib=osib) }}
• {{ osib_link(link="osib.owasp.asvs.4-0.6", osib=osib) }}, {{ osib_link(link= "osib.owasp.asvs.4-0.8", doc="", osib =osib) }}, {{ osib_link(link= "osib.owasp.asvs.4-0.9", doc="", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Transport Layer Protection", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "User Privacy Protection", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Password Storage", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Cryptographic Storage", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "HSTS", osib=osib) }}
• {{ osib_link(link="osib.owasp.wstg.4-2.4.9", osib=osib) }}

Liste der zugeordneten CWEs {{ osib_anchor(osib=osib~".mapped cwes", id=id~"-mapped_cwes", name=title~":Liste der zugeordneten CWEs", lang=lang, source=source~" #" ~id, parent=osib) }} Copy Chapter

• {{ osib_link(link="osib.mitre.cwe.0.261", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.296", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.310", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.319", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.321", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.322", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.323", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.324", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.325", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.326", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.327", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.328", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.329", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.330", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.331", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.335", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.336", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.337", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.338", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.340", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.347", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.523", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.720", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.757", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.759", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.760", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.780", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.818", doc="", osib=osib) }}
• {{ osib_link(link="osib.mitre.cwe.0.916", doc="", osib=osib) }}

2021 Docs De A03 2021 Injection (`2021/docs/de/A03_2021-Injection.md`) Copy Section

source: "https://owasp.org/Top10/A03_2021-Injection/" title: "A03:2021 – Injection" id: "A03:2021" lang: "de" Copy Chapter

{%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%}
{%- set osib = parent ~ ".3" -%}
#A03:2021 – Injection {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name="Injection", lang=lang, source=source, parent=parent, merged_from=[extra.osib.document ~ ".2017.1", extra.osib.document ~ ".2017.7"] ) }}

Beurteilungskriterien {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Übersicht", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Copy Chapter

Die Injection rutscht von der ersten auf die dritte Position ab. 94 % der Anwendungen wurden auf irgendeine Form der Injection getestet, mit einer maximalen Häufigkeit von 19,09 %, einer durchschnittlichen Häufigkeit von 3,37 % und über 274.000 Vorkommnissen. Zu den wichtigsten Common Weakness Enumerations (CWEs) zählen CWE-79: Cross-Site Scripting, CWE-89: SQL Injection und CWE-73: External Control of File Name or Path.

Beschreibung {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Beschreibung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Copy Chapter

Eine Anwendung ist für diesen Angriff anfällig, wenn:

• Daten, die von Nutzenden stammen, von der Anwendung nicht ausreichend validiert, gefiltert oder bereinigt werden.

• Dynamische Anfragen oder nicht-parametrisierte Aufrufe ohne ein, dem Kontext entsprechendes Escaping direkt einem Interpreter übergeben werden.

• Bösartige Daten innerhalb von ORM („Object-Relational Mapping“)-Suchparametern genutzt werden können, um vertrauliche Datensätze von Dritten zu extrahieren.

• Bösartige Daten direkt oder als Teil zusammengesetzter, dynamischer Querys verwendet werden. Die SQL-Abfragen oder Befehle beinhalten die Struktur und die schädlichen Daten in den dynamischen Querys, Befehlen oder Stored Procedures.

Zu den häufigeren Injection Arten gehören SQL, NoSQL, OS-Befehle, Object Relational Mapping (ORM), LDAP und Expression Language (EL) oder Object Graph Navigation Library (OGNL). Das Grundkonzept eines Injection-Angriffs ist für alle Interpreter gleich. Ein Quellcode-Review ist die beste Methode, um Injection-Schwachstellen in Anwendungen zu finden. Ausführliches (ggf. automatisiertes) Testen aller Parameter und Variablen, Header-, URL-, Cookies-, JSON-, SOAP- und XML-Eingaben wird dringend empfohlen. Statische (SAST, Quellcode-Ebene), dynamische (DAST, laufende Anwendung) und interaktive (IAST, Mischform aus statisch und dynamisch) Test-Werkzeuge können von Organisationen für ihre CI/CD-Pipeline genutzt werden, um neue Schwachstellen noch vor einer möglichen Auslieferung in Produktivsysteme zu identifizieren.

Prävention und Gegenmaßnahmen {{ osib_anchor(osib=osib ~ ".how to prevent", id=id ~ "-how_to_prevent", name=title ~ ": Prävention und Gegenmaßnahmen", lang=lang, source=source ~ "#" ~ id, parent=osib) }} Copy Chapter

Eine konsequente Trennung von Daten, Suchanfragen und Befehlen ist für die Vermeidung von Injection-Angriffen unerlässlich:

• Die bevorzugte Methode ist die Verwendung einer sicheren API, die die Verwendung des Interpreters vollständig vermeidet, eine parametrisierte Schnittstelle bereitstellt oder in objektrelationale Mapping-Tools (ORMs) umwandelt.
  Anmerkung: Stored Procedures können - auch parametrisiert - immer noch SQL-Injections ermöglichen, wenn PL/SQL oder T-SQL Anfragen und Eingabedaten konkateniert oder mit EXECUTE IMMEDIATE oder exec() ausgeführt werden.

• Für die serverseitige Eingabe-Validierung empfiehlt sich die Nutzung eines Positivlisten(“Whitelist”)-Ansatzes. Dies ist i. A. kein vollständiger Schutz, da viele Anwendungen Sonderzeichen z. B. in Textfelder oder APIs für mobile Anwendungen benötigen.

• Für jede noch verbliebene dynamische Query müssen Sonderzeichen für den jeweiligen Interpreter mit der richtigen Escape-Syntax entschärft werden. Anmerkung: Ein Escaping von SQL-Bezeichnern, wie z. B. die Namen von Tabellen oder Spalten usw. ist nicht möglich.
  Falls Nutzende solche Bezeichner selbst eingeben können, so ist dies durchaus gefährlich. Dies ist eine übliche Schwachstelle bei Software, die Reports aus einer Datenbank erstellt.

• SQL-Querys sollten LIMIT oder andere SQL-Controls verwenden, um den möglichen Massen-Abfluss von Daten zu verhindern.

Beispielhafte Angriffsszenarien {{ osib_anchor(osib=osib ~ ".example attack Scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Beispiel-Angriffsszenarien", lang=lang, source=source ~ "# " ~ id, parent=osib) }} Copy Chapter

Szenario Nr. 1: Eine Anwendung nutzt ungeprüfte Eingabedaten für den Zusammenbau der folgenden verwundbaren SQL-Abfrage:

String query = "SELECT \* FROM Accounts WHERE custID='" + request.getParameter("id") + "'";

Szenario Nr. 2: Auch das blinde Vertrauen in Frameworks kann zu Querys führen, die ganz analog zu obigem Beispiel verwundbar sind (z. B. Hibernate Query Language (HQL)):

Abfrage HQLQuery = session.createQuery("FROM Accounts WHERE custID='" + request.getParameter("id") + "'");

In beiden Fällen können Angreifende den ‘id’-Parameter im Browser ändern und sendet: „UNION SLEEP(10);--“. Zum Beispiel:

http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

Hierdurch wird die Logik der Anfrage verändert, so dass alle Datensätze der Tabelle „accounts“ ohne Einschränkung auf einen Kunden zurückgegeben werden.
Gefährlichere Attacken wären z. B. das Ändern oder Löschen von Daten oder das Aufrufen von Stored Procedures.

Referenzen {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Copy Chapter

• {{ osib_link(link="osib.owasp.opc.3." ~ "3", osib=osib) }}
• {{ osib_link(link="osib.owasp.asvs.4-0.5", osib=osib) }}
• {{ osib_link(link="osib.owasp.wstg.4-2.4.7.5", osib=osib) }}, {{ osib_link(link="osib.owasp.wstg.4-2.4.7.12", doc= "", osib=osib) }},
  {{ osib_link(link="osib.owasp.wstg.4-2.4.7.5.7", doc="", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Injection Prevention", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "SQL Injection Prevention", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Injection Prevention in Java", osib=osib) }}
• {{ osib_link(link="osib.owasp.cheatsheetseries.0." ~ "Query Parameterization", osib=osib) }}
• {{ osib_link(link="osib.owasp.oat.0.14", osib=osib) }}
• {{ osib_link(link="osib.portswigger.kb.issues.serversidetemplateinjection", doc="osib.portswigger.kb.issues", osib=osib) }}