# Technical Documentation: OWASP/Top10 > ℹ️ **Provenance:** Multi-Tier Ingestion · [CodeWiki Reference](https://codewiki.google/github.com/OWASP/Top10) ### Overview (README.md) # Top10 Official OWASP Top 10 Document Repository ## OWASP Top 10 2025 - RELEASED We have released the OWASP Top 10:2025 (Final): - [OWASP Top10:2025](https://owasp.org/Top10/2025/) Please log any [feedback, comments, or log issues](https://github.com/OWASP/Top10/issues) here. ## OWASP Top 10 2021 - SUPERSEDED - [OWASP Top10:2021](https://owasp.org/Top10/2021/) ## OWASP Top 10 2017 - HISTORIC - [OWASP Top 10:2017 (PPTX)](https://github.com/OWASP/Top10/blob/master/2017/OWASP%20Top%2010-2017%20(en).pptx) - [OWASP Top 10:2017 (PDF)](https://github.com/OWASP/Top10/blob/master/2017/OWASP%20Top%2010-2017%20(en).pdf) ## OWASP Top 10 Leadership There are currently five co-leaders for the OWASP Top 10: * Andrew van der Stock - X: [@vanderaj](https://x.com/vanderaj) * Brian Glas - X: [@infosecdad](https://x.com/infosecdad) * Neil Smithline - X: [@appsecneil](https://x.com/appsecneil) * Tanya Janca - X: [@shehackspurple](https://x.com/shehackspurple) * Torsten Gigler - Mastodon: [@torsten_gigler@infosec.exchange](https://infosec.exchange/@torsten_gigler) ## OWASP Top 10 References - [OWASP Top 10 Project Page](https://owasp.org/www-project-top-ten) - HISTORIC: [OWASP 2017 Summit Outcomes](https://owaspsummit.org/Outcomes/Owasp-Top-10-2017/Owasp-Top-10-2017.html) --- ### 2021 Docs Ar Index (`2021/docs/ar/index.md`) # مقدمة ## مرحباً بكم في أعلى عشرة مخاطر لعام 2021 مرحبًا بكم في أحدث إصدار من أعلى عشرة مخاطر من منظمة أواسب وهي النسخة الحديثة لعام 2021، والتي تأتي بشكل جديد تمامًا ومدعمة برسومات انفوجرافيك التي تستطيع طباعتها واستخدامها ويمكن الحصول عليها من صفحتنا الرئيسية. كما نتقدم بجزيل الشكر والعرفان لكلّ من ساهم بفكرة، أو وقت، أو جهد في سبيل إنجاح هذا العمل، ممتنّون لما بذلتموه، ولما حقّقناه بفضل الله ثم بمساعدتكم ودعمكم.. ## ما هي التغييرات التي طرأت على أعلى عشرة مخاطر لعام 2021 بشكل عام تم إضافة 3 تصنيفات جديدة و 4 تصنيفات ، تم تغيير الاسم وكذلك النطاق الخاص بها، وبعض عمليات الدمج التي تأتي مع أعلى عشرة مخاطر لعام 2021 Mapping of the relationship between the Top 10 2017 and the new Top 10 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. وتظهر البيانات حسب الاختبارات التي تم إجراؤها أن هذا التصنيف معدل الإصابة به فوق المتوسط مع ارتفاع منخفض. ومدى ارتباطه بمعدل التأثير وإمكانية الاستغلال. ويفيد المختصين في المجال أن وجود هذا التصنيف من ضمن المخاطر هو أمر مهم جدًا حتى وإن كانت البيانات الحالية غير مكتملة في الوقت الحالي. ## المنهجية لأول مرة يتم الاعتماد على البيانات في تصنيف أعلى عشرة مخاطر ويجب التنويه أنها لا تعتمد على البيانات بشكل كُلي. حيث تم اختيار ثمانية تصنيفات من أصل عشرة بناءً على البيانات واثنين منهم بناءً على الاستطلاع الذي تم إجراؤه في نطاق المخاطر. وتقوم منظمة أواسب بالاعتماد على البيانات السابقة أكثر من أي مصادر أخرى وذلك بسبب أن الباحثين في أمن التطبيقات يستغرقون وقت وجهد كبير في إيجاد الثغرات أو طرق جديدة لاستغلالها. مما يجعل عملية التحقق من النتائج والأدوات والطرق المستخدمة يستغرق وقت أكبر وقد تصل إلى سنوات. ولتحقيق التوازن قمنا باستخدام استطلاع على المخاطر التي تستهدف صناعة أمن التطبيقات وقمنا بتوجيه أسئلة للمختصّين في نقاط الضعف التي قد لا تظهرها البيانات. وكما أن هناك بعض التغييرات الجوهرية التي تم اعتمادها من قبل منظمة أواسب لمواصلة المنهجية المتّبعة في تصنيف أعلى عشرة مخاطر. ### كيف يتم تنظيم التصنيفات تم تغيير بعض التصنيفات من الإصدار السابق لأعلى عشر مخاطر وهنا ملخص لما تم تغيره على مستوى التصنيفات تركز الجهود المبذولة في جمع البيانات على مجموعات فرعية من 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 واستخدمها كلغة عمل وإطار. ### كيف يتم استخدام البيانات لبعض التصنيفات المختارة في الإصدار السابق لعام 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 في قاعدة البيانات وذلك لاستخدمها لتقييم درجات الأثر والاستغلال والاستفادة منها كذلك في احتساب المخاطر بناء على المعادلة المستخدمة. ## لماذا لا تكون مجرد بيانات إحصائية بحتة؟ تقتصر النتائج بشكل أساسي على ما يمكن اختباره بشكل آلي. وحينما تتحدث إلى أحد المختصّين المحترفين في مجال أمن التطبيقات سيخبرونك أن بعض المخرجات والاحصائيات لا يوجد لها بيانات بعد. ومع ذلك عند إعداد منهجيات الاختبار، تستغرق فترة من الزمن ومن ثم أنت بحاجة إلى المزيد من الوقت لكي تقوم بأتمتة تلك الاختبارات وتشغيلها على مجموعة كبيرة من التطبيقات. ولذلك قمنا باختيار ثمانية تصنيفات من أصل عشرة من البيانات بسبب عدم اكتمال ونضج البيانات، وبالنسبة للتصنيفين المتبقية قمنا بعمل استطلاع في مجال امن التطبيقات. مما يسمح للمختصين بالتصويت لما يرونه من المخاطر التي تستحق أن تضاف إلى قائمة أعلى عشرة مخاطر والتي قد لا يكون لها بيانات أو بيانات غير متناسقة أو غير مناسبة. ## لماذا معدل الحدوث بدلا من التكرار؟ هناك ثلاثة مصادر أساسية للبيانات. نحددها على أنها الانسان يساعد الأدوات (HaT) ، او الأدوات تساعد الإنسان (TaH) ، او الأدوات من غير أي تعديلات. تقوم HaT والأدوات بعمليات اكتشاف على مستوى عالي. حيث ان الأدوات تبحث عن نقاط ضعف محددة مع تجربة جميع الاحتمالات المتوقعة لاكتشاف الثغرة. وعند النظر الى ثغرة XSS والتي بالعادة اما ان تكون منخفضة الخطورة او بسيطة والتي تأتي بسبب أخطاء الأنظمة او أخطاء في عملية التصفية. وعندما تكون الثغرة بسبب خطاء في الأنظمة ترتفع بالنسبة تكرار الاكتشاف لهذه الثغرة والتي من الممكن ان تؤثر على مخرجات التقرير او البيانات. ومن ناحية أخرى، نجد أن TaH أخرجت لنا نطاق واسع من الثغرات ولكن مع تكرار أقل بكثير بسبب ضيق الوقت. وذلك بسبب قيام المختصين بفحص التطبيقات ويرون في بعض الأحيان مثل XSS سيقومون بإيجاد ٣ أو ٤ وبعد ذلك يتوقفون عن البحث عنها وإيجاد سبب الخطأ وكتابة تقرير عنها والتوصيات الممكنة لكي تقوم بإصلاحها والتي ستقوم بإصلاح جميع التطبيقات. وليس هناك حاجة أو وقت للعثور على جميع الثغرات بشكل متكرر. لنفترض أننا أخذنا مجموعتين من البيانات المميّزة والغير متشابهة وحاولنا دمجها على مستوى التكرار. في هذه الحالة سنجد أن البيانات الدقيقة المستخرجة من الأدوات وHaT غير قابلة للملاحظة مع بيانات TaH. وهذا يظهر في بعض الأحيان بشكل إيجابي في بعض الثغرات مثل ثغرة XSS والذي في بعض الأحيان يقوم برفع مستوى التصنيف من منخفض إلى متوسط بسبب العدد الهائل من النتائج. (ثغرات مثل XSS من السهل اختبارها والخروج بنتائج معقولة) في عام 2017 قمنا باستخدام معدّل الحدوث بدلًا من إلقاء نظرة مرة أخرى على البيانات ودمجها بشكل مناسب مع البيانات المستخرجة من الأدوات وHaT و TaH. حيث يكون معدل الحدوث يعتمد على نسبة التطبيقات التي لديها نوع من أنواع الثغرات. وحقيقة نحن في المنظمة لا نهتم في حال كانت الثغرة واحدة معدل حدوثها متكرر. وهدفنا هو معرفة عدد التطبيقات التي لديها ثغرة واحدة على الأقل. وهذا يعطينا تصوّر واضح من نتائج الاختبار والتي تُعتبر لدينا أفضل من إغراق البيانات بتكرار ليس له فائدة. ## ما هي عملية جمع البيانات وتحليلها؟ تم إضفاء الطابع الرسمي على عملية جمع بيانات أعلى عشر مخاطر في قمة Open Security Summit في عام 2017. وبعد ذلك أمضى المسؤولين في منظمة آواسب يومين في العمل على جعل عملية جمع البيانات مبنية على سياسة واضحة وشفافة. تعد نسخة 2021 هي المرة الثانية التي نستخدم فيها هذه المنهجية. قمنا بدعوة للحصول على البيانات من خلال قنوات التواصل الاجتماعي المتاحة لنا، لكلًّا من المشروع و OWASP. وفي [صفحة مشروع OWASP](https://owasp.org/www-project-top-ten/#div-data_2020), نقوم بإدراج عناصر وهيكل البيانات التي نبحث عنها وكيفية إرسالها. وفي [مشروع GitHub](https://github.com/OWASP/Top10/tree/master/2021/Data), لدينا أمثلة لملفات تعمل كقوالب. نعمل مع المنظمات الأخرى حسب الحاجة للمساعدة في تحديد الهيكلورسمه وربطه بـ CWEs. نحصل على البيانات من المؤسسات التي بالاختبارات من خلال المبادلة، ومن خلال منصات اكتشاف الثغرات، والمؤسسات التي تساهم ببياناتها الخاصة بالاختبار الداخلية. وبمجرد حصولنا على البيانات، نقوم بتحميلها معًا ونجري تحليلًا وفهماً عن أساسيًات الربط بـ CWEs لتصنيفات المخاطر. هناك تداخل بين بعض CWEs، بسبب التشابه بينهم (مثل نقاط الضعف في التشفير). حيث يتم توثيق ونشر أي قرارات تتعلق بالبيانات الأولية المقدمة لتكون مفتوحة وواضحة مع كيفية مواءمة البيانات. يتم النظر إلى التصنيفات الثمانية ذات أعلى معدلات حدوث لإدراجها في أعلى عشر مخاطر. وننظر أيضًا في نتائج الاستطلاع في مجال امن التطبيقات لمعرفة في حال وجود أي منها في البيانات. سيتم اختيار أعلى تقييمين غير موجودين بالفعل في البيانات المحللة سابقاً واضفتها الى أعلى عشر مخاطر. بمجرد اختيار جميع العشرة ، يتم تطبيق العوامل التي تم الاتفاق عليها وهي (الاستغلال والتأثير)؛ للمساعدة في ترتيب أعلى عشر مخاطر. ## العوامل المستخدمة مع البيانات هناك عوامل بيانات مدرجة لكل تصنيف من تصنيفات أعلى عشر مخاطر، وإليك ما تعنيه: - *ربط بـ CWEs*: عدد CWEs الذي تم ربطها بواسطة الفريق. - *معدل الحدوث/الحوادث*: معدل الحدوث وهو النسبة المئوية للتطبيقات المعرضة لثغرات ومعرفة مدى ارتباطها بمعيار CWE خلال الاختبارات التي. أجرتها المؤسسات في سنة محددة. - (الاختبارات) *والتغطية*:النسبة المئوية للتطبيقات التي تم اختبارها من قبل جميع المنظمات لـ CWE مُعيّن. - *خطورة الاستغلال*: معرفة الاستغلال و النقاط الفرعية له من CVSSv2 و CVSSv3 والتي لديها CVEs ومرتبطة بـ CWEs، ،موائمتها ، ووضعها على مقياس 10pt. - *التأثير المتوقع*: تأثير النقاط الفرعية من CVSSv2 و CVSSv3 والتي لديها CVEs ومرتبطة بـ CWEs، ،موائمتها ، ووضعها على مقياس 10pt. - *إجمالي التكرار/الحوادث*: إجمالي عدد التطبيقات التي تم ربطها بـ CWEs وتم وضع تصنيف محدد لها. - *إجمالي CVEs*: إجمالي عدد CVEs في NVD DB التي تم ربطها بـ CWEs وتم وضع تصنيف محدد لها. ## علاقات التصنيفات لعام 2021 مع تصنيفات عام 2017 هناك الكثير من الحديث عن التداخل بين المخاطر العشرة الأولى. ومن خلال تعريف كل (القوائم المدرجة في CWEs)، ولكن الذي يظهر لنا أنه لا يوجد أي تداخل فيها ومع ذلك، من الناحية النظرية، يمكن أن يكون هناك تداخل أو تأثر بناءً على التسمية. ونقوم باستخدام مخططات Venn لإظهار التداخل كما ورد في المثال أدناه. Diagram Description automatically generated يمثل مخطط Venn أعلاه الترابط بين التصنيفات في أعلى عشر مخاطر لعام 2017. وأثناء القيام بذلك، أصبحت بضع نقاط أساسية واضحة: 1. كان يُرى بأن هجوم - ثغرات XSS تنتمي في حقيقة الأمر إلى ثغرات الحقن(Injection) لأنها في الأساس عبارة عن حقن المحتوى. بالنظر إلى بيانات عام 2021 ، أصبح من الواضح أن ( XSS )بحاجة إلى الانتقال إلى الحقن(Injection). 2. التداخل فيما بينهم غالبًا يكون في اتجاه واحد. غالبًا ما نصنّف الثغرة من خلال "العَرَض"، وليس السبب الجذري (الذي يحتمل أن يكون عميقًا). على سبيل المثال، قد تكون " البيانات الحساسة المكشوفة " نتيجة "الإعدادات خاطئة الأمان، وفي الغالب لن تراها بالإتجاه المعاكس. نتيجة لذلك، يتم رسم الأسهم في مناطق التأثر للإشارة إلى الإتجاه الذي يحدث فيه. 3. أحيانًا يتم رسم هذه المخططات بشكل كامل كما في *A06: 2021 الثغرات والأنظمة الغير قابلة للتحديث*. في حين أن بعض التصنيفات من هذه المخاطر قد يكون السبب الجذري هي ثغرات من الطرف الثالث، فإنه يتم إدارتها بشكل مختلف ومسؤوليات مختلفة. والمخاطر الأخرى المتبقية تمثّل الطرف الأول. # شكراً لكل من ساهم معنا في جمع هذه البيانات ساهمت المنظمات التالية (جنبًا إلى جنب مع بعض المساهمين-المتبرعين المجهولين) لبيانات لأكثر من 500,000 تطبيق وجعلها هي القائمة الأكبر والأكثر والأشمل من التطبيقات التي تم إجراء اختبارات الأمان عليها وجعلها في قاعدة بيانات. وتأكد أنه من غير اسهاماتك لن يكون هذا ممكن. | | | | | | :---: | :---: | :---: | :---: | | AppSec Labs | GitLab | Micro Focus | Sqreen | | Cobalt.io | HackerOne | PenTest-Tools | Veracode | | Contrast Security | HCL Technologies | Probely | WhiteHat (NTT) | # شكرا لجميع داعمينا الماليين [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs De Index (`2021/docs/de/index.md`) --- source: "https://owasp.org/Top10/index" title: "A00_2021_Startseite" id: "Startseite" lang: "de" --- {%- 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 {: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 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](../0x00-notice/#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](A01_2021-Broken_Access_Control.md)** 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](A02_2021-Cryptographic_Failures.md)** 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](A03_2021-Injection.md)** {{ 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](A04_2021-Insecure_Design.md)** 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](A05_2021-Security_Misconfiguration.md)** 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](A06_2021-Vulnerable_and_Outdated_Components.md)** 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](A07_2021-Identification_and_Authentication_Failures.md)** 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](A08_2021-Software_and_Data_Integrity_Failures.md)** 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](A09_2021-Security_Logging_and_Monitoring_Failures.md)** 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](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** 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 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 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**](A10_2021-Server-Side_Request_Forgery_(SSRF).md) und das Maximum bei 40 CWEs in [**A04:2021-Unsicheres Anwendungsdesign**](A04_2021-Insecure_Design.md) 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 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? 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? 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? 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 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 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 Das OWASP Top 10 2021-Team dankt Secure Code Warrior und Just Eat für die finanzielle Unterstützung. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs En Index (`2021/docs/en/index.md`) # 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 Start with the [Introduction](A00_2021_Introduction.md) to learn about the OWASP Top 10:2021. ## Navigation Use the navigation menu on the left to explore: - [Introduction](A00_2021_Introduction.md) - [Notice](0x00_2021-notice.md) - [How to use the OWASP Top 10 as a standard](A00_2021_How_to_use_the_OWASP_Top_10_as_a_standard.md) - [How to start an AppSec program with the OWASP Top 10](A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10.md) - [About OWASP](0x01_2021-about-owasp.md) ### The Top 10:2021 List 1. [A01 Broken Access Control](A01_2021-Broken_Access_Control.md) 2. [A02 Cryptographic Failures](A02_2021-Cryptographic_Failures.md) 3. [A03 Injection](A03_2021-Injection.md) 4. [A04 Insecure Design](A04_2021-Insecure_Design.md) 5. [A05 Security Misconfiguration](A05_2021-Security_Misconfiguration.md) 6. [A06 Vulnerable and Outdated Components](A06_2021-Vulnerable_and_Outdated_Components.md) 7. [A07 Identification and Authentication Failures](A07_2021-Identification_and_Authentication_Failures.md) 8. [A08 Software and Data Integrity Failures](A08_2021-Software_and_Data_Integrity_Failures.md) 9. [A09 Security Logging and Monitoring Failures](A09_2021-Security_Logging_and_Monitoring_Failures.md) 10. [A10 Server Side Request Forgery (SSRF)](A10_2021-Server-Side_Request_Forgery_(SSRF).md) --- **Looking for the 2025 Release Candidate?** Visit [https://owasp.org/Top10/2025/](https://owasp.org/Top10/2025/) --- ### 2021 Docs Es Index (`2021/docs/es/index.md`) # Introducción ## Bienvenido al OWASP Top 10 - 2021 ¡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 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](A01_2021-Broken_Access_Control.md)** 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](A02_2021-Cryptographic_Failures.md)** 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](A03_2021-Injection.md)** 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](A04_2021-Insecure_Design.md)** 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](A05_2021-Security_Misconfiguration.md)** 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](A06_2021-Vulnerable_and_Outdated_Components.md)** 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](A07_2021-Identification_and_Authentication_Failures.md)** 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](A08_2021-Software_and_Data_Integrity_Failures.md)** 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](A09_2021-Security_Logging_and_Monitoring_Failures.md)** 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](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** 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 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 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 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? 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? 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? 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 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 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 El equipo del OWASP Top 10 2021 agradece el apoyo financiero de Secure Code Warrior y Just Eat. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs Fr Index (`2021/docs/fr/index.md`) # Introduction ## Bienvenue à l'OWASP Top 10 - 2021 {: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 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](A01_2021-Broken_Access_Control.md)** 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](A02_2021-Cryptographic_Failures.md)** 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](A03_2021-Injection.md)** 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](A04_2021-Insecure_Design.md)** 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é](A05_2021-Security_Misconfiguration.md)** 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](A06_2021-Vulnerable_and_Outdated_Components.md)** é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é](A07_2021-Identification_and_Authentication_Failures.md)** é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](A08_2021-Software_and_Data_Integrity_Failures.md)** 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](A09_2021-Security_Logging_and_Monitoring_Failures.md)**, 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](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** 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 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 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 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 ? 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 ? 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 ? 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 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 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 L'équipe de l'OWASP Top 10 2021 remercie le soutien financier de Secure Code Warrior et Just Eat. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs Id Index (`2021/docs/id/index.md`) # Pengantar ## Selamat datang ke OWASP Top 10 - 2021 {: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 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 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 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 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? 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? 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? 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 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 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 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 The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior. [](https://securecodewarrior.com) --- ### 2021 Docs It Index (`2021/docs/it/index.md`) # Introduzione alla OWASP Top 10 2021 ## Vi presentiamo la OWASP Top 10 - 2021 {: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 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](A01_2021-Broken_Access_Control.md)** 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](A02_2021-Cryptographic_Failures.md)** 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](A03_2021-Injection.md)** 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](A04_2021-Insecure_Design.md)** è 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](A05_2021-Security_Misconfiguration.md)** 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](A06_2021-Vulnerable_and_Outdated_Components.md)** 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](A07_2021-Identification_and_Authentication_Failures.md)** 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](A08_2021-Software_and_Data_Integrity_Failures.md)** è 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](A09_2021-Security_Logging_and_Monitoring_Failures.md)** 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](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** 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 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 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 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? 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? 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? 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 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 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 Il team OWASP Top 10 2021 ringrazia il supporto finanziario di Secure Code Warrior e Just Eat. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs Ja Index (`2021/docs/ja/index.md`) # 導入 ## OWASP Top 10 - 2021 へようこそ {:class="img-responsive"} OWASP トップ 10 の最新版へようこそ! OWASP トップ 10 2021年版は、グラフィックデザインが一新され、1ページのインフォグラフィックになっています。インフォグラフィックは、ホームページから入手でき、印刷することができます。 今回のトップ10の作成にあたって、貴重な時間やデータを提供してくださったすべての皆さんに感謝します。皆様のご協力なくしては、OWASP トップ 10 2021年版は存在し得ません。**本当に、感謝いたします**。 ## 2021年版トップ10の変更点 2021年版トップ10では、3つの新しいカテゴリー、4つのカテゴリーの名称とスコープの変更がありました。統合されたものもいくつかあります。 - **[A01:2021-アクセス制御の不備](A01_2021-Broken_Access_Control.md)** は、5位から最も深刻なWebアプリケーションのセキュリティリスクへと順位を上げました。貢献されたデータから、平均でテストされたアプリケーションの3.81%が1つ以上の共通脆弱性タイプ一覧（CWE）を持っており、このリスクカテゴリに該当するCWEは 318,000 件以上存在していたことがわかりました。他のカテゴリーに比べ、「アクセス制御の欠陥」にあたる34件のCWEがアプリケーション内で多く発生していました。 - **[A02:2021-暗号化の失敗](A02_2021-Cryptographic_Failures.md)** は、ひとつ順位を上げて2位になっています。以前は、**A3:2017-機微な情報の露出** と呼ばれていましたが、これは根本的な原因というより幅広くみられる症状と言えます。ここでは、機密データの漏えいやシステム侵害に多く関連する、暗号技術にまつわる失敗に焦点を当てています。 - **[A03:2021-インジェクション](A03_2021-Injection.md)** は、3位に下がっています。94%のアプリケーションで何らかのインジェクションに関する問題が確認されています。最大発生率は19%、平均発生率は3.37%であり、このカテゴリにあたる33のCWEは、アプリケーションでの発生数が2番目に多く見られます。発生数は27万4千件でした。今回から、クロスサイトスクリプティングは、このカテゴリに含まれています。 - **[A04:2021-安全が確認されない不安な設計](A04_2021-Insecure_Design.md)** は、2021年に新設されたカテゴリーで、設計上の欠陥に関するリスクに焦点を当てています。一業界として、我々が純粋に「シフトレフト」することを望むのであれば、脅威モデリングや、安全な設計パターンと原則、また、リファレンス・アーキテクチャをもっと利用していくことが必要です。 安全が確認されない不安な設計は完璧な実装によって修正されることはありません。定義上、(つまり設計自体が問題なので)特定の攻撃に対して必要なセキュリティ対策が作られることがありえないからです。 - **[A05:2021-セキュリティの設定ミス](A05_2021-Security_Misconfiguration.md)** は、前回の6位から順位を上げました。アプリケーションの90％に何らかの設定ミスが見られ、インシデントの平均発生率としては4.5%、このリスクカテゴリに該当するCWEは 208,000 件以上存在していたことがわかりました。 高度な設定が可能なソフトウェアへの移行が進む中で、このカテゴリーの順位が上がったことは当然と言えます。以前の、**A4:2017-XML 外部エンティティ参照 (XXE)** のカテゴリーは、このカテゴリーに含まれています。 - **[A06:2021-脆弱で古くなったコンポーネント](A06_2021-Vulnerable_and_Outdated_Components.md)** は、以前は「既知の脆弱性のあるコンポーネントの使用」というタイトルでした。この問題は、Top 10コミュニティの調査では2位であり、データ分析によってトップ10に入るだけのデータもありました。このカテゴリーは2017年の9位から順位を上げました。これは、テストやリスク評価に苦労する、よく知られた問題です。また、含まれるCWEにあたる共通脆弱性識別子 (CVE)のない、唯一のカテゴリであるため、デフォルトのエクスプロイトとインパクトの重みは5.0としてスコアに反映されています。 - **[A07:2021-識別と認証の失敗](A07_2021-Identification_and_Authentication_Failures.md)** は以前、「認証の不備」と呼ばれていましたが、この版では第2位から順位を落とし、識別の失敗に関連するCWEをより多く含む意味合いのカテゴリとなっています。このカテゴリーは依然としてトップ10に示すべき重要な項目ですが、標準化されたフレームワークの利用が進んだことが功を奏しているようです。 - **[A08:2021-ソフトウェアとデータの整合性の不具合](A08_2021-Software_and_Data_Integrity_Failures.md)** は、2021年に新設されたカテゴリーで、ソフトウェアの更新、重要なデータを、CI/CDパイプラインにおいて整合性を検証せずに見込みで進めることによる問題にフォーカスしています。共通脆弱性識別子/共通脆弱性評価システム (CVE/CVSS) のデータから最も重大な影響を受けたものの1つが、このカテゴリーの10のCWEにマッピングされています。**A8:2017-安全でないデシリアライゼーション** は、このカテゴリーの一部となりました。 - **[A09:2021-セキュリティログとモニタリングの失敗](A09_2021-Security_Logging_and_Monitoring_Failures.md)** は、従来は**A10:2017-不十分なロギングとモニタリング**でしたが、Top 10コミュニティの調査（第3位）から追加され、従来の第10位からランクアップしました。このカテゴリは、より多くの種類の失敗を含むように拡張されています。これは、テストが困難なものであり、かつ、CVE/CVSSのデータにはあまり反映されないものです。とはいえ、このカテゴリーで失敗が起きると、可視性、インシデントアラート、フォレンジックなどに直接影響を与える可能性があります。 - **[A10:2021-サーバーサイドリクエストフォージェリ(SSRF)](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** は、Top 10コミュニティの調査（第1位）から追加されたものです。調査データからわかることは、よくあるテストより広範な範囲において、問題の発生率は比較的低いものの、問題が起きた場合のエクスプロイトとインパクトは平均以上のものとなり得ます。このカテゴリは、現時点でデータとして現れるものではありませんでしたが、複数の業界の専門家により重要との示唆を得たシナリオとして反映しています。 ## 方法論 今回のトップ10は、これまで以上にデータを重視していますが、やみくもにデータを重視しているわけではありません。10項目のうち8項目は提供されたデータから、2項目はTop 10コミュニティの調査から高いレベルで選びました。こうすることにはひとつの根本的な理由があります。提供されたデータを見ることは、過去を見ることを意味している、ということです。アプリケーションセキュリティのリサーチャーが新しい脆弱性や、それをテストする新しい方法を見つけるのには時間がかかります。これらのテストをツールやプロセスに組み込むには時間がかかります。こうした弱点を広く確実にテストできるようになるまでには、何年もかかってしまうことでしょう。そこで、データではわからないような本質的な弱点は何かということについては、業界の第一線で活躍されている方々にお聞きすることでバランスをとる、というわけです。 トップ10を継続的に成熟させるために私たちが採用した、重要な変更点がいくつかあります。 ## カテゴリの構成について 前回の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に集中して教えることができるでしょう。 ## カテゴリ選定にデータがどのように使用されたか 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にマッピングし、リスク方程式のうち半分の*悪用性*および*(技術面の) 影響*スコアとして使用しました。 ## なぜ純粋な統計データだけではないのか データからの結果は、主に自動化された方法でテストできるものからに限られています。しかし、経験豊富なAppSecの専門家に話を聞けば、まだデータにはない発見や傾向について教えてくれるでしょう。とはいえ特定の脆弱性タイプに対するテスト手法を開発するのには時間が必要です。そのテストを自動化し、多くのアプリケーションに対して自動的に実行できるようにするのは、さらに時間がかかります。つまり、データから過去を振り返るだけでは限界があり、データにはない昨年のトレンドを見落としている可能性があります。 そのため、不完全ともいえるデータの結果からのカテゴリ選定は10項目のうち8項目に留めています。残りの2つのカテゴリーは、トップ10コミュニティ調査によって選びました。これは、最前線で実際に活躍されている方々が、最も高いリスクにもかかわらず、データには現れないであろう（データでは表しようもない）と思われるものを選んでくれたものです。 ## 頻度ではなく、発生率を基準とした理由 データソースは主に3つあります。ここでは、HaT（Human-assisted Tooling:人間援助型自動テスト）、TaH（Tool-assisted Human:ツールを利用した手動テスト）、そしてRaw Tooling:完全自動テストと名付けました。 自動テストとHaTは高頻度発見生成機です。これらは、特定の脆弱性に対して、その脆弱性を持つすべてのインスタンスをできる限り見つけようとします。このため、いくつかの脆弱性のタイプについて高い発見数を出力します。クロスサイトスクリプティングを例にしますと、この脆弱性は通常、軽微で孤立したミスによるものとシステム的な問題によるもの、の2種類があります。システム的な問題である場合、単一のアプリケーションで発見数が数千になることがあります。このようなデータで他のレポートやデータから発見された他のほとんどの脆弱性が埋もれてしまいます。 一方、TaHでは、より幅広い種類の脆弱性を発見しますが、時間の制約上、発見頻度はかなり低くなります。人間がアプリケーションをテストしてクロスサイトスクリプティングといったものを発見した場合、通常3つか4つのインスタンスを発見して切り上げます。この時点でシステム的な発見を判断し、アプリケーション全体のスケールで修正するための推奨事項とともに、レポートを書き上げることができます。すべてのインスタンスを見つけることは(それにかける時間も)必要ありません。 この2つの異なるデータセットを取り出して、頻度の観点でマージしようとしたとします。その場合、自動テストとHaTのデータで、より正確で（ただし広く薄い）TaHのデータを埋もれてしまうでしょう。これがクロスサイトスクリプティングのように、影響は一般的に小さいか中程度であるようなものが、多くのリストにおいて高い順位に挙げられている理由の一つです。つまりまさしく発見が非常に多いからです。(クロスサイトスクリプティングはテストもしやすいので、それに対するテストも多く行われています）。 2017年には、データを改めて見直し自動テスト及びHaTのデータをTaHのデータときれいに統合するために、代わりに発生率を用いることを導入しました。発生率とは、ある脆弱性タイプのインスタンスを一つ以上持っていたものが、アプリケーションの母集団のうち何％いたかを確認したものです。単発的なものかシステム的なものかは気にしません。それは私たちの目的に影響しないからです。つまり少なくとも1つのインスタンスを持つアプリケーションの数が分かればよいだけなのです。これは、高頻度の結果でデータを埋もれさせることなく、複数のテストタイプにまたがるテストの所見をより明確に示すのに役立ちます。リスク分析観点として、攻撃者はたった1つの脆弱なインスタンスがありさえすれば、カテゴリを経由してアプリケーション攻撃成功できる、ということにもあたります。 ## データの収集と分析のプロセスについて 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をリスクに基づく順序でランク付けするのに役立てるべく、悪用のしやすさと影響に関する一般要素をあてはめました。 ## 用語集 トップ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の総数です。 ## データ提供者への謝辞 この最も大規模で包括的なアプリケーションセキュリティのデータセットを作り上げるために、（何名かの匿名の提供者とともに）以下の組織には 50,000 を超えるアプリケーションに関するデータを提供いただきました。 これは皆様のご協力なくしては成し得ませんでした。 - AppSec Labs - Cobalt.io - Contrast Security - GitLab - HackerOne - HCL Technologies - Micro Focus - PenTest-Tools - Probely - Sqreen - Veracode - WhiteHat (NTT) ## スポンサーへの謝辞 [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs Pt BR Index (`2021/docs/pt-BR/index.md`) # Introdução ## Bem-vindo ao OWASP Top 10 - 2021 {: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 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 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 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 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? 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? 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? 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 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 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 A equipe OWASP Top 10 2021 agradece o apoio financeiro do Secure Code Warrior e Just Eat. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs Tr Index (`2021/docs/tr/index.md`) # Giriş ## OWASP Top 10 - 2021’e Hoş Geldiniz {\: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 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](A01_2021-Broken_Access_Control.md)** 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](A02_2021-Cryptographic_Failures.md)** 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](A03_2021-Injection.md)** üçü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](A04_2021-Insecure_Design.md)** 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](A05_2021-Security_Misconfiguration.md)** ö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](A06_2021-Vulnerable_and_Outdated_Components.md)** ö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](A07_2021-Identification_and_Authentication_Failures.md)** ö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](A08_2021-Software_and_Data_Integrity_Failures.md)** 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](A09_2021-Security_Logging_and_Monitoring_Failures.md)** ö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](A10_2021-Server-Side_Request_Forgery_%28SSRF%29.md)** 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 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ı 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 neden*e odaklanmaya karar verdik; çünkü tanımlama ve iyileştirme rehberi sağlamak açısından daha mantıklı. *Kök neden*e 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ı 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? 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ı? Üç 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? 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 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 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 OWASP Top 10 2021 ekibi, Secure Code Warrior ve Just Eat’in finansal desteğini minnetle kabul eder. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs Zh Hant Index (`2021/docs/zh-Hant/index.md`) # OWASP Top 10 2021 介紹 欢迎來到最新版本的 OWASP Top 10！! OWASP Top 10 2021 是一个全新的名单，包含了你可以打印下來的新图示说明，若有需要的话，你可以从我们的网页上面下载。 在此我们想对所有贡献了他们时间和资料的人給予极大的感谢。没有你们，这一个新版本不会产生。**谢谢**。 ## Top 10 for 2021 有什么新的变化？ 这次在 OWASP Top 10 for 2021 有三个全新的分类，有四个分类有做名称和范围的修正，并有将一些类别做合并。 Mapping of the relationship between the Top 10 2017 and the new Top 10 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-服务器端请求伪造** 这个类別是在业界问卷排名第一名，并在此版本內纳入。由资料显示此问题有较低被验测次数和范围，但有高于平均的威胁及影响权重比率。这个类別的出现也是因为业界专家重复申明这类別的问题相当重要，即使在本次资料中并沒有足够的资料去显示这个问题。 ## 分析方法 本次 Top 10 的选择方式比以往更重视资料分析，但并不是完全以资料分析为主。我们从资料分析中挑选了八个风险类別，然后由业界问卷中挑选两个风险类別。我们从过往的分享资料中去了解，并有我们一个基本的理由。原因是所有的资安研究人员都不断的在找新的弱点并找出方法去验证弱点，但会需要时间才能将这些验测方法纳入到既有的工具和测试流程中。当我们能有效的大量测试这个弱点时，有可能已经过了多年的时间。为了要让两者之间有平衡，我们使用业界问卷请教在前线的资安研究专家们并了解他们觉得有哪些是他们觉得严重但尚未出现在测试资料中的漏洞及问题。 这是几个我们为了要让 OWASP Top 10 更加成熟的重要改变。 ### 如何建构风险类別 有別于上一个版本，在这次的 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。 ### 选择类別时资料的使用方式 在 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 对应到资料中，然后将他的漏洞和引想力分数使用在另一半的风险公式中。 ## 为什么就不纯粹做统计分析？ 这些资料的結果最主要是被限制在能使用自动工具测试出來的結果。可是当你跟一位有经验的应用程式安全专家聊的时候，他们会跟你说绝大多数他们找到的问题都不在这些资料里面。原因是一个测试要被自动化的时候，需要花时间去开发这些弱点测试的方法论，当你需要将这个测试自动化并能对大量的应用程式去验证时，又会花上更多的时间。当我们回头看去年或以前有可能沒出现的一些问题的趋势，我们发现其实都沒有在这些资料当中。 因此，由于资料不完全的关系，我们只有从资料中选出 8 个类別，而并不是 10 个。剩下的两个类別是从业界问卷中所选出的。这会允许在前线的參与者去选出他们认为的高风险，而不是纯粹依据资料去判断（甚至可能资料永远都不会有出现的踪跡）。 ## 为什么用事故率而不是用发生次数 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? 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](https://owasp.org/www-project-top-ten/#div-data_2020), we list the data elements and structure we are looking for and how to submit them. In the [GitHub project](https://github.com/OWASP/Top10/tree/master/2021/Data), 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 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 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. Diagram Description automatically generated 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. | | | | | | :---------------: | :--------------: | :-----------: | :------------: | | AppSec Labs | GitLab | Micro Focus | Sqreen | | Cobalt.io | HackerOne | PenTest-Tools | Veracode | | Contrast Security | HCL Technologies | Probely | WhiteHat (NTT) | ## Thank you to our sponsors The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior and Just Eat. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs Zh TW Index (`2021/docs/zh-TW/index.md`) # OWASP Top 10 2021 介紹 歡迎來到最新版本的 OWASP Top 10！! OWASP Top 10 2021 是一個全新的名單，包含了你可以列印下來的新圖示說明，若有需要的話，你可以從我們的網頁上面下載。 在此我們想對所有貢獻了他們時間和資料的人給予一個極大的感謝。沒有你們，這一個新版本是不會出現的。**謝謝**。 ## Top 10 for 2021 有什麼新的變化？ 這次在 OWASP Top 10 for 2021 有三個全新的分類，有四個分類有做名稱和範圍的修正，並有將一些類別做合併。 Mapping of the relationship between the Top 10 2017 and the new Top 10 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-伺服端請求偽造** 這個類別是在業界問卷排名第一名，並在此版本內納入。由資料顯示此問題有較低被驗測次數和範圍，但有高於平均的威脅及影響權重比率。這個類別的出現也是因為業界專家重複申明這類別的問題相當重要，即使在本次資料中並沒有足夠的資料去顯示這個問題。 ## 分析方法 本次 Top 10 的選擇方式比以往更重視資料分析，但並不是完全以資料分析為主。我們從資料分析中挑選了八個風險類別，然後由業界問卷中挑選兩個風險類別。我們從過往的分享資料中去瞭解，並有我們一個基本的理由。原因是所有的資安研究人員都不斷的在找新的弱點並找出方法去驗證弱點，但會需要時間才能將這些驗測方法納入到既有的工具和測試流程中。當我們能有效的大量測試這個弱點時，有可能已經過了多年的時間。為了要讓兩者之間有平衡，我們使用業界問卷請教在前線的資安研究專家們並瞭解他們覺得有哪些是他們覺得嚴重但尚未出現在測試資料中的漏洞及問題。 這是幾個我們為了要讓 OWASP Top 10 更加成熟的重要改變。 ### 如何建構風險類別 有別於上一個版本，在這次的 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。 ### 選擇類別時資料的使用方式 在 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 對應到資料中，然後將他的漏洞和引想力分數使用在另一半的風險公式中。 ## 為什麼就不純粹做統計分析？ 這些資料的結果最主要是被限制在能使用自動工具測試出來的結果。可是當你跟一位有經驗的應用程式安全專家聊的時候，他們會跟你說絕大多數他們找到的問題都不在這些資料裡面。原因是一個測試要被自動化的時候，需要花時間去開發這些弱點測試的方法論，當你需要將這個測試自動化並能對大量的應用程式去驗證時，又會花上更多的時間。當我們回頭看去年獲以前有可能沒出現的一些問題的趨勢，我們發現其實都沒有在這些資料當中。 因此，由於資料不完全的關係，我們只有從資料中選出 8 個類別，而並不是 10 個。剩下的兩個類別是從業界問卷中所選出的。這會允許在前線的參與者去選出他們認為的高風險，而不是純粹依據資料去判斷（甚至可能資料永遠都不會有出現的蹤跡）。 ## 為什麼用事故率而不是用發生次數 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? 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](https://owasp.org/www-project-top-ten/#div-data_2020), we list the data elements and structure we are looking for and how to submit them. In the [GitHub project](https://github.com/OWASP/Top10/tree/master/2021/Data), 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 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 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. Diagram Description automatically generated 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. | | | | | | :---: | :---: | :---: | :---: | | AppSec Labs | GitLab | Micro Focus | Sqreen | | Cobalt.io | HackerOne | PenTest-Tools | Veracode | | Contrast Security | HCL Technologies | Probely | WhiteHat (NTT) | ## Thank you to our sponsors The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior and Just Eat. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2025 Docs Cs Index (`2025/docs/cs/index.md`) # 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í 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 [Hlavní stránka projektu](https://github.com/OWASP/www-project-top-ten) obsahuje informace o starších verzích a metadata o tomto projektu. ## Začínáme Začněte [Úvodem](0x00_2025-Introduction.md) kde se dozvíte, co je ve verzi 2025 nového. ## Navigace - [Úvod](0x00_2025-Introduction.md) - [O OWASP](0x01_2025-About_OWASP.md) - [Co jsou bezpečnostní rizika aplikací??](0x02_2025-What_are_Application_Security_Risks.md) - [Zavedení moderního programu bezpečnosti aplikací](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) ### Top 10:2025 List 1. [A01:2025 - Narušené řízení přístupu (Broken Access Control)](A01_2025-Broken_Access_Control.md) 2. [A02:2025 - Chybná bezpečnostní konfigurace (Security Misconfiguration)](A02_2025-Security_Misconfiguration.md) 3. [A03:2025 - Selhání dodavatelského řetězce softwaru (Software Supply Chain Failures)](A03_2025-Software_Supply_Chain_Failures.md) 4. [A04:2025 - Kryptografická selhání (Cryptographic Failures)](A04_2025-Cryptographic_Failures.md) 5. [A05:2025 - Injekce (Injection)](A05_2025-Injection.md) 6. [A06:2025 - Nezabezpečený návrh (Insecure Design)](A06_2025-Insecure_Design.md) 7. [A07:2025 - Selhání autentizace (Authentication Failures)](A07_2025-Authentication_Failures.md) 8. [A08:2025 - Selhání integrity softwaru nebo dat (Software or Data Integrity Failures)](A08_2025-Software_or_Data_Integrity_Failures.md) 9. [A09:2025 - Selhání bezpečnostního logování a upozorňování (Security Logging & Alerting Failures)](A09_2025-Security_Logging_and_Alerting_Failures.md) 10. [A10:2025 - Nesprávné zpracování výjimečných stavů (Mishandling of Exceptional Conditions)](A10_2025-Mishandling_of_Exceptional_Conditions.md) --- **Poznámka:** Překlady budou doplňovány, jakmile budou k dispozici. --- ### 2025 Docs De Index (`2025/docs/de/index.md`) # 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 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 Auf der [Hauptseite des Projekts](https://github.com/OWASP/www-project-top-ten) finden Sie Informationen zu älteren Versionen sowie Metadaten zu diesem Projekt. ## Erste Schritte Beginnen Sie mit der [Einführung](0x00_2025-Introduction.md), um mehr über die Neuerungen in der Version 2025 zu erfahren. ## Navigation - [Einführung](0x00_2025-Introduction.md) - [Über OWASP](0x01_2025-About_OWASP.md) - [Was sind Sicherheitsrisiken für die Anwendungen?](0x02_2025-What_are_Application_Security_Risks.md) - [Aufbau eines modernen Programms zur Anwendungssicherheit](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) ### Liste der Top 10:2025 1. [A01:2025 - Mangelhafte Zugriffskontrolle](A01_2025-Broken_Access_Control.md) 2. [A02:2025 - Sicherheitsrelevante Fehlkonfiguration](A02_2025-Security_Misconfiguration.md) 3. [A03:2025 - Schwachstellen in der Software-Lieferkette](A03_2025-Software_Supply_Chain_Failures.md) 4. [A04:2025 - Fehlerhafter Einsatz von Kryptografie](A04_2025-Cryptographic_Failures.md) 5. [A05:2025 - Injection](A05_2025-Injection.md) 6. [A06:2025 - Unsicheres Design](A06_2025-Insecure_Design.md) 7. [A07:2025 - Fehlerhafte Authentifizierung](A07_2025-Authentication_Failures.md) 8. [A08:2025 - Fehler bei der Software- oder Datenintegrität](A08_2025-Software_or_Data_Integrity_Failures.md) 9. [A09:2025 - Unzureichendes Sicherheitslogging und Alarmierung](A09_2025-Security_Logging_and_Alerting_Failures.md) 10. [A10:2025 - Fehlerhafte Behandlung von Ausnahmezuständen](A10_2025-Mishandling_of_Exceptional_Conditions.md) --- ### 2025 Docs En Index (`2025/docs/en/index.md`) # 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 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 The [main project page](https://github.com/OWASP/www-project-top-ten) has information about older versions and metadata about this project. ## Getting Started Start with the [Introduction](0x00_2025-Introduction.md) to learn about what's new in the 2025 version. ## Navigation - [Introduction](0x00_2025-Introduction.md) - [About OWASP](0x01_2025-About_OWASP.md) - [What are Application Security Risks?](0x02_2025-What_are_Application_Security_Risks.md) - [Establishing a Modern Application Security Program](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) ### Top 10:2025 List 1. [A01:2025 - Broken Access Control](A01_2025-Broken_Access_Control.md) 2. [A02:2025 - Security Misconfiguration](A02_2025-Security_Misconfiguration.md) 3. [A03:2025 - Software Supply Chain Failures](A03_2025-Software_Supply_Chain_Failures.md) 4. [A04:2025 - Cryptographic Failures](A04_2025-Cryptographic_Failures.md) 5. [A05:2025 - Injection](A05_2025-Injection.md) 6. [A06:2025 - Insecure Design](A06_2025-Insecure_Design.md) 7. [A07:2025 - Authentication Failures](A07_2025-Authentication_Failures.md) 8. [A08:2025 - Software or Data Integrity Failures](A08_2025-Software_or_Data_Integrity_Failures.md) 9. [A09:2025 - Security Logging and Alerting Failures](A09_2025-Security_Logging_and_Alerting_Failures.md) 10. [A10:2025 - Mishandling of Exceptional Conditions](A10_2025-Mishandling_of_Exceptional_Conditions.md) --- **Note:** Translations will be added as they become available. --- ### 2025 Docs Es Index (`2025/docs/es/index.md`) # 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 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 La [página principal del proyecto](https://github.com/OWASP/www-project-top-ten) contiene información sobre versiones anteriores y metadatos sobre este proyecto. ## Primeros pasos Comience con la [Introducción](0x00_2025-Introduction.md) para conocer las novedades de la versión 2025. ## Navegación - [Introducción](0x00_2025-Introduction.md) - [Sobre OWASP](0x01_2025-About_OWASP.md) - [¿Qué son los riesgos de seguridad de las aplicaciones?](0x02_2025-What_are_Application_Security_Risks.md) - [Establecimiento de un programa moderno de seguridad de aplicaciones](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) ### Lista Top 10:2025 1. [A01:2025 - Pérdida de Control de Acceso](A01_2025-Broken_Access_Control.md) 2. [A02:2025 - Configuración de Seguridad Incorrecta](A02_2025-Security_Misconfiguration.md) 3. [A03:2025 - Fallas en la Cadena de Suministro de Software](A03_2025-Software_Supply_Chain_Failures.md) 4. [A04:2025 - Fallas Criptográficas](A04_2025-Cryptographic_Failures.md) 5. [A05:2025 - Inyección](A05_2025-Injection.md) 6. [A06:2025 - Diseño Inseguro](A06_2025-Insecure_Design.md) 7. [A07:2025 - Fallas de Autenticación](A07_2025-Authentication_Failures.md) 8. [A08:2025 - Fallas en la Integridad del Software o de los Datos](A08_2025-Software_or_Data_Integrity_Failures.md) 9. [A09:2025 - Fallas en el Registro, Alerta y Monitoreo de Seguridad](A09_2025-Security_Logging_and_Alerting_Failures.md) 10. [A10:2025 - Manejo Inadecuado de Condiciones Excepcionales](A10_2025-Mishandling_of_Exceptional_Conditions.md) --- **Nota:** Las traducciones se añadirán a medida que estén disponibles. --- ### 2025 Docs It Index (`2025/docs/it/index.md`) # 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 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 La [pagina principale del progetto](https://github.com/OWASP/www-project-top-ten) contiene informazioni sulle versioni precedenti e metadati su questo progetto. ## Per iniziare Inizia dall'[Introduzione](0x00_2025-Introduction.md) per scoprire le novità della versione 2025. ## Navigazione - [Introduzione](0x00_2025-Introduction.md) - [Informazioni su OWASP](0x01_2025-About_OWASP.md) - [Cosa sono i Rischi di Sicurezza delle Applicazioni?](0x02_2025-What_are_Application_Security_Risks.md) - [Stabilire un Programma Moderno di Sicurezza Applicativa](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) ### Lista Top 10:2025 1. [A01:2025 - Broken Access Control](A01_2025-Broken_Access_Control.md) 2. [A02:2025 - Security Misconfiguration](A02_2025-Security_Misconfiguration.md) 3. [A03:2025 - Software Supply Chain Failures](A03_2025-Software_Supply_Chain_Failures.md) 4. [A04:2025 - Cryptographic Failures](A04_2025-Cryptographic_Failures.md) 5. [A05:2025 - Injection](A05_2025-Injection.md) 6. [A06:2025 - Insecure Design](A06_2025-Insecure_Design.md) 7. [A07:2025 - Authentication Failures](A07_2025-Authentication_Failures.md) 8. [A08:2025 - Software or Data Integrity Failures](A08_2025-Software_or_Data_Integrity_Failures.md) 9. [A09:2025 - Security Logging and Alerting Failures](A09_2025-Security_Logging_and_Alerting_Failures.md) 10. [A10:2025 - Mishandling of Exceptional Conditions](A10_2025-Mishandling_of_Exceptional_Conditions.md) --- **Nota:** Le traduzioni verranno aggiunte man mano che saranno disponibili. --- ### 2025 Docs Ja Index (`2025/docs/ja/index.md`) # OWASP Top 10:2025 OWASP Top 10:2025 リリースへようこそ。 OWASP Top 10 は、開発者やウェブアプリケーションセキュリティに関わる人々のための、標準的な啓発資料 (Awareness document) です。これは、ウェブアプリケーションに対する最も深刻なセキュリティリスクについて、広く認められた見解を表しています。 ## 本リリースについて (About This Release) これは OWASP Top 10 の **2025年** 版です。このバージョンには、最新のデータとセキュリティ動向に基づいた更新が含まれています。 ## メインプロジェクトページ (Main Project Page) [メインプロジェクトページ (GitHub)](https://github.com/OWASP/www-project-top-ten) には、旧バージョンに関する情報や、本プロジェクトのメタデータが掲載されています。 ## はじめに (Getting Started) [イントロダクション (Introduction)](0x00_2025-Introduction.md) から、2025年版での新要素について確認してください。 ## ナビゲーション (Navigation) - [イントロダクション (Introduction)](0x00_2025-Introduction.md) - [OWASP について (About OWASP)](0x01_2025-About_OWASP.md) - [アプリケーションセキュリティリスクとは何か？ (What are Application Security Risks?)](0x02_2025-What_are_Application_Security_Risks.md) - [今日求められるアプリケーションセキュリティプログラムの確立 (Establishing a Modern Application Security Program)](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) ### Top 10:2025 リスト (Top 10:2025 List) 1. [A01:2025 - アクセス制御の不備 (Broken Access Control)](A01_2025-Broken_Access_Control.md) 2. [A02:2025 - セキュリティ設定の不備 (Security Misconfiguration)](A02_2025-Security_Misconfiguration.md) 3. [A03:2025 - ソフトウェアサプライチェーンの不備 (Software Supply Chain Failures)](A03_2025-Software_Supply_Chain_Failures.md) 4. [A04:2025 - 暗号化の不備 (Cryptographic Failures)](A04_2025-Cryptographic_Failures.md) 5. [A05:2025 - インジェクション (Injection)](A05_2025-Injection.md) 6. [A06:2025 - 安全性を欠いた設計 (Insecure Design)](A06_2025-Insecure_Design.md) 7. [A07:2025 - 認証の不備 (Authentication Failures)](A07_2025-Authentication_Failures.md) 8. [A08:2025 - ソフトウェアまたはデータの完全性の不備 (Software or Data Integrity Failures)](A08_2025-Software_or_Data_Integrity_Failures.md) 9. [A09:2025 - セキュリティログとアラートの不備 (Security Logging and Alerting Failures)](A09_2025-Security_Logging_and_Alerting_Failures.md) 10. [A10:2025 - 例外的な状況への不適切な対応 (Mishandling of Exceptional Conditions)](A10_2025-Mishandling_of_Exceptional_Conditions.md) --- **注記：** 翻訳版は、利用可能になり次第随時追加されます。 --- ### 2025 Docs Ko Index (`2025/docs/ko/index.md`) # OWASP Top 10:2025 OWASP Top 10:2025 버전에 오신 것을 환영합니다. OWASP Top 10은 개발자와 웹 애플리케이션 보안을 위한 인식 제고용 자료이며, 웹 애플리케이션의 가장 중대한 보안 위험에 대한 업계의 폭넓은 합의를 반영한다. ## 이번 버전 소개 이 문서는 OWASP Top 10의 2025년 버전이다. 최신 데이터와 보안 동향을 반영하여 업데이트되었다. ## 메인 프로젝트 페이지 [메인 프로젝트 페이지](https://github.com/OWASP/www-project-top-ten)에는 과거 자료를 포함한, 해당 프로젝트의 메타데이터가 정리되어 있다. ## 시작하기 2025년 버전에서 변경되거나 추가된 내용을 파악하려면 [소개](0x00_2025-Introduction.md) 페이지를 획인하라. ## 목차 - [소개](0x00_2025-Introduction.md) - [OWASP 소개](0x01_2025-About_OWASP.md) - [애플리케이션 보안 위험이란 무엇인가?](0x02_2025-What_are_Application_Security_Risks.md) - [현대적 애플리케이션 보안 체계 수립](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) ### Top 10:2025 목록 1. [A01:2025 - 충분한 접근 제어](A01_2025-Broken_Access_Control.md) 2. [A02:2025 - 보안 설정 오류](A02_2025-Security_Misconfiguration.md) 3. [A03:2025 - 소프트웨어 공급망 실패](A03_2025-Software_Supply_Chain_Failures.md) 4. [A04:2025 - 암호 체계 실패](A04_2025-Cryptographic_Failures.md) 5. [A05:2025 - 인젝션](A05_2025-Injection.md) 6. [A06:2025 - 안전하지 않은 설계](A06_2025-Insecure_Design.md) 7. [A07:2025 - 인증 실패](A07_2025-Authentication_Failures.md) 8. [A08:2025 - 소프트웨어 또는 데이터 무결성 실패](A08_2025-Software_or_Data_Integrity_Failures.md) 9. [A09:2025 - 보안 로깅 및 알림 실패](A09_2025-Security_Logging_and_Alerting_Failures.md) 10. [A10:2025 - 부적절한 예외 처리](A10_2025-Mishandling_of_Exceptional_Conditions.md) --- **참고:** 번역은 준비되는 대로 순차적으로 추가될 예정이다. --- ### 2025 Docs Pt BR Index (`2025/docs/pt-BR/index.md`) # 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 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 A [página principal do projeto](https://github.com/OWASP/www-project-top-ten) contém informações sobre versões anteriores e metadados sobre este projeto. ## Primeiros Passos Comece pela [Introdução](0x00_2025-Introduction.md) para saber o que há de novo na versão 2025. ## Navegação - [Introdução](0x00_2025-Introduction.md) - [Sobre a OWASP](0x01_2025-About_OWASP.md) - [O que são Riscos de Segurança de Aplicações?](0x02_2025-What_are_Application_Security_Risks.md) - [Estabelecendo um Programa Moderno de Segurança de Aplicações](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) ### Lista do Top 10:2025 1. [A01:2025 - Controle de Acesso Quebrado](A01_2025-Broken_Access_Control.md) 2. [A02:2025 - Configuração Insegura](A02_2025-Security_Misconfiguration.md) 3. [A03:2025 - Falhas na Cadeia de Suprimentos de Software](A03_2025-Software_Supply_Chain_Failures.md) 4. [A04:2025 - Falhas Criptográficas](A04_2025-Cryptographic_Failures.md) 5. [A05:2025 - Injeção](A05_2025-Injection.md) 6. [A06:2025 - Design Inseguro](A06_2025-Insecure_Design.md) 7. [A07:2025 - Falhas de Autenticação](A07_2025-Authentication_Failures.md) 8. [A08:2025 - Falhas de Integridade de Software ou de Dados](A08_2025-Software_or_Data_Integrity_Failures.md) 9. [A09:2025 - Falhas de Registro e Monitoramento de Segurança](A09_2025-Security_Logging_and_Alerting_Failures.md) 10. [A10:2025 - Tratamento Incorreto de Condições Excepcionais](A10_2025-Mishandling_of_Exceptional_Conditions.md) --- **Nota:** As traduções serão adicionadas conforme estiverem disponíveis. --- ### 2025 Docs Zh Hant Index (`2025/docs/zh-Hant/index.md`) # OWASP Top 10:2025 欢迎阅读 OWASP Top 10:2025 发布版。 OWASP Top 10 是面向开发人员和 Web 应用安全从业者的标准安全意识文档。它代表了业界对 Web 应用最关键安全风险的广泛共识。 ## 关于本次发布 这是 OWASP Top 10 的 **2025** 版本。本版本根据最新数据和安全趋势进行了更新。 ## 主项目页面 [主项目页面](https://github.com/OWASP/www-project-top-ten) 包含旧版本信息以及本项目的元数据。 ## 开始阅读 建议从[引言](0x00_2025-Introduction.md)开始，了解 2025 版本的新变化。 ## 导航 - [引言](0x00_2025-Introduction.md) - [关于 OWASP](0x01_2025-About_OWASP.md) - [什么是应用安全风险？](0x02_2025-What_are_Application_Security_Risks.md) - [建立现代应用安全计划](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) ### Top 10:2025 列表 1. [A01:2025 - 失效的访问控制](A01_2025-Broken_Access_Control.md) 2. [A02:2025 - 安全配置错误](A02_2025-Security_Misconfiguration.md) 3. [A03:2025 - 软件供应链失效](A03_2025-Software_Supply_Chain_Failures.md) 4. [A04:2025 - 加密机制失效](A04_2025-Cryptographic_Failures.md) 5. [A05:2025 - 注入](A05_2025-Injection.md) 6. [A06:2025 - 不安全设计](A06_2025-Insecure_Design.md) 7. [A07:2025 - 认证失效](A07_2025-Authentication_Failures.md) 8. [A08:2025 - 软件或数据完整性失效](A08_2025-Software_or_Data_Integrity_Failures.md) 9. [A09:2025 - 安全日志和告警失效](A09_2025-Security_Logging_and_Alerting_Failures.md) 10. [A10:2025 - 异常条件处理不当](A10_2025-Mishandling_of_Exceptional_Conditions.md) --- **注意：** 翻译会在可用时逐步加入。 --- ### Osib Docs A00 2021 Introduction (`osib/docs/A00_2021_Introduction.md`) --- source: "https://owasp.org/Top10/A00_2021_Introduction/" title: "A00_2021_Introduction" id: "introduction" lang: "en" --- {%- 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 {: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 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](A01_2021-Broken_Access_Control.md)** 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](A02_2021-Cryptographic_Failures.md)** 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](A03_2021-Injection.md)** 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](A04_2021-Insecure_Design.md)** 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](A05_2021-Security_Misconfiguration.md)** 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](A06_2021-Vulnerable_and_Outdated_Components.md)** 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](A07_2021-Identification_and_Authentication_Failures.md)** 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](A08_2021-Software_and_Data_Integrity_Failures.md)** 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](A09_2021-Security_Logging_and_Monitoring_Failures.md)** 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](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** 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 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 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](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** to 40 CWEs in **[A04:2021-Insecure Design](A04_2021-Insecure_Design.md)**. 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 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? 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? 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? 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 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 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 The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior and Just Eat. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### Osib Docs A01 2021 Broken Access Control (`osib/docs/A01_2021-Broken_Access_Control.md`) --- source: "https://owasp.org/Top10/A01_2021-Broken_Access_Control/" title: "A01:2021 – Broken Access Control" id: "A01:2021" lang: "en" --- {%- 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) }} | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 34 | 55.97% | 3.81% | 6.92 | 5.93 | 94.55% | 47.72% | 318,487 | 19,013 | ## Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} 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) }} 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) }} 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) }} **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) }} - {{ 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) }} - {{ 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`) --- source: "https://owasp.org/Top10/A02_2021-Cryptographic_Failures/" title: "A02:2021 – Cryptographic Failures" id: "A02:2021" lang: "en" --- {%- 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) }} | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 29 | 46.44% | 4.49% |7.29 | 6.81 | 79.33% | 34.85% | 233,788 | 3,075 | ## Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} 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) }} 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) }} 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) }} **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) }} - {{ 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) }} - {{ 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`) --- source: "https://owasp.org/Top10/A03_2021-Injection/" title: "A03:2021 – Injection" id: "A03:2021" lang: "en" --- {%- 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) }} | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 33 | 19.09% | 3.37% | 7.25 | 7.15 | 94.04% | 47.90% | 274,228 | 32,078 | ## Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} 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) }} 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) }} 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) }} **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) }} - {{ 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) }} - {{ 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`) --- source: "https://owasp.org/Top10/A04_2021-Insecure_Design/" title: "A04:2021 – Insecure Design" id: "A04:2021" lang: "en" --- {%- 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) }} | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 40 | 24.19% | 3.00% | 6.46 | 6.78 | 77.25% | 42.51% | 262,407 | 2,691 | ## Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} 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) }} 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 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 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 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)](https://owaspsamm.org) 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) }} - 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) }} **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) }} - {{ 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) }} - {{ 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`) --- source: "https://owasp.org/Top10/A05_2021-Security_Misconfiguration/" title: "A05:2021 – Security Misconfiguration" id: "A05:2021" lang: "en" --- {%- 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) }} | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 20 | 19.84% | 4.51% | 8.12 | 6.56 | 89.58% | 44.84% | 208,387 | 789 | ## Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} 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) }} 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](A06_2021-Vulnerable_and_Outdated_Components.md)). 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) }} 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](A06_2021-Vulnerable_and_Outdated_Components.md)). 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) }} **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) }} - {{ 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) }} - {{ 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`) --- source: "https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/" title: "A06:2021 – Vulnerable and Outdated Components" id: "A06:2021" lang: "en" --- {%- 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) }} | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Max Coverage | Avg Coverage | Avg Weighted Exploit | Avg Weighted Impact | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 3 | 27.96% | 8.77% | 51.78% | 22.47% | 5.00 | 5.00 | 30,457 | 0 | ## Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} 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) }} 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](A05_2021-Security_Misconfiguration.md)). ## 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) }} 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) }} **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) }} - {{ 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) }} - {{ 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`) --- source: "https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/" title: "A07:2021 – Identification and Authentication Failures" id: "A07:2021" lang: "en" --- {%- 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) }} | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 22 | 14.84% | 2.55% | 7.40 | 6.50 | 79.51% | 45.72% | 132,195 | 3,897 | ## Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} 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) }} 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](A02_2021-Cryptographic_Failures.md)). - 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) }} - 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) }} **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) }} - {{ 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) }} - {{ 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`) --- 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" --- {%- 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) }} | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 10 | 16.67% | 2.05% | 6.94 | 7.94 | 75.04% | 45.35% | 47,972 | 1,152 | ## Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} 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) }} 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) }} - 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) }} **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) }} - {{ 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) }} - {{ 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`) --- 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" --- {%- 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) }} | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 4 | 19.23% | 6.51% | 6.87 | 4.99 | 53.67% | 39.97% | 53,615 | 242 | ## Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} 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) }} 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](A01_2021-Broken_Access_Control.md)). ## 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) }} 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) }} **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) }} - {{ 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) }} - {{ 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`) --- 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" --- {%- 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) }} | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 1 | 2.72% | 2.72% | 8.28 | 6.72 | 67.72% | 67.72% | 9,503 | 385 | ## Overview {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Overview", lang=lang, source=source ~ "#" ~ id, parent=osib) }} 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) }} 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) }} Developers can prevent SSRF by implementing some or all the following defense in depth controls: ### **From Network layer** - 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](A09_2021-Security_Logging_and_Monitoring_Failures.md)). ### **From Application layer:** - 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:** - 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) }} 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) }} - {{ 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) }} - {{ osib_link(link="osib.mitre.cwe.0.918", doc="", osib=osib) }} --- ### Osib Docs A11 2021 Next Steps (`osib/docs/A11_2021-Next_Steps.md`) --- source: "https://owasp.org/Top10/A11_2021-Next_Steps.md/" title: "A11:2021 – Next Steps" id: "A11:2021" lang: "en" --- {%- 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 | CWEs Mapped  | Max Incidence Rate  | Avg Incidence Rate  | Avg Weighted Exploit  | Avg Weighted Impact  | Max Coverage  | Avg Coverage  | Total Occurrences  | Total CVEs  | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 38 | 49.46% | 2.22% | 7.1 | 6.7 | 60.85% | 23.42% | 101736 | 7564 | - **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 | CWEs Mapped  | Max Incidence Rate  | Avg Incidence Rate  | Avg Weighted Exploit  | Avg Weighted Impact  | Max Coverage  | Avg Coverage  | Total Occurrences  | Total CVEs  | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 8 | 17.54% | 4.89% | 8.3 | 5.9 | 79.58% | 33.26% | 66985 | 973 | - **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 | CWEs Mapped  | Max Incidence Rate  | Avg Incidence Rate  | Avg Weighted Exploit  | Avg Weighted Impact  | Max Coverage  | Avg Coverage  | Total Occurrences  | Total CVEs  | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 14 | 7.03% | 1.16% | 6.7 | 8.1 | 56.06% | 31.74% | 26576 | 16184 | - **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`) # الاصدار 24th September 2021 ## المؤلفون الرئيسيون - [Andrew van der Stock](mailto:vanderaj@owasp.org) (twitter: [@vanderaj](https://x.com/vanderaj)) - [Brian Glas](mailto:brian.glas@owasp.org) (twitter: [@infosecdad](https://x.com/infosecdad)) - [Neil Smithline](mailto:neil.smithline@owasp.org) (twitter: [@appsecneil](https://x.com/appsecneil)) - [Torsten Gigler](mailto:torsten.gigler@owasp.org) (twitter: [@torsten_tweet](https://x.com/torsten_tweet)) ## المساهمين - Orange Tsai [@orange_8361](https://x.com/orange_8361), Author of A10-2021: Server Side Request Forgery - Jim Manico [@manicode](https://x.com/manicode) and Jakub Maćkowski [@kubamackowski](https://x.com/kubamackowski) - OWASP CheatSheets Coordination ## المترجمين - [Malek Aldossary](https://x.com/Malajab), [Mohammed Alsuhaymi](https://x.com/msuhaymi),[Thamer Alshammeri](https://x.com/t44t_), [Yara Eissa Abdu Ajeebi](https://x.com/YE_A1), [Wesal Majeed Alobaidi](https://x.com/Wesal_m6), [Amal Almutairi](http://linkedin.com/in/amal-almutairi-9a617915b), [Noura Abdulmohsen Alsubaie](https://x.com/NouraAlsubaie97), [Mohammed Ibrahem Alsheky](https://www.linkedin.com/in/mohammed-ibrahem-6b088368), [Zainab Hussain Al Hussain](https://x.com/zain303), [FAHAD ALOTAIFEE](https://x.com/fad_777), [Nowayer](https://x.com/_Nowayer_), [Saja Alqurashi](https://x.com/saja_alqurashi), [Raghad Aljabr](http://linkedin.com/in/raghad-aljabr-3b3846124), [Majed alrhyel](https://x.com/1en_majed), [Almaha](https://x.com/emy797kay), [Mohammed AL Busaidi](https://www.linkedin.com/in/mohammed-al-busaidi-124988ab), [Aljohara Alsubaie](http://linkedin.com/in/aljohara-alsubaie-538b3b168), [Rana Gharmallah Alzahrani](http://linkedin.com/in/rana-alzahrani-26447b19b), [Haniya](https://x.com/_______HAA), [Fahdah Alhadayan ](https://www.linkedin.com/in/fahdahmh ), [Ibtisam AlTuraif](https://x.com/EbAlturaif), [Abeer Alwelaie ](https://x.com/abeerp7_), [Nasser bin Hasen ](https://x.com/r00t_nasser), [Mubark Allaghbi](https://x.com/mallaghbi), [Roaa Aljohani](https://www.linkedin.com/in/roaa-aljohani-86824b89) ## كيف تقوم بمساعدتنا في هذه المراحل، نطلب مساعدتك فيما يلي: - علماء البيانات: يرجى مراجعة التحليلات التي قمنا بها. - مصمّمو الويب: نحتاج إلى إنشاء نسخة متوافقة مع الأجهزة المحمولة. - المترجمون: يرجى مراجعة النص باللغة الإنجليزية والتأكد أنه قابل للترجمة. ## طلبات الرفع وتسجيل التذاكر في حال وجود أي مشكلة أو تعديل، يرجى زيارة الرابط التالي: - [https://github.com/OWASP/Top10/issues](https://github.com/OWASP/Top10/issues) --- ### 2021 Docs Ar 0x01 2021 About Owasp (`2021/docs/ar/0x01_2021-about-owasp.md`) # عن أواسب مشروع أمان تطبيق الويب المفتوح أواسب (OWASP) هو مجتمع مفتوح المصدر ويركز على تمكين المؤسسات من تطوير وشراء وصيانة التطبيقات وواجهات برمجة التطبيقات (APIs) التي يمكن الوثوق بها. في أواسب ستجد: - أدوات ومعايير أمان التطبيق - الأبحاث المتطورة - الضوابط الأمنية الأساسية المبنية على افضل السياسات. - كتب كاملة عن اختبار أمن التطبيقات، وتطوير ومراجعة النص البرمجي الآمن. - العروض التقديمية و [مقاطع الفيديو](https://www.youtube.com/user/OWASPGLOBAL) - [Cheat sheets](https://cheatsheetseries.owasp.org/) حول العديد من الموضوعات الشائعة - [اجتماعات المجموعات](https://owasp.org/chapters/) - [الأحداث والتدريب والمؤتمرات](https://owasp.org/events/). - [ مجموعات قوقل ](https://groups.google.com/g/owasp) اعرف المزيد على: [https://owasp.org](https://owasp.org). جميع أدوات أواسب والمستندات ومقاطع الفيديو والعروض التقديمية والفصول مجانية ومفتوحة لأي شخص مهتم بتحسين أمن التطبيقات. نحن ندعو إلى التعامل مع أمن التطبيقات باعتباره مشكلة تتعلق بالأشخاص والسياسات التقنية، لأن الأساليب الأكثر فاعلية لأمن التطبيقات تتطلّب تحسينات في هذه المجالات. أواسب نوع جديد من التنظيم. يسمح لنا بالتحرّر من الضغوط التجارية بتقديم معلومات غير متحيزة وعملية وفعالة من حيث التكلفة حول أمن التطبيقات. أواسب ليست تابعة لأي شركة تقنية، على الرغم من أننا ندعم الاستخدام المستنير لتقنيات الأمن التجارية. تنتج أواسب أنواعًا عديدة من المواد بطريقة تعاونية وشفافة ومنفتحة. مؤسسة أواسب هي كيان غير ربحي والذي يضمن نجاح المشروع على المدى الطويل. كل شخص مرتبط بـ أواسب تقريبًا متطوع، بما في ذلك مجلس أواسب وقادة الفروع وقادة المشروع وأعضاء المشروع. نحن ندعم الأبحاث الأمنية المُبتكرة من خلال المنح والبنية التحتية. ## حقوق النشر والترخيص حقوق النشر © مؤسسة أواسب 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`) # كيف تبدأ برنامج أمن التطبيقات مع أواسب – أعلى عشرة مخاطر في السابق، لم يتم تصميم أواسب – أعلى عشرة مخاطر أبدًا ليكون أساسًا لبرامج أمن التطبيقات. ومع ذلك، من الضروري أن تبدأ من مكانٍ ما، العديد من المؤسسات التي بدأت للتوّ في رحلة أمان التطبيقات الخاصة بها. تُعد أواسب – أعلى عشرة مخاطر لعام 2021 بداية جيّدة كخط أساس لقوائم المراجعة وما إلى ذلك، ولكنها ليست كافية في حد ذاتها. ## المرحلة الأولى: تحديد الثغرات والأهداف الخاصة ببرنامج أمن التطبيقات تحاول العديد من برامج أمن التطبيقات (AppSec) الجري قبل أن تتمكن من الزحف أو المشي. هذه الجهود محكوم عليها بالفشل. نحن نشجّع بشدّة مدراء أمن المعلومات CISOs وكبار مختصّي أمن التطبيقات على استخدام نموذج أواسب لنضج وضمان البرامج [SAMM](https://owaspsamm.org) لتحديد نقاط الضعف ومجالات التحسين على مدى فترة تتراوح ما بين 1-3 سنوات. تتمثّل الخطوة الأولى في تقييم وضعك الحالي، وتحديد الثغرات في الحوكمة والتصميم والتنفيذ والتحقق والعمليات التي تحتاج إلى حلّها على الفور مقابل تلك التي يمكن أن تنتظر، وتحديد أولويات تنفيذ أو تحسين الخمسة عشر لنموذج أواسب لنضج وضمان البرامج (SAMM). يمكن أن يساعدك نموذج أواسب (SAMM) في بناء وقياس التحسينات في البرنامج لضمان الجهود. ## المرحلة الثانية: التخطيط لمفهوم الطريق المُمهد في دورة حياة تطوير البرمجيات بطريقة آمنة تقليديًا، الحفاظ على ما يسمى "أحادي القرن"، مفهوم الطريق المُمهد هو أسهل طريقة لتحقيق أكبر قدر من التأثير وتوسيع نطاق موارد أمن التطبيقات مع سرعة فرق التطوير، والتي تزيد كل عام فقط. يعتبر مفهوم الطريق المُمهد أسهل طريقة وأيضًا الطريقة الأكثر أمانًا، ويجب أن تتضمّن ثقافة الشراكة العميقة بين فريق التطوير والفريق الأمني، ويُفضّل أن يكونا نفس الفريق. يهدف الطريق المُمهد إلى التحسين المُستمر للبدائل الغير آمنة وقياسها واكتشافها واستبدالها من خلال وجود مكتبة على مستوى المؤسسة من البدائل المؤمّنة، مع أدوات للمساعدة في معرفة أين يمكن إجراء التحسينات من خلال اعتماد الطريق المُمهد. يسمح ذلك لأدوات التطوير الحالية بالإبلاغ عن البنيات الغير آمنة ومساعدة فرق التطوير على التصحيح الذاتي بعيدًا عن البدائل الغير آمنة. قد يبدو أن الطريق المُمهد يتطلّب الكثير من الوقت، ولكن يجب أن يتم بناؤه تدريجيًا مع مرور الوقت. هناك أشكال أخرى من برامج أمن التطبيقات، لاسيما دورة حياة التطوير الآمن أجايل مايكروسوفت Microsoft Agile. ليست بالضرورة أن تناسب منهجيّة برنامج أمن التطبيقات كل الأعمال. ## المرحلة الثالثة: تنفيذ مفهوم الطريق الممهد مع فرق التطوير الخاصة بك يتم بناء منهجيّة الطريق المُمهد بالموافقة والمشاركة المباشرة من قبل فرق التطوير والعمليات ذات الصِلة. يجب مواءمة منهجيّة الطريق المُمهد بشكل استراتيجي مع الأعمال والمساعدة في تقديم تطبيقات أكثر أمانًا بشكل أسرع. يجب أن يكون تطوير الطريق المُمهد تمرينًا شاملًا يُغطي النظام البيئي للمؤسسة أو التطبيق بالكامل، وليس أداة مساعدة لكل تطبيق، كما كان في الزمن السابق. ## المرحلة الرابعة: ترحيل جميع التطبيقات الحالية والقادمة إلى منهجية الطريق الممهد أضِف أدوات اكتشاف منهجيّة الطريق المُمهد أثناء تطويرها وقم بتقديم معلومات لفرق التطوير لتحسين أمان تطبيقاتهم من خلال كيفية اعتمادهم المباشر لعناصر مفهوم الطريق المُمهد. وبمجرد اعتماد جانب من جوانب مفهوم الطريق المُمهد، يجب على المؤسسات تنفيذ فحوصات تكامل مستمرة لفحص الشفرة الحالية وعمليات تسجيل الوصول التي تستخدم بدائل محظورة وتحذّر أو تمنع إنشاؤها أو الوصول لها. هذا يمنع الخيارات الغير آمنة من التسلل إلى الشفرة بمرور الوقت، مما يمنع الأعباء التقنية والتطبيق الغير الآمن المُعيب. يجب أن ترتبط هذه التحذيرات بالبديل الآمن، حتى يتم إعطاء فرق التطوير الإجابة الصحيحة على الفور. يمكنهم إعادة بناء واعتماد مكوّن الطريق المُمهد بسرعة. ## المرحلة الخامسة: اختبار مفهوم الطريق المُمهد إن كان قد خفّف من المشاكل الموجودة في أواسب – أعلى عشرة مخاطر يجب أن تعالج مكونات الطريق المُمهد المشاكل الكبيرة في أواسب – أعلى عشرة مخاطر، على سبيل المثال، كيفية اكتشاف أو إصلاح المكونات الضعيفة تلقائيًا، أو مكوّن بيئة تطوير متكاملة IDE لتحليل النص البرمجي الثابت لاكتشاف الحقن أو حتى مكتبة معروفة بأنها آمنة ضد الحقن، مثل مكتبة React أو Vue. كلما زاد عدد هذه البدائل الآمنة التي يتم توفيرها للفرق، كان ذلك أفضل. تتمثّل إحدى المهام الحيوية لفريق "أمان التطبيقات" في التأكد من أن أمان هذه المكونات يتم تقييمه وتحسينه باستمرار. وبمجرد تحسينها، يجب أن يُشير شكل من أشكال مسار الاتصال مع مستخدمي المكوّن إلى أنه يجب إجراء ترقية، ويُفضّل أن يكون ذلك تلقائيًا، وإن لم يكن الأمر كذلك، يجب على الأقل تسليط الضوء على اللوحة الرئيسية للتحكم أو ما شابه ذلك. ## المرحلة السادسة: قم ببناء برنامجك في بيئة برمجية آمنة يجب ألا يقتصر اعتمادك على أواسب- اعلى عشرة مخاطر فقط. فهو يغطي فقط 10 فئات من المخاطر. نحن نشجع المؤسسات بشدة على اعتماد معيار التحقق من أمن التطبيقات وإضافة مكونات منهجية الطرق الممهدة واختبارات المستوى 1 و2 و3 تدريجيًا، اعتمادًا على مستوى مخاطر التطبيقات المطورة. ## الذهاب إلى أبعد من ذلك جميع برامج حماية التطبيقات الرائعة تتجاوز الحد الأدنى، فيجب على الجميع الاستمرار إذا أردنا أن نتغلّب على الثغرات الأمنية للتطبيقات. - **تكامل المفاهيم**. يجب أن تحتوي برامج أمن التطبيقات المتطورة على بعض المفاهيم الخاصة بهندسة الأمن، سواء كانت بنية سحابية رسمية أو بنية أمان مؤسسية أو نمذجة للتهديدات - **الأتمتة والقياس**. تحاول برامج أمن التطبيقات المتطوّرة أتمتة أكبر قدر ممكن من مخرجاتها، باستخدام البرامج النصيّة لمحاكاة خطوات اختبار الاختراق المعقدة، وأدوات تحليل النص البرمجي الثابت المتاح لفرق التطوير، ومساعدة فرق التطوير في بناء وحدة أمن التطبيقات واختبارات التكامل، وغيرها.. - **الثقافة**. تحاول برامج أمن التطبيقات المتطوّرة بناء تصميم غير آمن والقضاء على الديّن التقني للنص البرمجي الحالي من خلال كونها جزءًا من فريق التطوير وليس عملًا جانبيًا. فرق أمن التطبيقات ترى فرق التطوير على أنها "نحن" و "هم" محكوم عليهم بالفشل. - **التحسين المستمر**. تتطلّع البرمجة الآمنة للتطبيقات المتطوّرة إلى التحسين المستمر. إذا كان هناك شيء لا يتحسّن أو يتطوّر، فتوقّف عنه أو إذا كان هناك شيء غير قابل للتطوير، اعمل على تحسينه. إذا لم يتم استخدام شيء من قِبل فرق التطوير ولم يكن له تأثير أو تأثير محدود، فافعل شيئًا مُختلفًا. لمجرد أننا أجرينا اختبارات مثل الفحوصات المكتبية منذ السبعينات لا يعني أنها فكرة جيّدة. قم بالقياس والتقييم ثم البناء أو التحسين المستمر --- ### 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`) # كيف تستخدم إطار أعلى عشرة مخاطر من أواسب كنموذج معياري. يعتبر مشروع (أواسب – أعلى عشرة مخاطر) وثيقة توّعوية، إلا أن ذلك لم يمنع المنظمات من استخدامه معيارًا فعليًا لأمن التطبيقات منذ بداية نشره في عام 2003. إذا كنت ترغب في استخدام (أواسب – أعلى عشرة مخاطر) بصفته معيار ترميز أو اختبار، فاعلم أنه يعتبر الحد الأدنى ونقطة البداية. إحدى صعوبات استخدام (أواسب – أعلى عشرة مخاطر) كمعيار هو أننا نقوم بتوثيق مخاطر أمن التطبيقات، وهي ليست بالضرورة مشاكل قابلة للاختبار بسهولة. على سبيل المثال، A04: 2021- التصميم الغير آمن خارج نطاق معظم نماذج الاختبار. مثال آخر هو الاختبار المعمول به في الاستخدام والتسجيل الفعال والمراقبة لا يمكن أن يتم إلا من خلال المقابلات وطلب عيّنات من الاستجابات الفعالة للحوادث. يمكن لأداة تحليل الرموز البرمجية الثابتة البحث عن عدم وجود السجلات، ولكن قد يكون من المستحيل تحديد ما إذا كان طريقة العمل أو التحكم في الوصول يسجل الانتهاكات الأمنية الخطيرة. قد يتمكن مختبرين الاختراق فقط من تحديد طريقة الاستجابة للحوادث في بيئة العمل التجريبية، والتي نادرًا ما تتم مراقبتها بنفس الطريقة في بيئة العمل الفعلية. فيما يلي توصياتنا لاستخدام (أواسب – أعلى عشرة مخاطر) عندما يكون ذلك متاحًا | حالة الاستخدام | أواسب –أعلى عشرة 2021 | معيار أواسب للتحقق من أمان التطبيق | |------------------------------------|-----------------------|-----------------------------------| | التوعية | نعم | | | التدريب | المستوى الأول | شامل | | التصميم والبنية المعمارية | إلى حدٍ ما | نعم | | معيار النص البرمجي | الحد الأدنى | نعم | | مراجعة النص البرمجي الآمن | الحد الأدنى | نعم | | قائمة التحقق من البرمجيات المشابهه | الحد الأدنى | نعم | | اختبار الوحدة | إلى حدٍ ما | نعم | | اختبار التكامل | إلى حدٍ ما | نعم | | اختبار الاختراق | الحد الأدنى | نعم | | دعم الادوات | الحد الأدنى | نعم | | سلسة التوريد الامنة | إلى حدٍ ما | نعم | نشجّع أي شخص يرغب في اعتماد معيار الأمن للتطبيقات على استخدام معيار أواسب للتحقق من أمن التطبيقات (ASVS)، حيث أنه مُصمّم لكي يمكننا التحقق منه واختباره، ويمكن استخدامه في جميع أجزاء دورة حياة التطوير الآمن. معيار التحقق من أمن التطبيقات (ASVS) هو الخيار الوحيد المقبول لمزودي الأدوات. لا يمكن للأدوات الكشف الشامل أو الاختبار أو الحماية ضد (أواسب – أعلى عشرة مخاطر) نظرًا لطبيعة العديد من مخاطر (أواسب –اعلى عشرة مخاطر )، مع الإشارة إلى A04: 2021-التصميم الغير آمن. لا تتفق أواسب مع أي ادعاءات بالتغطية الكاملة لـ (أواسب – أعلى عشرة مخاطر )، لأنها ببساطة غير صحيحة. --- ### 2021 Docs Ar A00 2021 Introduction (`2021/docs/ar/A00_2021-Introduction.md`) # مقدمة ## مرحباً بكم في أعلى عشرة مخاطر لعام 2021 مرحبًا بكم في أحدث إصدار من أعلى عشرة مخاطر من منظمة أواسب وهي النسخة الحديثة لعام 2021، والتي تأتي بشكل جديد تمامًا ومدعمة برسومات انفوجرافيك التي تستطيع طباعتها واستخدامها ويمكن الحصول عليها من صفحتنا الرئيسية. كما نتقدم بجزيل الشكر والعرفان لكلّ من ساهم بفكرة، أو وقت، أو جهد في سبيل إنجاح هذا العمل، ممتنّون لما بذلتموه، ولما حقّقناه بفضل الله ثم بمساعدتكم ودعمكم.. ## ما هي التغييرات التي طرأت على أعلى عشرة مخاطر لعام 2021 بشكل عام تم إضافة 3 تصنيفات جديدة و 4 تصنيفات ، تم تغيير الاسم وكذلك النطاق الخاص بها، وبعض عمليات الدمج التي تأتي مع أعلى عشرة مخاطر لعام 2021 Mapping of the relationship between the Top 10 2017 and the new Top 10 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. وتظهر البيانات حسب الاختبارات التي تم إجراؤها أن هذا التصنيف معدل الإصابة به فوق المتوسط مع ارتفاع منخفض. ومدى ارتباطه بمعدل التأثير وإمكانية الاستغلال. ويفيد المختصين في المجال أن وجود هذا التصنيف من ضمن المخاطر هو أمر مهم جدًا حتى وإن كانت البيانات الحالية غير مكتملة في الوقت الحالي. ## المنهجية لأول مرة يتم الاعتماد على البيانات في تصنيف أعلى عشرة مخاطر ويجب التنويه أنها لا تعتمد على البيانات بشكل كُلي. حيث تم اختيار ثمانية تصنيفات من أصل عشرة بناءً على البيانات واثنين منهم بناءً على الاستطلاع الذي تم إجراؤه في نطاق المخاطر. وتقوم منظمة أواسب بالاعتماد على البيانات السابقة أكثر من أي مصادر أخرى وذلك بسبب أن الباحثين في أمن التطبيقات يستغرقون وقت وجهد كبير في إيجاد الثغرات أو طرق جديدة لاستغلالها. مما يجعل عملية التحقق من النتائج والأدوات والطرق المستخدمة يستغرق وقت أكبر وقد تصل إلى سنوات. ولتحقيق التوازن قمنا باستخدام استطلاع على المخاطر التي تستهدف صناعة أمن التطبيقات وقمنا بتوجيه أسئلة للمختصّين في نقاط الضعف التي قد لا تظهرها البيانات. وكما أن هناك بعض التغييرات الجوهرية التي تم اعتمادها من قبل منظمة أواسب لمواصلة المنهجية المتّبعة في تصنيف أعلى عشرة مخاطر. ### كيف يتم تنظيم التصنيفات تم تغيير بعض التصنيفات من الإصدار السابق لأعلى عشر مخاطر وهنا ملخص لما تم تغيره على مستوى التصنيفات تركز الجهود المبذولة في جمع البيانات على مجموعات فرعية من 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 واستخدمها كلغة عمل وإطار. ### كيف يتم استخدام البيانات لبعض التصنيفات المختارة في الإصدار السابق لعام 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 في قاعدة البيانات وذلك لاستخدمها لتقييم درجات الأثر والاستغلال والاستفادة منها كذلك في احتساب المخاطر بناء على المعادلة المستخدمة. ## لماذا لا تكون مجرد بيانات إحصائية بحتة؟ تقتصر النتائج بشكل أساسي على ما يمكن اختباره بشكل آلي. وحينما تتحدث إلى أحد المختصّين المحترفين في مجال أمن التطبيقات سيخبرونك أن بعض المخرجات والاحصائيات لا يوجد لها بيانات بعد. ومع ذلك عند إعداد منهجيات الاختبار، تستغرق فترة من الزمن ومن ثم أنت بحاجة إلى المزيد من الوقت لكي تقوم بأتمتة تلك الاختبارات وتشغيلها على مجموعة كبيرة من التطبيقات. ولذلك قمنا باختيار ثمانية تصنيفات من أصل عشرة من البيانات بسبب عدم اكتمال ونضج البيانات، وبالنسبة للتصنيفين المتبقية قمنا بعمل استطلاع في مجال امن التطبيقات. مما يسمح للمختصين بالتصويت لما يرونه من المخاطر التي تستحق أن تضاف إلى قائمة أعلى عشرة مخاطر والتي قد لا يكون لها بيانات أو بيانات غير متناسقة أو غير مناسبة. ## لماذا معدل الحدوث بدلا من التكرار؟ هناك ثلاثة مصادر أساسية للبيانات. نحددها على أنها الانسان يساعد الأدوات (HaT) ، او الأدوات تساعد الإنسان (TaH) ، او الأدوات من غير أي تعديلات. تقوم HaT والأدوات بعمليات اكتشاف على مستوى عالي. حيث ان الأدوات تبحث عن نقاط ضعف محددة مع تجربة جميع الاحتمالات المتوقعة لاكتشاف الثغرة. وعند النظر الى ثغرة XSS والتي بالعادة اما ان تكون منخفضة الخطورة او بسيطة والتي تأتي بسبب أخطاء الأنظمة او أخطاء في عملية التصفية. وعندما تكون الثغرة بسبب خطاء في الأنظمة ترتفع بالنسبة تكرار الاكتشاف لهذه الثغرة والتي من الممكن ان تؤثر على مخرجات التقرير او البيانات. ومن ناحية أخرى، نجد أن TaH أخرجت لنا نطاق واسع من الثغرات ولكن مع تكرار أقل بكثير بسبب ضيق الوقت. وذلك بسبب قيام المختصين بفحص التطبيقات ويرون في بعض الأحيان مثل XSS سيقومون بإيجاد ٣ أو ٤ وبعد ذلك يتوقفون عن البحث عنها وإيجاد سبب الخطأ وكتابة تقرير عنها والتوصيات الممكنة لكي تقوم بإصلاحها والتي ستقوم بإصلاح جميع التطبيقات. وليس هناك حاجة أو وقت للعثور على جميع الثغرات بشكل متكرر. لنفترض أننا أخذنا مجموعتين من البيانات المميّزة والغير متشابهة وحاولنا دمجها على مستوى التكرار. في هذه الحالة سنجد أن البيانات الدقيقة المستخرجة من الأدوات وHaT غير قابلة للملاحظة مع بيانات TaH. وهذا يظهر في بعض الأحيان بشكل إيجابي في بعض الثغرات مثل ثغرة XSS والذي في بعض الأحيان يقوم برفع مستوى التصنيف من منخفض إلى متوسط بسبب العدد الهائل من النتائج. (ثغرات مثل XSS من السهل اختبارها والخروج بنتائج معقولة) في عام 2017 قمنا باستخدام معدّل الحدوث بدلًا من إلقاء نظرة مرة أخرى على البيانات ودمجها بشكل مناسب مع البيانات المستخرجة من الأدوات وHaT و TaH. حيث يكون معدل الحدوث يعتمد على نسبة التطبيقات التي لديها نوع من أنواع الثغرات. وحقيقة نحن في المنظمة لا نهتم في حال كانت الثغرة واحدة معدل حدوثها متكرر. وهدفنا هو معرفة عدد التطبيقات التي لديها ثغرة واحدة على الأقل. وهذا يعطينا تصوّر واضح من نتائج الاختبار والتي تُعتبر لدينا أفضل من إغراق البيانات بتكرار ليس له فائدة. ## ما هي عملية جمع البيانات وتحليلها؟ تم إضفاء الطابع الرسمي على عملية جمع بيانات أعلى عشر مخاطر في قمة Open Security Summit في عام 2017. وبعد ذلك أمضى المسؤولين في منظمة آواسب يومين في العمل على جعل عملية جمع البيانات مبنية على سياسة واضحة وشفافة. تعد نسخة 2021 هي المرة الثانية التي نستخدم فيها هذه المنهجية. قمنا بدعوة للحصول على البيانات من خلال قنوات التواصل الاجتماعي المتاحة لنا، لكلًّا من المشروع و OWASP. وفي [صفحة مشروع OWASP](https://owasp.org/www-project-top-ten/#div-data_2020), نقوم بإدراج عناصر وهيكل البيانات التي نبحث عنها وكيفية إرسالها. وفي [مشروع GitHub](https://github.com/OWASP/Top10/tree/master/2021/Data), لدينا أمثلة لملفات تعمل كقوالب. نعمل مع المنظمات الأخرى حسب الحاجة للمساعدة في تحديد الهيكلورسمه وربطه بـ CWEs. نحصل على البيانات من المؤسسات التي بالاختبارات من خلال المبادلة، ومن خلال منصات اكتشاف الثغرات، والمؤسسات التي تساهم ببياناتها الخاصة بالاختبار الداخلية. وبمجرد حصولنا على البيانات، نقوم بتحميلها معًا ونجري تحليلًا وفهماً عن أساسيًات الربط بـ CWEs لتصنيفات المخاطر. هناك تداخل بين بعض CWEs، بسبب التشابه بينهم (مثل نقاط الضعف في التشفير). حيث يتم توثيق ونشر أي قرارات تتعلق بالبيانات الأولية المقدمة لتكون مفتوحة وواضحة مع كيفية مواءمة البيانات. يتم النظر إلى التصنيفات الثمانية ذات أعلى معدلات حدوث لإدراجها في أعلى عشر مخاطر. وننظر أيضًا في نتائج الاستطلاع في مجال امن التطبيقات لمعرفة في حال وجود أي منها في البيانات. سيتم اختيار أعلى تقييمين غير موجودين بالفعل في البيانات المحللة سابقاً واضفتها الى أعلى عشر مخاطر. بمجرد اختيار جميع العشرة ، يتم تطبيق العوامل التي تم الاتفاق عليها وهي (الاستغلال والتأثير)؛ للمساعدة في ترتيب أعلى عشر مخاطر. ## العوامل المستخدمة مع البيانات هناك عوامل بيانات مدرجة لكل تصنيف من تصنيفات أعلى عشر مخاطر، وإليك ما تعنيه: - *ربط بـ CWEs*: عدد CWEs الذي تم ربطها بواسطة الفريق. - *معدل الحدوث/الحوادث*: معدل الحدوث وهو النسبة المئوية للتطبيقات المعرضة لثغرات ومعرفة مدى ارتباطها بمعيار CWE خلال الاختبارات التي. أجرتها المؤسسات في سنة محددة. - (الاختبارات) *والتغطية*:النسبة المئوية للتطبيقات التي تم اختبارها من قبل جميع المنظمات لـ CWE مُعيّن. - *خطورة الاستغلال*: معرفة الاستغلال و النقاط الفرعية له من CVSSv2 و CVSSv3 والتي لديها CVEs ومرتبطة بـ CWEs، ،موائمتها ، ووضعها على مقياس 10pt. - *التأثير المتوقع*: تأثير النقاط الفرعية من CVSSv2 و CVSSv3 والتي لديها CVEs ومرتبطة بـ CWEs، ،موائمتها ، ووضعها على مقياس 10pt. - *إجمالي التكرار/الحوادث*: إجمالي عدد التطبيقات التي تم ربطها بـ CWEs وتم وضع تصنيف محدد لها. - *إجمالي CVEs*: إجمالي عدد CVEs في NVD DB التي تم ربطها بـ CWEs وتم وضع تصنيف محدد لها. ## علاقات التصنيفات لعام 2021 مع تصنيفات عام 2017 هناك الكثير من الحديث عن التداخل بين المخاطر العشرة الأولى. ومن خلال تعريف كل (القوائم المدرجة في CWEs)، ولكن الذي يظهر لنا أنه لا يوجد أي تداخل فيها ومع ذلك، من الناحية النظرية، يمكن أن يكون هناك تداخل أو تأثر بناءً على التسمية. ونقوم باستخدام مخططات Venn لإظهار التداخل كما ورد في المثال أدناه. Diagram Description automatically generated يمثل مخطط Venn أعلاه الترابط بين التصنيفات في أعلى عشر مخاطر لعام 2017. وأثناء القيام بذلك، أصبحت بضع نقاط أساسية واضحة: 1. كان يُرى بأن هجوم - ثغرات XSS تنتمي في حقيقة الأمر إلى ثغرات الحقن(Injection) لأنها في الأساس عبارة عن حقن المحتوى. بالنظر إلى بيانات عام 2021 ، أصبح من الواضح أن ( XSS )بحاجة إلى الانتقال إلى الحقن(Injection). 2. التداخل فيما بينهم غالبًا يكون في اتجاه واحد. غالبًا ما نصنّف الثغرة من خلال "العَرَض"، وليس السبب الجذري (الذي يحتمل أن يكون عميقًا). على سبيل المثال، قد تكون " البيانات الحساسة المكشوفة " نتيجة "الإعدادات خاطئة الأمان، وفي الغالب لن تراها بالإتجاه المعاكس. نتيجة لذلك، يتم رسم الأسهم في مناطق التأثر للإشارة إلى الإتجاه الذي يحدث فيه. 3. أحيانًا يتم رسم هذه المخططات بشكل كامل كما في *A06: 2021 الثغرات والأنظمة الغير قابلة للتحديث*. في حين أن بعض التصنيفات من هذه المخاطر قد يكون السبب الجذري هي ثغرات من الطرف الثالث، فإنه يتم إدارتها بشكل مختلف ومسؤوليات مختلفة. والمخاطر الأخرى المتبقية تمثّل الطرف الأول. # شكراً لكل من ساهم معنا في جمع هذه البيانات ساهمت المنظمات التالية (جنبًا إلى جنب مع بعض المساهمين-المتبرعين المجهولين) لبيانات لأكثر من 500,000 تطبيق وجعلها هي القائمة الأكبر والأكثر والأشمل من التطبيقات التي تم إجراء اختبارات الأمان عليها وجعلها في قاعدة بيانات. وتأكد أنه من غير اسهاماتك لن يكون هذا ممكن. | | | | | | :---: | :---: | :---: | :---: | | AppSec Labs | GitLab | Micro Focus | Sqreen | | Cobalt.io | HackerOne | PenTest-Tools | Veracode | | Contrast Security | HCL Technologies | Probely | WhiteHat (NTT) | [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs Ar A01 2021 Broken Access Control (`2021/docs/ar/A01_2021-Broken_Access_Control.md`) # A01:2021 – تخطي صلاحيات الوصول ## العوامل | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 34 | 55.97% | 3.81% | 94.55% | 47.72% | 6.92 | 5.93 | 318,487 | 19,013 | ## نظرة عامة صعد هذا المعيار من المركز الخامس في الإصدار السابق إلى الأول في هذا الإصدار بعد اختبار ثغرات "تخطي صلاحيات التحكم بالوصول" على 94% من التطبيقات وقد لوحظ أنها تعاني من نقاط الضعف الشائعة "CWEs” تشمل : CWE-200 و CWE-201 و CWE-352 ## الوصف تفرض صلاحيات التحكم بالوصول سياسات وقوانين مثل ان المستخدم لا يمكنه التصرف خارج نطاق الأذونات الممنوحة له. عادة ما تؤدي هذه الاخطاء الى كشف معلومات غير مصرح بها او التعديل عليها، او تخريب جميع البيانات أو حتى تنفيذ إجراءات خارج صلاحيات المستخدم المسموحة. تتضمن نقاط الضعف الشائعة لصلاحيات التحكم بالوصول: - تجاوز إجراءات **التحقق من التحكم في الوصول** من خلال تعديل محدد فيURL، او تعديل الكائنات “objects” المرتبطة بالبرنامج داخل الذاكرة أو تعديل صفحة الـ HTML، أو ببساطة استخدام أداة هجوم مخصصة لمهاجمة API - السماح بالتبديل بين مفتاح رئيسي “primary key” وسجلات مستخدم آخر “users record”، مما قد يسمح باستعراض أو التعديل على حسابات أخرى - تصعيد الصلاحيات: التصرف كمستخدم من دون تسجيل الدخول او التصرف كمدير عند تسجيل الدخول بصلاحيات كمستخدم. - التلاعب في البيانات الوصفية "meta data” كإعادة إدخال أو التلاعب برمز التوثيق "JSON Web Token (JWT)،" أو التلاعب في ملفات الارتباط أو الحقول المخفية لغرض تصعيد الصلاحيات أو إساءة استخدام الـ JWT - التهيئة الغير صحيحة لـ CORS تسمح بالدخول الغير مصرح به لواجهة برمجة التطبيقات API. - استعراض صفحات "تستلزم المصادقة" عبر مستخدمين "غير مصادق عليهم" أو الوصول الى صفحات ذات امتيازات عليا باستخدام صلاحيات “حساب مستخدم “، أو الوصول الى واجهة برمجة التطبيقات "API” بوجود قصور في "التحكم في صلاحيات الوصول" مما يؤدي الى تنفيذ طلباتPOST، PUT، DELETE. ## كيفية الحماية منها يكون "التحكم بصلاحيات الوصول" فعالا فقط عندما عند تطبيقه على **الشفرة المصدرية** من جهة الخوادم الموثوقة- trusted server-side code، أو الخوادم التي لا تملك واجهة برمجة تطبيقات والتي يطلق عليها (server-less API)، حيث لا يستطيع المهاجم تعديل "صلاحيات التحكم بالوصول" أو التلاعب في البيانات الوصفية. - باستثناء طلبات الوصول "للموارد المتاحة للعامة" يتم حظر جميع الطلبات بشكل افتراضي. - وضع الأليات التي تتحكم بالوصول لمرة واحدة في البرنامج/التطبيق مع إعادة استخدامها -هي نفسها- عند الحاجة، وأيضا تقليل استخدام CORS. - نموذج التحكم بالوصول يجب أن يفرض مُلكية السجل " record ownership" بدلًا من الموافقة على أن المستخدم يستطيع إنشاء، قراءة، تحديث، أو حذف أي سجل. - متطلّبات حدود تطبيقات الأعمال الفريدة من نوعها "Unique application business limit" يجب أن يتم فرضها خلال استخدام نماذج المجال (domain models). - تعطيل استعراض مجلدات خادم الويب والتأكد بأن ملف البيانات الوصفية "Meta Data” وملفات النسخ الاحتياطي لا يتم الوصول اليها من خلال مجلد المسار الرئيسي "Root". - توثيق سجلات فشل التحكم في صلاحيات الوصول وتنبيه المسؤولين عند وقوع هذه الأخطاء. - تقييم حد الوصول إلى واجهة برمجة التطبيقات API ووضع حد لمعدّل الطلبات لتقليل الضرر الناجم عن أدوات الهجوم الآلي. - يجب التخلص من رموز JWT على الخادم بعد تسجيل الخروج. يجب على فرق المطوّرين وموظفين قسم ضمان الجودة "QA" أن تتضمّن وحدة فعالة للتحكم في الوصول وإجراء اختبارات التكامل . ## أمثلة على سيناريوهات الهجوم **سيناريو #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 يعتبر خللا اذا كان يمكن للمستخدم غير المصرح له الوصول الى اي من الصفحتين. يعتبر خللا اذا كان يمكن لغير المسؤول الوصول لصفحة المسؤول. ## المصادر - [OWASP Proactive Controls: Enforce Access Controls](https://owasp.org/www-project-proactive-controls/v3/en/c7-enforce-access-controls) - [OWASP Application Security Verification Standard: V4 Access Control](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: Authorization Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README) - [OWASP Cheat Sheet: Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) - [PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) - [OAuth: Revoking Access](https://www.oauth.com/oauth2-servers/listing-authorizations/revoking-access/) ## قائمة الربط مع إطار CWEs [CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) [CWE-23 Relative Path Traversal](https://cwe.mitre.org/data/definitions/23.html) [CWE-35 Path Traversal: '.../...//'](https://cwe.mitre.org/data/definitions/35.html) [CWE-59 Improper Link Resolution Before File Access ('Link Following')](https://cwe.mitre.org/data/definitions/59.html) [CWE-200 Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html) [CWE-201 Exposure of Sensitive Information Through Sent Data](https://cwe.mitre.org/data/definitions/201.html) [CWE-219 Storage of File with Sensitive Data Under Web Root](https://cwe.mitre.org/data/definitions/219.html) [CWE-264 Permissions, Privileges, and Access Controls (should no longer be used)](https://cwe.mitre.org/data/definitions/264.html) [CWE-275 Permission Issues](https://cwe.mitre.org/data/definitions/275.html) [CWE-276 Incorrect Default Permissions](https://cwe.mitre.org/data/definitions/276.html) [CWE-284 Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) [CWE-285 Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) [CWE-352 Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html) [CWE-359 Exposure of Private Personal Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/359.html) [CWE-377 Insecure Temporary File](https://cwe.mitre.org/data/definitions/377.html) [CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak')](https://cwe.mitre.org/data/definitions/402.html) [CWE-425 Direct Request ('Forced Browsing')](https://cwe.mitre.org/data/definitions/425.html) [CWE-441 Unintended Proxy or Intermediary ('Confused Deputy')](https://cwe.mitre.org/data/definitions/441.html) [CWE-497 Exposure of Sensitive System Information to an Unauthorized Control Sphere](https://cwe.mitre.org/data/definitions/497.html) [CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory](https://cwe.mitre.org/data/definitions/538.html) [CWE-540 Inclusion of Sensitive Information in Source Code](https://cwe.mitre.org/data/definitions/540.html) [CWE-548 Exposure of Information Through Directory Listing](https://cwe.mitre.org/data/definitions/548.html) [CWE-552 Files or Directories Accessible to External Parties](https://cwe.mitre.org/data/definitions/552.html) [CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key](https://cwe.mitre.org/data/definitions/566.html) [CWE-601 URL Redirection to Untrusted Site ('Open Redirect')](https://cwe.mitre.org/data/definitions/601.html) [CWE-639 Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html) [CWE-651 Exposure of WSDL File Containing Sensitive Information](https://cwe.mitre.org/data/definitions/651.html) [CWE-668 Exposure of Resource to Wrong Sphere](https://cwe.mitre.org/data/definitions/668.html) [CWE-706 Use of Incorrectly-Resolved Name or Reference](https://cwe.mitre.org/data/definitions/706.html) [CWE-862 Missing Authorization](https://cwe.mitre.org/data/definitions/862.html) [CWE-863 Incorrect Authorization](https://cwe.mitre.org/data/definitions/863.html) [CWE-913 Improper Control of Dynamically-Managed Code Resources](https://cwe.mitre.org/data/definitions/913.html) [CWE-922 Insecure Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/922.html) [CWE-1275 Sensitive Cookie with Improper SameSite Attribute](https://cwe.mitre.org/data/definitions/1275.html) --- ### 2021 Docs Ar A02 2021 Cryptographic Failures (`2021/docs/ar/A02_2021-Cryptographic_Failures.md`) # A02:2021 – فشل آلية التشفير ## العوامل | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 29 | 46.44% | 4.49% | 79.33% | 34.85% | 7.29 | 6.81 | 233,788 | 3,075 | ## نظرة عامة يأتي فشل آلية التشفير في المرتبة رقم #2 والتي كانت تعرف “بالبيانات الحساسة الغير محمية أو المكشوفة" والتي قد تكون أسبابها متعدّدة أكثر من كونها ناتجة عن سبب جذري واحد، ويأتي التركيز هنا على حالات الفشل في التشفير والتي غالبًا ما تؤدي إلى كشف غير مصرّح به للبيانات الحساسة. تم ملاحظة أن نقاط الضعف الشائعة CWEs تشمل: CWE-259: استخدام كلمة المرور المضمنة مسبقًا "" ، CWE-327: خوارزمية تشفير مُعطّلة أو محفوفة بالمخاطر، و CWE-331 التشتت الغير فعّال أو بعبارة أخرى -عشوائية بشكل غير كافي-” Insufficient Entropy”. ## الوصف أولًا، تحديد احتياجات حماية **البيانات أثناء النقل** (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) ## كيفية الحماية منها يجب عمل ما يلي على الأقل لحماية البيانات الحساسة: - تصنيف البيانات التي تتم معالجتها أو تخزينها أو إرسالها بواسطة تطبيق ما. تحديد البيانات الحساسة وفقًا لقوانين الخصوصية أو المتطلبات التنظيمية أو احتياجات العمل. - تطبيق الضوابط بناءً على التصنيف. - لا تقم بتخزين بيانات حساسة غير مطلوبة، قم بتجاهلها والتخلّص منها في أقرب وقت ممكن لأن البيانات التي لا تملكها لا يمكن سرقتها. - تأكّد من تشفير جميع البيانات الحساسة المخزنة. - ضمان استخدام خوارزميات وبروتوكولات ومفاتيح تشفير محدّثة وذات معايير صارمة كذلك إدارة المفاتيح بشكل جيد ومناسب. - قم بتشفير جميع البيانات أثناء النقل باستخدام بروتوكولات آمنة مثل TLS مع شفرة الـ Perfect Forward Secrecy (PFS)، وتحديد أولويات التشفير والمعطيات الآمنة بواسطة الخادم و كذلك فرض التشفير باستخدام التوجيهات مثل HTTP Strict Transport Security (HSTS). - تعطيل خاصية التخزين المؤقت في الصفحات "caching" للردود التي تحتوي على بيانات حساسة. - قم بتخزين كلمات المرور باستخدام دوال اختزال متكيّفة وقوية **مع بيانات عشوائية إضافية** " salted " ، مثل Argon2 أو scrypt أو bcrypt أو PBKDF2. - تحقق بشكل مستقل من فعالية التكوين والإعدادات. ## أمثلة على سيناريوهات الهجوم **سيناريو #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". ## المصادر - [OWASP Proactive Controls: Protect Data Everywhere](https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere) - [OWASP Application Security Verification Standard (V7, 9, 10)](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Cheat Sheet: Transport Layer Protection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) - [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) - OWASP Cheat Sheet: Password and Cryptographic Storage - [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) - OWASP Testing Guide: Testing for weak cryptography ## قائمة الربط مع إطار CWEs 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`) # A03:2021 – الحقن ## العوامل | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 33 | 19.09% | 3.37% | 94.04% | 47.90% | 7.25 | 7.15 | 274,228 | 32,078 | ## نظرة عامة هجمات الحقن تحتل المركز الثالث، حيث أن 94٪ من التطبيقات التي تم فحصها مهدّدة بصنف واحد أو أكثر من هجمات الحقن المرتبطة مع CWE-79، CWE-89، CWE-73 ## الوصف يكون البرنامج معرض للإصابة بهذه الهجمات عندما: - إذا كانت المدخلات المزوّدة من المستخدم غير مُتحقّق منها أو غير موثوقة، أو لم يتم تصفيتها من قِبل البرنامج. - تمرير طلبات الاستعلامات الديناميكية أو استدعاء بيانات غير محدّدة المعاملات (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، لتحديد العيوب الموجودة من قبل عملية طرح المنتج للاستخدام. ## كيفية الحماية منها - لتفادي هجمات الحقن يجب الفصل والتفّريق بين كل من البيانات والأوامر والاستعلامات. - ُفضّل استخدام **واجهات برمجة تطبيقات (API) ** آمنة، وذلك لتفادي استخدام ** مفسّر الأوامر** كُلّيًا، و توفير واجهة إدخال ذات معاملات " Parametrized Interface " أو الانتقال إلى استخدام كائنات الـ "Relational Mapping Tools (ORMs)". - ملاحظة: حتى في حال استخدام المعاملات" Parameterized” الإجراءات المخزّنة قد لا تزال قاعدة البيانات مُعرّضة لهجمات الحقن في حال كانت الـ PL/SQL أو T-SQL قابلة لتنفيذ الاستعلامات المتسلسلة "الغير مباشرة " أو تنفيذ تعليمات برمجية ضارّة من خلال EXECUTE IMMEDIATE أو exec (). - استخدام عمليات التحقّق من المدخلات الإيجابية و المرتبطة ب "قوائم السماح/القوائم البيضاء" من طرف الخادم. لكن هذه لا تعتبر حماية متكاملة حيث أن هناك العديد من البرامج تتطّلب رموز خاصة "Special Characters" مثل حقل النص (TextArea) أو واجهات تطبيقات البرامج (APIs) لتطبيقات الهواتف. - في حال وجود استعلامات ديناميكية متبقية، قم بتصفية الاستعلام من الرموز الخاصة من خلال استخدام صيغة برمجية "Syntax " لتصفية المدخلات المحددة إلى مفسّر الأوامر. - ملاحظة: هيكلة SQL مثل أسماء الجداول أو الأعمدة وغيرها، لا يمكن إجراء عوامل التصفية عليها، لذلك يجب الحذر من هياكل البيانات القادمة من المستخدم حيث أنها تعتبر خطرة. وهذا خطأ شائع عند كتابة-تقارير البرمجيات. - ضع حدودا و أو ضوابط تحكّم أخرى عند استخدام الاستعلامات داخل SQL، لتجنّب كشف السجلات الحساسة في حال وجود هجمات حقن الـ SQL ## أمثلة على سيناريوهات الهجوم **سيناريو #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);-- وهذا ينتج تغيير في معنى الاستعلام للحصول على جميع السجلات من جدول الحسابات. وقد يستغلّها المُخترق بشكل آخر لتعديل أو حذف أو حتى استدعاء العمليات المخزّنة. ## المصادر - [OWASP Proactive Controls: Secure Database Access](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database) - [OWASP ASVS: V5 Input Validation and Encoding](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: SQL Injection,](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection) [Command Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection), and [ORM Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection) - [OWASP Cheat Sheet: Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) - [OWASP Cheat Sheet: SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) - [OWASP Cheat Sheet: Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) - [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) - [OWASP Automated Threats to Web Applications – OAT-014](https://owasp.org/www-project-automated-threats-to-web-applications/) - [PortSwigger: Server-side template injection](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) ## قائمة الربط مع إطار CWEs [CWE-20 Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html) [CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')](https://cwe.mitre.org/data/definitions/74.html) [CWE-75 Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)](https://cwe.mitre.org/data/definitions/75.html) [CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')](https://cwe.mitre.org/data/definitions/77.html) [CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')](https://cwe.mitre.org/data/definitions/78.html) [CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html) [CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)](https://cwe.mitre.org/data/definitions/80.html) [CWE-83 Improper Neutralization of Script in Attributes in a Web Page](https://cwe.mitre.org/data/definitions/83.html) [CWE-87 Improper Neutralization of Alternate XSS Syntax](https://cwe.mitre.org/data/definitions/87.html) [CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')](https://cwe.mitre.org/data/definitions/88.html) [CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')](https://cwe.mitre.org/data/definitions/89.html) [CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')](https://cwe.mitre.org/data/definitions/90.html) [CWE-91 XML Injection (aka Blind XPath Injection)](https://cwe.mitre.org/data/definitions/91.html) [CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')](https://cwe.mitre.org/data/definitions/93.html) [CWE-94 Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html) [CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')](https://cwe.mitre.org/data/definitions/95.html) [CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')](https://cwe.mitre.org/data/definitions/96.html) [CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page](https://cwe.mitre.org/data/definitions/97.html) [CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')](https://cwe.mitre.org/data/definitions/98.html) [CWE-99 Improper Control of Resource Identifiers ('Resource Injection')](https://cwe.mitre.org/data/definitions/99.html) [CWE-100 Deprecated: Was catch-all for input validation issues](https://cwe.mitre.org/data/definitions/100.html) [CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')](https://cwe.mitre.org/data/definitions/113.html) [CWE-116 Improper Encoding or Escaping of Output](https://cwe.mitre.org/data/definitions/116.html) [CWE-138 Improper Neutralization of Special Elements](https://cwe.mitre.org/data/definitions/138.html) [CWE-184 Incomplete List of Disallowed Inputs](https://cwe.mitre.org/data/definitions/184.html) [CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')](https://cwe.mitre.org/data/definitions/470.html) [CWE-471 Modification of Assumed-Immutable Data (MAID)](https://cwe.mitre.org/data/definitions/471.html) [CWE-564 SQL Injection: Hibernate](https://cwe.mitre.org/data/definitions/564.html) [CWE-610 Externally Controlled Reference to a Resource in Another Sphere](https://cwe.mitre.org/data/definitions/610.html) [CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')](https://cwe.mitre.org/data/definitions/643.html) [CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax](https://cwe.mitre.org/data/definitions/644.html) [CWE-652 Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')](https://cwe.mitre.org/data/definitions/652.html) [CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')](https://cwe.mitre.org/data/definitions/917.html) --- ### 2021 Docs Ar A04 2021 Insecure Design (`2021/docs/ar/A04_2021-Insecure_Design.md`) # A04:2021 – التصميم الغير آمن ## العوامل | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 40 | 24.19% | 3.00% | 77.25% | 42.51% | 6.46 | 6.78 | 262,407 | 2,691 | ## نظرة عامة هو تصنيف جديد تمت إضافته في هذه النسخة لعام 2021 والذي يركّز على المخاطر المتعلقة بعيوب وأخطاء التصميم، مما يدعو إلى المزيد من استخدام نمذجة التهديدات، وأنماط التصميم الآمنة وبنية تحتية مبنيّة على أفضل الامتثالات. الجدير بالذكر أن إطار CWE تضمن الـ CWEs التالية: CWE-209، CWE-256، CWE-501، CWE-522. ## الوصف التصميم الغير آمن تصنيف واسع يشمل العديد من نقاط الضعف المختلفة، ويُعرف على أنه " تصميم ذو عنصر تحكم " Control “مفقود أو غير فعّال، التصميم الغير آمن هو المكان الذي يكون فيه عنصر التحكم غائبًا، على سبيل المثال، لنفرض أن هناك **شفّرة مصدرية** يجب أن تُراعي تشفير البيانات الحساسة ولكن لا توجد طريقة لتطبيق التشّفير. التصميم الغير آمن والغير فعّال هو: المكان حينما يمكن إدراك وجود التهديد، لكن التحقّق المنطقي الغير فعّال من فضاء العمل (الأعمال) يمنع تنفيذ الإجراء. على سبيل المثال لنفرض أن هناك فضاء عمل يجب أن يقوم بمعالجة الإعفاء الضريبي للجائحة بناءً على فئات الدخل لكنه لا يقوم بالتحقّق فيما إذا كانت البيانات المدخلة موقعة بشكل صحيح أو لا، مما قد يؤدي إلى فائدة أكثر مما ينبغي . التصميم الآمن عبارة عن ثقافة ومنهجيّة تقوم بتقييم التهديدات باستمرار وتضمن أن **الشّفرة المصدرية** مصمّمة بشكل قوي ومختبرة ضد طرق الهجوم المعروفة. يتطلّب التصميم الآمن دورة حياة تطوير آمنة، والبعض من أنماط التصميم الآمنة أو مكتبات المكونات المجهزة مُسبقًا أو الأدوات ونمذجة التهديدات. ## كيفية الحماية منها - إنشاء واستخدام دورة حياة تطوير آمنة مع الاستعانة بأخصائي أمن تطبيقات لتقييم وتصميم عناصر التحكّم المتعلقة بالأمان والخصوصية. - إنشاء واستخدام مكتبة تحتوي على أنماط التصميم الآمن ومكونات مُسبقة وجاهزة للاستخدام. - نمذجة التهديدات لعمليات المصادقة "التحقّق من الهوية" الحساسة، والتحكّم في الوصول، والتسلسل المنطقي التطبيق، والمسارات الأساسية للتطبيق. - وحدة للكتابة ولاختبارات التكامل للتحقّق من أن جميع المسارات الحرجة مقاومة لنموذج التهديد المتوقّع. ## أمثلة على سيناريوهات الهجوم **سيناريو #1:** قد يتضمّن مسار عملية استرداد عناصر اعتماد المصداقية" أسئلة وإجابات"، الذي يحظره إطار NIST 800-63b وOWASP ASVS وOWASP Top 10، فلا يمكن الوثوق في الأسئلة والإجابات كأدلّة على صحة هوية المستخدم حيث يمكن لأكثر من شخص معرفة الإجابات، وهذا هو سبب حظره. يجب إزالة الشّفرة المصدرية تلك واستبدالها بتصميم أكثر أمانًا. **سيناريو #2:** تقوم دور سينما بعمل خصومات لعمليات الحجز الجماعي لـ١٥ شخص كحد أقصى قبل الدفع. هذا المسار قد يُشكّل خطرًا ويسمح للمهاجم باختبار ما إذا كان بإمكانه حجز ٦٠٠ مقعد دفعة واحدة من خلال طلبات قليلة، مما يتسبّب في خسارة هائلة للدخل. **سيناريو #3:** لا تتمتّع مواقع التجارة الإلكترونية من الحماية ضد الروبوتات التي يُديرها مستثمرون يقومون بشراء بطاقات المعالجة الرسومية المطوّرة لإعادة بيعها لاحقًا في مواقع المزادات بأسعار أعلى. هذا يضع صانعيّ كروت الفيديو وكذلك متاجر البيع بالتجزئة في موقف حرج، التصاميم اليقظة ضد الروبوتات وإضافة قواعد تصميم النطاق المعتمدة على المنطق " مثل رصد عمليات الشراء التي تتم في غضون ثوانٍ معدودة "قد ترصد عمليات الشراء الغير طبيعية وتقوم برفضها. ## المصادر - [OWASP Cheat Sheet: Secure Design Principles](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) - [OWASP SAMM: Design:Security Architecture](https://owaspsamm.org/model/design/security-architecture/) - [OWASP SAMM: Design:Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/) - [NIST – Guidelines on Minimum Standards for Developer Verification of Software](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) - [The Threat Modeling Manifesto](https://threatmodelingmanifesto.org) - [Awesome Threat Modeling](https://github.com/hysnsec/awesome-threat-modelling) ## قائمة الربط مع إطار CWEs [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) [CWE-209 Generation of Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html) [CWE-213 Exposure of Sensitive Information Due to Incompatible Policies](https://cwe.mitre.org/data/definitions/213.html) [CWE-235 Improper Handling of Extra Parameters](https://cwe.mitre.org/data/definitions/235.html) [CWE-256 Unprotected Storage of Credentials](https://cwe.mitre.org/data/definitions/256.html) [CWE-257 Storing Passwords in a Recoverable Format](https://cwe.mitre.org/data/definitions/257.html) [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) [CWE-280 Improper Handling of Insufficient Permissions or Privileges](https://cwe.mitre.org/data/definitions/280.html) [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) [CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) [CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) [CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) [CWE-430 Deployment of Wrong Handler](https://cwe.mitre.org/data/definitions/430.html) [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) [CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')](https://cwe.mitre.org/data/definitions/444.html) [CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) [CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) [CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) [CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) [CWE-579 J2EE Bad Practices: Non-serializable Object Stored in Session](https://cwe.mitre.org/data/definitions/579.html) [CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) [CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) [CWE-650 Trusting HTTP Permission Methods on the Server Side](https://cwe.mitre.org/data/definitions/650.html) [CWE-653 Insufficient Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) [CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) [CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) [CWE-840 Business Logic Errors](https://cwe.mitre.org/data/definitions/840.html) [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) [CWE-927 Use of Implicit Intent for Sensitive Communication](https://cwe.mitre.org/data/definitions/927.html) [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) [CWE-1173 Improper Use of Validation Framework](https://cwe.mitre.org/data/definitions/1173.html) --- ### 2021 Docs Ar A05 2021 Security Misconfiguration (`2021/docs/ar/A05_2021-Security_Misconfiguration.md`) # A05:2021 – الإعدادات الأمنية الخاطئة ## العوامل | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 20 | 19.84% | 4.51% | 89.58% | 44.84% | 8.12 | 6.56 | 208,387 | 789 | ## نظرة عامة بعد أن كان هذا التهديد في المرتبة السادسة في الإصدار السابق لعام 2017 الآن نجده في المرتبة الخامسة، حيث أنه تم إجراء اختبار على %90 من البرامج والتطبيقات للتأكد إن كانت تحتوي على أيّة أخطاء في طريقة الإعدادات والتكوين الصحيحة، فليس من المُستغرب انتقال هذا التهديد من المرتبة السادسة إلى الخامسة. كذلك تم ضم "XML External Entities XXE" لهذا النوع من الإعدادات والتكوين الخاطئة. تضمن الـ CWEs التالية CWE-16 (Configuration), CWE-611 (Improper Restriction of XML External Entity). ## الوصف من المحتمل ان يكون التطبيق ضعيف امنياً إذا احتوى على النقاط التالية: - عدم مراجعة التكوين والضبط الآمن لإعدادات التطبيق أو في أي جزء من أجزاء التطبيق أو تكوين أذونات خاطئة في الخدمات السحابيّة. - تثبيت وإتاحة خدمات ومِيزات غير ضرورية (منافذ غير ضرورية، الخدمات، الصفحات، الحسابات، والصلاحيات). - تفعيل الحسابات الافتراضية أو عدم تغييرها أو عدم تغيير كلمات المرور الخاصة بها. - كشف رسائل معالجة الأخطاء (Error Handling) عن معلومات قابلة للتتبّع (Stack Traces) أو عرض رسائل الخطأ التي تحتوي على معلومات تفصيلية يمكن أن تُستغل من قِبل المستخدم. - تكون الميزات الأمنية الأحدث مُعطّلة أو لم يتم تكوينها بشكل آمن في الأنظمة التي تمت ترقيتها. - عدم تعيين إعدادات الأمان في خوادم التطبيقات وإطار التطبيقات على سبيل المثال (Struts, Spring, ASP.NET) والمكتبات وقواعد البيانات وما إلى ذلك إلى قيم آمنة. - لا يرسل أو يستخدم الخادم عناوين "Headers" عند نقل البيانات الحساسة للمتصفح أو عند تقديمها من قِبل المتصفح. - لم يعد البرنامج مدعومًا من قبل مزوّدي الخدمات أو ضعيف أمنيًا لاحتوائه على ثغرات أمنية (انظر إلى - A06:2021 الثغرات والأنظمة الغير قابلة للتحديث). من دون امتلاك إجراءات مفهومة وقابلة للتكّرار للإعدادات الأمنية لتكوين البرنامج بما يتوافق مع الضوابط الأمنية، تُصبح الأنظمة في خطر عالي. ## كيفية الحماية منها يجب تطبيق آلية آمنة لتكوين البرامج أو الأجهزة، تشمل على: - تكرار عملية مراجعة التكوين الآمن، والذي سيؤدي إلى تسريع وتسهيل مهمة إنشاء بيئة جديدة مكوّنة بشكل آمن. كما يجب أن يتم تكوين بيئات التطوير وضمان جودة وبيئة الإنتاج بشكل يتطابق مع استخدام كلمات مرور مختلفة في كل بيئة. أيضًا يجب أن تكون هذه العملية آلية للتقليل من الجهد المتطلّب عند إعداد بيئة جديدة وآمنة. - الاكتفاء بالحد الأدنى الأساسي من النظام أو المنصّة بدون تفعيل مِيزات، أو مكونات، أو وثائق، أو عيّنات غير ضرورية، مع حذف وإبطال الميزات وإطار الغير مستخدمة أو عدم تثبيتها. - مراجعة وتحديث الإعدادات بما يتناسب مع كافة ملاحظات الأمان والتحديثات والإصلاحات كجزء من عملية إدارة حِزم الإصلاحات والترقيات. (انظر إلى- A06:2021 الثغرات والأنظمة الغير قابلة للتحديثات). بالإضافة إلى مراجعة أذونات التخزين السحابيّة على سبيل المثال (S3 Bucket Permissions). - تتيح بنية التطبيق المقسّمة فصلًا فعّالًا وآمنًا بين المكونات، مع التجزئة في مجموعات أمان السحابة (ACLs). - إرسال توجيهات الأمان إلى المستخدمين على سبيل المثال Security Headers. - أتمتة عملية التحقق من التحديثات الآمنة للتحقّق من فعاليّة التكوينات والإعدادات في جميع البيئات. - تشغيل أدوات الفحص للتحقّق من فعاليّة التكوينات والإعدادات في جميع البيئات للكشف عن الإعدادات الخاطئة. ## أمثلة على سيناريوهات الهجوم **سيناريو #1:** عندما يحتوي احد الخوادم على تطبيق من التطبيقات غير محدث وما يزال يُستخدم في بيئة الإنتاج "Production Server" هذه العيّنات من التطبيقات قد تحتوي على ثغرات أمنية يمكن أن يستخدمها المهاجم في اختراق الخادم ، وبافتراض أن أحد هذه البرامج هي وحدة تحكّم لإدارة الخادم وتحتوي على الاعدادات الافتراضية والرقم السري الافتراضي، في هذه الحالة فإن المهاجم سوف يُسجّل الدخول باستخدام الرقم السري الافتراضي ويتحكّم بالخادم. **سيناريو #2:** عندما تكون قائمة الدليل "Directory Listing" غير معطّلة في الخادم الخاص بك، قد يكتشف المهاجم أن بإمكانه سرد قائمة الملفات المخزنة على الخادم وبعد ذلك بإمكانه العثور وتثبيت جميع فئات جافا (Compiled Java Classes) ومن ثم يقوم بفكّها وتطبيق الهندسة العكسية لعرض الشّفرة المصدرية، سوف يحاول المهاجم بعد ذلك إيجاد خطأ أمني للتحكّم في الوصول إلى الخادم. **سيناريو #3:** عندما تقوم إعدادات خادم التطبيق بإرجاع رسائل خاطئة تفصيليّة، على سبيل المثال Stack Traces إلى المستخدم، ومن المُحتمل أن يؤدي هذا إلى الكشف عن معلومات حساسة أو ثغرات أمنية أخرى أو معلومات مثل إصدارات المكونات المعروفة بأنها قابلة للاستغلال. **سيناريو #4:** أن يكون مقدّم الخدمة السحابيّة لديه أذونات مشاركة افتراضية مفتوحة على الإنترنت من قِبل مستخدمي CSP الآخرين، يسمح هذا بالوصول إلى البيانات الحساسة المخزّنة في سحابة التخزين. ## المصادر - [OWASP Testing Guide: Configuration Management](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) - [OWASP Testing Guide: Testing for Error Codes](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) - Application Security Verification Standard V19 Configuration - [NIST Guide to General Server Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) - [CIS Security Configuration Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) - [Amazon S3 Bucket Discovery and Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) ## قائمة الربط مع إطار CWEs [CWE-2 7PK - Environment](https://cwe.mitre.org/data/definitions/2.html) [CWE-11 ASP.NET Misconfiguration: Creating Debug Binary](https://cwe.mitre.org/data/definitions/11.html) [CWE-13 ASP.NET Misconfiguration: Password in Configuration File](https://cwe.mitre.org/data/definitions/13.html) [CWE-15 External Control of System or Configuration Setting](https://cwe.mitre.org/data/definitions/15.html) [CWE-16 Configuration](https://cwe.mitre.org/data/definitions/16.html) [CWE-260 Password in Configuration File](https://cwe.mitre.org/data/definitions/260.html) [CWE-315 Cleartext Storage of Sensitive Information in a Cookie](https://cwe.mitre.org/data/definitions/315.html) [CWE-520 .NET Misconfiguration: Use of Impersonation](https://cwe.mitre.org/data/definitions/520.html) [CWE-526 Exposure of Sensitive Information Through Environmental Variables](https://cwe.mitre.org/data/definitions/526.html) [CWE-537 Java Runtime Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/537.html) [CWE-541 Inclusion of Sensitive Information in an Include File](https://cwe.mitre.org/data/definitions/541.html) [CWE-547 Use of Hard-coded, Security-relevant Constants](https://cwe.mitre.org/data/definitions/547.html) [CWE-611 Improper Restriction of XML External Entity Reference](https://cwe.mitre.org/data/definitions/611.html) [CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute](https://cwe.mitre.org/data/definitions/614.html) [CWE-756 Missing Custom Error Page](https://cwe.mitre.org/data/definitions/756.html) [CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')](https://cwe.mitre.org/data/definitions/776.html) [CWE-942 Permissive Cross-domain Policy with Untrusted Domains](https://cwe.mitre.org/data/definitions/942.html) [CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag](https://cwe.mitre.org/data/definitions/1004.html) [CWE-1032 OWASP Top Ten 2017 Category A6 - Security Misconfiguration](https://cwe.mitre.org/data/definitions/1032.html) [CWE-1174 ASP.NET Misconfiguration: Improper Model Validation](https://cwe.mitre.org/data/definitions/1174.html) --- ### 2021 Docs Ar A06 2021 Vulnerable And Outdated Components (`2021/docs/ar/A06_2021-Vulnerable_and_Outdated_Components.md`) # A06:2021 الثغرات و الانظمة الغير قابلة للتحديثات ## العوامل | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 3 | 27.96% | 8.77% | 51.78% | 22.47% | 5.00 | 5.00 | 30,457 | 0 | ## نظرة عامة كانت تحتل المرتبة الثانية في عملية الاستطلاع التي تم إجراؤها في قطاع أمن التطبيقات ولكنها أيضًا تمتلك بيانات كافية لتُصبح من أعلى عشرة مخاطر من خلال تحليل البيانات. يُعتبر تصنيف " الثغرات والمكوّنات الغير مُحدّثة" من المشاكل المعروفة التي تواجه صعوبات من أجل اختبارها وتقييم مخاطرها ويُعتبر التصنيف الوحيد الذي لا يتضمّن CVEs ومرتبط بـ CWEs. لذلك تم استخدام المعيار الافتراضي للاستغلال أو الأثر وهو 5.0، ونجد أن هناك ارتباط وحيد في هذا التصنيف وهو CWE-1104. ## الوصف من المحتمل ان تكون عرضة للاختراق: - إذا كنت لا تعرف إصدارات جميع المكونات التي تستخدمها (من جانب المستخدم أو من جانب الخادم). وهذا يتضمّن المكونات التي تستخدمها بشكل مُباشر بالإضافة إلى المكونات الغير مباشرة. - إذا كانت المكونات او البرمجيات معرضه للاختراق بسبب انها غير مدعومة أو قديمة. ويتضمن ذلك نظام التشغيل وخادم الويب أو التطبيقات ونظام إدارة قواعد البيانات (DBMS) والتطبيقات وواجهات برمجة التطبيقاتAPI وجميع المكونات وبيئات التي تعمل مع بدء التشغيل .(runtime) - إذا لم تقم بالمسح الأمني بحثاً عن الثغرات بانتظام، والاشتراك في نشرات الأمن المتعلقة بالمكونات التي تستخدمها. - إذا لم تقم بإصلاح أو ترقية النظام الأساسي والإطار والتبعيات الأساسيّة بطريقة مبنيّة على تقييم المخاطر وفي الوقت المناسب. يحدث هذا عادةً في البيئات التي يكون فيها إغلاق الثغرات وتنصيب التحديثات مَهمة شهرية أو ربع سنوية تحت إدارة التغييرات، مما يترك المؤسسات عُرضة لمدة أيام أو شهور من عدم تطبيق التحديث للثغرات الضرورية. - إذا لم يقم مطورو البرامج باختبار توافق المكتبات المحدثة أو التي تم اجراء إصلاحات عليها. - إذا لم تقم بتأمين الاعدادات بالشكل الصحيح. (انظر A05: 2021 – الإعدادات الأمنية الخاطئة ). ## كيفية الحماية منها يجب أن تكون هناك آلية لإدارة اغلاق الثغرات وذلك لتلبية ما يلي: - إزالة المكونات الغير مستخدمة والمميزات والملفات والوثائق الغير ضرورية. - عمل جرد بشكل دوري للإصدارات من جانب المستخدم ومن جانب الخادم (على سبيل المثال، إطار العمل والمكتبات) ومكوناتها باستخدام أدوات مثل Versions, OWASP Dependency Check, Retire.JS وما إلى ذلك، مراقبة المصادر الخاصة بالثغرات باستمرار مثل CVE و NVD بحثًا عن الثغرات التي في المكونات. وقم باستخدام الأدوات الخاصة بتحليل الإعدادات وذلك من أجل أتمتة العملية. وأخيرًا، قم بالاشتراك في تنبيهات البريد الإلكتروني الخاصة بالثغرات الأمنية المتعلقة بالمكونات التي تستخدمها. - الحصول على المكونات من المصادر الرسمية فقط عبر الروابط الآمنة. يفضل التأكد من ان الحزم موقعه رقمياً لتقليل فرصة تثبيت مكونات معدلة وضارة (انظر A08: 2021- فشل سلامة البيانات والبرمجيات). - مراقبة المكتبات والمكونات التي لا يتم صيانتها أو التي لا تقوم بعمل تحديثات الأمان للإصدارات القديمة. إذا لم تكن عملية سدّ الثغرات مُمكنة، فكّر في إنشاء آلية افتراضية لمراقبة تلك المكونات ورصد المحاولات الضَّارة والحماية منها يجب أن تضمن كل مؤسسة خطة مستمرة للمراقبة، وتصنيف، وتطبيق التحديثات أو تغيير الاعدادات طوال الحياة الافتراضية للتطبيقات. ## أمثلة على سيناريوهات الهجوم **سيناريو #1:** تعمل المكونات عادةً بنفس الامتيازات التي يتمتّع بها التطبيق نفسه، لذا فإن العيوب في أي مكوّن يمكن أن يؤدي إلى تأثير خطير. يمكن أن تكون هذه العيوب عرضية (على سبيل المثال، الأخطاء البرمجية) أو عيوب مقصودة (على سبيل المثال، باب خلفي في أحد المكونات). بعض الأمثلة على ثغرات المكونات القابلة للاستغلال التي تم اكتشافها هي: - نظرة على ثغرة CVE-2017-5638، وهي ثغرة أمنية تقوم بتنفيذ تعليمات برمجية عن بُعد لـ Struts 2 والتي تُتيح تنفيذ تعليمات برمجية عشوائية على الخادم، والتي تُسبّب اختراقات خطيرة. - على الرغم من صعوبة أو استحالة تحديث إنترنت الأشياء في بعض منتجات (IoT)، إلا أن أهمية تحديثها يمكن ان يكون له أهمية كبيرة (مثل الأجهزة الطبية). هناك أدوات آلية لمساعدة المهاجمين في العثور على أنظمة غير محدثة أو معدة بشكل خاطئ. على سبيل المثال، يمكن أن يساعدك محرك بحث Shodan IoT في العثور على الأجهزة التي لا تزال تعاني من الثغرة الأمنية مثل ثغرة Heartbleed والتي تم إصلاحها وتحديثها في أبريل من عام 2014. ## المصادر - 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 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`) # A07:2021 – الهوية و فشل عملية التحقق ## العوامل | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 22 | 14.84% | 2.55% | 79.51% | 45.72% | 7.40 | 6.50 | 132,195 | 3,897 | ## نظرة عامة هذ التصنيف يُعرف سابقًا باسم ضعف التحقّق من الهوية (Broken Authentication) وكانت هي الخطر رقم #2 في الإصدار السابق. وحاليًا تشمل على العديد من CWEs المتعلقة بفشل عملية التحقّق. يتضمّن هذا التصنيف كل من (CWE-384,CWE-297,CWE-287). ## الوصف يُعد تأكيد هوية المستخدم والمصادقة وإدارة الجلسة أمرًا بالغ الأهمية وذلك للحماية من الهجمات المتعلقة بالمصادقة. قد يكون هناك ضعف في المصادقة إذا كان التطبيق: - يسمح بالهجمات الآلية مثل هجمات بيانات الاعتماد (Credential Stuffing)، حيث يكون لدى المهاجم قائمة بأسماء المستخدمين وكلمات المرور. - يسمح باستغلال هجوم كسر كلمات المرور (Brute Force) أو الهجمات الآلية الأخرى. - يسمح بهجمات كلمات المرور الافتراضية أو الضعيفة أو المعروفة ، مثل "Password1" أو " Admin / Admin". - يستخدم عوامل ضعيفة وغير فعّالة لاستعادة كلمات المرور واسترجاع بيانات الاعتماد والتي يجعلها آمنة، مثل "الأجوبة المستندِة على المعرفة". - يستخدم كلمات مرور غير مشفّرة، أو مشفّرة بشكل مُجزّأ أو بشكل ضعيف (راجع A3:2017- البيانات الحساسة الغير محميّة أو المكشوفة). - عدم تفعيل التحقّق الثنائي أو تكون غير فعّالة. - يعرض معرّفات الجلسة (Session IDs) في عنوان URL - لا يقوم بإعادة إنشاء معرّفات الجلسة بعد تسجيل الدخول بنجاح. - لا ينهي معرّفات الجلسة بشكل صحيح. لا يتم إنهاء جلسات المستخدم أو رموز المصادقة (Authentication Tokens) وخاصة رموز الدخول الموحّد (SSO) بشكل صحيح خلال تسجيل الخروج أو في فترة الخمول. ## كيفية الحماية منها - حيثما أمكن ذلك، قم بتفعيل التحقّق الثنائي لمنع الهجمات الآلية لبيانات الاعتماد(Credential Stuffing)، وهجوم كسر كلمات المرور (Brute Force) وهجمات إعادة استخدام بيانات الاعتماد المسروقة. - لا ترسل أو تضع بيانات اعتماد افتراضية، خاصة بالنسبة لمدراء النظام (المسؤولين) - نفِّذ عمليات التحقّق من كلمات المرور الضعيفة، مثل اختبار كلمات المرور الجديدة أو التي تم تغييرها ومقارنتها بقائمة أسوأ 10,000 كلمة مرور. - اضبط طول كلمة المرور وصعوبتها وقم باتباع السياسات والإرشادات الواردة في NIST 800-63b في القسم 5.1.1 "تذكّر كلمات السر المحفوظة أو سياسات كلمة المرور". - تأكد من أن مسارات كُلًا من التسجيل واستعادة بيانات الاعتماد وواجهة برمجة التطبيقات (API) محميّة ضد هجمات فحص الحسابات (Account Enumeration) ، قم بإظهار نفس رسائل الخطأ لجميع عمليات تسجيل الدخول. - الحد من محاولات تسجيل الدخول الفاشلة. وقم بتسجيل جميع حالات فشل عملية تسجيل الدخول وقم بتنبيه المسؤولين عند اكتشاف محاولة هجمات كسر بيانات الاعتماد (Credential Stuffing) أو هجوم كسر كلمات المرور (Brute Force) أو أي هجمات أخرى. - استخدم مدير جلسة مُدمج وآمن من جانب الخادم، يقوم بإنشاء معرّف جلسة عشوائية جديدة مع (Entropy) عالية بعد تسجيل الدخول، معرّفات الجلسات يجب ألا تكون موجودة في عنوان URL، ويجب تخزينها بشكل آمن و إنهاء صلاحيتها بعد تسجيل الخروج، أو الخمول، والانتهاء المُطلق (انتهاء أو نفاذ الوقت). ## أمثلة على سيناريوهات الهجوم **سيناريو #1:** هجمات بيانات الاعتماد وهي عبارة عن استخدام قوائم معروفة سابقًا لمجموعة من كلمات المرور وتُعتبر من أكثر الهجمات شيوعًا، و لنفرض أن أحد التطبيقات لم يُطبّق الحماية التلقائية والكافية للحد من التهديدات أو هجمات بيانات الاعتماد، في هذه الحالة، يمكن استخدام رسائل الخطأ الصادرة من التطبيق كمعيار لتحديد ما إذا كانت بيانات الاعتماد صالحة. **سيناريو #2:** تحدث معظم هجمات المصادقة بسبب الاستخدام المستمر لكلمات المرور كعامل وحيد لتسجيل الدخول حتى وإن تم اعتماد أفضل الممارسات والتغيير المستمر لكلمات المرور حيث جعل سياسة كلمة المرور معقّدة، يُشجّع المستخدمين على إعادة استخدام كلمة المرور. لذلك ننصح المؤسسات بإيقاف هذه المُمارسات وفقًا لـ NIST 800-63 واستخدام التحقّق الثنائي. **سيناريو #3:** لا يتم تعيين مدة انتهاء الجلسة (Timeouts) للتطبيق بشكل صحيح، يقوم المستخدم باستخدام أحد الأجهزة الموجودة في الأماكن العامة للوصول إلى أحد التطبيقات بدلًا من اختيار "تسجيل الخروج"، يقوم المستخدم ببساطة بإغلاق علامة تبويب المتصفح، فيقوم المهاجم باستخدام نفس المتصفح بعد ساعات قليلة ليجد أنه لا يزال المستخدم قيد تسجيل الدخول (Authenticated). ## المصادر - [OWASP Proactive Controls: Implement Digital Identity](https://owasp.org/www-project-proactive-controls/v3/en/c6-digital-identity) - [OWASP Application Security Verification Standard: V2 authentication](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Application Security Verification Standard: V3 Session Management](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: Identity](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/03-Identity_Management_Testing/README), [Authentication](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/README) - [OWASP Cheat Sheet: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) - [OWASP Cheat Sheet: Credential Stuffing](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) - [OWASP Cheat Sheet: Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) - [OWASP Cheat Sheet: Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) - [OWASP Automated Threats Handbook](https://owasp.org/www-project-automated-threats-to-web-applications/) - NIST 800-63b: 5.1.1 Memorized Secrets ## قائمة الربط مع إطار CWEs [CWE-255 Credentials Management Errors](https://cwe.mitre.org/data/definitions/255.html) [CWE-259 Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html) [CWE-287 Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) [CWE-288 Authentication Bypass Using an Alternate Path or Channel](https://cwe.mitre.org/data/definitions/288.html) [CWE-290 Authentication Bypass by Spoofing](https://cwe.mitre.org/data/definitions/290.html) [CWE-294 Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html) [CWE-295 Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html) [CWE-297 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/297.html) [CWE-300 Channel Accessible by Non-Endpoint](https://cwe.mitre.org/data/definitions/300.html) [CWE-302 Authentication Bypass by Assumed-Immutable Data](https://cwe.mitre.org/data/definitions/302.html) [CWE-304 Missing Critical Step in Authentication](https://cwe.mitre.org/data/definitions/304.html) [CWE-306 Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html) [CWE-307 Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html) [CWE-346 Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html) [CWE-384 Session Fixation](https://cwe.mitre.org/data/definitions/384.html) [CWE-521 Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html) [CWE-613 Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html) [CWE-620 Unverified Password Change](https://cwe.mitre.org/data/definitions/620.html) [CWE-640 Weak Password Recovery Mechanism for Forgotten Password](https://cwe.mitre.org/data/definitions/640.html) [CWE-798 Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) [CWE-940 Improper Verification of Source of a Communication Channel](https://cwe.mitre.org/data/definitions/940.html) [CWE-1216 Lockout Mechanism Errors](https://cwe.mitre.org/data/definitions/1216.html) --- ### 2021 Docs Ar A08 2021 Software And Data Integrity Failures (`2021/docs/ar/A08_2021-Software_and_Data_Integrity_Failures.md`) # A08:2021 – فشل سلامة البرامج والبيانات ## العوامل | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 10 | 16.67% | 2.05% | 75.04% | 45.35% | 6.94 | 7.94 | 47,972 | 1,152 | ## نظرة عامة تمت إضافة هذا التصنيف في عام 2021 حيث يُركّز على وضع افتراضات تتعلّق بتحديثات البرامج والبيانات الحساسة أو تطبيق معايير CI/CD pipeline من دون التحقّق من سلامتها. إن أحد أكبر التأثيرات الكبيرة والموجودة في قواعد بيانات الثغرات CVE /CVSS والمرتبطة مع إطار CWEs وهم: CWE-502، CWE-829، CWE-494. ## الوصف فشل سلامة البيانات والبرامج تتعلّق بالشّفرة المصدرية والبنية التحتيّة الغير محميّة من الانتهاكات التي تتعّلق بسلامتها. على سبيل المثال: حين يتم ترميز الكائنات أو البيانات بطريقة تُمكّن المهاجم أن يطّلع أو يقوم بإجراء التعديلات الغير مُصرّح بها. مثال آخر: عندما يعتمد التطبيق على إضافات أخرى أو مكتبات أو بعض الأنماط الغير موثوقة أو من خلال استخدام شبكات توصيل المحتوى CDNs الغير موثوق بها، ويمكن أن يؤدي CI / CIC الغير آمن إلى إمكانية الوصول الغير مُصرّح به أو تنزيل برمجية خبيثة أو اختراق النظام. أخيرًا، تتضمّن العديد من التطبيقات الآن وظيفة التحديث التلقائي، حيث يتم تنزيل التحديثات دون التحقّق من السلامة بشكل كافي وتثبيتها على التطبيقات التي تم الوثوق بها سابقًا. مما يُمكّن المهاجمين أن يقوموا بتحميل تحديثاتهم الخاصة ليتم تثبيتها وتشغيلها على جميع الأجهزة. ## كيفية الحماية منها - تأكد من عدم إرسال البيانات الغير مشفّرة أو الغير موقّعة إلى عملاء غير موثوقين بدون شكل من أشكال التحقق من سلامة أو وجود توقيع رقمي وذلك من أجل اكتشاف التلاعب بالبيانات. - التحقّق من سلامة البرامج أو البيانات من المصادر الرسمية والمتوقعة، عبر التأكد من وجود التواقيع أو آليات مُشابهة لضمان سلامة البيانات - تأكد من أن المكتبات والمكونات، مثل Npm أو Maven، تستخدم مصادر موثوقة. - تأكد من استخدام أدوات الحماية عند استخدام برمجيات الطرف الثالث، مثل OWASP Dependency Check أو OWASP CycloneDX ، والتي تقوم بالتأكد من عدم وجود أي ثغرات أمنية - تأكد من أن CI / CD لديه الإعدادات المناسبة والتحكّم المناسب للوصول للبرامج والبيانات للتأكد من سلامتها خلال آلية الإنشاء والنشر. ## أمثلة على سيناريوهات الهجوم **سيناريو #1 إلغاء التسلسل الغير آمن:** يستدعي تطبيق React مجموعة من الخدمات المصغّرة لـ Spring Boot. فقد حاول المبرمجين بالتأكد من أن الشّفرة المصدرية الخاصة بهم غير قابلة للتغيير. والحل الذي توصلوا إليه هو إجراء تسلسل لحالة المستخدم وتمريرها ذهابًا وإيابًا مع كل طلب. فقد لاحظ المهاجم توقيع كائن جافا R00 يمكنه من استخدام أداة Java Serial Killer للحصول على إمكانية التنفيذ عن بعد. **سيناريو #2 التحديث بدون التأكد من التواقيع:** العديد من أجهزة الموجّهات المنزلية والبرامج الثابتة Firmware وغيرها لا تتحقّق من صحة التواقيع الرقمية عند إجراء التحديثات. حيث تُعد البرامج الثابتة الغير موقعة هدفًا سهلًا للمهاجمين. فالخطر هنا أنه لا توجد آلية لإصلاحه، بل في انتظار الإصلاح في الإصدارات القادمة **سيناريو #3 التحديثات التي استهدفت SolarWinds**: يقوم المهاجمون المتقدمون باستهداف آلية التحديث للأنظمة. ومن خلال ملاحظة الهجمة الحديثة التي استهدفت SolarWinds Orion. حيث قامت الشركة بتطوير آلية وسياسة للتأكد من سلامة عملية التحديث وأمنها. ومع ذلك فقد يستطيع المهاجمون استغلالها، وقد حدث ذلك واستغلوا المهاجمين تلك الآلية ولمدة أشهر، حيث قاموا بحقن برمجيات التحديثات للأنظمة التي أثّرت على أكثر من 18,000 نظام لأكثر من 100 منظمة حول العالم. حيث يُعتبر هذا الهجوم من أخطر الهجمات التي حدثت حتى يومنا هذا. ## المصادر - [OWASP Cheat Sheet: Software Supply Chain Security](Coming Soon) - [OWASP Cheat Sheet: Secure build and deployment](Coming Soon) - [OWASP Cheat Sheet: Infrastructure as Code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) - [OWASP Cheat Sheet: Deserialization]( ) - [SAFECode Software Integrity Controls](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) - [A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack]() - [CodeCov Bash Uploader Compromise](https://about.codecov.io/security-update) - [Securing DevOps by Julien Vehent](https://www.manning.com/books/securing-devops) ## قائمة الربط مع إطار CWEs [CWE-345 Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html) [CWE-353 Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353.html) [CWE-426 Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) [CWE-494 Download of Code Without Integrity Check](https://cwe.mitre.org/data/definitions/494.html) [CWE-502 Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) [CWE-565 Reliance on Cookies without Validation and Integrity Checking](https://cwe.mitre.org/data/definitions/565.html) [CWE-784 Reliance on Cookies without Validation and Integrity Checking in a Security Decision](https://cwe.mitre.org/data/definitions/784.html) [CWE-829 Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html) [CWE-830 Inclusion of Web Functionality from an Untrusted Source](https://cwe.mitre.org/data/definitions/830.html) [CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html) --- ### 2021 Docs Ar A09 2021 Security Logging And Monitoring Failures (`2021/docs/ar/A09_2021-Security_Logging_and_Monitoring_Failures.md`) # A09:2021 – فشل عملية تسجيل الاحداث والمراقبة ## العوامل | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 4 | 19.23% | 6.51% | 53.67% | 39.97% | 6.87 | 4.99 | 53,615 | 242 | ## نظرة عامة شهد " فشل في تسجيل السجلات الأمنية والمراقبة " ارتفاع بسيط من المرتبة العاشرة في أعلى عشرة مخاطر لعام 2017 إلى المرتبة التاسعة في الاستطلاع الذي تم إجراؤه في قطاع أمن التطبيقات. حيث يُشكّل " فشل في تسجيل السجلات الأمنية والمراقبة " تحدّيًا لإيجاد طريقة لاختباره، غالبًا ما يتطلّب ‏مقابلات أو استفسارات ما إذا كانت الهجمات تم اكتشافها أثناء عمليات اختبار الاختراق. ومع ذلك لا يوجد لهذا التصنيف الكثير من البيانات في قاعدة البيانات CVE/CVSS,، ولكن عمليات الاكتشاف والرصد والاستجابة لهذا التصنيف أمر في غاية الأهمية. و يمكن أن يكون مؤثرًا على عدم فعاليّة المراقبة للأحداث وعلى الانتباه للإنذارات والتي قد تُسبّب الحوادث، أو عدم وجود أدلة كافية عند القيام بالتحاليل الجنائية وهذا التصنيف يرتبط بـ CWE-778 وكذلك CWE-117 و CWE-223 و CWE-532. ## الوصف عند العودة إلى أعلى عشرة مخاطر لعام 2021، نجد أن هذا التصنيف يقوم بالمساعدة على رصد واكتشاف واستجابة الثغرات النشِطة أو لعمليات الاختراق التي تحدث، ومن غير عملية تسجيل الأحداث ومراقبتها، لن تستطيع اكتشاف ورصد أو حتى الاستجابة للاختراقات، لذلك وجود عملية تسجيل الأحداث ومراقبتها يساعد على الاستجابة في الوقت المناسب: - الأحداث القابلة لإجراءات التدقيق والمتابعة، مثل عمليات تسجيل الدخول الفاشلة وكذلك عمليات النقل للملفات ذات الأحجام العالية التي لم يتم تسجيلها. - التنبيهات والإنذارات التي لم يتم تسجيلها أو يتم تسجيلها من دون وصف واضح. - لا يتم متابعة وتسجيل الأحداث ومراقبتها للتطبيقات أو واجهة برمجة التطبيقات API أي أنشطة ضارّة. - يتم تخزين سجلات الأحداث محلّيًا فقط - وضع معايير مناسبة للتنبيهات الأمنية مثل (حد عمليات تسجيل الدخول) ، وكذلك إيجاد سياسة واضحة لعملية تصعيد التنبيهات الأمنية والعمل عليها بالشكل الصحيح. - عدم وجود أي إنذارات عند إجراء اختبارات الاختراق أو الفحص بواسطة أداة DAST مثل OWASP ZAP - التطبيقات لا تستطيع اكتشاف أو التنبيه عند وجود أنشطة ضارّة تحدث في الوقت الحالي. أنت مُعرّض لتسريب البيانات والمعلومات في حال عدم ضبط عملية تسجيل الأحداث والتنبيهات بالشكل الصحيح والتي قد تسمح للمستخدم أو حتى المهاجم من مشاهدتها انظر إلى (A02- تخطّي صلاحيات الوصول.) ## كيفية الحماية منها يجب على المطوّرين تطبيق بعض أو كل عناصر التحكّم التالية والتي تعتمد على مدى استهداف وارتفاع المخاطر التي تستهدف التطبيق: - يجب التأكد من أن جميع عمليات الدخول، التحكم بالوصول والمدخلات التي تحدث على جانب الخادم مسجّلة بطريقة صحيحة وواضحة، وذلك لكشف العمليات الضارّة التي تساعدك فيما بعد في عملية التحليل الجنائي الرقمي - التأكد أن عمليات تسجيل الأحداث تتم بشكل منسّق وصحيح وذلك لكي يتم إدارتها بشكل صحيح. - التأكد من أن البيانات مشفّرة بالشكل الصحيح وذلك للحماية من عمليات الحقن أو الهجمات التي قد تحدث على أنظمة المراقبة - التأكد من أن عمليات نقل البيانات الحساسة تتم مراقبتها والتأكد من سلامتها، وذلك للتأكد من عدم تعرّضها لتخريب أو تلاعب أو أي حذف. - يجب أن يكون لدى فريق DevSecOps آلية فعّالة لعملية المراقبة والتي تقوم بعملية الاكتشاف والاستجابة للتنبيهات، مثل الأنشطة الضارّة. ومن أهم المرتكزات هي سرعة الاكتشاف والاستجابة لها. - قم بإيجاد خطة للاستجابة للحوادث السيبرانية وتستطيع الاعتماد على NIST 800-61r2 أو النسخ الأحدث إن توفّرت. هناك تطبيقات وإطارات مفتوحة المصدر وتجارية مثل (OWASP ModSecurity Core Rule Set,، Open-Source Log) وهنا كذلك منصّات تقوم بعملية جمع وربط سجلات الأحداث مثل منصّة ELK Stack والتي تُتيح لك مميزات إضافية منها لوح للمراقبة وكذلك تنبيهات. ## أمثلة على سيناريوهات الهجوم **سيناريو #1:** ‎المشغّل لموقع تابع لشركة تؤمّن خطط التأمين الطبي للأطفال لم يتمكن من اكتشاف ثغرة امنية لعدم توفر أدوات تسجيل الاحداث الأمنية ومراقبتها. حيث قام أحد الأطراف الخارجية بإبلاغ شركة التأمين الطبي عن وجود هجمة سيبرانية تضمنت الدخول والتعديل على آلاف السجلات الصحية لأكثر من 3.5 مليون طفل. وفي التقرير المعدّ بعد الهجمة وُجِد أن مطوّري موقع الويب أهملوا نقاط ضعف امنية مهمّة. ولعدم وجود أدوات تسجيل الاحدث الأمنية ومراقبتها، قد يكون تسريب البيانات قد حدث من بداية عام 2013 وامتد الى أكثر من 7 سنوات. **سيناريو #2:** ‎ واجهت شركة طيران هندية كبرى تسريب بيانات يضم بيانات جُمعت لأكثر من عشر سنوات لمعلومات مسافريها الشخصية مما يتضمن بيانات الجوازات والبطاقات البنكية. تسريب البيانات حدث في خدمة تخزين سحابية من موفّر خدمات سحابية والذي قام بدوره بتنبيه شركة الطيران بوجود التسريب بعد مدة. **سيناريو #3:** ‎عانت شركة طيران أوروبية كبرى من تسريب ضمن لائحة النظام العام لحماية البيانات (GDPR). وقد عُلم أن التسريب حدث بسبب ثغرات في نظام الدفع تم استغلالها من قبل منفذي الهجوم والذين جمعوا سجلات الدفع لأكثر من 400,000 عميل. نتيجة لذلك، قام مشرّع الخصوصية بتغريم شركة الطيران 20 مليون باوند. ## المصادر - [OWASP Proactive Controls: Implement Logging and Monitoring](https://top10proactive.owasp.org/archive/2024/the-top-10/c9-security-logging-and-monitoring/) - [OWASP Application Security Verification Standard: V8 Logging and Monitoring](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: Testing for Detailed Error Code](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_for_Error_Code) - [OWASP Cheat Sheet: Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) - [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)) - [Data Integrity: Recovering from Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-11/final) - [Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-25/final) - [Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-26/final) ## قائمة الربط مع إطار CWEs [CWE-117 Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) [CWE-223 Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) [CWE-532 Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html) [CWE-778 Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html) --- ### 2021 Docs Ar A10 2021 Server Side Request Forgery (SSRF) (`2021/docs/ar/A10_2021-Server-Side_Request_Forgery_(SSRF).md`) # A10:2021 – تزوير الطلبات من جانب الخادم SSRF ## العوامل | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 1 | 2.72% | 2.72% | 67.72% | 67.72% | 8.28 | 6.72 | 9,503 | 385 | ## نظرة عامة حيث تُظهر البيانات أن معدّل الحوادث كان مُنخفض نسبيًا بهذا التصنيف مع أن نسبة الاختبار التي تم إجراؤها كانت فوق المتوسط وأن معدّل الاختراقات التي حدثت واثارها المترتبة ستكون أعلى من المتوسط ومن المحتمل أن تكون هناك مجموعة من المساهمات الصغيرة أو الفردية لهذا التصنيف في إطار CWEs وذلك من أجل رفع الوعي الأمني، لذا نأمل أن يتم التركيز عليها وأن يتم إدراجها ضمن تصنيف أكبر في الإصدارات المُقبلة. ## الوصف يتم تزوير طلبات الخادم عندما يقوم تطبيق الويب بجلب موارد عن بعد دون عملية التحقّق من صحة العنوان المقدّم من قِبل المستخدم، حيث يسمح ذلك للمهاجم بإجبار التطبيق على إرسال طلب معدّل إلى وجهة غير متوقعة للخادم، حتى عندما يكون محميّ بجدار حماية، أو شبكة خاصة افتراضية VPN أو أية نوع من قائمة التحكم بالوصول إلى الشبكة. نظرًا لأن تطبيقات الويب (المواقع الإلكترونية) الحديثة توفّر للمستخدمين مُميزات متقدّمة، فإن جلب العناوين من الخادم أصبح سيناريو شائع. نتيجة لذلك، فإن معدّل حدوث تزوير لطلبات الخادم آخذ في الازدياد، لذلك أصبح استغلال هذه الثغرة أشد خطورة على الخادم عندما ظهرت الخدمات السحابيّة وكذلك تعقيد البنية التحتيّة. ## كيفية الحماية منها يستطيع المُطوّرين منع تزوير طلبات الخادم بتنفيذ بعض أو كل وسائل الدفاع التالية في ضوابط الدفاع العميق (Defense in Depth) : ## **من خلال طبقات الشبكة** - تقسيم وظائف الوصول إلى الموارد عن بعد في شبكات مُنفصلة لتقليل تأثير تزوير طلبات الخادم. - فرض سياسات جدار الحماية "الرفض افتراضيًا" أو ضبط آليات التحكّم في الوصول إلى الشبكة لحظر جميع حركات المرور للشبكة الداخلية باستثناء حركات المرور الأساسية. ## **من خلال طبقات التطبيقات** - التصّفية والتحقّق من صحة جميع بيانات الإدخال المقدّمة من قِبل المستخدم. - استخدام عناوين محدّدة في الروابط، URL استخدام منافذ محدّدة مع تحديد قائمة من العناوين المحدّدة مسبقًا في قائمة مسموح بها. - لا تقم برد الطلبات للعميل على شكل بيانات خام - قم بتعطيل إعادة التوجيه إلى HTTP. - كن على حذر من هجمات إعادة الترتيب الرابط أو الأحرف والتي قد تأتي في بعض الهجمات من خلال بروتوكول DNS أو من خلال استخدام TOCTOU. لا تقم بتخفيف المخاطر على هجمات SSRF من خلال استخدام سياسة المنع المبنيّة على قائمة التعبيرات المنطقية أو (Regular Expression). حيث أن المهاجمين لديهم قوائم مُعدّة مسبقًا ومتعدّدة لمحاولة تخطّي عمليات الحجب تلك. ## أمثلة على سيناريوهات الهجوم يستطيع المهاجمين استخدام تزوير طلبات الخادم لمهاجمة الأنظمة المحميّة خلف جدران حماية تطبيقات الويب(WAF)، وجدران الحماية أو قائمة التحكّم للوصول للشبكة باستخدام سيناريو مثل: **سيناريو #1:** فحص المنافذ للخوادم الداخلية في معمارية الشبكة: الشبكات الغير مقسّمة بشكل جيّد تُمكّن المهاجمين من رسم الشبكات الداخلية بشكل دقيق ويصل إلى تمكين المهاجم لمعرفة في حال كانت المنافذ مفتوحة أم مُغلقة للخوادم والخدمات الداخلية من خلال دراسة أو استجابة الخادم لطلبات أو من خلال الوقت المُستغرق لكل طلب على كل منفذ مختلف وذلك لمعرفة في حال كان استغلال SSRF نجح أم فشل. **سيناريو #2:** بيانات حساسة غير محميّة والتي يستطيع المهاجم الوصول إليها: يستطيع المهاجم الوصول للبيانات الحساسة الداخلية مثل ملف ( file:///etc/passwd)أو حتى للخدمات الداخلية من خلال استغلال هذه الثغرة **سيناريو #3:** الوصول إلى تخزين البيانات الوصفيّة للخدمات السحابيّة : يمتلك معظم موفرّي السحابة تخزين البيانات الوصفيّة مثل http://169.254.169.254 ويمكن للمهاجم قراءة تلك البيانات الوصفيّة للحصول على معلومات حساسة منها. **سيناريو #4:** اختراق الخدمات الداخلية وإساءة استخدامها من قِبل المهاجم: يمكن للمهاجم إساءة استخدام الخدمات الداخلية لإجراء مزيد من الهجمات مثل تنفيذ التعليمات البرمجية عن بُعد (RCE) أو هجوم حجب الخدمة (DoS). ## المصادر - [OWASP - Server-Side Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) - [PortSwigger - Server-side request forgery (SSRF)](https://portswigger.net/web-security/ssrf) - [Acunetix - What is Server-Side Request Forgery (SSRF)?](https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/) - [SSRF bible](https://cheatsheetseries.owasp.org/assets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet_SSRF_Bible.pdf) - [A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) ## قائمة الربط مع إطار CWEs [CWE-918 Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html) --- ### 2021 Docs Ar A11 2021 Next Steps (`2021/docs/ar/A11_2021-Next_Steps.md`) # A11:2021 – الخطوات المقبلة المنظمات التي تعمل لبناء برنامج أمني متكامل للتطبيقات أو تقديم استشارات أمنية أو خلق أدوات برمجية؛ تأمل في توسيع نطاق خدماتها. خلال ذلك قد تواجه هذه المشكلات الأربعة التالية التي تستحق الالتفات لها وتحديدها ومعالجتها: ## مشكلات جودة الشفرة المصدرية | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |----------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 38 | 49.46% | 2.22% | 60.85% | 23.42% | | | 101736 | 7564 | - **الوصف.** تتضمن مشكلات جودة الشفرة المصدرية: عيوبًا أمنية، أو انماطًا معروفة، أو إعادة استخدام المتغيرات لأغراض متعددة، ظهور معلومات حساسة في نمط التصحيح “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](https://owasp.org/www-pdf-archive/OWASP_Code_Review_Guide_v2.pdf) - [Google Code Review Guide](https://google.github.io/eng-practices/review/) ## حجب الخدمة | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 8 | 17.54% | 4.89% | 79.58% | 33.26% | | | 66985 | 973 | - **الوصف**. دائمًا ما يكون هجمات حجب الخدمة ممكنًا إذا توفرت المصادر الكافية. ولكن ممارسات التصميم والتشفير لها تأثير كبير على قوة حجب الخدمة. لنفترض ان أي شخص افترض أن أي شخص لديه صلاحية الدخول لملف كبير، أو أنه يقوم بعملية حسابية تستهلك الموارد وتحدث في كل صفحة من صفحات الموقع. في هذه الحالة، تحدث هجمات حجب الخدمة من دون أي جهود تذكر. - **كيفية الحماية منها**. - قم بعمل اختبار الشفرة المصدرية لوحدة المعالجة المركزيةCPU، والمدخلات / المخرجات، والذاكرة المستخدمة. قم بإعادة هندسة العمليات التي تستهلك المصادر أو تحسينها أو تخزينها مؤقتًا. ضع في اعتبارك ضوابط الوصول للأشياء ذات الاحجام الكبيرة لضمان أن الأفراد المصرح لهم فقط يمكنهم الوصول إلى ملفات أو أشياء ضخمة أو قم بخدمتهم عن طريق شبكة تخزين مؤقت. - **مثال على سيناريو هجوم**. - قد يتوقع المهاجم أن كل عملية تستغرق لتنفيذها من 5 إلى 10 ثوانٍ حتى تكتمل. لذلك يقوم بتشغيل أربع عمليات في نفس الوقت ولها (thread) محدد، سيبدو لك أن الخادم قد يتوقف عن الاستجابة بسبب عملية الضغط. لذلك يعود المهاجم (1000 thread ) لكي يتعطل النظام ولا يستجيب بشكل كامل - **المصادر** - [OWASP Cheat Sheet: Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) - [OWASP Attacks: Denial of Service](https://owasp.org/www-community/attacks/Denial_of_Service) ## ادارة اخطاء الذاكرة | ربطها مع CWEs | الحد الأقصى للحدوث | متوسط معدل الحدوث | التغطية القصوى | متوسط معدل التغطية | متوسط استغلال الثغرات | متوسط التأثير | إجمالي التكرار | إجمالي نقاط الضعف CVEs | |---------------|--------------------|-------------------|----------------|--------------------|-----------------------|---------------|----------------|------------------------| | 14 | 7.03% | 1.16% | 56.06% | 31.74% | | | 26576 | 16184 | - **الوصف**. غالبًا ما تتم كتابة تطبيقات الويب بلغات يمكن التحكم بذاكرتها، مثل 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](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow) - [OWASP Attacks: Buffer Overflow](https://owasp.org/www-community/attacks/Buffer_overflow_attack) - [Science Direct: Integer Overflow](https://www.sciencedirect.com/topics/computer-science/integer-overflow) --- ### 2021 Docs De 0x00 2021 Notice (`2021/docs/de/0x00_2021-notice.md`) ## Erscheinungsdatum Das englische Original wurde am 24. September 2021 veröffentlicht ## Hauptautoren - [Andrew van der Stock](mailto:vanderaj@owasp.org) (twitter: [@vanderaj](https://twitter.com/vanderaj)) - [Brian Glas](mailto:brian.glas@owasp.org) (twitter: [@infosecdad](https://twitter.com/infosecdad)) - [Neil Smithline](mailto:neil.smithline@owasp.org) (Twitter: [@appsecneil](https://twitter.com/appsecneil)) - [Torsten Gigler](mailto:torsten.gigler@owasp.org) (twitter: [@torsten_tweet](https://twitter.com/torsten_tweet)) ## Gastautoren - Orange Tsai [@orange_8361](https://twitter/orange_8361), Autor von A10-2021: Server Side Request Forgery - Jim Manico [@manicode](https://twitter/manicode) und Jakub Maćkowski [@kubamackowski](https://twitter/kubamackowski) – OWASP CheatSheets Coordination ## Vorwort der deutschen Version „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](A01_2021-Broken_Access_Control.md) ex: A5:2017-Fehler in der Zugriffskontrolle - [A07:2021–Fehlerhafte Authentifizierung](A07_2021-Identification_and_Authentication_Failures.md) 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](A09_2021-Security_Logging_and_Monitoring_Failures.md) 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/](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 In mehreren deutschen Städten gibt es [OWASP-Stammtische](https://owasp.org/www-chapter-germany/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](/www-chapter-germany/stammtische/augsburg/), [Berlin](/www-chapter-germany/stammtische/berlin), [Dresden](/www-chapter-germany/stammtische/dresden/), [Frankfurt](/www-chapter-germany/stammtische/frankfurt/), [Hamburg](/www-chapter-germany/stammtische/hamburg/), [Hannover](/www-chapter-germany/stammtische/hannover/), [Heilbronn-Franken](/www-chapter-germany/stammtische/heilbronn_franken/), [Karlsruhe](/www-chapter-germany/stammtische/karlsruhe/), [Köln](/www-chapter-germany/stammtische/koeln/), [München](/www-chapter-germany/stammtische/muenchen/) und [Stuttgart](/www-chapter-germany/stammtische/stuttgart/). ## Wie können Sie uns unterstützen 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 Bitte informieren Sie uns über Ergänzungs- und Verbesserungsvorschläge: - [https://github.com/OWASP/Top10/issues](https://github.com/OWASP/Top10/issues) --- ### 2021 Docs De 0x01 2021 About Owasp (`2021/docs/de/0x01_2021-about-owasp.md`) --- source: "https://owasp.org/Top10/A00-about-owasp/" title: "A00_2021 Über OWASP" id: "Über OWASP" lang: "de" --- {%- 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](https://www.youtube.com/user/OWASPGLOBAL). - ["Cheat sheets"](https://owasp.org/www-project-cheat-sheets/) zu vielen sicherheitsrelevanten Themen. - Standard Security-Controls und Programm-Bibliotheken. - [Lokale "Chapter" auf der ganzen Welt](https://owasp.org/chapters/) und zusätzlich **[Stammtische](/www-chapter-germany/stammtische/)** in Deutschland. - Neueste Forschung. - Große und häufige [Konferenzen auf der ganzen Welt](https://owasp.org/events/). - [Mailinglisten](https://groups.google.com/a/owasp.org/forum/#!overview). Alle Informationen auf [https://www.owasp.org](https://www.owasp.org) bzw. [https://www.owasp.de](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!](https://owasp.org/www-chapter-germany/) ## Copyright und Lizenz 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`) # 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 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)](https://owaspsamm.org) 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) 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 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 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 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 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 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`) # 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](A04_2021-Insecure_Design.md) 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: | Anwendungsfall | OWASP Top 10 2021 | OWASP Application Security Verification Standard | |-----------------------------|:-----------------------:|:------------------------------------------------:| | Awareness | ja | | | Ausbildung | Einstiegsniveau | umfassend | | Design und Architektur | gelegentlich | ja | | Codierungsstandard | als Mindestanforderung | ja | | Security Code Review | als Mindestanforderung | ja | | Checkliste für Peer-Reviews | als Mindestanforderung | ja | | Unit-Tests | gelegentlich | ja | | Integrationstests | gelegentlich | ja | | Penetrationstests | als Mindestanforderung | ja | | Werkzeugunterstützung | als Mindestanforderung | ja | | Sichere Lieferkette | gelegentlich | ja | Wir empfehlen jedem, der einen Anwendungssicherheitsstandard übernehmen möchte, den [OWASP Application Security Verification Standard](https://owasp.org/www-project-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`) --- source: "https://owasp.org/Top10/A00_2021_Introduction/" title: "A00_2021_Einführung" id: "Einführung" lang: "de" --- {%- 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 {: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 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](../0x00_2021-notice/#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](A01_2021-Broken_Access_Control.md)** 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](A02_2021-Cryptographic_Failures.md)** 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](A03_2021-Injection.md)** {{ 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](A04_2021-Insecure_Design.md)** 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](A05_2021-Security_Misconfiguration.md)** 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](A06_2021-Vulnerable_and_Outdated_Components.md)** 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](A07_2021-Identification_and_Authentication_Failures.md)** 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](A08_2021-Software_and_Data_Integrity_Failures.md)** 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](A09_2021-Security_Logging_and_Monitoring_Failures.md)** 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](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** 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 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 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**](A10_2021-Server-Side_Request_Forgery_(SSRF).md) und das Maximum bei 40 CWEs in [**A04:2021-Unsicheres Anwendungsdesign**](A04_2021-Insecure_Design.md) 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 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? 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? 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? 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 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 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 Das OWASP Top 10 2021-Team dankt Secure Code Warrior und Just Eat für die finanzielle Unterstützung. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs De A01 2021 Broken Access Control (`2021/docs/de/A01_2021-Broken_Access_Control.md`) --- source: "https://owasp.org/Top10/A01_2021-Broken_Access_Control/" title: "A01:2021 – Mangelhafte Zugriffskontrolle" id: "A01:2021" lang: "de" --- {%- 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) }} | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 34 | 55.97 % | 3.81 % | 6.92 | 5.93 | 94.55 % | 47.72 % | 318,487 | 19,013 | ## Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Übersicht", lang=lang, source=source ~ "#" ~ id, parent= osib) }} 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) }} 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) }} 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) }} **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) }} - {{ 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) }} - {{ 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`) --- source: "https://owasp.org/Top10/A02_2021-Cryptographic_Failures/" title: "A02:2021 – Fehlerhafter Einsatz von Kryptographie" id: "A02:2021" lang: "de" --- {%- 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) }} | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 29 | 46.44 % | 4.49 % |7.29 | 6.81 | 79.33 % | 34.85 % | 233,788 | 3,075 | ## Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Bezug / Kontext / Auswertung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} 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) }} 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) }} 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) }} **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) }} - {{ 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) }} - {{ 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`) --- source: "https://owasp.org/Top10/A03_2021-Injection/" title: "A03:2021 – Injection" id: "A03:2021" lang: "de" --- {%- 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) }} | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 33 | 19.09 % | 3.37 % | 7.25 | 7.15 | 94.04 % | 47.90 % | 274,228 | 32,078 | ## Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Übersicht", lang=lang, source=source ~ "#" ~ id, parent= osib) }} 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) }} 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) }} 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) }} **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) }} - {{ 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) }} ## 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) }} - {{ 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) }} --- ### 2021 Docs De A04 2021 Insecure Design (`2021/docs/de/A04_2021-Insecure_Design.md`) --- source: "https://owasp.org/Top10/A04_2021-Insecure_Design/" title: "A04:2021 – Unsicheres Anwendungsdesign" id: "A04:2021" lang: "de" --- {%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%} {%- set osib = parent ~ ".4" -%} #A04:2021 – Unsicheres Anwendungsdesign {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name ="Unsicheres Design", lang=lang, source=source, parent=parent) }} ## Beurteilungskriterien {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 40 | 24.19 % | 3.00 % | 6.46 | 6.78 | 77.25 % | 42.51 % | 262,407 | 2,691 | ## Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Übersicht", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Eine der neuen Kategorie für 2021 konzentriert sich auf Risiken im Zusammenhang mit Design- und Architekturfehlern und fordert einen stärkeren Einsatz von Bedrohungsmodellierung, sicheren Design Pattern und Referenzarchitekturen. Als Community sollten wir uns nicht nur auf den "Shift-Left"-Ansatz während der Entwicklung fokussieren, sondern auch auf die vorangehenden Aktivitäten, die für die Prinzipien von „Secure by Design“ wesentlich sind. Bemerkenswerte Common Weakness Enumerations (CWEs) sind *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*. ## Beschreibung {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Beschreibung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Unsicheres Design ist eine umfassende Kategorie, die verschiedene Schwachstellen umfasst und als „fehlendes oder ineffektives Design von Schutzmechanismen“ beschrieben wird.Unsicheres Anwendungsdesign ist nicht die Ursache für alle anderen Top-10-Risikokategorien. Es gibt einen Unterschied zwischen unsicherem Design und unsicherer Implementierung. Designfehler und Implementierungsfehler unterscheiden sich aus gutem Grund, da sie unterschiedliche Ursachen und Mitigationen erfordern. Ein sicheres Design kann immer noch Implementierungsfehler enthalten, die zu ausnutzbaren Schwachstellen führen. Ein unsicheres Design lässt sich nicht durch eine perfekte Implementierung beheben, da die notwendigen Sicherheitskontrollen von vornherein nicht zur Abwehr bestimmter Angriffe vorgesehen waren. Ein Faktor, der zu einem unsicheren Design beiträgt, ist das Fehlen eines Geschäftsrisikoprofils, das der entwickelten Software oder dem System zugrunde liegt, was dazu führt, dass das erforderliche Maß an Sicherheitsdesign nicht bestimmt wird. ### Anforderungs- und Ressourcenmanagement Legen Sie zusammen mit den Geschäftseinheiten die fachlichen Anforderungen an die Anwendung fest, einschließlich des Schutzbedarfs hinsichtlich Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität aller Datenbestände, sowie die vorgesehene Geschäftslogik. Berücksichtigen Sie, wie exponiert Ihre Anwendung sein wird und ob Sie (zusätzlich zur Zugangskontrolle) eine Mandantentrennung benötigt. Stellen Sie die technischen Anforderungen zusammen, einschließlich funktionaler und nicht funktionaler Sicherheitsanforderungen. Planen Sie das Budget für alle Design-, Entwicklungs-, Test- und Betriebsaktivitäten, unter Berücksichtigung der Sicherheit. ### Sicheres Design Sicheres Design ist sowohl eine Denkweise als auch eine Vorgehensweise, die kontinuierlich Bedrohungen analysiert und sicherstellt, dass der Code robust entwickelt und getestet wird, um bekannte Angriffsmethoden zu verhindern. Die Bedrohungsmodellierung sollte in *Backlog Refinement* Terminen oder vergleichbaren Aktivitäten integriert werden. Dabei sollten Änderungen im Datenfluss, in der Zugriffskontrolle und anderen Sicherheitsmaßnahmen überprüft werden. Identifizieren Sie während der Entwicklung der User Story die richtigen Ablauf- und Fehlerzustände und stellen Sie sicher, dass sie gut verstanden sind und die Verantwortlichen und sonstigen Beteiligten dazu übereinstimmen. Analysieren Sie Annahmen und Bedingungen für erwartete sowie fehlgeschlagene Prozesse, um sicherzustellen, dass diese weiterhin angemessen und die erwünschten sind. Bestimmen Sie, wie Annahmen überprüft und Bedingungen erzwingt werden können, die für das korrekte Verhalten erforderlich sind. Stellen Sie sicher, dass die Ergebnisse in der User Story dokumentiert sind. Lernen Sie aus Fehlern und bieten Sie positive Anreize, um kontinuierliche Verbesserungen voranzutreiben. Sicheres Design ist weder ein Add-on noch ein Tool, das Sie einer Software hinzufügen können. ### Sicherer Entwicklungslebenszyklus Sichere Software erfordert einen sicheren Entwicklungslebenszyklus, den Einsatz von sicheren Entwurfsmustern, eine bewährte Methodik, sichere Komponentenbibliotheken, geeignete Tools und Bedrohungsmodellierung. Wenden Sie sich zu Beginn eines Softwareprojekts während der gesamten Projektlaufzeit und Wartung Ihrer Software an Ihre Sicherheitsspezialisten. Erwägen Sie die Nutzung des [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org), um Ihre Bemühungen zur sicheren Softwareentwicklung zu strukturieren. ## 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) }} - Entwickeln und nutzen Sie einen sicheren Entwicklungslebenszyklus mit Unterstützung durch AppSec-Experten bei der Bewertung und Gestaltung von Sicherheits- und Datenschutzkontrollen. - Erstellen und verwenden Sie eine Bibliothek mit sicheren Entwurfsmustern und bewährten, erprobten Komponenten. - Verwenden Sie Bedrohungsmodellierung für kritische Bereiche wie Authentifizierung, Zugriffskontrolle, Geschäftslogik und wichtige Abläufe. - Integrieren Sie Sicherheitsvorgaben und -kontrollen in den User Stories. - Implementieren Sie Plausibilitätsprüfungen auf allen Ebenen Ihrer Anwendung, vom Frontend bis zum Backend. - Schreiben Sie Unit- und Integrationstests, um zu validieren, dass alle kritischen Abläufe resistent gegen das Bedrohungsmodell sind. Stellen Sie Anwendungs- *und* Missbrauchsfälle für jede Ebene Ihrer Anwendung zusammen. - Trennen Sie die Ebenen basierend auf Gefährdungs- und Schutzbedarf auf System- und Netzwerkebene. - Stellen Sie sicher, dass die Trennung der Mandanten konsequent auf allen Ebenen erfolgt. - Begrenzen Sie den Ressourcenverbrauch pro Nutzerin/Nutzer oder Dienst ## 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) }} **Szenario Nr. 1:** Ein Workflow zur Wiederherstellung von Anmeldeinformationen kann „Fragen und Antworten“ enthalten, was jedoch gemäß NIST 800-63b, dem OWASP ASVS und den OWASP Top 10 nicht zulässig ist. Fragen und Antworten können nicht als vertrauenswürdiger Identitätsnachweis betrachtet werden. Mehr als eine Person kann die Antworten kennen, weshalb sie verboten sind. Dieser Code sollte entfernt und durch ein sichereres Design ersetzt werden. **Szenario Nr. 2:** Eine Kinokette bietet Gruppenbuchungsrabatte an und verlangt erst bei mehr als fünfzehn Besuchern eine Anzahlung. Angreifende könnten dieses System ausnutzen, indem sie versuchen, mit wenigen Anfragen sechshundert Sitzplätze in allen Kinos gleichzeitig zu reservieren, was zu erheblichen Einnahmeverlusten führen könnte. **Szenario Nr. 3:** Die E-Commerce-Website einer Einzelhandelskette ist nicht vor Bots geschützt, die von Scalpern betrieben werden, die High-End-Grafikkarten kaufen, um sie auf Auktionsplattformen weiterzuverkaufen. Dies sorgt für schreckliche Publicity bei den Grafikkartenherstellern und Besitzern von Einzelhandelsketten und sorgt für anhaltende Frustration bei Enthusiasten, die diese Karten nicht erwerben können. Sorgfältiges Anti-Bot-Design sowie Automatismen, die z. B. Käufe ablehnen, die innerhalb weniger Sekunden nach Verfügbarkeit getätigt werden, können helfen, unechte Käufe zu identifizieren und solche Transaktionen zu verhindern. ## Referenzen {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent= osib) }} - {{ 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) }} ## 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) }} - {{ 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) }} --- ### 2021 Docs De A05 2021 Security Misconfiguration (`2021/docs/de/A05_2021-Security_Misconfiguration.md`) --- source: "https://owasp.org/Top10/A05_2021-Security_Misconfiguration/" title: "A05:2021 – Sicherheitsrelevante Fehlkonfiguration" id: "A05:2021" lang: "de" --- {%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%} {%- set osib = parent ~ ".5" -%} #A05:2021 – Sicherheitsrelevante Fehlkonfiguration {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id, name ="Sicherheitsfehlkonfiguration", lang=lang, source=source, parent=parent, merged_from=[extra.osib.document ~ ".2017.4", extra.osib.document ~ ".2017.6"]) }} ## Beurteilungskriterien {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 20 | 19.84 % | 4.51 % | 8.12 | 6.56 | 89.58 % | 44.84 % | 208,387 | 789 | ## Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Übersicht", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Die Kategorie rückt auf von Platz 6 in der vorherigen Ausgabe: 90 % der Anwendungen wurden auf irgendeine Form von Fehlkonfiguration getestet, mit einer durchschnittlichen Inzidenzrate von 4 % und über 208.000 Vorkommen einer Common Weakness Enumeration (CWE) in dieser Risikokategorie. Angesichts der zunehmenden Verlagerung hin zu hoch konfigurierbarer Software ist es nicht verwunderlich, dass diese Kategorie aufsteigt. Bemerkenswerte enthaltene CWEs sind *CWE-16 Configuration* und *CWE-611 Unproper Restriction of XML External Entity Reference*. ## Beschreibung {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Beschreibung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Die Anwendung besitzt möglicherweise Schwachstellen, wenn folgendes zutrifft: - Mangelhafte Sicherheitshärtung des Anwendungsstacks oder ungeeignet konfigurierte Berechtigungen auf Cloud-Diensten. - Nicht benötigte Features sind aktiviert oder installiert (z. B. unnötige Ports, Dienste, Seiten, Accounts oder Rechte). - Standardkonten und -passwörter sind aktiviert bzw. unverändert. - Die Fehlerbehandlung gibt Stack-Traces oder andere interne technische Fehlermeldungen an Anwendende preis. - Für aktualisierte Systeme sind die neuesten Sicherheitsfeatures deaktiviert oder nicht sicher konfiguriert. - Die Sicherheitseinstellungen in den Anwendungsservern und -frameworks (z. B. Struts, Spring, ASP.NET), Bibliotheken, Datenbanken etc. sind nicht auf sichere Werte gesetzt. - Der Server sendet keine Sicherheits-Header oder -Direktiven, bzw. diese sind nicht sicher konfiguriert. - Die Software ist veraltet oder verwundbar (siehe [A06:2021-Unsichere oder veraltete Komponenten](A06_2021-Vulnerable_and_Outdated_Components.md)). Ohne einen abgestimmten und reproduzierbaren Prozess zur sicheren Konfiguration sind Systeme einem höheren Risiko ausgesetzt! ## 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) }} Es sollten sichere Installationsprozesse implementiert werden, darunter: - Ein wiederholbarer Härtungsprozess ermöglicht die schnelle und einfache Bereitstellung zusätzlicher Umgebungen, die entsprechend abgesichert sind. Entwicklungs-, Qualitätssicherungs- und Produktionsumgebungen sollten alle identisch konfiguriert sein, wobei in jeder Umgebung unterschiedliche Anmeldeinformationen verwendet werden sollten. Dieser Prozess sollte automatisiert werden, um den Aufwand für die Einrichtung einer neuen sicheren Umgebung zu minimieren. - Eine minimale Plattform ohne unnötige Funktionen, Komponenten, Dokumentation und Beispiele: Entfernen Sie Funktionen und Frameworks die Sie nicht verwenden oder installieren Sie diese erst gar nicht. - Überprüfen und Aktualisieren der Konfigurationen, die für alle Sicherheitshinweise, Updates und Patches im Rahmen des Patch-Verwaltungsprozesses geeignet sind (siehe [A06:2021-Unsichere oder veraltete Komponenten](A06_2021-Vulnerable_and_Outdated_Components.md)). Überprüfen Sie die Cloud-Speicherberechtigungen (z. B. S3-Bucket-Berechtigungen). - Eine segmentierte Anwendungsarchitektur sorgt durch Segmentierung, Containerisierung oder Cloud-Sicherheitsgruppen (ACLs) für eine effektive und sichere Trennung zwischen Komponenten oder Mandanten. - Senden von Sicherheitsanweisungen an Clients, z. B. Sicherheits-Header. - Ein automatisierter Prozess zur Überprüfung der Wirksamkeit der Konfigurationen und Einstellungen in allen Umgebungen. ## Beispielhafte Angriffsszenarien {{ osib_anchor(osib=osib ~ ".example attack Scenarios", id=id ~ "-example_attack_scenarios", name=title ~ ": Mögliche-Angriffsszenarien", lang=lang, source=source ~ "# " ~ id, parent=osib) }} **Szenario Nr. 1:** Der Anwendungsserver wird mit Beispielanwendungen geliefert, die nicht vom Produktionsserver entfernt wurden. Diese Beispielanwendungen weisen bekannte Sicherheitslücken auf, die Angreifende nutzen, um den Server zu gefährden. Angenommen, eine dieser Anwendungen ist die Admin-Konsole und die Standardkonten wurden nicht geändert. In diesem Fall meldet sich die angreifende Person mit Standardkennwörtern an und übernimmt die Kontrolle. **Szenario Nr. 2:** Die Directory Listings wurden auf dem Server nicht deaktiviert. Angreifende entdecken, dass Verzeichnisse einfach aufgelistet werden können. Die angreifende Person findet die kompilierten Java-Klassen und lädt sie herunter, dekompiliert sie und betreibt Reverse Engineering, um den Code anzuzeigen. Dies ermöglicht das Findet eines schwerwiegenden Fehlers in der Zugriffskontrolle in der Anwendung. **Szenario Nr. 3:** Die Konfiguration des Anwendungsservers ermöglicht die Rückgabe detaillierter Fehlermeldungen an Anwendende, z. B. Stack-Traces. Dadurch werden möglicherweise vertrauliche Informationen oder zugrunde liegende Fehler wie Komponentenversionen offengelegt, die bekanntermaßen anfällig sind. **Szenario Nr. 4:** Ein Cloud-Dienstanbieter (CSP) enthält Standardfreigaben, die aus dem Internet für andere Cloud-Nutzende erreichbar sind und ermöglicht dadurch Zugriff auf sensitive Daten in der Cloud. ## Referenzen {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent= osib) }} - {{ 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) }} ## 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) }} - {{ 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.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) }} --- ### 2021 Docs De A06 2021 Vulnerable And Outdated Components (`2021/docs/de/A06_2021-Vulnerable_and_Outdated_Components.md`) --- source: "https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/" title: "A06:2021 – Unsichere oder veraltete Komponenten" id: "A06:2021" lang: "de" --- {%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%} {%- set osib = parent ~ ".6" -%} #A06:2021 – Unsichere oder veraltete Komponenten {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id , name="Vulnerable and Outdated Components", lang=lang, source=source, parent=parent, previous=extra.osib.document ~ ".2017.9") }} ## Beurteilungskriterien {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 3 | 27.96 % | 8.77 % | 5.00 | 5.00 | 51.78 % | 22.47 % | 30,457 | 0 | ## Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Übersicht", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Es belegte Platz 2 in der Top-10-Community-Umfrage, verfügte aber auch über genügend Daten, um es datentechnisch in die Top 10 zu schaffen. Unsichere Komponenten sind ein bekanntes Problem, das wir nur schwer testen und bewerten können. Sie stellen die einzige Kategorie dar, in der den enthaltenen CWEs keine Common Vulnerability and Exposures (CVEs) zugeordnet sind. Daher wird eine standardmäßige Exploit-/Auswirkungsgewichtung von 5,0 verwendet. Bemerkenswerte CWEs sind *CWE-1104: Use of Unmaintained Third-Party Components* und die beiden CWEs aus den Top 10 2013 und 2017. ## Beschreibung {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Beschreibung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Die Anwendung besitzt möglicherweise Schwachstellen, wenn folgendes zutrifft: - Fehlende Kenntnis über die Versionen aller verwendeten Komponenten der in der Anwendung (sowohl client- als auch serverseitig). Dies beinhaltet sowohl direkte als auch indirekte, verschachtelte Abhängigkeiten. - Die verwendete Software besitzt Schwachstellen, wird nicht mehr unterstützt oder ist veraltet. Dies beinhaltet das Betriebssystem, den Web-/Applikationsserver, das Datenbankmanagementsystem (DBMS), Anwendungen, APIs und alle verwendeten Komponenten, Laufzeitumgebungen sowie Bibliotheken. - Schwachstellenscans werden nicht regelmäßig durchgeführt und die sicherheitsrelevanten Bulletins der verwendeten Komponenten sind nicht abonniert. - Die zugrundeliegende Plattform, die Frameworks und die Abhängigkeiten werden nicht risikobasiert und rechtzeitig repariert oder aktualisiert. Dies geschiet in der Regel in Umgebungen, in denen Patchen eine monatliche oder quartalsweise Tätigkeit ist und einer Änderungskontrolle unterliegt. Dies setzt die Organisation unnötigerweise über Tage oder Monate dem Risiko von Schwachstellen aus, für die schon Patches existieren. - Softwareentwickler führen keine Kompatibilitäts-Tests der aktualisierten oder gepatchten Bibliotheken durch. - Die Komponenten sind nicht sicher konfiguriert (siehe [A05:2021-Sicherheitsrelevante Fehlkonfiguration](A05_2021-Security_Misconfiguration.md)). ## 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) }} Es sollte ein Patch-Management-Prozess vorhanden sein: - Entfernen Sie ungenutzte Abhängigkeiten, unnötige Funktionen, Komponenten, Dateien und Dokumentation. - Kontinuierliche Bestandsaufnahme der Versionen sowohl der clientseitigen als auch der serverseitigen Komponenten (z. B. Frameworks, Bibliotheken) und ihrer Abhängigkeiten mithilfe von Tools wie "versions", "OWASP Dependency Check", "retire.js" usw. Überwachen Sie kontinuierlich Quellen wie Common Vulnerability and Exposures (CVE) und die National Vulnerability Database (NVD) für Schwachstellen in den Komponenten. Verwenden Sie Software-Tools zur Analyse der Softwarebestandteile, um den Prozess zu automatisieren. Abonnieren Sie E-Mail-Benachrichtigungen zu Sicherheitslücken im Zusammenhang mit den verwendeten Komponenten. - Beziehen Sie Komponenten nur von offiziellen Quellen über sichere Links. Bevorzugen Sie signierte Pakete, um die Wahrscheinlichkeit zu verringern, dass eine modifizierte, bösartige Komponente enthalten ist (siehe [A08:2021-Fehlerhafte Prüfung der Software- und Datenintegrität](A08_2021-Software_and_Data_Integrity_Failures.md)). - Überwachen Sie Bibliotheken und Komponenten, die nicht gewartet werden oder keine Sicherheitspatches für ältere Versionen erstellen. Wenn das Patchen nicht möglich ist, erwägen Sie die Bereitstellung eines virtuellen Patches zur Überwachung, Erkennung oder zum Schutz vor dem entdeckten Problem. Jede Organisation muss einen fortlaufenden Plan für die Überwachung, Triage und Anwendung von Updates oder Konfigurationsänderungen während der gesamten Lebensdauer der Anwendung oder des Portfolios sicherstellen. ## 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) }} **Szenario Nr. 1:** Komponenten werden normalerweise mit denselben Berechtigungen wie die Anwendung selbst ausgeführt, sodass Fehler in einer Komponente schwerwiegende Auswirkungen haben können. Solche Fehler können zufällig (z. B. ein Programmierfehler) oder absichtlich (z. B. eine Backdoor in einer Komponente) sein. Einige Beispiele für entdeckte ausnutzbare Komponentenschwachstellen sind: - CVE-2017-5638, eine Remote Code Execution Schwachstelle in Struts 2, die Angreifende ermächtigt, beliebigen Code auf dem Server auszuführen, wurde für einige erhebliche Sicherheitsvorfälle verantwortlich gemacht. - Obwohl das Patchen von Internet of Things (IoT) Geräten oft nur sehr schwierig oder unmöglich ist, kann dies sehr wichtig sein (z. B. für biomedizinische Geräte). Es existieren automatisierte Tools, die Angreifenden helfen, nicht gepatchte oder falsch konfigurierte Systeme zu finden. Die Shodan IoT-Suchmaschine kann Ihnen beispielsweise dabei helfen, Geräte zu finden, die immer noch für die im April 2014 gepatchte Heartbleed-Sicherheitslücke verwundbar sind. ## Referenzen {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent= osib) }} - {{ 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) }} ## 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) }} - {{ 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) }} --- ### 2021 Docs De A07 2021 Identification And Authentication Failures (`2021/docs/de/A07_2021-Identification_and_Authentication_Failures.md`) --- source: "https://owasp.org/Top10/A07_2021-identification_and_Authentication_Failures/" title: "A07:2021 – Fehlerhafte Authentifizierung" id: "A07:2021" lang: "de" --- {%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%} {%- set osib = parent ~ ".7" -%} #A07:2021 – Fehlerhafte Authentifizierung {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id=id , name="Fehlerhafte Authentifizierung", lang=lang, source=source, parent=parent, previous=extra.osib.document ~ ".2017.2") }} ## Beurteilungskriterien {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 22 | 14.84 % | 2.55 % | 7.40 | 6.50 | 79.51 % | 45.72 % | 132,195 | 3,897 | ## Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ":Bezug / Kontext / Auswertung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Diese Kategorie, die früher als *Broken Authentication* bekannt war, rutschte von der zweiten Position nach unten und umfasst nun Common Weakness Enumerations (CWEs) im Zusammenhang mit Identifikationsfehlern. Die bedeutendsten CWEs sind - *{{ osib_link(link="osib.mitre.cwe.0.297", doc="", osib=osib) }}* - *{{ osib_link(link="osib.mitre.cwe.0.287", doc="", osib=osib) }}* und - *{{ osib_link(link="osib.mitre.cwe.0.384", doc="", osib=osib) }}* ## Beschreibung {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Beschreibung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Die Überprüfung der Identität des Nutzenden, die Authentifizierung und die Sitzungsverwaltung sind entscheidend für den Schutz vor authentifizierungsbezogenen Angriffen. Schwachstellen bei der Authentifizierung können auftreten, falls die Anwendung: - automatisierte Angriffe wie Credential Stuffing zulässt, bei dem Angreifende über eine Liste gültiger Usernamen und Passwörter verfügen. - Brute-Force- oder andere automatisierte Angriffe ermöglicht. - Standard-, schwache oder gängige Passwörter zulässt, wie z. B. "Passwort1" oder "admin/admin". - schwache oder ineffektive Verfahren zur Wiederherstellung von Anmeldeinformationen und Verfahren für vergessene Passwörtern, wie z. B. „wissensbasierte Antworten“, die nicht sicher gemacht werden können, verwendet werden. - Klartext-, verschlüsselte oder schwach gehashte Kennwortdatenspeicher (siehe [A02:2021-Cryptographic Failures](A02_2021-Cryptographic_Failures.md)) verwendet. - Fehlende oder unwirksame Multi-Faktor-Authentifizierung. - Die Session-ID wird in der URL angezeigt. - Session-IDs nach erfolgreichem Login wieder verwendet werden. - Session-IDs werden nicht korrekt ungültig gemacht. Sitzungen von Benutzenden (user sessions) oder Authentifizierungs-Tokens (hauptsächlich Single Sign-On (SSO) Tokens) werden beim Abmelden oder bei Inaktivität nicht ordnungsgemäß invalidiert. ## 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) }} - Wenn möglich, sollte eine Multi-Faktor-Authentifizierung implementiert werden, um automatisiertes Credential Stuffing, Brute Force-Angriffe und die Wiederverwendung gestohlener Zugangsdaten zu verhindern. - Liefern Sie die Anwendung nicht mit Standard Login-Daten aus, insbesondere nicht für Administrator-Konten. - Implementieren Sie Prüfungen auf schwache Passwörter, wie z. B. durch den Vergleich von neuen oder geänderten Passwörtern mit der Liste der 10.000 schlechtesten Passwörter. - Angleichung der Passwortlänge, -komplexität und -rotation an die Richtlinien des National Institute of Standards and Technology (NIST) 800-63b in Abschnitt 5.1.1 "Memorized Secrets" oder andere modernen, bewährten Passwortrichtlinien. - Sicherstellen, dass die Registrierung, die Wiederherstellung von Zugangsdaten und die API-Pfade gegen Angriffe zur Ermittlung von Konten gehärtet sind, indem für alle Resultate die gleiche Nachricht ausgegeben wird. - Begrenzen oder bremsen Sie fehlgeschlagene Anmeldeversuche immer weiter aus, aber achten Sie darauf, dass hierbei kein Denial-of-Service-Szenario entsteht. Loggen Sie alle Fehlversuche und alarmieren Sie die Administratoren, wenn Credential Stuffing, Brute Force oder andere Angriffe erkannt werden. - Verwenden Sie einen serverseitigen, sicheren, integrierten Sitzungsmanager, der für jede Sitzung eine neue zufällige Sitzungs-ID mit hoher Entropie erzeugt. Die Sitzungs-ID sollte nicht in der URL enthalten sein, sicher gespeichert werden und nach Abmeldung, Inaktivität und Absoluten Timeouts entwertet werden. ## 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) }} **Szenario Nr. 1:** Credential Stuffing, die Verwendung von Listen mit bekannten Kennwörtern, ist ein gängiger Angriff. Angenommen, eine Anwendung verfügt keinen automatischen Schutz vor Bedrohungen oder Credential Stuffing. In diesem Fall kann die Anwendung als Passwort-Orakel verwendet werden, um festzustellen, ob die Anmeldeinformationen gültig sind. **Szenario #2:** Die meisten Authentifizierungsangriffe erfolgen aufgrund der andauernden Verwendung von Kennwörtern als einzigem Zugangsmerkmal. Die früher als Best Practices geltenden Anforderungen an den Wechsel und die Komplexität von Passwörtern verleiten die Nutzende zur Verwendung und Wiederverwendung schwacher Passwörter. Organisationen wird empfohlen, diese Praktiken gemäß NIST 800-63 einzustellen und eine Mehrfaktor-Authentifizierung zu verwenden. **Szenario #3:** Die Session-Timeouts von Anwendungen sind nicht korrekt gesetzt. Eine Nutzerin/Nutzer verwendet einen öffentlichen Computer, um auf eine Anwendung zuzugreifen. Anstatt sich abzumelden, schließt die nutzende Person einfach die Browser-Registerkarte und geht weg. Angreifende verwenden denselben Browser eine Stunde später, und die Nutzerin/Nutzer ist noch immer authentifiziert. ## Referenzen {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": Referenzen", lang=lang, source=source ~ "#" ~ id, parent= osib) }} - {{ 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) }} ## 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) }} - {{ 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) }} --- ### 2021 Docs De A08 2021 Software And Data Integrity Failures (`2021/docs/de/A08_2021-Software_and_Data_Integrity_Failures.md`) --- source: "https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/" title: "A08:2021 – Fehlerhafte Prüfung der Software- und Datenintegrität" id: "A08:2021" lang: "de" --- {%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%} {%- set osib = parent ~ ".8" -%} #A08:2021 – Fehlerhafte Prüfung der Software- und Datenintegrität {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id= id, name="Software- und Datenintegritätsfehler", lang=lang, source=source, parent=parent, previous=extra.osib.document ~ ".2017.8") }} ## Beurteilungskriterien {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 10 | 16.67 % | 2.05 % | 6.94 | 7.94 | 75.04 % | 45.35 % | 47,972 | 1,152 | ## Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Übersicht", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Bei der neuen Kategorie für 2021 liegt der Schwerpunkt auf Annahmen in Bezug auf Software-Updates, relevante Daten und CI/CD-Pipelines ohne Überprüfung der Integrität. Eine der am höchsten gewichteten Auswirkungen von Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) Daten. Zu den erwähnenswerten Common Weakness Enumerations (CWEs) gehören: *CWE-829: Inclusion of Functionality from Untrusted Control Sphere*, *CWE-494: Download of Code Without Integrity Check* und *CWE-502: Deserialization of Untrusted Data*. ## Beschreibung {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Beschreibung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Software- und Datenintegritätsfehler beziehen sich auf Code und Infrastruktur, die keine Schutzmaßnahmen gegen Integritätsverletzungen bieten. Ein Beispiel hierfür ist, wenn eine Anwendung auf Plugins, Bibliotheken oder Module aus nicht vertrauenswürdigen Quellen, Repositories und Content Delivery Networks (CDNs) angewiesen ist. Eine unsichere CI/CD-Pipeline kann das Potenzial für unbefugten Zugriff, bösartigen Code oder Systemkompromittierung bieten. Schließlich enthalten viele Anwendungen heute eine automatische Update-Funktion, bei der Updates ohne ausreichende Integritätsprüfung heruntergeladen und auf die zuvor vertrauenswürdige Anwendung angewendet werden. Angreifende könnten ihre eigenen Updates hochladen, die dann auf alle Installationen verbreitet und ausgeführt werden. Ein weiteres Beispiel besteht darin, dass Objekte oder Daten in eine Struktur kodiert oder serialisiert werden, die Angreifende sehen und ändern können, und die durch eine unsichere Deserialisierung verwundbar sind. ## 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) }} - Verwenden Sie digitale Signaturen oder ähnliche Mechanismen, um sicherzustellen, dass die Software oder Daten aus der erwarteten Quelle stammen und nicht verändert wurden. - Stellen Sie sicher, dass Bibliotheken und Abhängigkeiten, wie z. B. npm oder Maven, vertrauenswürdige Repositories nutzen. Wenn Sie ein höheres Risikoprofil haben, sollten Sie in Erwägung ziehen, ein internes Repository zu hosten, das als vertrauenswürdig gilt und überprüft wurde. - Stellen Sie sicher, dass ein Software-Supply-Chain-Sicherheitstool wie OWASP Dependency Check oder OWASP CycloneDX verwendet wird, um zu überprüfen, dass Komponenten keine bekannten Schwachstellen enthalten. - Stellen Sie sicher, dass es einen Überprüfungsprozess für Code- und Konfigurationsänderungen gibt, um das Risiko zu minimieren, dass bösartiger Code oder bösartige Konfigurationen in Ihre Software-Pipeline eingeschleust werden. - Stelle Sie sicher, dass Ihre CI/CD-Pipeline über eine angemessene Trennung, Konfiguration und Zugriffskontrolle verfügt, um die Integrität des Codes zu gewährleisten, der den Build- und Bereitstellungsprozess durchläuft. - Stellen Sie sicher, dass unsignierte oder unverschlüsselte serialisierte Daten nicht an nicht vertrauenswürdige Clients ohne eine Form der Integritätsprüfung oder digitalen Signatur gesendet werden, um dadurch eine Manipulation oder ein erneutes Versenden der serialisierten Daten zu erkennen. ## 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) }} **Szenario Nr. 1: Update ohne Signierung:** Viele Heimrouter, Set-Top-Boxen, Geräte-Firmware und Andere verifizieren Updates nicht über signierte Firmware. Unsignierte Firmware ist ein wachsendes Ziel für Angreifende, und es wird erwartet, dass es in Zukunft noch schlimmer werden wird. Dies ist besonders besorgniserregend, da es in vielen Fällen keinen anderen Mechanismus zur Behebung gibt, als die Fehler in einer zukünftigen Version zu beheben und zu warten, bis die vorherigen Versionen veraltet sind. **Szenario #2 SolarWinds bösartiges Update**: Nationalstaaten sind dafür bekannt, dass sie Update-Mechanismen angreifen. Ein bemerkenswerter Angriff war vor kurzem der SolarWinds-Orion-Angriff. Das Unternehmen, das die Software entwickelt, verfügte über sichere Build- und Update-Integritätsprozesse. Dennoch konnten diese unterwandert werden, und das Unternehmen verteilte über mehrere Monate hinweg ein sehr gezieltes bösartiges Update an mehr als 18.000 Organisationen, von denen etwa 100 betroffen waren. Dies ist eine der weitreichendsten und bedeutendsten Sicherheitsverletzungen dieser Art in der Geschichte. **Szenario #3 Unsichere Deserialisierung:** Eine React-Anwendung ruft eine Reihe von Spring Boot Microservices auf. Als funktionale Programmierer versuchten sie sicherzustellen, dass ihr Code unveränderlich ist. Die Lösung, die sie gefunden haben, besteht darin, den Sitzungszustand zu serialisieren und ihn mit jeder Anfrage hin und her zu schicken. Eine angreifende Person bemerkt die "`rO0" Java-Objektsignatur (in base64) und verwendet das Java Serial Killer-Tool, um Remote-Code-Ausführung auf dem Anwendungsserver zu erlangen. ## Referenzen {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent= osib) }} - {{ 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) }} ## 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) }} - {{ 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) }} --- ### 2021 Docs De A09 2021 Security Logging And Monitoring Failures (`2021/docs/de/A09_2021-Security_Logging_and_Monitoring_Failures.md`) --- source: "https://owasp.org/Top10/09_2021-Security_Logging_and_Monitoring_Failures/" title: "A09:2021 – Unzureichendes Logging und Sicherheitsmonitoring" id: "A09:2021" lang: "de" --- {%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%} {%- set osib = parent ~ ".9" -%} #A09:2021 – Unzureichendes Logging und Sicherheitsmonitoring {: style="height:80px;width:80px" align="right"} {{ osib_anchor(osib=osib, id= id, name="Fehler beim Logging und Monitoring", lang=lang, source=source, parent=parent, previous=extra.osib.document ~ ".2017.10") }} ## Beurteilungskriterien {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 4 | 19.23 % | 6.51 % | 6.87 | 4.99 | 53.67 % | 39.97 % | 53,615 | 242 | ## Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ": Übersicht", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Sicherheitsprotokollierung und -überwachung wurden in der Top-10-Community-Umfrage (Platz 3) genannt, was eine leichte Verbesserung gegenüber dem zehnten Platz in der OWASP Top 10 2017 bedeutet. Das Logging und Monitoring können schwierig zu testen sein, da sie oft Interviews oder die Frage nach der Erkennung von Angriffen während eines Penetrationstests beinhalten. Es gibt nicht viele CVE/CVSS-Daten für diese Kategorie, aber das Erkennen von und Reagieren auf Angriffe ist von entscheidender Bedeutung. Allerdings kann dies für die Nachweisbarkeit, die Nachvollziehbarkeit, die Alarmierung bei Vorfällen und Forensik von großer Bedeutung sein. Diese Kategorie erstreckt sich über *CWE-778 Insufficient Logging* hinaus und umfasst auch *CWE-117 Improper Output Neutralization for Logs*, *CWE-223 Omission of Security-relevant Information* und *CWE-532 Insertion of Sensitive Information into Log File*. ## Beschreibung {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ": Beschreibung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Mit Blick auf die OWASP Top 10 2021 soll diese Kategorie bei der Erkennung, Eskalation und Reaktion auf laufende Angriffe unterstützen. Ohne Protokollierung und Überwachung können Angriffe nicht erkannt werden. Unzureichende Protokollierung, Erkennung, Überwachung und aktive Reaktion sind jederzeit möglich: - Nachvollziehbare Ereignisse, wie Anmeldungen, fehlgeschlagene Anmeldungen und wertvolle Transaktionen, werden nicht protokolliert. - Warnungen und Fehler erzeugen keine, unangemessene oder unklare Log-Einträge. - Die Logs von Anwendungen und APIs werden nicht auf verdächtige Aktivitäten überwacht. - Protokolle werden nur lokal gespeichert. - Geeignete Schwellenwerte für Warnmeldungen und Eskalationsprozesse für Gegenmaßnahmen sind nicht vorhanden oder nicht wirksam. - Penetrationstests und Scans durch DAST-Tools (Dynamic Application Security Testing) (wie OWASP ZAP) lösen keine Alarme aus. - Die Anwendungen können Angriffe weder in Echtzeit noch nahezu in Echtzeit erkennen, eskalieren oder Alarm schlagen. Es besteht die Gefahr von Informationslecks, falls Sie die Logging- und Alerting Ereignisse für Nutzende oder Angreifende sichtbar gemacht werden (siehe [A01:2021-Broken Access Control](A01_2021-Broken_Access_Control.md)). ## 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) }} Je nach dem Risiko der Anwendung sollten Entwickler einige oder alle der folgenden Maßnahmen ergreifen: - Sicherstellen, dass alle Anmeldevorgänge, Zugriffskontrollen und Fehler bei der serverseitigen Eingabeüberprüfung mit ausreichendem Sitzungskontext der Nutzenden erfasst werden, um verdächtige oder böswillige Anwendende zu identifizieren und ausreichend lange gespeichert werden, um eine spätere forensische Analyse zu ermöglichen. - Stellen Sie sicher, dass die Protokolle in einem Format gespeichert werden, das von Protokollmanagement Lösungen leicht verarbeitet werden können. - Es sollte sichergestellt werden, dass die Protokolldaten korrekt umgewandelt werden, sodass Injection-Angriffe oder Angriffe auf Logging- oder Überwachungssysteme verhindert werden. - Es soll sichergestellt sein, dass hochwertige Transaktionen einen Prüfpfad mit Integritätskontrollen aufweisen um Manipulationen oder Löschungen zu verhindern, z. B. durch Datenbanktabellen, die nur erweitert werden können, oder ähnliches. - DevSecOps-Teams sollten eine effektive Überwachung und Alarmierung einrichten, sodass verdächtige Aktivitäten schnell erkannt und darauf reagiert werden kann. - Erstellen oder übernehmen Sie einen Notfallplan für die Reaktion auf Vorfälle und für die Wiederherstellung, wie z. B. dem Leitfaden des National Institute of Standards and Technology (NIST) 800-61r2 oder neuer. Es gibt kommerzielle und Open-Source-Frameworks zum Schutz von Anwendungen wie das OWASP ModSecurity Core Rule Set, und Open-Source-Log correlation software, wie Elasticsearch, Logstash, Kibana (ELK) Stack, die individuelle Dashboards und Warnmeldungen bereitstellen. ## 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) }} **Szenario 1:** Der Betreiber der Website eines Anbieters von Kinderkrankenversicherungen konnte das Eindringen in das System aufgrund mangelnder Überwachung und Protokollierung nicht erkennen. Eine externe Partei informierte den Krankenversicherungsanbieter, dass Angreifende auf Tausende der mehr als 3,5 Millionen sensiblen Gesundheitsdaten der Kinder zugegriffen und diese verändert hatten. Eine Überprüfung nach dem Vorfall ergab, dass die Entwickler der Website wesentliche Schwachstellen nicht behoben hatten. Da es weder eine Protokollierung noch eine Überwachung des Systems gab, bestand die Datenlücke möglicherweise bereits seit 2013, also über einen Zeitraum von mehr als sieben Jahren. **Szenario #2:** Bei einer größeren indischen Fluggesellschaft kam es zu einer Datenpanne, die mehr als zehn Jahre lang personenbezogene Daten von Millionen von Fluggästen betraf, einschließlich Reisepass- und Kreditkartendaten. Die Datenpanne trat bei einem externen Cloud-Hosting-Anbieter auf, der die Fluggesellschaft nach einiger Zeit über die Lücke informierte. **Szenario #3:** Bei einer großen europäischen Fluggesellschaft kam es zu einem meldepflichtigen Verstoß gegen die DSGVO. Der Verstoß wurde Berichten zufolge durch Sicherheitsschwachstellen in Zahlungsanwendungen verschuldet, die von Angreifenden ausgenutzt wurden, die mehr als 400.000 Zahlungsdatensätze von Kunden abfingen. Die Fluggesellschaft wurde daraufhin von der Datenschutzbehörde mit einer Geldstrafe von 20 Millionen Pfund belegt. ## Referenzen {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ": References", lang=lang, source=source ~ "#" ~ id, parent= osib) }} - {{ 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) }} ## 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) }} - {{ 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) }} --- ### 2021 Docs De A10 2021 Server Side Request Forgery (SSRF) (`2021/docs/de/A10_2021-Server-Side_Request_Forgery_(SSRF).md`) --- source: "https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_(SSRF)/" title: "A10:2021 – Server-Side Request Forgery (SSRF)" id: "A10:2021" lang: "de" --- {%- 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) }} ## Beurteilungskriterien {{ osib_anchor(osib=osib ~ ".factors", id=id ~ "-factors", name=title ~ ": Factors", lang=lang, source=source ~ "#" ~ id, parent=osib) }} | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 1 | 2.72 % | 2.72 % | 8.28 | 6.72 | 67.72 % | 67.72 % | 9,503 | 385 | ## Übersicht {{ osib_anchor(osib=osib ~ ".overview", id=id ~ "-overview", name=title ~ ":Übersicht", lang=lang, source=source ~ "#" ~ id, parent= osib) }} Diese Kategorie stammt aus der Top-10-Community-Umfrage (Nr. 1). Die Daten zeigen eine relativ niedrige Häufigkeit mit einer überdurchschnittlichen Testabdeckung und überdurchschnittlichen Missbrauchs- und Auswirkungspotentialen. Da es sich bei neuen Einträgen wahrscheinlich um einzelne oder kleine Gruppen von Common Weakness Enumerations (CWEs) handelt, die für Aufmerksamkeit und Bewusstsein sorgen, besteht die Hoffnung, dass sie in einer zukünftigen Ausgabe in eine größere Kategorie aufgenommen werden können. ## Beschreibung {{ osib_anchor(osib=osib ~ ".description", id=id ~ "-description", name=title ~ ":Beschreibung", lang=lang, source=source ~ "#" ~ id, parent= osib) }} SSRF-Schwachstellen treten immer dann auf, wenn eine Webanwendung eine Remote-Ressource abruft, ohne die, vom Nutzenden angegebene URL zu überprüfen. Dadurch kann ein Angreifender die Anwendung dazu zwingen, eine manipulierte Anfrage an ein unerwartetes Ziel zu senden, selbst wenn sie durch eine Firewall, ein VPN oder eine andere Art von Netzwerkzugriffskontrollliste (ACL) geschützt ist. Da moderne Webanwendungen Nutzenden komfortable Funktionen bieten, wird das Abrufen einer URL zu einem gängigen Szenario. Infolgedessen nimmt die Häufigkeit von SSRF zu. Außerdem nimmt der Schweregrad von SSRF aufgrund von der Verbreitung von Cloud-Diensten und der Komplexität der Architekturen zu. ## 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) }} Entwickler können SSRF verhindern, indem sie folgende Defense-in-Depth-Controls implementieren: ### **Auf der Netzwerk-Ebene** - Segmentieren Sie die Remote-Ressourcenzugriffsfunktionalität in separate Netzwerke, um die Auswirkungen von SSRF zu reduzieren. - Setzen Sie standardmäßig blockierende Firewall-Richtlinien oder Netzwerkzugriffskontrollregeln ein, um den gesamten Intranet-Verkehr zu blockieren, der nicht unbedingt erforderlich ist.
*Hinweise:*
~ Legen Sie eine Zuständigkeit und einen Lebenszyklus für Firewall-Regeln auf der Grundlage von Anwendungen fest.
~ Protokollieren aller akzeptierten *und* blockierten Netzströme auf Firewalls (siehe [A09:2021 – Fehler beim Logging und Monitoring](A09_2021-Security_Logging_and_Monitoring_Failures.md)). ### **Auf der Anwendungsebene:** * Bereinigung und Validierung aller vom Client gelieferten Eingabedaten * Erzwingen Sie das URL-Schema, den Port und das Ziel mit einer Positivliste * Senden Sie keine ungeprüften Antworten an Clients. * Deaktivieren Sie HTTP-Umleitungen. * Achten Sie auf die URL-Konsistenz, um Angriffe wie DNS-Rebinding und „time of check, time of use“ (TOCTOU) Race Conditions zu vermeiden Verhindern Sie SSRF nicht durch die Verwendung einer Negativliste oder eines regulären Ausdrucks. Angreifer verfügen über Payload-Listen, Tools und Fähigkeiten zum Umgehen von Negativlisten. ### **Zusätzliche zu berücksichtigende Maßnahmen:** - Setzen Sie keine anderen sicherheitsrelevanten Dienste auf Frontsystemen ein (z. B. OpenID). Kontrollieren Sie den lokalen Verkehr auf diesen Systemen (z. B. localhost). - Für Frontends mit dedizierten und verwaltbaren Gruppen für Anwendende nutzen Sie Netzwerkverschlüsselung (z. B. VPNs) auf unabhängigen Systemen um sehr hohen Schutzbedarf zu berücksichtigen. ## 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) }} Angreifende können SSRF nutzen, um Systeme anzugreifen, die durch Web Application Firewalls, Firewalls oder Netzwerk-ACLs geschützt sind, und dabei Szenarien wie folgende verwenden: **Szenario Nr. 1:** Port-Scan interner Server – Wenn die Netzwerkarchitektur nicht segmentiert ist, können Angreifende interne Netzwerke abbilden und anhand der Verbindungsergebnisse oder der verstrichenen Zeit für die Verbindung oder Ablehnung von SSRF-Nutzlast-Verbindungen feststellen, ob Ports auf internen Servern offen oder geschlossen sind. **Szenario Nr. 2:** Preisgabe sensibler Daten – Angreifende können auf lokale Dateien oder interne Dienste zugreifen, um vertrauliche Informationen wie „file:///etc/passwd“ und „http://localhost:28017/“ zu erhalten. **Szenario Nr. 3:** Zugriff auf Metadatenspeicher von Cloud-Diensten – Die meisten Cloud-Anbieter verfügen über Metadatenspeicher wie „http://169.254.169.254/“. Eine angreifende Person kann die Metadaten lesen, um an vertrauliche Informationen zu gelangen. **Szenario Nr. 4:** Kompromittierung interner Dienste – Die angreifende Person kann interne Dienste missbrauchen, um weitere Angriffe wie beispielsweise Remote Code Execution (RCE) oder Denial of Service (DoS) durchzuführen. ## Referenzen {{ osib_anchor(osib=osib ~ ".references", id=id ~ "-references", name=title ~ ":Referenzen", lang=lang, source=source ~ "#" ~ id, parent= osib) }} - {{ 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) }} ## 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) }} - {{ osib_link(link="osib.mitre.cwe.0.918", doc="", osib=osib) }} --- ### 2021 Docs De A11 2021 Next Steps (`2021/docs/de/A11_2021-Next_Steps.md`) --- source: "https://owasp.org/Top10/A11_2021-Next_Steps/" title: "A11:2021 – Nächste Schritte" id: "A11:2021" lang: "de" --- {%- set parent = extra.osib.document ~ "." ~ extra.osib.version -%} {%- set osib = parent ~ ".11" -%} #A11:2021 – Nächste Schritte {{ osib_anchor(osib=osib, id=id, name="Nächste Schritte", lang=lang, source=source, parent=parent) }} Die OWASP Top 10 sind von Natur aus auf die zehn bedeutendsten Risiken beschränkt. Jede OWASP Top 10 hat Risiken, die an der Schwelle zur Aufnahme in die Top 10 stehen, die aber letztendlich doch nicht in die Liste aufgenommen wurden. Ganz gleich, wie wir die Daten zu interpretieren oder zu verändern versuchten, die anderen Risiken waren weitaus häufiger und schwerwiegender. Für Unternehmen, die auf ein ausgereiftes Programm zur Anwendungssicherheit hinarbeiten, oder für Sicherheitsberatungsunternehmen und Tool-Anbieter, die ihre Angebote erweitern möchten, lohnen sich die folgenden vier Probleme, die es zu identifizieren und zu beheben gilt. ## Probleme mit der Codequalität | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 38 | 49.46 % | 2.22 % | 7.1 | 6.7 | 60.85 % | 23.42 % | 101736 | 7564 | - **Beschreibung.** Zu den Problemen der Codequalität gehören bekannte Sicherheitsmängel oder -muster, die Wiederverwendung von Variablen für mehrere Zwecke, die Offenlegung vertraulicher Informationen in der Debugging-Ausgabe, Off-by-One-Fehler, TOCTOU-Race-Conditions (Time of Check/Time of Use), Konvertierungsfehler bei der Verwendung von vorzeichenlosen oder vorzeichenbehafteten Daten, die Verarbeitung nach dem Freigeben von Daten und vieles mehr. Das Besondere an diesem Abschnitt ist, dass sie in der Regel durch strenge Compiler-Flags, statische Code-Analyse-Tools und Linter-IDE-Plugins identifiziert werden können. Moderne Sprachen haben viele dieser Probleme durch ihr Design eliminiert, wie z. B. Rusts Konzept des Speicherbesitzes und der -ausleihe, Rusts Threading-Design und die strikte Typisierung und Grenzwertprüfung in Go. - **Prävention und Gegenmaßnahmen**. Aktivieren und verwenden Sie die statische Code- Analyse Ihres Editors und Ihrer Sprache. Erwägen Sie die Verwendung eines Tools zur statischen Codeanalyse. Überlegen Sie, ob es möglich ist, eine Sprache oder ein Framework zu verwenden oder dorthin zu migrieren, welches Fehlerklassen eliminiert, wie z. B. in Rust oder Go. - **Beispielhafte Angriffsszenarien**. Ein Angreifer könnte vertrauliche Informationen erhalten oder verändern, indem er eine Race Condition ausnutzt, die eine statisch freigegebene Variable in mehreren Threads verwendet. - **Referenzen** - {{ 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 | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 8 | 17.54 % | 4.89 % | 8.3 | 5.9 | 79.58 % | 33.26 % | 66985 | 973 | - **Beschreibung**. Mit den nötigen Ressourcen ist ein Denial-of-Service immer möglich. Design- und Programmierpraktiken haben jedoch einen erheblichen Einfluss auf das Ausmaß des Denial-of-Service. Mit ausreichenden Ressourcen ist eine Denial of Service immer möglich. Allerdings haben Design und Programmierpraktiken einen erheblichen Einfluss auf das Ausmaß des Denial of Service. Angenommen, jede Person mit einem Link kann auf eine große Datei zugreifen, oder auf jeder Seite findet eine rechenintensive Transaktion statt. In diesem Fall ist die Denial-of-Service-Attacke mit weniger Aufwand zu bewerkstelligen. - **Prävention und Gegenmaßnahmen**. Testen Sie die Effizienz des Codes auf CPU-, E/A- und Speichernutzung, überarbeiten, optimieren oder cachen Sie aufwendige Operationen. Erwägen Sie Zugriffskontrollen für größere Objekte, um sicherzustellen, dass nur autorisierte Personen auf große Dateien oder Objekte zugreifen können, oder stellen Sie sie über ein Edge-Caching-Netzwerk bereit. - **Beispielhafte Angriffsszenarien**. Ein Angreifer könnte feststellen, dass ein Vorgang 5-10 Sekunden benötigt, um ihn abzuschließen. Wenn vier Threads gleichzeitig laufen, scheint der Server nicht mehr zu reagieren. Der Angreifer nutzt 1000 Threads und nimmt das gesamte System offline. - **Referenzen** - {{ 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) }} ## Speicherverwaltungsfehler | Zugeordnete CWEs | Maximale Häufigkeit | Durchschn. Häufigkeit | Durchschn. Ausnutzbarkeit (gewichtet) | Durchschn. Auswirkungen (gewichtet) | Maximale Abdeckung | Durchschnittliche Abdeckung | Gesamtanzahl | CVEs insgesamt | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 14 | 7.03 % | 1.16 % | 6.7 | 8.1 | 56.06 % | 31.74 % | 26576 | 16184 | - **Beschreibung**. Webanwendungen werden in der Regel in Managed Memory-Sprachen geschrieben, wie zum Beispiel Java, .NET oder node.js (JavaScript oder TypeScript). Allerdings sind diese Sprachen in Systemsprachen geschrieben, die Probleme mit der Speicherverwaltung haben, z. B. Puffer- oder Heap-Überläufe, Use after free, Integer-Überläufe und mehr. Im Laufe der Jahre gab es viele Sandbox-„Ausbrüche“, die zeigen, dass nur weil die Webanwendungssprache nominell „ speicher- sicher“ ist, die Grundlagen es nicht sind. - **Prävention und Gegenmaßnahmen**. Viele moderne APIs sind heute in speichersicheren Sprachen wie Rust oder Go geschrieben. Im Fall von Rust ist die Speichersicherheit ein entscheidendes Merkmal der Sprache. Bei vorhandenem Code kann die Verwendung von strengen Compiler-Flags, starker Typisierung, statischer Codeanalyse und Fuzzing-Tests bei der Identifizierung von Speicherlecks, Speicher- und Array-Überläufen und vielem mehr hilfreich sein. - **Beispielhafte Angriffsszenarien**. Puffer- und Heap-Überläufe sind seit Jahren ein beliebtes Ziel von Angreifern. Der Angreifer sendet dabei Daten an ein Programm, welches diese in einem zu kleinen Stack-Puffer speichert. Dies hat zur Folge, dass Informationen auf dem Call Stack überschrieben werden, darunter auch der Rückgabezeiger der Funktion. Die Daten legen den Wert des Rückgabezeigers fest, so dass bei der Rückkehr der Funktion die Kontrolle an den in den Daten des Angreifers enthaltenen Schadcode übergeben wird. - **Referenzen** - {{ 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 En 0x00 2021 Introduction (`2021/docs/en/0x00_2021-introduction.md`) # Introduction ## Welcome to the OWASP Top 10 - 2021 {: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 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](A01_2021-Broken_Access_Control.md)** moves up from the fifth position 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](A02_2021-Cryptographic_Failures.md)** shifts up one position to #2, previously known as **A3:2017-Sensitive Data Exposure**, 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](A03_2021-Injection.md)** 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.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](A04_2021-Insecure_Design.md)** 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](A05_2021-Security_Misconfiguration.md)** moves 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 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 **A4:2017-XML External Entities (XXE)** is now part of this risk category. - **[A06:2021-Vulnerable and Outdated Components](A06_2021-Vulnerable_and_Outdated_Components.md)** 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 #9 in 2017 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](A07_2021-Identification_and_Authentication_Failures.md)** was previously Broken Authentication and is sliding down from the second position, 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](A08_2021-Software_and_Data_Integrity_Failures.md)** 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. **A8:2017-Insecure Deserialization** is now a part of this larger category. - **[A09:2021-Security Logging and Monitoring Failures](A09_2021-Security_Logging_and_Monitoring_Failures.md)** was previously **A10:2017-Insufficient Logging & Monitoring** 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](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** 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 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 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 (SSRF)** 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 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? 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? 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? 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 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. ## 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. - AppSec Labs - Cobalt.io - Contrast Security - GitLab - HackerOne - HCL Technologies - Micro Focus - PenTest-Tools - Probely - Sqreen - Veracode - WhiteHat (NTT) ## Thank you to our sponsors The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior and Just Eat. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs En 0x00 2021 Notice (`2021/docs/en/0x00_2021-notice.md`) # Release Originally released 24th September 2021, v1.1 released 13 July 2025. ## Lead Authors - [Andrew van der Stock](mailto:vanderaj@owasp.org) (twitter: [@vanderaj](https://x.com/vanderaj)) - [Brian Glas](mailto:brian.glas@owasp.org) (twitter: [@infosecdad](https://x.com/infosecdad)) - [Neil Smithline](mailto:neil.smithline@owasp.org) (twitter: [@appsecneil](https://x.com/appsecneil)) - [Torsten Gigler](mailto:torsten.gigler@owasp.org) (twitter: [@torsten_tweet](https://x.com/torsten_tweet)) ## Contributors - Orange Tsai [@orange_8361](https://x.com/orange_8361), Author of A10-2021: Server Side Request Forgery - Jim Manico [@manicode](https://x.com/manicode) and Jakub Maćkowski [@kubamackowski](https://x.com/kubamackowski) - OWASP CheatSheets Coordination ## How you can help At this stage, we are asking for - Data scientists - please peer review our analysis - Web designers - we need to make a mobile friendly version - Translators - please review the English text to make sure it's translatable - ASVS, Testing Guide, and Code Review Guide leadership - please use our data and help us link our documents and standards together ## Log issues and pull requests Please log any corrections or issues: - [https://github.com/OWASP/Top10/issues](https://github.com/OWASP/Top10/issues) --- ### 2021 Docs En 0x01 2021 About Owasp (`2021/docs/en/0x01_2021-about-owasp.md`) # About OWASP The Open Worldwide Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications and APIs that can be trusted. At OWASP, you'll find free and open: - Application security tools and standards - Cutting edge research - Standard security controls and libraries - Complete books on application security testing, secure code development, and secure code review - Presentations and [videos](https://www.youtube.com/user/OWASPGLOBAL) - [Cheat sheets](https://cheatsheetseries.owasp.org/) on many common topics - [Chapters meetings](https://owasp.org/chapters/) - [Events, training, and conferences](https://owasp.org/events/). - [Google Groups](https://groups.google.com/g/owasp) Learn more at: [https://owasp.org](https://owasp.org). All OWASP tools, documents, videos, presentations, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem, because the most effective approaches to application security require improvements in these areas. OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, and cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. OWASP produces many types of materials in a collaborative, transparent, and open way. The OWASP Foundation is the non-profit entity that ensures the project's long-term success. Almost everyone associated with OWASP is a volunteer, including the OWASP board, chapter leaders, project leaders, and project members. We support innovative security research with grants and infrastructure. Come join us! ## Copyright and License Copyright © 2003-2025 The OWASP® Foundation, Inc. This document is released under the Creative Commons Attribution Share-Alike 4.0 license. For any reuse or distribution, you must make it clear to others the license terms of this work. --- ### 2021 Docs En A00 2021 How To Start An AppSec Program With The OWASP Top 10 (`2021/docs/en/A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10.md`) # How to start an AppSec Program with the OWASP Top 10 Previously, the OWASP Top 10 was never designed to be the basis for an AppSec program. However, it's essential to start somewhere for many organizations just starting out on their application security journey. The OWASP Top 10 2021 is a good start as a baseline for checklists and so on, but it's not in itself sufficient. ## Stage 1. Identify the gaps and goals of your appsec program Many Application Security (AppSec) programs try to run before they can crawl or walk. These efforts are doomed to failure. We strongly encourage CISOs and AppSec leadership to use [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org) to identify weaknesses and areas for improvement over a 1-3 year period. The first step is to evaluate where you are now, identify the gaps in governance, design, implementation, verification, and operations you need to resolve immediately versus those that can wait, and prioritize implementing or improving the fifteen OWASP SAMM security practices. OWASP SAMM can help you build and measure improvements in your software assurance efforts. ## Stage 2. Plan for a paved road secure development lifecycle Traditionally the preserve of so-called "unicorns", the paved road concept is the easiest way to make the most impact and scale AppSec resources with development team velocity, which only increases every year. The paved road concept is "the easiest way is also the most secure way" and should involve a culture of deep partnerships between the development team and the security team, preferably such that they are one and the same team. The paved road aims to continuously improve, measure, detect and replace insecure alternatives by having an enterprise-wide library of drop-in secured replacements, with tooling to help see where improvements can be made by adopting the paved road. This allows existing development tools to report on insecure builds and help development teams self-correct away from insecure alternatives. The paved road might seem a lot to take in, but it should be built incrementally over time. There are other forms of appsec programs out there, notably the Microsoft Agile Secure Development Lifecycle. Not every appsec program methodology suits every business. ## Stage 3. Implement the paved road with your development teams Paved roads are built with the consent and direct involvement of the relevant development and operations teams. The paved road should be aligned strategically with the business and help deliver more secure applications faster. Developing the paved road should be a holistic exercise covering the entire enterprise or application ecosystem, not a per-app band-aid, as in the old days. ## Stage 4. Migrate all upcoming and existing applications to the paved road Add paved road detection tools as you develop them and provide information to development teams to improve the security of their applications by how they can directly adopt elements of the paved road. Once an aspect of the paved road has been adopted, organizations should implement continuous integration checks that inspect existing code and check-ins that use prohibited alternatives and warn or reject the build or check-in. This prevents insecure options from creeping into code over time, preventing technical debt and a defective insecure application. Such warnings should link to the secure alternative, so the development team is given the correct answer immediately. They can refactor and adopt the paved road component quickly. ## Stage 5. Test that the paved road has mitigated the issues found in the OWASP Top 10 Paved road components should address a significant issue with the OWASP Top 10, for example, how to automatically detect or fix vulnerable components, or a static code analysis IDE plugin to detect injections or even better start using a library that is known safe against injection. The more of these secure drop-in replacements provided to teams, the better. A vital task of the appsec team is to ensure that the security of these components is continuously evaluated and improved. Once they are improved, some form of communication pathway with consumers of the component should indicate that an upgrade should occur, preferably automatically, but if not, at least highlighted on a dashboard or similar. ## Stage 6. Build your program into a mature AppSec program You must not stop at the OWASP Top 10. It only covers 10 risk categories. We strongly encourage organizations to adopt the Application Security Verification Standard and progressively add paved road components and tests for Level 1, 2, and 3, depending on the developed applications' risk level. ## Going beyond All great AppSec programs go beyond the bare minimum. Everyone must keep going if we're ever going to get on top of appsec vulnerabilities. - **Conceptual integrity**. Mature AppSec programs must contain some concept of security architecture, whether a formal cloud or enterprise security architecture or threat modeling - **Automation and scale**. Mature AppSec programs try to automate as much of their deliverables as possible, using scripts to emulate complex penetration testing steps, static code analysis tools directly available to the development teams, assisting dev teams in building appsec unit and integration tests, and more. - **Culture**. Mature AppSec programs try to build out the insecure design and eliminate the technical debt of existing code by being a part of the development team and not to the side. AppSec teams who see development teams as "us" and "them" are doomed to failure. - **Continuous improvement**. Mature AppSec programs look to constantly improve. If something is not working, stop doing it. If something is clunky or not scalable, work to improve it. If something is not being used by the development teams and has no or limited impact, do something different. Just because we've done testing like desk checks since the 1970s doesn't mean it's a good idea. Measure, evaluate, and then build or improve. --- ### 2021 Docs En A00 2021 How To Use The OWASP Top 10 As A Standard (`2021/docs/en/A00_2021_How_to_use_the_OWASP_Top_10_as_a_standard.md`) # How to use the OWASP Top 10 as a standard The OWASP Top 10 is primarily an awareness document. However, this has not stopped organizations from using it as a de facto industry AppSec standard since its inception in 2003. If you want to use the OWASP Top 10 as a coding or testing standard, know that it is the bare minimum and just a starting point. One of the difficulties of using the OWASP Top 10 as a standard is that we document AppSec risks, and not necessarily easily testable issues. For example, A04:2021-Insecure Design is beyond the scope of most forms of testing. Another example is testing whether in-place, in-use, and effective logging and monitoring are implemented, which can only be done with interviews and requesting a sampling of effective incident responses. A static code analysis tool can look for the absence of logging, but it might be impossible to determine if business logic or access control is logging critical security breaches. Penetration testers may only be able to determine that they have invoked incident response in a test environment, which is rarely monitored in the same way as production. Here are our recommendations for when it is appropriate to use the OWASP Top 10: | Use Case | OWASP Top 10 2021 | OWASP Application Security Verification Standard | |-------------------------|:-------------------:|:--------------------------------------------------:| | Awareness | Yes | | | Training | Entry level | Comprehensive | | Design and architecture | Occasionally | Yes | | Coding standard | Bare minimum | Yes | | Secure Code review | Bare minimum | Yes | | Peer review checklist | Bare minimum | Yes | | Unit testing | Occasionally | Yes | | Integration testing | Occasionally | Yes | | Penetration testing | Bare minimum | Yes | | Tool support | Bare minimum | Yes | | Secure Supply Chain | Occasionally | Yes | We would encourage anyone wanting to adopt an application security standard to use the [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/) (ASVS), as it’s designed to be verifiable and tested, and can be used in all parts of a secure development lifecycle. The ASVS is the only acceptable choice for tool vendors. Tools cannot comprehensively detect, test, or protect against the OWASP Top 10 due to the nature of several of the OWASP Top 10 risks, with reference to A04:2021-Insecure Design. OWASP discourages any claims of full coverage of the OWASP Top 10, because it’s simply untrue. --- ### 2021 Docs En A00 2021 Introduction (`2021/docs/en/A00_2021_Introduction.md`) # Introduction ## Welcome to the OWASP Top 10 - 2021 {: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 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](A01_2021-Broken_Access_Control.md)** moves up from the fifth position 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](A02_2021-Cryptographic_Failures.md)** shifts up one position to #2, previously known as **A3:2017-Sensitive Data Exposure**, 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](A03_2021-Injection.md)** 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.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](A04_2021-Insecure_Design.md)** 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](A05_2021-Security_Misconfiguration.md)** moves 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 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 **A4:2017-XML External Entities (XXE)** is now part of this risk category. - **[A06:2021-Vulnerable and Outdated Components](A06_2021-Vulnerable_and_Outdated_Components.md)** 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 #9 in 2017 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](A07_2021-Identification_and_Authentication_Failures.md)** was previously Broken Authentication and is sliding down from the second position, 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](A08_2021-Software_and_Data_Integrity_Failures.md)** 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. **A8:2017-Insecure Deserialization** is now a part of this larger category. - **[A09:2021-Security Logging and Monitoring Failures](A09_2021-Security_Logging_and_Monitoring_Failures.md)** was previously **A10:2017-Insufficient Logging & Monitoring** 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](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** 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 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 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 (SSRF)** 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 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? 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? 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? 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 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. ## 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. - AppSec Labs - Cobalt.io - Contrast Security - GitLab - HackerOne - HCL Technologies - Micro Focus - PenTest-Tools - Probely - Sqreen - Veracode - WhiteHat (NTT) ## Thank you to our sponsors The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior and Just Eat. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs En A01 2021 Broken Access Control (`2021/docs/en/A01_2021-Broken_Access_Control.md`) # A01:2021 – Broken Access Control {: style="height:80px;width:80px" align="right"} ## Factors | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 34 | 55.97% | 3.81% | 6.92 | 5.93 | 94.55% | 47.72% | 318,487 | 19,013 | ## Overview 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 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 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 **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 - [OWASP Proactive Controls: Enforce Access Controls](https://owasp.org/www-project-proactive-controls/v3/en/c7-enforce-access-controls) - [OWASP Application Security Verification Standard: V4 Access Control](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: Authorization Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README) - [OWASP Cheat Sheet: Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) - [PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) - [OAuth: Revoking Access](https://www.oauth.com/oauth2-servers/listing-authorizations/revoking-access/) ## List of Mapped CWEs [CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) [CWE-23 Relative Path Traversal](https://cwe.mitre.org/data/definitions/23.html) [CWE-35 Path Traversal: '.../...//'](https://cwe.mitre.org/data/definitions/35.html) [CWE-59 Improper Link Resolution Before File Access ('Link Following')](https://cwe.mitre.org/data/definitions/59.html) [CWE-200 Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html) [CWE-201 Exposure of Sensitive Information Through Sent Data](https://cwe.mitre.org/data/definitions/201.html) [CWE-219 Storage of File with Sensitive Data Under Web Root](https://cwe.mitre.org/data/definitions/219.html) [CWE-264 Permissions, Privileges, and Access Controls (should no longer be used)](https://cwe.mitre.org/data/definitions/264.html) [CWE-275 Permission Issues](https://cwe.mitre.org/data/definitions/275.html) [CWE-276 Incorrect Default Permissions](https://cwe.mitre.org/data/definitions/276.html) [CWE-284 Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) [CWE-285 Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) [CWE-352 Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html) [CWE-359 Exposure of Private Personal Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/359.html) [CWE-377 Insecure Temporary File](https://cwe.mitre.org/data/definitions/377.html) [CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak')](https://cwe.mitre.org/data/definitions/402.html) [CWE-425 Direct Request ('Forced Browsing')](https://cwe.mitre.org/data/definitions/425.html) [CWE-441 Unintended Proxy or Intermediary ('Confused Deputy')](https://cwe.mitre.org/data/definitions/441.html) [CWE-497 Exposure of Sensitive System Information to an Unauthorized Control Sphere](https://cwe.mitre.org/data/definitions/497.html) [CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory](https://cwe.mitre.org/data/definitions/538.html) [CWE-540 Inclusion of Sensitive Information in Source Code](https://cwe.mitre.org/data/definitions/540.html) [CWE-548 Exposure of Information Through Directory Listing](https://cwe.mitre.org/data/definitions/548.html) [CWE-552 Files or Directories Accessible to External Parties](https://cwe.mitre.org/data/definitions/552.html) [CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key](https://cwe.mitre.org/data/definitions/566.html) [CWE-601 URL Redirection to Untrusted Site ('Open Redirect')](https://cwe.mitre.org/data/definitions/601.html) [CWE-639 Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html) [CWE-651 Exposure of WSDL File Containing Sensitive Information](https://cwe.mitre.org/data/definitions/651.html) [CWE-668 Exposure of Resource to Wrong Sphere](https://cwe.mitre.org/data/definitions/668.html) [CWE-706 Use of Incorrectly-Resolved Name or Reference](https://cwe.mitre.org/data/definitions/706.html) [CWE-862 Missing Authorization](https://cwe.mitre.org/data/definitions/862.html) [CWE-863 Incorrect Authorization](https://cwe.mitre.org/data/definitions/863.html) [CWE-913 Improper Control of Dynamically-Managed Code Resources](https://cwe.mitre.org/data/definitions/913.html) [CWE-922 Insecure Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/922.html) [CWE-1275 Sensitive Cookie with Improper SameSite Attribute](https://cwe.mitre.org/data/definitions/1275.html) --- ### 2021 Docs En A02 2021 Cryptographic Failures (`2021/docs/en/A02_2021-Cryptographic_Failures.md`) # A02:2021 – Cryptographic Failures {: style="height:80px;width:80px" align="right"} ## Factors | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 29 | 46.44% | 4.49% |7.29 | 6.81 | 79.33% | 34.85% | 233,788 | 3,075 | ## Overview 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 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 ASVS Crypto (V7), Data Protection (V9), and SSL/TLS (V10) ## How to Prevent 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 **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 - [OWASP Proactive Controls: Protect Data Everywhere](https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere) - [OWASP Application Security Verification Standard (V7, 9, 10)](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Cheat Sheet: Transport Layer Protection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) - [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) - [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) - [OWASP Cheat Sheet: Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) - [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) - [OWASP Testing Guide: Testing for weak cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README) ## List of Mapped CWEs [CWE-259 Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html) [CWE-261 Weak Encoding for Password](https://cwe.mitre.org/data/definitions/261.html) [CWE-296 Improper Following of a Certificate's Chain of Trust](https://cwe.mitre.org/data/definitions/296.html) [CWE-310 Cryptographic Issues](https://cwe.mitre.org/data/definitions/310.html) [CWE-319 Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) [CWE-321 Use of Hard-coded Cryptographic Key](https://cwe.mitre.org/data/definitions/321.html) [CWE-322 Key Exchange without Entity Authentication](https://cwe.mitre.org/data/definitions/322.html) [CWE-323 Reusing a Nonce, Key Pair in Encryption](https://cwe.mitre.org/data/definitions/323.html) [CWE-324 Use of a Key Past its Expiration Date](https://cwe.mitre.org/data/definitions/324.html) [CWE-325 Missing Required Cryptographic Step](https://cwe.mitre.org/data/definitions/325.html) [CWE-326 Inadequate Encryption Strength](https://cwe.mitre.org/data/definitions/326.html) [CWE-327 Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html) [CWE-328 Reversible One-Way Hash](https://cwe.mitre.org/data/definitions/328.html) [CWE-329 Not Using a Random IV with CBC Mode](https://cwe.mitre.org/data/definitions/329.html) [CWE-330 Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html) [CWE-331 Insufficient Entropy](https://cwe.mitre.org/data/definitions/331.html) [CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/335.html) [CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/336.html) [CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/337.html) [CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/338.html) [CWE-340 Generation of Predictable Numbers or Identifiers](https://cwe.mitre.org/data/definitions/340.html) [CWE-347 Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html) [CWE-523 Unprotected Transport of Credentials](https://cwe.mitre.org/data/definitions/523.html) [CWE-720 OWASP Top Ten 2007 Category A9 - Insecure Communications](https://cwe.mitre.org/data/definitions/720.html) [CWE-757 Selection of Less-Secure Algorithm During Negotiation('Algorithm Downgrade')](https://cwe.mitre.org/data/definitions/757.html) [CWE-759 Use of a One-Way Hash without a Salt](https://cwe.mitre.org/data/definitions/759.html) [CWE-760 Use of a One-Way Hash with a Predictable Salt](https://cwe.mitre.org/data/definitions/760.html) [CWE-780 Use of RSA Algorithm without OAEP](https://cwe.mitre.org/data/definitions/780.html) [CWE-818 Insufficient Transport Layer Protection](https://cwe.mitre.org/data/definitions/818.html) [CWE-916 Use of Password Hash With Insufficient Computational Effort](https://cwe.mitre.org/data/definitions/916.html) --- ### 2021 Docs En A03 2021 Injection (`2021/docs/en/A03_2021-Injection.md`) # A03:2021 – Injection {: style="height:80px;width:80px" align="right"} ## Factors | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 33 | 19.09% | 3.37% | 7.25 | 7.15 | 94.04% | 47.90% | 274,228 | 32,078 | ## Overview 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 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 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. ## Example Attack Scenarios **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 - [OWASP Proactive Controls: Secure Database Access](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database) - [OWASP ASVS: V5 Input Validation and Encoding](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: SQL Injection,](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection) [Command Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection), and [ORM Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection) - [OWASP Cheat Sheet: Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) - [OWASP Cheat Sheet: SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) - [OWASP Cheat Sheet: Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) - [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) - [OWASP Automated Threats to Web Applications – OAT-014](https://owasp.org/www-project-automated-threats-to-web-applications/) - [PortSwigger: Server-side template injection](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) ## List of Mapped CWEs [CWE-20 Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html) [CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')](https://cwe.mitre.org/data/definitions/74.html) [CWE-75 Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)](https://cwe.mitre.org/data/definitions/75.html) [CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')](https://cwe.mitre.org/data/definitions/77.html) [CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')](https://cwe.mitre.org/data/definitions/78.html) [CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html) [CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)](https://cwe.mitre.org/data/definitions/80.html) [CWE-83 Improper Neutralization of Script in Attributes in a Web Page](https://cwe.mitre.org/data/definitions/83.html) [CWE-87 Improper Neutralization of Alternate XSS Syntax](https://cwe.mitre.org/data/definitions/87.html) [CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')](https://cwe.mitre.org/data/definitions/88.html) [CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')](https://cwe.mitre.org/data/definitions/89.html) [CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')](https://cwe.mitre.org/data/definitions/90.html) [CWE-91 XML Injection (aka Blind XPath Injection)](https://cwe.mitre.org/data/definitions/91.html) [CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')](https://cwe.mitre.org/data/definitions/93.html) [CWE-94 Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html) [CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')](https://cwe.mitre.org/data/definitions/95.html) [CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')](https://cwe.mitre.org/data/definitions/96.html) [CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page](https://cwe.mitre.org/data/definitions/97.html) [CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')](https://cwe.mitre.org/data/definitions/98.html) [CWE-99 Improper Control of Resource Identifiers ('Resource Injection')](https://cwe.mitre.org/data/definitions/99.html) [CWE-100 Deprecated: Was catch-all for input validation issues](https://cwe.mitre.org/data/definitions/100.html) [CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')](https://cwe.mitre.org/data/definitions/113.html) [CWE-116 Improper Encoding or Escaping of Output](https://cwe.mitre.org/data/definitions/116.html) [CWE-138 Improper Neutralization of Special Elements](https://cwe.mitre.org/data/definitions/138.html) [CWE-184 Incomplete List of Disallowed Inputs](https://cwe.mitre.org/data/definitions/184.html) [CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')](https://cwe.mitre.org/data/definitions/470.html) [CWE-471 Modification of Assumed-Immutable Data (MAID)](https://cwe.mitre.org/data/definitions/471.html) [CWE-564 SQL Injection: Hibernate](https://cwe.mitre.org/data/definitions/564.html) [CWE-610 Externally Controlled Reference to a Resource in Another Sphere](https://cwe.mitre.org/data/definitions/610.html) [CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')](https://cwe.mitre.org/data/definitions/643.html) [CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax](https://cwe.mitre.org/data/definitions/644.html) [CWE-652 Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')](https://cwe.mitre.org/data/definitions/652.html) [CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')](https://cwe.mitre.org/data/definitions/917.html) --- ### 2021 Docs En A04 2021 Insecure Design (`2021/docs/en/A04_2021-Insecure_Design.md`) # A04:2021 – Insecure Design {: style="height:80px;width:80px" align="right"} ## Factors | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 40 | 24.19% | 3.00% | 6.46 | 6.78 | 77.25% | 42.51% | 262,407 | 2,691 | ## Overview 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 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 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 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 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)](https://owaspsamm.org) to help structure your secure software development efforts. ## How to Prevent - 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 **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 - [OWASP Cheat Sheet: Secure Design Principles](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) - [OWASP SAMM: Design:Security Architecture](https://owaspsamm.org/model/design/security-architecture/) - [OWASP SAMM: Design:Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/) - [NIST – Guidelines on Minimum Standards for Developer Verification of Software](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) - [The Threat Modeling Manifesto](https://threatmodelingmanifesto.org) - [Awesome Threat Modeling](https://github.com/hysnsec/awesome-threat-modelling) ## List of Mapped CWEs [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) [CWE-209 Generation of Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html) [CWE-213 Exposure of Sensitive Information Due to Incompatible Policies](https://cwe.mitre.org/data/definitions/213.html) [CWE-235 Improper Handling of Extra Parameters](https://cwe.mitre.org/data/definitions/235.html) [CWE-256 Unprotected Storage of Credentials](https://cwe.mitre.org/data/definitions/256.html) [CWE-257 Storing Passwords in a Recoverable Format](https://cwe.mitre.org/data/definitions/257.html) [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) [CWE-280 Improper Handling of Insufficient Permissions or Privileges](https://cwe.mitre.org/data/definitions/280.html) [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) [CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) [CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) [CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) [CWE-430 Deployment of Wrong Handler](https://cwe.mitre.org/data/definitions/430.html) [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) [CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')](https://cwe.mitre.org/data/definitions/444.html) [CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) [CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) [CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) [CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) [CWE-579 J2EE Bad Practices: Non-serializable Object Stored in Session](https://cwe.mitre.org/data/definitions/579.html) [CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) [CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) [CWE-650 Trusting HTTP Permission Methods on the Server Side](https://cwe.mitre.org/data/definitions/650.html) [CWE-653 Insufficient Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) [CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) [CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) [CWE-840 Business Logic Errors](https://cwe.mitre.org/data/definitions/840.html) [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) [CWE-927 Use of Implicit Intent for Sensitive Communication](https://cwe.mitre.org/data/definitions/927.html) [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) [CWE-1173 Improper Use of Validation Framework](https://cwe.mitre.org/data/definitions/1173.html) --- ### 2021 Docs En A05 2021 Security Misconfiguration (`2021/docs/en/A05_2021-Security_Misconfiguration.md`) # A05:2021 – Security Misconfiguration {: style="height:80px;width:80px" align="right"} ## Factors | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 20 | 19.84% | 4.51% | 8.12 | 6.56 | 89.58% | 44.84% | 208,387 | 789 | ## Overview 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.51%, 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 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](A06_2021-Vulnerable_and_Outdated_Components.md)). Without a concerted, repeatable application security configuration process, systems are at a higher risk. ## How to Prevent 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](A06_2021-Vulnerable_and_Outdated_Components.md)). 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 **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 - [OWASP Testing Guide: Configuration Management](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) - [OWASP Testing Guide: Testing for Error Codes](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) - [Application Security Verification Standard V14 Configuration](https://github.com/OWASP/ASVS/blob/master/4.0/en/0x22-V14-Config.md) - [NIST Guide to General Server Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) - [CIS Security Configuration Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) - [Amazon S3 Bucket Discovery and Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) ## List of Mapped CWEs [CWE-2 7PK - Environment](https://cwe.mitre.org/data/definitions/2.html) [CWE-11 ASP.NET Misconfiguration: Creating Debug Binary](https://cwe.mitre.org/data/definitions/11.html) [CWE-13 ASP.NET Misconfiguration: Password in Configuration File](https://cwe.mitre.org/data/definitions/13.html) [CWE-15 External Control of System or Configuration Setting](https://cwe.mitre.org/data/definitions/15.html) [CWE-16 Configuration](https://cwe.mitre.org/data/definitions/16.html) [CWE-260 Password in Configuration File](https://cwe.mitre.org/data/definitions/260.html) [CWE-315 Cleartext Storage of Sensitive Information in a Cookie](https://cwe.mitre.org/data/definitions/315.html) [CWE-520 .NET Misconfiguration: Use of Impersonation](https://cwe.mitre.org/data/definitions/520.html) [CWE-526 Exposure of Sensitive Information Through Environmental Variables](https://cwe.mitre.org/data/definitions/526.html) [CWE-537 Java Runtime Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/537.html) [CWE-541 Inclusion of Sensitive Information in an Include File](https://cwe.mitre.org/data/definitions/541.html) [CWE-547 Use of Hard-coded, Security-relevant Constants](https://cwe.mitre.org/data/definitions/547.html) [CWE-611 Improper Restriction of XML External Entity Reference](https://cwe.mitre.org/data/definitions/611.html) [CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute](https://cwe.mitre.org/data/definitions/614.html) [CWE-756 Missing Custom Error Page](https://cwe.mitre.org/data/definitions/756.html) [CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')](https://cwe.mitre.org/data/definitions/776.html) [CWE-942 Permissive Cross-domain Policy with Untrusted Domains](https://cwe.mitre.org/data/definitions/942.html) [CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag](https://cwe.mitre.org/data/definitions/1004.html) [CWE-1032 OWASP Top Ten 2017 Category A6 - Security Misconfiguration](https://cwe.mitre.org/data/definitions/1032.html) [CWE-1174 ASP.NET Misconfiguration: Improper Model Validation](https://cwe.mitre.org/data/definitions/1174.html) --- ### 2021 Docs En A06 2021 Vulnerable And Outdated Components (`2021/docs/en/A06_2021-Vulnerable_and_Outdated_Components.md`) # A06:2021 – Vulnerable and Outdated Components {: style="height:80px;width:80px" align="right"} ## Factors | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Max Coverage | Avg Coverage | Avg Weighted Exploit | Avg Weighted Impact | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 3 | 27.96% | 8.77% | 51.78% | 22.47% | 5.00 | 5.00 | 30,457 | 0 | ## Overview 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 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](A05_2021-Security_Misconfiguration.md)). ## How to Prevent 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](A08_2021-Software_and_Data_Integrity_Failures.md)). - 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 **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 - [OWASP Application Security Verification Standard: V1 Architecture, design and threat modelling](/www-project-application-security-verification-standard) - [OWASP Dependency Check (for Java and .NET libraries)](/www-project-dependency-check) - [OWASP Testing Guide - Map Application Architecture (OTG-INFO-010)](/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/10-Map_Application_Architecture) - [OWASP Virtual Patching Best Practices](/www-community/Virtual_Patching_Best_Practices) - [The Unfortunate Reality of Insecure Libraries](https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf) - [MITRE Common Vulnerabilities and Exposures (CVE) search](https://www.cvedetails.com/version-search.php) - [National Vulnerability Database (NVD)](https://nvd.nist.gov/) - [Retire.js for detecting known vulnerable JavaScript libraries](https://github.com/retirejs/retire.js/) - [GitHub Advisory Database](https://github.com/advisories) - [Ruby Libraries Security Advisory Database and Tools](https://rubysec.com/) - [SAFECode Software Integrity Controls \[PDF\]](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) ## List of Mapped CWEs [CWE-937 OWASP Top 10 2013: Using Components with Known Vulnerabilities](https://cwe.mitre.org/data/definitions/937.html) [CWE-1035 2017 Top 10 A9: Using Components with Known Vulnerabilities](https://cwe.mitre.org/data/definitions/1035.html) [CWE-1104 Use of Unmaintained Third Party Components](https://cwe.mitre.org/data/definitions/1104.html) --- ### 2021 Docs En A07 2021 Identification And Authentication Failures (`2021/docs/en/A07_2021-Identification_and_Authentication_Failures.md`) # A07:2021 – Identification and Authentication Failures {: style="height:80px;width:80px" align="right"} ## Factors | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 22 | 14.84% | 2.55% | 7.40 | 6.50 | 79.51% | 45.72% | 132,195 | 3,897 | ## Overview 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 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](A02_2021-Cryptographic_Failures.md)). - 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 - 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 **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 - [OWASP Proactive Controls: Implement Digital Identity](https://owasp.org/www-project-proactive-controls/v3/en/c6-digital-identity) - [OWASP Application Security Verification Standard: V2 authentication](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Application Security Verification Standard: V3 Session Management](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: Identity](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/03-Identity_Management_Testing/README), [Authentication](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/README) - [OWASP Cheat Sheet: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) - [OWASP Cheat Sheet: Credential Stuffing](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) - [OWASP Cheat Sheet: Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) - [OWASP Cheat Sheet: Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) - [OWASP Automated Threats Handbook](https://owasp.org/www-project-automated-threats-to-web-applications/) - [NIST 800-63b: 5.1.1 Memorized Secrets](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret) ## List of Mapped CWEs [CWE-255 Credentials Management Errors](https://cwe.mitre.org/data/definitions/255.html) [CWE-259 Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html) [CWE-287 Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) [CWE-288 Authentication Bypass Using an Alternate Path or Channel](https://cwe.mitre.org/data/definitions/288.html) [CWE-290 Authentication Bypass by Spoofing](https://cwe.mitre.org/data/definitions/290.html) [CWE-294 Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html) [CWE-295 Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html) [CWE-297 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/297.html) [CWE-300 Channel Accessible by Non-Endpoint](https://cwe.mitre.org/data/definitions/300.html) [CWE-302 Authentication Bypass by Assumed-Immutable Data](https://cwe.mitre.org/data/definitions/302.html) [CWE-304 Missing Critical Step in Authentication](https://cwe.mitre.org/data/definitions/304.html) [CWE-306 Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html) [CWE-307 Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html) [CWE-346 Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html) [CWE-384 Session Fixation](https://cwe.mitre.org/data/definitions/384.html) [CWE-521 Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html) [CWE-613 Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html) [CWE-620 Unverified Password Change](https://cwe.mitre.org/data/definitions/620.html) [CWE-640 Weak Password Recovery Mechanism for Forgotten Password](https://cwe.mitre.org/data/definitions/640.html) [CWE-798 Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) [CWE-940 Improper Verification of Source of a Communication Channel](https://cwe.mitre.org/data/definitions/940.html) [CWE-1216 Lockout Mechanism Errors](https://cwe.mitre.org/data/definitions/1216.html) --- ### 2021 Docs En A08 2021 Software And Data Integrity Failures (`2021/docs/en/A08_2021-Software_and_Data_Integrity_Failures.md`) # A08:2021 – Software and Data Integrity Failures {: style="height:80px;width:80px" align="right"} ## Factors | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 10 | 16.67% | 2.05% | 6.94 | 7.94 | 75.04% | 45.35% | 47,972 | 1,152 | ## Overview 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 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 - 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 **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 - \[OWASP Cheat Sheet: Software Supply Chain Security\](Coming Soon) - \[OWASP Cheat Sheet: Secure build and deployment\](Coming Soon) - [OWASP Cheat Sheet: Infrastructure as Code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) - [OWASP Cheat Sheet: Deserialization]( ) - [SAFECode Software Integrity Controls]( https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) - [A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack]() - [CodeCov Bash Uploader Compromise](https://about.codecov.io/security-update) - [Securing DevOps by Julien Vehent](https://www.manning.com/books/securing-devops) ## List of Mapped CWEs [CWE-345 Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html) [CWE-353 Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353.html) [CWE-426 Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) [CWE-494 Download of Code Without Integrity Check](https://cwe.mitre.org/data/definitions/494.html) [CWE-502 Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) [CWE-565 Reliance on Cookies without Validation and Integrity Checking](https://cwe.mitre.org/data/definitions/565.html) [CWE-784 Reliance on Cookies without Validation and Integrity Checking in a Security Decision](https://cwe.mitre.org/data/definitions/784.html) [CWE-829 Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html) [CWE-830 Inclusion of Web Functionality from an Untrusted Source](https://cwe.mitre.org/data/definitions/830.html) [CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html) --- ### 2021 Docs En A09 2021 Security Logging And Monitoring Failures (`2021/docs/en/A09_2021-Security_Logging_and_Monitoring_Failures.md`) # A09:2021 – Security Logging and Monitoring Failures {: style="height:80px;width:80px" align="right"} ## Factors | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 4 | 19.23% | 6.51% | 6.87 | 4.99 | 53.67% | 39.97% | 53,615 | 242 | ## Overview 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 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](A01_2021-Broken_Access_Control.md)). - You are vulnerable to injections or attacks on the logging or monitoring systems if log data is not correctly encoded. ## How to Prevent 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 **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 - [OWASP Proactive Controls: Implement Logging and Monitoring](https://top10proactive.owasp.org/archive/2024/the-top-10/c9-security-logging-and-monitoring/) - [OWASP Application Security Verification Standard: V7 Logging and Monitoring](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: Testing for Detailed Error Code](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_for_Error_Code) - [OWASP Cheat Sheet: Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) - [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) - [Data Integrity: Recovering from Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-11/final) - [Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-25/final) - [Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-26/final) ## List of Mapped CWEs [CWE-117 Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) [CWE-223 Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) [CWE-532 Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html) [CWE-778 Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html) --- ### 2021 Docs En A10 2021 Server Side Request Forgery (SSRF) (`2021/docs/en/A10_2021-Server-Side_Request_Forgery_(SSRF).md`) # A10:2021 – Server-Side Request Forgery (SSRF) {: style="height:80px;width:80px" align="right"} ## Factors | CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 1 | 2.72% | 2.72% | 8.28 | 6.72 | 67.72% | 67.72% | 9,503 | 385 | ## Overview 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 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 Developers can prevent SSRF by implementing some or all the following defense in depth controls: ### **From Network layer** - 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](A09_2021-Security_Logging_and_Monitoring_Failures.md)). ### **From Application layer:** - 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:** - 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 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 - [OWASP - Server-Side Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) - [PortSwigger - Server-side request forgery (SSRF)](https://portswigger.net/web-security/ssrf) - [Acunetix - What is Server-Side Request Forgery (SSRF)?](https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/) - [SSRF bible](https://cheatsheetseries.owasp.org/assets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet_SSRF_Bible.pdf) - [A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) ## List of Mapped CWEs [CWE-918 Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html) --- ### 2021 Docs En A11 2021 Next Steps (`2021/docs/en/A11_2021-Next_Steps.md`) # A11:2021 – Next Steps 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 three issues are well worth the effort to identify and remediate. ## Code Quality issues | CWEs Mapped  | Max Incidence Rate  | Avg Incidence Rate  | Avg Weighted Exploit  | Avg Weighted Impact  | Max Coverage  | Avg Coverage  | Total Occurrences  | Total CVEs  | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 38 | 49.46% | 2.22% | 7.1 | 6.7 | 60.85% | 23.42% | 101736 | 7564 | - **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** - [OWASP Code Review Guide](https://owasp.org/www-pdf-archive/OWASP_Code_Review_Guide_v2.pdf) - [Google Code Review Guide](https://google.github.io/eng-practices/review/) ## Denial of Service | CWEs Mapped  | Max Incidence Rate  | Avg Incidence Rate  | Avg Weighted Exploit  | Avg Weighted Impact  | Max Coverage  | Avg Coverage  | Total Occurrences  | Total CVEs  | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 8 | 17.54% | 4.89% | 8.3 | 5.9 | 79.58% | 33.26% | 66985 | 973 | - **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** - [OWASP Cheat Sheet: Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) - [OWASP Attacks: Denial of Service](https://owasp.org/www-community/attacks/Denial_of_Service) ## Memory Management Errors | CWEs Mapped  | Max Incidence Rate  | Avg Incidence Rate  | Avg Weighted Exploit  | Avg Weighted Impact  | Max Coverage  | Avg Coverage  | Total Occurrences  | Total CVEs  | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 14 | 7.03% | 1.16% | 6.7 | 8.1 | 56.06% | 31.74% | 26576 | 16184 | - **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** - [OWASP Vulnerabilities: Buffer Overflow](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow) - [OWASP Attacks: Buffer Overflow](https://owasp.org/www-community/attacks/Buffer_overflow_attack) - [Science Direct: Integer Overflow](https://www.sciencedirect.com/topics/computer-science/integer-overflow) --- ### 2021 Docs Es 0x01 2021 About Owasp (`2021/docs/es/0x01_2021-about-owasp.md`) # Acerca de OWASP El proyecto abierto de seguridad en aplicaciones Web (OWASP por sus siglas en inglés) es una comunidad abierta dedicada a facultar a las organizaciones a desarrollar, adquirir y mantener aplicaciones y APIS que pueden ser confiables. En OWASP, encontrará gratuitas y abiertas: - Herramientas y estándares de seguridad en aplicaciones. - Investigación de vanguardia. - Controles estándar de seguridad y bibliotecas. - Libros completos de revisiones de seguridad en aplicaciones, desarrollo de código fuente seguro, y revisiones de seguridad en código fuente. - Presentaciones y [videos](https://www.youtube.com/user/OWASPGLOBAL). - [Hojas de ayuda (Cheat sheets)](https://cheatsheetseries.owasp.org/) en varios tópicos comunes. - [Reuniones de Capítulos](https://owasp.org/chapters/) - [Eventos, entrenamientos y conferencias](https://owasp.org/events/). - [Grupos de Google](próximamente) Conozca más en: [https://www.owasp.org](https://www.owasp.org). Todas las herramientas, documentos, videos, presentaciones y capítulos de OWASP son gratuitos y están abiertos a cualquier interesado en mejorar la seguridad en aplicaciones. Abogamos por resolver la seguridad en aplicaciones como un problema de personas, procesos y tecnología, ya que los enfoques más efectivos para la seguridad en aplicaciones requieren mejoras en todas estas áreas. OWASP es un nuevo tipo de organización. Nuestra libertad de presiones comerciales nos permite proveer información sobre seguridad en aplicaciones sin sesgos, práctica y efectiva. OWASP no está afiliada con ninguna compañía de tecnología, aunque apoyamos el uso instruido de tecnologías de seguridad comercial. OWASP produce muchos tipos de materiales en una manera colaborativa, transparente y abierta. La fundación OWASP es una entidad sin fines de lucro para asegurar el éxito a largo plazo del proyecto. Casi todos los asociados con OWASP son voluntarios, incluyendo la junta directiva de OWASP, líderes de capítulos, líderes y miembros de proyectos. Apoyamos la investigación innovadora sobre seguridad a través de becas e infraestructura. ¡Únase a nosotros! ## Derechos de Autor y Licencia Copyright © 2003-2025 The OWASP® Foundation. Este documento se publica bajo la licencia Creative Commons Attribution Share-Alike 4.0. Para cualquier reutilización o distribución, debe dejar en claro los términos de la licencia de este trabajo. --- ### 2021 Docs Es A00 2021 How To Start An AppSec Program With The OWASP Top 10 (`2021/docs/es/A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10.md`) # Cómo iniciar un programa de Seguridad en Aplicaciones (AppSec) con el OWASP Top 10 Anteriormente, el OWASP Top 10 no había sido diseñado para ser la base de un programa de AppSec. Sin embargo, es esencial comenzar en algún lugar, sobre todo para aquellas organizaciones que recién comienzan su travesía en seguridad de aplicaciones. El OWASP Top 10 2021 no es suficiente en sí mismo, pero es un buen comienzo como base para las listas de controles, etc. ## Etapa 1. Identifique las necesidades y los objetivos de su programa de AppSec Muchos programas de seguridad en aplicaciones intentan correr antes de poder gatear o caminar. Estos esfuerzos están condenados al fracaso. Recomendamos encarecidamente a los CISO y a los líderes de AppSec que utilicen el [Modelo de Madurez para el Aseguramiento del Software (SAMM)](https://owaspsamm.org) de OWASP para identificar debilidades y áreas de mejora durante un período de 1 a 3 años. El primer paso es evaluar dónde se encuentra ahora, identificar las brechas en las áreas de gobernanza, diseño, implementación, verificación y operaciones que necesita resolver de inmediato frente a las que pueden esperar, priorizando la implementación o mejora de las quince prácticas de seguridad SAMM de OWASP. OWASP SAMM puede ayudar a construir y medir mejoras en sus esfuerzos de aseguramiento de software. ## Etapa 2. Planifique un ciclo de vida de desarrollo seguro de carretera pavimentada ("paved road") El concepto de carretera pavimentada ("paved road") en seguridad informática es una forma concisa de expresar que el camino mas rápido también es el mas seguro. Esto permite escalar los recursos necesarios de AppSec al mismo ritmo que aumenta la velocidad requerida por los equipos de desarrollo; que dicho sea de paso, se acelera cada año. El concepto de camino pavimentado es: "la forma más fácil es también la forma más segura" y debe involucrar una cultura de asociaciones profundas entre el equipo de desarrollo y el equipo de seguridad, preferiblemente de manera que sean el mismo equipo. El camino pavimentado tiene como objetivo mejorar, medir, detectar y reemplazar alternativas inseguras, teniendo a nivel de toda la organización una biblioteca de alternativas seguras, utilizando a su vez herramientas de apoyo para detectar dónde es posible realizar mejoras al adoptar el camino pavimentado. Esto permite que las herramientas de desarrollo ya existentes informen sobre compilaciones inseguras y ayude a los equipos de desarrollo a autocorregirse. La carretera pavimentada puede parecer mucho para asimilar, pero debe construirse gradualmente con el tiempo. Existen otras formas de programas de AppSec, como por ejemplo el ciclo de vida de desarrollo seguro ágil de Microsoft. No todas las metodologías de programas de AppSec se adaptan a todas las organizaciones. ## Etapa 3. Implemente la carretera pavimentada con sus equipos de desarrollo. Las carreteras pavimentadas se construyen con el consentimiento y la participación directa de los equipos de desarrollo y operaciones involucrados. Debe estar alineada estratégicamente con el negocio y ayudar a entregar aplicaciones más seguras con mayor rapidez. El desarrollo de la carretera pavimentada debería ser un ejercicio holístico que cubra todo el ecosistema de aplicaciones de la organización, no un remiendo por aplicación, como en los viejos tiempos. ## Etapa 4. Migre todas las aplicaciones existentes y futuras a la carretera pavimentada. Agregue herramientas de detección a la carretera pavimentada a medida que las desarrolle y proporcione información a los equipos de desarrollo para mejorar la seguridad de sus aplicaciones a través de la adopción de herramientas ya incluidas en la carretera pavimentada. Una vez que se ha adoptado un aspecto de la carretera pavimentada, las organizaciones deberían implementar controles en los procesos de integración continua que inspeccionen el código ya existente y las modificaciones (check-ins), rechazando o advirtiendo sobre aquellas que introducen alternativas prohibidas. Esto evita que las opciones inseguras se introduzcan en el código con el tiempo, evitando la deuda técnica y una aplicación insegura defectuosa. Dichas advertencias deben estar ligadas a la alternativa segura, de modo que el equipo de desarrollo reciba la respuesta correcta de inmediato. Ellos pueden refactorizar y adoptar los componentes de la carretera pavimentada rápidamente. ## Etapa 5. Pruebe que la carretera pavimentada haya mitigado los problemas encontrados en el Top 10 de OWASP Los componentes de carretera pavimentada deben abordar un problema importante del OWASP Top 10, por ejemplo, cómo detectar o reparar automáticamente componentes vulnerables, o un complemento IDE de análisis de código estático para detectar inyecciones o, mejor aún, comenzar a usar una biblioteca que se sabe que es segura contra inyecciones. Cuantas más de estas sustituciones seguras se proporcionen a los equipos, mejor. Una tarea vital del equipo de AppSec es garantizar que la seguridad de estos componentes se evalúe y mejore continuamente. Una vez mejorados, alguna forma de comunicación debe existir con los consumidores del componente para indicar que existe una actualización disponible. Es preferiblemente una forma automática, pero si no es posible, se recomienda utilizar al menos un resaltado en un dashboard o algo similar. ## Etapa 6. Transforme su programa en un programa de AppSec maduro No debe detenerse en el OWASP Top 10. Sólo cubre 10 categorías de riesgo. Recomendamos enfáticamente a las organizaciones que adopten el [Estándar de Verificación de Seguridad de Aplicaciones](https://owasp.org/www-project-application-security-verification-standard/) (ASVS) de OWASP y agreguen progresivamente componentes a la carretera pavimentada pensados en los niveles 1, 2 y 3, según el nivel objetivo determinado para cada aplicación desarrolladas. ## Yendo más allá Todos los grandes programas de AppSec van más allá del mínimo indispensable. Todos deben ir más allá si queremos realmente superar las vulnerabilidades de AppSec. - **Integridad conceptual**. Los programas maduros de AppSec deben contener algún concepto de arquitectura de seguridad, ya sea una arquitectura formal de seguridad en la nube o empresarial o modelado de amenazas. - **Automatización y escala**. Los programas maduros de AppSec intentan automatizar la mayor cantidad de entregables posibles, utilizando scripts para emular pasos complejos de pruebas de penetración, herramientas de análisis de código estático directamente disponibles para los equipos de desarrollo, ayudando a los equipos de desarrollo a crear pruebas de integración y unitarias de AppSec, y más. - **Cultura**. Los programas maduros de AppSec intentan evitar el diseño inseguro y eliminan la deuda técnica del código existente al ser parte del equipo de desarrollo y no uno anexo. Los equipos de AppSec que ven a los equipos de desarrollo como "ellos" y "nosotros", están condenados al fracaso. - **Mejora continua**. Los programas maduros de AppSec buscan mejorar constantemente. Si algo no funciona, deje de hacerlo. Si algo es inútil o no escalable, trabaje para mejorarlo. Si los equipos de desarrollo no están utilizando algo o tiene un impacto nulo o limitado, haga algo diferente. El hecho de que hayamos realizado pruebas como comprobaciones de escritorio desde la década de 1970 no significa que sea una buena idea. Haga mediciones, evalúe y luego construya o mejore. --- ### 2021 Docs Es A00 2021 How To Use The OWASP Top 10 As A Standard (`2021/docs/es/A00_2021_How_to_use_the_OWASP_Top_10_as_a_standard.md`) # Cómo utilizar OWASP Top 10 como estándar El OWASP Top 10 es principalmente un documento de concientización. Sin embargo, esto no ha impedido que organizaciones lo utilicen como estándar de facto de la industria AppSec desde su creación en 2003. Si desea utilizar OWASP Top 10 como un estándar de codificación o pruebas, sepa que es lo mínimo y sólo un punto de partida. Una de las dificultades de utilizar el OWASP Top 10 como estándar es que documentamos riesgos de AppSec y no necesariamente problemas fácilmente comprobables. Por ejemplo, A04:2021-Diseño Inseguro está más allá del alcance de la mayoría de las formas de prueba. Otro ejemplo son las pruebas en el lugar y en uso del registro y monitoreo efectivos. Sólo se pueden realizar a través de entrevistas y solicitando un muestreo de respuestas efectivas a incidentes. Una herramienta de análisis estático de código puede detectar la ausencia de registro, pero puede ser imposible determinar si se registran correctamente brechas de seguridad críticas en la lógica de negocio o en el control de acceso. Los testers de penetración sólo pueden determinar que han invocado la respuesta a incidentes en un entorno de prueba, el cual rara vez se monitorea de la misma manera que en un entorno de producción. Estas son nuestras recomendaciones sobre cuándo es apropiado utilizar el OWASP Top 10: | Caso de uso | OWASP Top 10 2021 | Estándar de Verificación de Seguridad en Aplicaciones de OWASP (ASVS) | |-----------------------------------------------|:-------------------:|:---------------------------------------------------------------------:| | Concientización | Sí | | | Capacitación | Nivel Introductorio | Completo | | Diseño y arquitectura | Ocasionalmente | Sí | | Estándar de codificación | Apenas Mínimo | Sí | | Revisión de código seguro | Apenas Mínimo | Sí | | Lista verificación para la revisión por pares | Apenas Mínimo | Sí | | Pruebas unitarias | Ocasionalmente | Sí | | Pruebas de integración | Ocasionalmente | Sí | | Pruebas de penetración | Apenas Mínimo | Sí | | Soporte de herramientas | Apenas Mínimo | Sí | | Cadena de suministro segura | Ocasionalmente | Sí | Alentamos a cualquiera que desee adoptar un estándar de seguridad de aplicaciones a usar el [Estándar de Verificación de Seguridad de Aplicaciones](https://owasp.org/www-project-application-security-verification-standard/) (ASVS) de OWASP, ya que fue diseñado para ser verificable, testeble, y puede usarse en todas las etapas de un ciclo de desarrollo seguro. El ASVS es la única opción aceptable para los proveedores de herramientas. Las herramientas no pueden detectar, probar o proteger de manera integral contra los riesgos descriptos en OWASP Top 10, tomando como referencia el A04:2021-Diseño Inseguro. OWASP disuade el uso cualquier afirmación pretensiosa de cobertura completa del OWASP Top 10, porque simplemente no es cierto. --- ### 2021 Docs Es A00 2021 Introduction (`2021/docs/es/A00_2021_Introduction.md`) # Introducción ## Bienvenido al OWASP Top 10 - 2021 {:class="img-responsive"} ¡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 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 raíz en lugar del síntoma. - **[A01:2021-Pérdida de Control de Acceso](A01_2021-Broken_Access_Control.md)** 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 analizadas poseían una o más de las debilidades identificadas en el Common Weakness Enumerations (CWEs), con más de 318 mil ocurrencias en estas categorías 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](A02_2021-Cryptographic_Failures.md)** 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](A03_2021-Injection.md)** descienden hasta la tercera posición. El 94% de las aplicaciones fueron analizadas en búsqueda de algún tipo de inyección, mostrando una tasa de incidencia máxima del 19% y de 3.37% de promedio. Las 33 CWEs relacionadas con esta categoría tienen la segunda mayor cantidad de ocurrencias en aplicaciones con 274.000. Las Secuencia de Comandos en Sitios Cruzados (Cross-Site Scripting o XSS), son parte de esta categoría en esta edición. - **[A04:2021-Diseño Inseguro](A04_2021-Insecure_Design.md)** es nueva categoría en la edición 2021, con un foco en los riesgos relacionados a las fallas de diseño. Si realmente deseamos avanzar como industria, necesitamos más modelado de amenazas, utilizar mas patrones y principios de diseño seguro y arquitecturas de referencia. Un diseño inseguro no puede ser corregido 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](A05_2021-Security_Misconfiguration.md)** asciende desde la sexta posición en la edición anterior. El 90% de las aplicaciones fueron probadas para detectar algún tipo de configuración incorrecta, con una tasa de incidencia promedio del 4,5% y más de 208 mil casos de CWEs relacionadas con esta categoría de riesgo. Con la adopción de software altamente configurable, no es sorprendente ver que esta categoría asciende. Las **A4:2017-Entidades Externas XML(XXE)** en esta edición, forman parte de esta categoría de riesgo. - **[A06:2021-Componentes Vulnerables y Desactualizados](A06_2021-Vulnerable_and_Outdated_Components.md)** 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 tenía 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 (Common Vulnerability and Exposures) 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](A07_2021-Identification_and_Authentication_Failures.md)** 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 la Integridad del Software y de los Datos](A08_2021-Software_and_Data_Integrity_Failures.md)** es una nueva categoría para la edición 2021, enfocándose en realizar hipótesis relacionadas con actualizaciones de software, datos críticos y pipelines de CI/CD sin verificar su integridad. Uno de los mayores impactos ponderados de los datos del CVE/CVSS (Common Vulnerability and Exposures/Common Vulnerability Scoring System) asignados a los 10 CWE de esta categoría. El **A8:2017-Deserialización Insegura**, pasa a formar parte de esta categoría mas ámplia. - **[A09:2021-Fallas en el Registro y Monitoreo de la Seguridad](A09_2021-Security_Logging_and_Monitoring_Failures.md)** previamente denominada como **A10:2017 Registro y Monitoreo Insuficientes** es añadido a partir de la encuesta a la comunidad del Top 10 (tercer lugar), 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 que son difíciles de probar y no están bien representadas en los datos de CVE/CVSS. Igualmente, las fallas incluidas 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 (SSRF)](A10_2021-Server-Side_Request_Forgery_(SSRF).md)** es añadido a partir de la encuesta a la comunidad del Top 10 (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, a pesar de no ser visible en los datos en este momento. ## Metodología 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 Algunas categorías han cambiado con respecto a la anterior entrega del OWASP Top 10. 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 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 detenernos. 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 remediación. Centrarse en la *causa raíz* en lugar de en el *síntoma* no es un concepto nuevo; el Top 10 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 cierto lenguaje/framework. ## Cómo se utilizan los datos para seleccionar las categorías 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.000 registros de una CVE mapeadas a una CWE en los datos de la NVD (National Vulnerability Database) extraídos del OWASP Dependency Check y hay 241 CWEs únicas mapeadas a una CVE. 62.000 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 10 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 únicamente los datos estadísticos puros? 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 es 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? 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 que suelen 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 se prueba manualmente una aplicación y se ve algo como un Cross-Site Scripting, normalmente se encontrarán tres o cuatro instancias y se detendrá, siendo suficiente para determinar un hallazgo sistémico y escribir una recomendación para corregirlo en la aplicación en general. No hay necesidad (ni tiempo) de encontrar cada instancia en particular. 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 enmascarará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. Esto se debe al gran volumen de hallazgos. El Cross-Site Scripting es relativamente 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 y combinar de manera transparente los datos de Herramientas y HaT con los 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 enmascarar 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 el proceso de recopilación y análisis de datos? 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 en la que utilizamos esta metodología. Publicamos la solicitud de datos a través de las redes sociales 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 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 su la normalización. 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 ya se encuentran presentes en los datos. Las dos más votadas que no estén ya presentes fueron 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. ## Factores de datos Existen factores de datos que se enumeran para cada una de las categorías, aquí se explica su significado: - 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. ## Agradecimiento a nuestros proveedores de datos 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 nuestros patrocinadores El equipo del OWASP Top 10 2021 agradece el apoyo financiero de Secure Code Warrior y Just Eat. [{ width="256" }](https://securecodewarrior.com) [{ width="256" }](https://www.just-eat.co.uk/) --- ### 2021 Docs Es A01 2021 Broken Access Control (`2021/docs/es/A01_2021-Broken_Access_Control.md`) # A01:2021 – Pérdida de Control de Acceso {: style="height:80px;width:80px" align="right"} ## Factores | CWEs mapeadas | Tasa de incidencia máx | Tasa de incidencia prom | Explotabilidad ponderada prom| Impacto ponderado prom | Cobertura máx | Cobertura prom | Incidencias totales | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 34 | 55.97% | 3.81% | 6.92 | 5.93 | 94.55% | 47.72% | 318,487 | 19,013 | ## Resumen Subiendo desde la quinta posición, el 94% de las aplicaciones fueron probadas para detectar algún tipo de pérdida de control de acceso con una tasa de incidencia promedio del 3,81%. Tuvo la mayor cantidad de ocurrencias en el conjunto de datos analizado con más de 318.000. Las CWE (Common Weakness Enumerations) más importantes incluidas son *CWE-200: Exposición de información sensible a un actor no autorizado*, *CWE-201: Exposición de información confidencial a través de datos enviados*, y *CWE-352: Falsificación de Petciones en Sitos Cruzados (Cross Site Request Forgery, CSRF por su siglas en inglés)*. ## Descripción El control de acceso implementa el cumplimiento de política de modo que los usuarios no pueden actuar fuera de los permisos que le fueron asignados. Las fallas generalmente conducen a la divulgación de información no autorizada, la modificación o la destrucción de todos los datos o la ejecución de una función de negocio fuera de los límites del usuario. Las vulnerabilidades comunes de control de acceso incluyen: - Violación del principio de mínimo privilegio o denegación por defecto, según el cual el acceso sólo debe ser permitido para capacidades, roles o usuarios particulares, y no disponible para cualquier persona. - Eludir las comprobaciones de control de acceso modificando la URL (alteración de parámetros o navegación forzada), el estado interno de la aplicación o la página HTML, o mediante el uso de una herramienta que modifique los pedidos a APIs. - Permitir ver o editar la cuenta de otra persona, con tan solo conocer su identificador único (referencia directa insegura a objetos) - Acceder a APIs con controles de acceso inexistentes para los métodos POST, PUT y DELETE. - Elevación de privilegios. Actuar como usuario sin haber iniciado sesión o actuar como administrador cuando se inició sesión como usuario regular. - Manipulación de metadatos, como reutilizar o modificar un token de control de acceso JSON Web Token (JWT), una cookie o un campo oculto, manipulándolos para elevar privilegios o abusar de la invalidación de tokens JWT. - Configuraciones incorrectas de CORS (uso compartido de recursos de origen cruzado) que permiten el acceso a APIs desde orígenes no autorizados o confiables. - Forzar la navegación a páginas autenticadas siendo usuario no autenticado o a páginas privilegiadas siendo usuario regular. ## Cómo se previene El control de acceso solo es efectivo si es implementado en el servidor (server-side) o en la API (caso serverless), donde el atacante no puede modificarlo ni manipular metadatos. - A excepción de los recursos públicos, denegar por defecto. - Implemente mecanismos de control de acceso una única vez y reutilícelos en toda la aplicación, incluyendo la minimización del uso de CORS. - El control de acceso debe implementar su cumplimiento a nivel de dato y no permitir que el usuario pueda crear, leer, actulizar o borrar cualquier dato. - Los modelos de dominio deben hacer cumplir los requisitos únicos de límite de negocio de aplicaciones. - Deshabilite el listado de directorios del servidor web y asegúrese de que los archivos de metadatos (por ejemplo una carpeta .git) y archivos de respaldo no puedan ser accedidos a partir de la raíz del sitio web. - Registre las fallas de control de acceso (loggin), alertando a los administradores cuando sea apropiado (por ejemplo, fallas repetidas). - Establezca límites a la tasa de accesos permitidos a APIs y controladores de forma de poder minimizar el daño provocado por herramientas automatizadas de ataque. - Los identificadores de sesiones deben invalidarse en el servidor luego de cerrar la sesión. Los tokens JWT deberían ser preferiblemente de corta duración para minimizar la ventana de oportunidad de ataque. Para tokens JWT de mayor duración, es sumamente recomendable seguir los estándares de OAuth de revocación de acceso. Tanto desarrolladores como personal de control de calidad deben incluir pruebas funcionales de control de acceso tanto a nivel unitario como de integración. ## Ejemplos de escenarios de ataque **Escenario #1:** La aplicación utiliza datos no verificados en una llamada SQL que accede a información de una cuenta: ``` pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( ); ``` Un atacante simplemente modifica el parámetro 'acct' en el navegador para enviar el número de cuenta que desee. Si no es verificado correctamente, el atacante puede acceder a la cuenta de cualquier usuario. ``` https://example.com/app/accountInfo?acct=notmyacct ``` **Escenario #2:** Un atacante simplemente navega a una URL específica. Se deberían requerir derechos de administrador para acceder a la página de administración. ``` https://example.com/app/getappInfo https://example.com/app/admin_getappInfo ``` Si un usuario no autenticado puede acceder a cualquiera de las páginas, es una falla. Si una persona que no es administrador puede acceder a la página de administración, esto es también una falla. ## Referencias - [OWASP Proactive Controls: Enforce Access Controls](https://owasp.org/www-project-proactive-controls/v3/en/c7-enforce-access-controls) - [OWASP Application Security Verification Standard: V4 Access Control](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: Authorization Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README) - [OWASP Cheat Sheet: Access Control](https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html) - [OWASP Cheat Sheet: Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) - [PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) - [OAuth: Revoking Access](https://www.oauth.com/oauth2-servers/listing-authorizations/revoking-access/) ## Lista de CWEs mapeadas [CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) [CWE-23 Relative Path Traversal](https://cwe.mitre.org/data/definitions/23.html) [CWE-35 Path Traversal: '.../...//'](https://cwe.mitre.org/data/definitions/35.html) [CWE-59 Improper Link Resolution Before File Access ('Link Following')](https://cwe.mitre.org/data/definitions/59.html) [CWE-200 Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html) [CWE-201 Exposure of Sensitive Information Through Sent Data](https://cwe.mitre.org/data/definitions/201.html) [CWE-219 Storage of File with Sensitive Data Under Web Root](https://cwe.mitre.org/data/definitions/219.html) [CWE-264 Permissions, Privileges, and Access Controls (should no longer be used)](https://cwe.mitre.org/data/definitions/264.html) [CWE-275 Permission Issues](https://cwe.mitre.org/data/definitions/275.html) [CWE-276 Incorrect Default Permissions](https://cwe.mitre.org/data/definitions/276.html) [CWE-284 Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) [CWE-285 Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) [CWE-352 Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html) [CWE-359 Exposure of Private Personal Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/359.html) [CWE-377 Insecure Temporary File](https://cwe.mitre.org/data/definitions/377.html) [CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak')](https://cwe.mitre.org/data/definitions/402.html) [CWE-425 Direct Request ('Forced Browsing')](https://cwe.mitre.org/data/definitions/425.html) [CWE-441 Unintended Proxy or Intermediary ('Confused Deputy')](https://cwe.mitre.org/data/definitions/441.html) [CWE-497 Exposure of Sensitive System Information to an Unauthorized Control Sphere](https://cwe.mitre.org/data/definitions/497.html) [CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory](https://cwe.mitre.org/data/definitions/538.html) [CWE-540 Inclusion of Sensitive Information in Source Code](https://cwe.mitre.org/data/definitions/540.html) [CWE-548 Exposure of Information Through Directory Listing](https://cwe.mitre.org/data/definitions/548.html) [CWE-552 Files or Directories Accessible to External Parties](https://cwe.mitre.org/data/definitions/552.html) [CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key](https://cwe.mitre.org/data/definitions/566.html) [CWE-601 URL Redirection to Untrusted Site ('Open Redirect')](https://cwe.mitre.org/data/definitions/601.html) [CWE-639 Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html) [CWE-651 Exposure of WSDL File Containing Sensitive Information](https://cwe.mitre.org/data/definitions/651.html) [CWE-668 Exposure of Resource to Wrong Sphere](https://cwe.mitre.org/data/definitions/668.html) [CWE-706 Use of Incorrectly-Resolved Name or Reference](https://cwe.mitre.org/data/definitions/706.html) [CWE-862 Missing Authorization](https://cwe.mitre.org/data/definitions/862.html) [CWE-863 Incorrect Authorization](https://cwe.mitre.org/data/definitions/863.html) [CWE-913 Improper Control of Dynamically-Managed Code Resources](https://cwe.mitre.org/data/definitions/913.html) [CWE-922 Insecure Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/922.html) [CWE-1275 Sensitive Cookie with Improper SameSite Attribute](https://cwe.mitre.org/data/definitions/1275.html) --- ### 2021 Docs Es A02 2021 Cryptographic Failures (`2021/docs/es/A02_2021-Cryptographic_Failures.md`) # A02:2021 – Fallas Criptográficas {: style="height:80px;width:80px" align="right"} ## Factores | CWEs mapeadas | Tasa de incidencia máx | Tasa de incidencia prom | Explotabilidad ponderada prom| Impacto ponderado prom | Cobertura máx | Cobertura prom | Incidencias totales | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 29 | 46.44% | 4.49% |7.29 | 6.81 | 79.33% | 34.85% | 233,788 | 3,075 | ## Resumen Subiendo una posición al número 2, anteriormente conocido como *Exposición de datos sensibles*, que es más un amplio síntoma que una causa raíz, la atención se centra en las fallas relacionadas con la criptografía (o la falta de ésta). Esto a menudo conduce a la exposición de datos sensibles. Las CWE incluidas son *CWE-259: Uso de contraseña en código fuente*, *CWE-327: Algoritmo criptográfico vulnerado o inseguro* y *CWE-331: Entropía insuficiente*. ## Descripción Lo primero es determinar las necesidades de protección de los datos en tránsito y en reposo. Por ejemplo, contraseñas, números de tarjetas de crédito, registros médicos, información personal y secretos comerciales requieren protección adicional, principalmente si están sujetos a leyes de privacidad (por ejemplo, el Reglamento General de Protección de Datos -GDPR- de la UE), o regulaciones, (por ejemplo, protección de datos financieros como el Estándar de Seguridad de Datos de PCI -PCI DSS-). Para todos esos datos: - ¿Se transmiten datos en texto claro? Esto se refiere a protocolos como HTTP, SMTP, FTP que también utilizan actualizaciones de TLS como STARTTLS. El tráfico externo de Internet es peligroso. Verifique todo el tráfico interno, por ejemplo, entre balanceadores de carga, servidores web o sistemas de back-end. - ¿Se utilizan algoritmos o protocolos criptográficos antiguos o débiles de forma predeterminada o en código antiguo? - ¿Se utilizan claves criptográficas predeterminadas, se generan o reutilizan claves criptográficas débiles, o es inexistente la gestión o rotación de claves adecuadas? ¿Se incluyen las claves criptográficas en los repositorios de código fuente? - ¿No es forzado el cifrado, por ejemplo, faltan las directivas de seguridad de los encabezados HTTP (navegador) o los encabezados? - ¿El certificado de servidor recibido y la cadena de confianza se encuentran debidamente validados? - ¿Los vectores de inicialización se ignoran, se reutilizan o no se generan de forma suficientemente seguros para el modo de operación criptográfico? ¿Se utiliza un modo de funcionamiento inseguro como el ECB? ¿Se utiliza un cifrado cuando el cifrado autenticado es más apropiada? - ¿Las contraseñas se utilizan como claves criptográficas en ausencia de una función de derivación de claves a partir de contraseñas? - ¿Se utiliza con fines criptográficos generadores de aleatoriedad que no fueron diseñaron para dicho fin? Incluso si se elige la función correcta, debe ser inicializada (seed) por el desarrollador y, de no ser así, ¿el desarrollador ha sobrescrito la funcionalidad de semilla fuerte incorporada con una semilla que carece de suficiente entropía/imprevisibilidad? - ¿Se utilizan funciones hash en obsoletas, como MD5 o SHA1, o se utilizan funciones hash no criptográficas cuando se necesitan funciones hash criptográficas? - ¿Se utilizan métodos criptográficos de relleno(padding) obsoletos, como PKCS número 1 v1.5? - ¿Se pueden explotar los mensajes de errores criptográficos como un canal lateral, por ejemplo, en forma de ataques de criptoanálisis por modificación relleno (Oracle Padding)? Consulte ASVS Crypto (V7), Data Protection (V9) y SSL/TLS (V10) ## Cómo se previene Haga lo siguiente como mínimo, y consulte las referencias: - Clasifique los datos procesados, almacenados o transmitidos por una aplicación. Identifique qué datos son confidenciales de acuerdo con las leyes de privacidad, los requisitos reglamentarios o las necesidades comerciales. - No almacene datos sensibles innecesariamente. Descártelos lo antes posible o utilice una utilización de tokens compatible con PCI DSS o incluso el truncamiento. Los datos que no se conservan no se pueden robar. - Asegúrese de cifrar todos los datos sensibles en reposo (almacenamiento). - Garantice la implementación de algoritmos, protocolos y claves que utilicen estándares sólidos y actualizados; utilice una gestión de claves adecuada. - Cifre todos los datos en tránsito con protocolos seguros como TLS con cifradores de confidencialidad adelantada (forward secrecy, o FS), priorización de cifradores por parte del servidor y parámetros seguros. Aplique el cifrado mediante directivas como HTTP Strict Transport Security (HSTS). - Deshabilite el almacenamiento en caché para respuestas que contengan datos sensibles. - Aplique los controles de seguridad requeridos según la clasificación de los datos. - No utilice protocolos antiguos como FTP y SMTP para transportar datos sensibles. - Almacene las contraseñas utilizando funciones robustas, flexibles, que utilicen sal en los hashes y use un factor de retraso (factor de trabajo), como Argon2, scrypt, bcrypt o PBKDF2. - Elija vectores de inicialización apropiados para el modo de operación. Para muchos modos, esto significa usar un CSPRNG (generador de números pseudoaleatorios criptográficamente seguro). Para los modos que requieren un nonce, el vector de inicialización (IV) no necesita un CSPRNG. En todos los casos, el IV nunca debe usarse dos veces para una clave fija. - Utilice siempre cifrado autenticado en lugar de solo cifrado. - Las claves deben generarse criptográficamente al azar y almacenarse en la memoria como arrays de bytes. Si se utiliza una contraseña, debe convertirse en una clave mediante una función adecuada de derivación de claves basada en contraseña. - Asegúrese de que se utilice la aleatoriedad criptográfica cuando sea apropiado y que no se utilice una semilla de una manera predecible o con baja entropía. La mayoría de las API modernas no requieren que el desarrollador genere el CSPRNG para obtener seguridad. - Evite las funciones criptográficas y los esquemas de relleno(padding) en desuso, como MD5, SHA1, PKCS número 1 v1.5. - Verifique de forma independiente la efectividad de la configuración y los ajustes. ## Ejemplos de escenarios de ataque **Escenario #1**: Una aplicación cifra los números de tarjetas de crédito en una base de datos mediante el cifrado automático de la base de datos. Sin embargo, estos datos se descifran automáticamente cuando se recuperan, lo que permite que por una falla de inyección SQL se recuperen números de tarjetas de crédito en texto sin cifrar. **Escenario #2**: Un sitio no utiliza ni aplica TLS para todas sus páginas o admite un cifrado débil. Un atacante monitorea el tráfico de la red (por ejemplo, en una red inalámbrica insegura), degrada las conexiones de HTTPS a HTTP, intercepta solicitudes y roba la cookie de sesión del usuario. El atacante luego reutiliza esta cookie y secuestra la sesión (autenticada) del usuario, accediendo o modificando los datos privados del usuario. En lugar de lo anterior, podrían alterar todos los datos transportados, por ejemplo, el destinatario de una transferencia de dinero. **Escenario #3**: La base de datos de contraseñas utiliza hashes simples o sin un valor inicial aleatorio único(salt) para almacenar todas las contraseñas. Una falla en la carga de archivos permite a un atacante recuperar la base de datos de contraseñas. Todos los hashes sin salt se pueden calcular a partir de una rainbow table de hashes pre calculados. Los hash generados por funciones hash simples o rápidas pueden ser descifrados a través de cálculos intensivos provistos por una o mas GPUs, incluso si utilizan un salt. ## Referencias - [OWASP Proactive Controls: Protect Data Everywhere](https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere) - [OWASP Application Security Verification Standard (V7, 9, 10)](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Cheat Sheet: Transport Layer Protection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) - [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) - [OWASP Cheat Sheet: Password and Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) - [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) - [OWASP Testing Guide: Testing for weak cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README) ## Lista de CWEs mapeadas [CWE-261 Weak Encoding for Password](https://cwe.mitre.org/data/definitions/261.html) [CWE-296 Improper Following of a Certificate's Chain of Trust](https://cwe.mitre.org/data/definitions/296.html) [CWE-310 Cryptographic Issues](https://cwe.mitre.org/data/definitions/310.html) [CWE-319 Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) [CWE-321 Use of Hard-coded Cryptographic Key](https://cwe.mitre.org/data/definitions/321.html) [CWE-322 Key Exchange without Entity Authentication](https://cwe.mitre.org/data/definitions/322.html) [CWE-323 Reusing a Nonce, Key Pair in Encryption](https://cwe.mitre.org/data/definitions/323.html) [CWE-324 Use of a Key Past its Expiration Date](https://cwe.mitre.org/data/definitions/324.html) [CWE-325 Missing Required Cryptographic Step](https://cwe.mitre.org/data/definitions/325.html) [CWE-326 Inadequate Encryption Strength](https://cwe.mitre.org/data/definitions/326.html) [CWE-327 Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html) [CWE-328 Reversible One-Way Hash](https://cwe.mitre.org/data/definitions/328.html) [CWE-329 Not Using a Random IV with CBC Mode](https://cwe.mitre.org/data/definitions/329.html) [CWE-330 Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html) [CWE-331 Insufficient Entropy](https://cwe.mitre.org/data/definitions/331.html) [CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/335.html) [CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/336.html) [CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/337.html) [CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/338.html) [CWE-340 Generation of Predictable Numbers or Identifiers](https://cwe.mitre.org/data/definitions/340.html) [CWE-347 Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html) [CWE-523 Unprotected Transport of Credentials](https://cwe.mitre.org/data/definitions/523.html) [CWE-720 OWASP Top Ten 2007 Category A9 - Insecure Communications](https://cwe.mitre.org/data/definitions/720.html) [CWE-757 Selection of Less-Secure Algorithm During Negotiation('Algorithm Downgrade')](https://cwe.mitre.org/data/definitions/757.html) [CWE-759 Use of a One-Way Hash without a Salt](https://cwe.mitre.org/data/definitions/759.html) [CWE-760 Use of a One-Way Hash with a Predictable Salt](https://cwe.mitre.org/data/definitions/760.html) [CWE-780 Use of RSA Algorithm without OAEP](https://cwe.mitre.org/data/definitions/780.html) [CWE-818 Insufficient Transport Layer Protection](https://cwe.mitre.org/data/definitions/818.html) [CWE-916 Use of Password Hash With Insufficient Computational Effort](https://cwe.mitre.org/data/definitions/916.html) --- ### 2021 Docs Es A03 2021 Injection (`2021/docs/es/A03_2021-Injection.md`) # A03:2021 – Inyección {: style="height:80px;width:80px" align="right"} ## Factores | CWEs mapeadas | Tasa de incidencia máx | Tasa de incidencia prom | Explotabilidad ponderada prom| Impacto ponderado prom | Cobertura máx | Cobertura prom | Incidencias totales | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 33 | 19.09% | 3.37% | 7.25 | 7.15 | 94.04% | 47.90% | 274,228 | 32,078 | ## Resumen La Inyección desciende a la tercera posición. El 94% de las aplicaciones fueron probadas para algún tipo de inyección con una tasa de incidencia máxima del 19%, una tasa de incidencia promedio del 3% y 274.000 ocurrencias. Las CWE incluidas son *CWE-79: Secuencia de Comandos en Sitios Cruzados (XSS)*, *CWE-89: Inyección SQL*, y la *CWE-73:Control Externo de Nombre de archivos o ruta*. ## Descripción Una aplicación es vulnerable a estos tipos de ataque cuando: - Los datos proporcionados por el usuario no son validados, filtrados ni sanitizados por la aplicación. - Se invocan consultas dinámicas o no parametrizadas, sin codificar los parámetros de forma acorde al contexto. - Se utilizan datos dañinos dentro de los parámetros de búsqueda en consultas Object-Relational Mapping (ORM), para extraer registros adicionales sensibles. - Se utilizan datos dañinos directamente o se concatenan, de modo que el SQL o comando resultante contiene datos y estructuras con consultas dinámicas, comandos o procedimientos almacenados. Algunas de las inyecciones más comunes son SQL, NoSQL, comandos de sistema operativo, Object-Relational Mapping (ORM), LDAP, expresiones de lenguaje u Object Graph Navigation Library (OGNL). El concepto es idéntico para todos los intérpretes. La revisión del código fuente es el mejor método para detectar si las aplicaciones son vulnerables a inyecciones. Las pruebas automatizadas en todos los parámetros, encabezados, URL, cookies, JSON, SOAP y XML son fuertemente recomendados. Las organizaciones pueden incluir herramientas de análisis estático (SAST), dinámico (DAST) o interactivo (IAST) en sus pipelines de CI/CD con el fin de identificar fallas recientemente introducidas, antes de ser desplegadas en producción.. ## Cómo se previene Prevenir inyecciones requiere separar los datos de los comandos y las consultas. - La opción preferida es utilizar una API segura, que evite el uso de un intérprete por completo y proporcione una interfaz parametrizada o utilizar una herramienta de ORM.
**Nota:**: Incluso cuando se parametrizan, los procedimientos almacenados pueden introducir una inyección SQL si el procedimiento PL/SQL o T-SQL concatena consultas y datos, o se ejecutan parámetros utilizando EXECUTE IMMEDIATE o exec(). - Implemente validaciones de entradas de datos en el servidor, utilizando "listas blancas". De todos modos, esto no es una defensa completa, ya que muchas aplicaciones requieren el uso de caracteres especiales, como en campos de texto o APIs para aplicaciones móviles. - Para cualquier consulta dinámica restante, escape caracteres especiales utilizando la sintaxis de caracteres específica para el intérprete que se trate.
**Nota:** La estructura de SQL como nombres de tabla, nombres de columna, etc. no se pueden escapar y, por lo tanto, los nombres de estructura suministrados por el usuario son peligrosos. Este es un problema común en el software de redacción de informes. - Utilice LIMIT y otros controles SQL dentro de las consultas para evitar la fuga masiva de registros en caso de inyección SQL. ## Ejemplos de escenarios de ataque **Escenario #1:** Una aplicación usa datos no confiables en la construcción de la siguiente sentencia SQL vulnerable: ``` String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'"; ``` **Escenario #2:** Del mismo modo, la confianza total de una aplicación en frameworks puede resultar en consultas que siguen siendo vulnerables a inyecciones, (por ejemplo: Hibernate Query Language (HQL)): ``` Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); ``` En ambos casos, el atacante modifica el valor del parámetro "id" en su navegador y enviar por ejemplo: ' UNION SLEEP(10);--. ``` http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);-- ``` Esto modifica el significado de ambas consultas, retornando todos los registros de la tabla “accounts. Ataques más peligrosos podrían modificar datos o incluso invocar procedimientos almacenados. ## Referencias - [OWASP Proactive Controls: Secure Database Access](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database) - [OWASP ASVS: V5 Input Validation and Encoding](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: SQL Injection,](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection) [Command Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection), and [ORM Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection) - [OWASP Cheat Sheet: Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) - [OWASP Cheat Sheet: SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) - [OWASP Cheat Sheet: Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) - [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) - [OWASP Automated Threats to Web Applications – OAT-014](https://owasp.org/www-project-automated-threats-to-web-applications/) - [PortSwigger: Server-side template injection](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) ## Lista de CWEs mapeadas [CWE-20 Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html) [CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')](https://cwe.mitre.org/data/definitions/74.html) [CWE-75 Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)](https://cwe.mitre.org/data/definitions/75.html) [CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')](https://cwe.mitre.org/data/definitions/77.html) [CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')](https://cwe.mitre.org/data/definitions/78.html) [CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html) [CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)](https://cwe.mitre.org/data/definitions/80.html) [CWE-83 Improper Neutralization of Script in Attributes in a Web Page](https://cwe.mitre.org/data/definitions/83.html) [CWE-87 Improper Neutralization of Alternate XSS Syntax](https://cwe.mitre.org/data/definitions/87.html) [CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')](https://cwe.mitre.org/data/definitions/88.html) [CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')](https://cwe.mitre.org/data/definitions/89.html) [CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')](https://cwe.mitre.org/data/definitions/90.html) [CWE-91 XML Injection (aka Blind XPath Injection)](https://cwe.mitre.org/data/definitions/91.html) [CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')](https://cwe.mitre.org/data/definitions/93.html) [CWE-94 Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html) [CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')](https://cwe.mitre.org/data/definitions/95.html) [CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')](https://cwe.mitre.org/data/definitions/96.html) [CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page](https://cwe.mitre.org/data/definitions/97.html) [CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')](https://cwe.mitre.org/data/definitions/98.html) [CWE-99 Improper Control of Resource Identifiers ('Resource Injection')](https://cwe.mitre.org/data/definitions/99.html) [CWE-100 Deprecated: Was catch-all for input validation issues](https://cwe.mitre.org/data/definitions/100.html) [CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')](https://cwe.mitre.org/data/definitions/113.html) [CWE-116 Improper Encoding or Escaping of Output](https://cwe.mitre.org/data/definitions/116.html) [CWE-138 Improper Neutralization of Special Elements](https://cwe.mitre.org/data/definitions/138.html) [CWE-184 Incomplete List of Disallowed Inputs](https://cwe.mitre.org/data/definitions/184.html) [CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')](https://cwe.mitre.org/data/definitions/470.html) [CWE-471 Modification of Assumed-Immutable Data (MAID)](https://cwe.mitre.org/data/definitions/471.html) [CWE-564 SQL Injection: Hibernate](https://cwe.mitre.org/data/definitions/564.html) [CWE-610 Externally Controlled Reference to a Resource in Another Sphere](https://cwe.mitre.org/data/definitions/610.html) [CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')](https://cwe.mitre.org/data/definitions/643.html) [CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax](https://cwe.mitre.org/data/definitions/644.html) [CWE-652 Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')](https://cwe.mitre.org/data/definitions/652.html) [CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')](https://cwe.mitre.org/data/definitions/917.html) --- ### 2021 Docs Es A04 2021 Insecure Design (`2021/docs/es/A04_2021-Insecure_Design.md`) # A04:2021 – Diseño Inseguro {: style="height:80px;width:80px" align="right"} ## Factores | CWEs mapeadas | Tasa de incidencia máx | Tasa de incidencia prom | Explotabilidad ponderada prom| Impacto ponderado prom | Cobertura máx | Cobertura prom | Incidencias totales | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 40 | 24.19% | 3.00% | 6.46 | 6.78 | 77.25% | 42.51% | 262,407 | 2,691 | ## Resumen Una nueva categoría en la versión 2021. se centra en los riesgos relacionados con el diseño y las fallas arquitectónicas, exhortando a un mayor uso de: modelado de amenazas, patrones de diseño seguros y arquitecturas de referencia. Como comunidad, debemos ir más allá de la codificación y adoptar actividades cruciales para obtener Seguridad por Diseño. Debemos "mover a la izquierda" del proceso de desarrollo las actividades de seguridad. Las CWE notables incluidas son *CWE-209: Generación de mensaje de error que contiene información confidencial*, *CWE-256: Almacenamiento desprotegido de credenciales*, *CWE-501: Violación de las fronteras de confianza* y *CWE-522: Credenciales protegidas insuficientemente*. ## Descripción El diseño inseguro es una categoría amplia que representa diferentes debilidades, expresadas como "diseño de control faltante o ineficaz". El diseño inseguro no es la fuente de las otras 10 categorías. Existe una diferencia entre un diseño inseguro y una implementación insegura. Distinguimos entre fallas de diseño y defectos de implementación por un motivo, difieren en la causa raíz y remediaciones. Incluso un diseño seguro puede tener defectos de implementación que conduzcan a vulnerabilidades que pueden explotarse. Un diseño inseguro no se puede arreglar con una implementación perfecta, ya que, por definición, los controles de seguridad necesarios nunca se crearon para defenderse de ataques específicos. Uno de los factores que contribuyen al diseño inseguro es la falta de perfiles de riesgo empresarial inherentes al software o sistema que se está desarrollando y, por lo tanto, la falta de determinación del nivel de diseño de seguridad que se requiere. ### Gestión de requerimientos y recursos Recopile y negocie los requerimientos para la aplicación con el negocio, incluidos los requisitos de protección relacionados con la confidencialidad, integridad, disponibilidad y autenticidad de todos los activos de datos y la lógica de negocio esperada. Tenga en cuenta qué tan expuesta estará su aplicación y si necesita segregación de funcionalidades (además del control de acceso). Recopile los requerimientos técnicos, incluidos los funcionales de seguridad y los no funcionales. Planifique y negocie que el presupuesto cubra el diseño, construcción, prueba y operación, incluyendo las actividades de seguridad. ### Diseño seguro El diseño seguro es una cultura y metodología que evalúa constantemente las amenazas y garantiza que el código esté diseñado y probado de manera sólida para prevenir métodos de ataque conocidos. El modelado de amenazas debe estar integrado en sesiones de refinamiento (o actividades similares); buscar cambios en los flujos de datos y el control de acceso u otros controles de seguridad. Durante la creación de las historias de usuario, determine el flujo correcto y los estados de falla. Asegúrese de que sean bien entendidos y acordados por las partes responsables e impactadas. Analice las suposiciones y las condiciones para los flujos esperados y de falla, asegúrese de que aún sean precisos y deseables. Determine cómo validar las suposiciones y hacer cumplir las condiciones necesarias para los comportamientos adecuados. Asegúrese de que los resultados estén documentados en las historias de usuario. Aprenda de los errores y ofrezca incentivos positivos para promover mejoras. El diseño seguro no es un complemento ni una herramienta que pueda agregar al software. ### Ciclo de Desarrollo Seguro (S-SDLC) El software seguro requiere un ciclo de desarrollo seguro, alguna forma de patrón de diseño seguro, metodologías de carretera pavimentada ("paved road"), bibliotecas de componentes seguros, herramientas y modelado de amenazas. Comuníquese con sus especialistas en seguridad desde el comienzo y durante todo el proyecto, así como durante su fase de mantenimiento. Considere aprovechar el [Modelo de Madurez para el Aseguramiento del Software (SAMM)](https://owaspsamm.org) para ayudar a estructurar sus esfuerzos de desarrollo de software seguro. ## Cómo se previene - Establezca y use un ciclo de desarrollo seguro apoyado en Profesionales en Seguridad de Aplicaciones para ayudarlo a evaluar y diseñar la seguridad y controles relacionados con la privacidad. - Establezca y utilice un catálogo de patrones de diseño seguros o componentes de "camino pavimentado" listos para ser utilizados. - Utilice el modelado de amenazas para flujos críticos de autenticación, control de acceso, lógica de negocio y todo clave. - Integre el lenguaje y los controles de seguridad en las historias de usuario. - Integre verificaciones de viabilidad en cada capa de su aplicación (desde el frontend al backend). - Escriba pruebas unitarias y de integración para validar que todos los flujos críticos son resistentes al modelo de amenazas. Recopile casos de uso *y* casos de mal uso para cada capa de la aplicación. - Separe las capas del sistema y las capas de red según las necesidades de exposición y protección. - Separe a los tenants de manera robusta por diseño en todos los niveles. - Limitar el consumo de recursos por usuario o servicio. ## Ejemplos de Escenarios de Ataque **Escenario #1:** Un flujo de trabajo de recuperación de credenciales puede incluir "preguntas y respuestas", lo cual está prohibido por NIST 800-63b, OWASP ASVS y OWASP Top 10. No se puede confiar en preguntas y respuestas como evidencia de identidad ya que más de una persona puede conocer las respuestas. Dicho código debe eliminarse y reemplazarse por un diseño más seguro. **Escenario #2:** Una cadena de cines permite descuentos en la reserva de grupos y tiene un máximo de quince asistentes antes de solicitar un depósito. Los atacantes podrían modelar este flujo y probar si podían reservar seiscientos asientos en todos los cines a la vez utilizando unas pocos pedidos, lo que provocaría grandes pérdidas de ingresos. **Escenario #3:** El sitio web de comercio electrónico de una cadena minorista no tiene protección contra bots administrados por revendedores que compran tarjetas de video de alta gama para revender sitios web de subastas. Esto crea una publicidad terrible para los fabricantes de tarjetas de video y los propietarios de cadenas minoristas y una mala sangre duradera con entusiastas que no pueden obtener estas tarjetas a ningún precio. El diseño cuidadoso de anti automatización y las reglas de lógica de negocio, como compras realizadas a los pocos segundos de disponibilidad, pueden identificar compras no auténticas y rechazar dichas transacciones. ## Referencias - [OWASP Cheat Sheet: Secure Design Principles](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) - [OWASP SAMM: Design:Security Architecture](https://owaspsamm.org/model/design/security-architecture/) - [OWASP SAMM: Design:Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/) - [NIST – Guidelines on Minimum Standards for Developer Verification of Software](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) - [The Threat Modeling Manifesto](https://threatmodelingmanifesto.org) - [Awesome Threat Modeling](https://github.com/hysnsec/awesome-threat-modelling) ## Lista de CWEs mapeadas [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) [CWE-209 Generation of Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html) [CWE-213 Exposure of Sensitive Information Due to Incompatible Policies](https://cwe.mitre.org/data/definitions/213.html) [CWE-235 Improper Handling of Extra Parameters](https://cwe.mitre.org/data/definitions/235.html) [CWE-256 Unprotected Storage of Credentials](https://cwe.mitre.org/data/definitions/256.html) [CWE-257 Storing Passwords in a Recoverable Format](https://cwe.mitre.org/data/definitions/257.html) [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) [CWE-280 Improper Handling of Insufficient Permissions or Privileges](https://cwe.mitre.org/data/definitions/280.html) [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) [CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) [CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) [CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) [CWE-430 Deployment of Wrong Handler](https://cwe.mitre.org/data/definitions/430.html) [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) [CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')](https://cwe.mitre.org/data/definitions/444.html) [CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) [CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) [CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) [CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) [CWE-579 J2EE Bad Practices: Non-serializable Object Stored in Session](https://cwe.mitre.org/data/definitions/579.html) [CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) [CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) [CWE-650 Trusting HTTP Permission Methods on the Server Side](https://cwe.mitre.org/data/definitions/650.html) [CWE-653 Insufficient Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) [CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) [CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) [CWE-840 Business Logic Errors](https://cwe.mitre.org/data/definitions/840.html) [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) [CWE-927 Use of Implicit Intent for Sensitive Communication](https://cwe.mitre.org/data/definitions/927.html) [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) [CWE-1173 Improper Use of Validation Framework](https://cwe.mitre.org/data/definitions/1173.html) --- ### 2021 Docs Es A05 2021 Security Misconfiguration (`2021/docs/es/A05_2021-Security_Misconfiguration.md`) # A05:2021 – Configuración de Seguridad Incorrecta {: style="height:80px;width:80px" align="right"} ## Factores | CWEs mapeadas | Tasa de incidencia máx | Tasa de incidencia prom | Explotabilidad ponderada prom| Impacto ponderado prom | Cobertura máx | Cobertura prom | Incidencias totales | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 20 | 19.84% | 4.51% | 8.12 | 6.56 | 89.58% | 44.84% | 208,387 | 789 | ## Resumen Ascendiendo una posición desde el sexto puesto 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 ocurrencias de CWEs en esta categoría de riesgo. Con mayor presencia de software altamente configurable, no es sorprendente ver que esta categoría ascendiera. Las CWE notables incluidas son *CWE-16 Configuración* y *CWE-611 Restricción incorrecta entidades externas referenciadas de XML*. ## Descripción La aplicación puede ser vulnerable si: - Le falta el *hardening* de seguridad adecuado en cualquier parte del *stack tecnológico* o permisos configurados incorrectamente en los servicios en la nube. - Tiene funciones innecesarias habilitadas o instaladas (puertos, servicios, páginas, cuentas o privilegios innecesarios, por ejemplo). - Las cuentas predeterminadas y sus contraseñas aún están habilitadas y sin cambios. - El manejo de errores revela a los usuarios rastros de pila u otros mensajes de error demasiado informativos. - Para sistemas actualizados, las últimas funciones de seguridad están deshabilitadas o no configuradas de forma segura. - Las configuraciones de seguridad en los servidores de aplicaciones, frameworks de aplicaciones (Struts, Spring o ASP.NET por ejemplo), bibliotecas, bases de datos, etc., no poseen configurados valores seguros. - El servidor no envía encabezados o directivas de seguridad, o no poseen configurados valores seguros. - El software está desactualizado o es vulnerable (consulte [A06:2021-Componentes Vulnerables y Desactualizados](A06_2021-Vulnerable_and_Outdated_Components.md)). Sin un proceso de configuración de seguridad de aplicaciones coordinado y repetible, los sistemas corren un mayor riesgo. ## Cómo se previene Deben implementarse procesos de instalación seguros, incluyendo: - Un proceso de *hardening* repetible agiliza y facilita la implementación de otro entorno que esté debidamente inaccesible. Los entornos de desarrollo, control de calidad y producción deben configurarse de forma idéntica, con diferentes credenciales utilizadas en cada uno. Este proceso debe automatizarse para minimizar el esfuerzo necesario para configurar un nuevo entorno seguro. - Una plataforma mínima sin funciones, componentes, documentación ni ejemplos innecesarios. Elimine o no instale características y frameworks no utilizados. - Una tarea para revisar y actualizar las configuraciones apropiadas para todas las notas de seguridad, actualizaciones y parches como parte del proceso de administración de parches (consulte [A06: 2021-Componentes Vulnerables y Desactualizados](A06_2021-Vulnerable_and_Outdated_Components.md)). Revise los permisos de almacenamiento en la nube (por ejemplo, Permisos de bucket de S3). - Una arquitectura de aplicación segmentada proporciona una separación efectiva y segura entre componentes o instancias, con segmentación, organización en contenedores o grupos de seguridad en la nube (ACLs). - Envío de directivas de seguridad a los clientes, por ejemplo, encabezados de seguridad. - Un proceso automatizado para verificar la efectividad de las configuraciones y ajustes en todos los entornos. ## Ejemplos de escenarios de ataque **Escenario #1:** El servidor de aplicaciones contiene aplicaciones de ejemplo que no se eliminan del servidor de producción. Estas aplicaciones de ejemplo poseen fallas de seguridad conocidas que los atacantes utilizan para comprometer el servidor. Supongamos que una de estas aplicaciones es la consola de administración y no se modificaron las cuentas predeterminadas. En ese caso, el atacante inicia sesión con las contraseñas predeterminadas y toma el control. **Escenario #2:** El listado de directorios no se encuentra deshabilitado en el servidor. Un atacante descubre que simplemente puede enumerar directorios. El atacante detecta y descarga las clases Java compiladas, que decompila y aplica ingeniería inversa para ver el código. El atacante luego encuentra una falla severa de control de acceso en la aplicación. **Escenario #3:** La configuración del servidor de aplicaciones permite que se retornen a los usuarios mensajes de error detallados, por ejemplo, trazas de pila(stack traces). Esto potencialmente expone información confidencial o fallas subyacentes, como versiones de componentes que se sabe son vulnerables. **Escenario #4:** Un proveedor de servicios en la nube (CSP) posee permisos de uso compartido predeterminados abiertos a Internet a otros usuarios. Esto permite acceder a los datos confidenciales almacenados en el almacenamiento en la nube. ## Referencias - [OWASP Testing Guide: Configuration Management](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) - [OWASP Testing Guide: Testing for Error Codes](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) - [Application Security Verification Standard V14 Configuration](https://github.com/OWASP/ASVS/blob/master/4.0/en/0x22-V14-Config.md) - [NIST Guide to General Server Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) - [CIS Security Configuration Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) - [Amazon S3 Bucket Discovery and Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) ## Lista de CWEs mapeadas [CWE-2 7PK - Environment](https://cwe.mitre.org/data/definitions/2.html) [CWE-11 ASP.NET Misconfiguration: Creating Debug Binary](https://cwe.mitre.org/data/definitions/11.html) [CWE-13 ASP.NET Misconfiguration: Password in Configuration File](https://cwe.mitre.org/data/definitions/13.html) [CWE-15 External Control of System or Configuration Setting](https://cwe.mitre.org/data/definitions/15.html) [CWE-16 Configuration](https://cwe.mitre.org/data/definitions/16.html) [CWE-260 Password in Configuration File](https://cwe.mitre.org/data/definitions/260.html) [CWE-315 Cleartext Storage of Sensitive Information in a Cookie](https://cwe.mitre.org/data/definitions/315.html) [CWE-520 .NET Misconfiguration: Use of Impersonation](https://cwe.mitre.org/data/definitions/520.html) [CWE-526 Exposure of Sensitive Information Through Environmental Variables](https://cwe.mitre.org/data/definitions/526.html) [CWE-537 Java Runtime Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/537.html) [CWE-541 Inclusion of Sensitive Information in an Include File](https://cwe.mitre.org/data/definitions/541.html) [CWE-547 Use of Hard-coded, Security-relevant Constants](https://cwe.mitre.org/data/definitions/547.html) [CWE-611 Improper Restriction of XML External Entity Reference](https://cwe.mitre.org/data/definitions/611.html) [CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute](https://cwe.mitre.org/data/definitions/614.html) [CWE-756 Missing Custom Error Page](https://cwe.mitre.org/data/definitions/756.html) [CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')](https://cwe.mitre.org/data/definitions/776.html) [CWE-942 Permissive Cross-domain Policy with Untrusted Domains](https://cwe.mitre.org/data/definitions/942.html) [CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag](https://cwe.mitre.org/data/definitions/1004.html) [CWE-1032 OWASP Top Ten 2017 Category A6 - Security Misconfiguration](https://cwe.mitre.org/data/definitions/1032.html) [CWE-1174 ASP.NET Misconfiguration: Improper Model Validation](https://cwe.mitre.org/data/definitions/1174.html) --- ### 2021 Docs Es A06 2021 Vulnerable And Outdated Components (`2021/docs/es/A06_2021-Vulnerable_and_Outdated_Components.md`) # A06:2021 – Componentes Vulnerables y Desactualizados {: style="height:80px;width:80px" align="right"} ## Factores | CWEs mapeadas | Tasa de incidencia máx | Tasa de incidencia prom | Explotabilidad ponderada prom| Impacto ponderado prom | Cobertura máx | Cobertura prom | Incidencias totales | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 3 | 27.96% | 8.77% | 51.78% | 22.47% | 5.00 | 5.00 | 30,457 | 0 | ## Resumen Era el segundo de la encuesta de la comunidad Top 10, pero también tuvo datos suficientes para llegar al Top 10 a través del análisis de datos. Los componentes vulnerables son un problema conocido que es difícil de probar y evaluar el riesgo. Es la única categoría que no tiene enumeraciones de debilidades comunes (CWE) asignadas a las CWE incluidas, por lo que se utiliza un peso de impacto/exploits predeterminado de 5,0. Las CWE notables incluidas son *CWE-1104: Uso de componentes de terceros no mantenidos* y las dos CWE del OWASP Top 10 2013 y 2017. ## Descripción Usted probablemente sea vulnerable: - Si no conoce las versiones de todos los componentes que utiliza (tanto en el cliente como en el servidor). Esto incluye los componentes que usa directamente, así como las dependencias anidadas. - Si el software es vulnerable, carece de soporte o no está actualizado. Esto incluye el sistema operativo, el servidor web/de aplicaciones, el sistema de administración de bases de datos (DBMS), las aplicaciones, las API y todos los componentes, los entornos de ejecución y las bibliotecas. - Si no analiza en búsqueda de vulnerabilidades de forma regular y no se suscribe a los boletines de seguridad relacionados con los componentes que utiliza. - Si no repara o actualiza la plataforma subyacente, frameworks y dependencias de manera oportuna y basada en el riesgo. Esto suele ocurrir en entornos en los que la aplicación de parches de seguridad es una tarea mensual o trimestral bajo control de cambios, lo que deja a las organizaciones abiertas a días o meses de exposición innecesaria a vulnerabilidades con soluciones disponibles. - Si los desarrolladores de software no testean la compatibilidad de las bibliotecas actualizadas, actualizadas o parcheadas. - Si no asegura las configuraciones de los componentes (consulte [A05:2021 – Configuración de Seguridad Incorrecta](A05_2021-Security_Misconfiguration.md)). ## Cómo se previene Debe existir un proceso de administración de parches que: - Elimine las dependencias que no son utilizadas, funcionalidades, componentes, archivos y documentación innecesarios. - Realice un inventario continuo de las versiones de los componentes en el cliente y en el servidor (por ejemplo, frameworks, bibliotecas) y sus dependencias utilizando herramientas como: versions, OWASP Dependency Check, retire.js, etc. Supervise continuamente fuentes como Common Vulnerability and Exposures (CVE) y National Vulnerability Database (NVD) para detectar vulnerabilidades en los componentes. Utilice herramientas de análisis de composición de software para automatizar el proceso. Suscríbase para recibir alertas por correo electrónico sobre vulnerabilidades de seguridad relacionadas con los componentes que utiliza. - Solo obtenga componentes de fuentes oficiales a través de enlaces seguros. Prefiera los paquetes firmados para reducir la posibilidad de incluir un componente malicioso modificado (consulte [A08:2021 – Fallas en el Software y en la Integridad de los Datos](A08_2021-Software_and_Data_Integrity_Failures.md)). - Supervise las bibliotecas y los componentes que no sea mantenidos o no generen parches de seguridad para versiones anteriores. Si la aplicación de parches no es posible, considere implementar un parche virtual para monitorear, detectar o protegerse contra el problema descubierto. Toda organización debe garantizar un plan continuo para monitorear, clasificar y aplicar actualizaciones o cambios de configuración durante la vida útil de la aplicación o portafolio de aplicaciones. ## Ejemplos de escenarios de ataque **Escenario #1:** Los componentes normalmente se ejecutan con los mismos privilegios que la propia aplicación, por lo que las fallas en cualquier componente pueden tener un impacto grave. Tales fallas pueden ser accidentales (por ejemplo, error de codificación) o intencionales (por ejemplo, una puerta trasera en un componente). Algunos ejemplos de vulnerabilidades de componentes explotables descubiertos son: - CVE-2017-5638, una vulnerabilidad de ejecución remota de código de Struts 2 que permite la ejecución arbitraria de código en el servidor, ha sido culpada de brechas importantes. - Si bien el Internet de las Cosas (IoT) es con frecuencia difícil o imposible de parchear, la importancia de parchearlo puede ser grande (por ejemplo, dispositivos biomédicos). Existen herramientas automatizadas para ayudar a los atacantes a encontrar sistemas sin parches o mal configurados. Por ejemplo, el motor de búsqueda Shodan IoT puede ayudarlo a encontrar dispositivos que aún sufren la vulnerabilidad Heartbleed parchada en abril de 2014. ## Referencias - 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 ## Lista de CWEs mapeadas 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 Es A07 2021 Identification And Authentication Failures (`2021/docs/es/A07_2021-Identification_and_Authentication_Failures.md`) # A07:2021 – Fallas de Identificación y Autenticación {: style="height:80px;width:80px" align="right"} ## Factores | CWEs mapeadas | Tasa de incidencia máx | Tasa de incidencia prom | Explotabilidad ponderada prom | Impacto ponderado prom | Cobertura máx | Cobertura prom | Incidencias totales | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 22 | 14.84% | 2.55% | 7.40 | 6.50 | 79.51% | 45.72% | 132,195 | 3,897 | ## Resumen Previamente denominada como *Pérdida de Autenticación*, descendió desde la segunda posición, y ahora incluye CWEs que están más relacionados con fallas de identificación. Las CWE notables incluidas son *CWE-297: Validación incorrecta de Certificado con discrepancia de host*, *CWE-287: Autenticación incorrecta* y *CWE-384: Fijación de sesiones*. ## Descripción La confirmación de la identidad, la autenticación y la gestión de sesiones del usuario son fundamentales para protegerse contra ataques relacionados con la autenticación. Puede haber debilidades de autenticación si la aplicación: - Permite ataques automatizados como la reutilización de credenciales conocidas, donde el atacante posee una lista de pares de usuario y contraseña válidos. - Permite ataques de fuerza bruta u otros ataques automatizados. - Permite contraseñas por defecto, débiles o bien conocidas, como "Password1" o "admin/admin". - Posee procesos débiles o no efectivos para las funcionalidades de olvido de contraseña o recuperación de credenciales, como "respuestas basadas en el conocimiento", las cuales no se pueden implementar de forma segura. - Almacena las contraseñas en texto claro, cifradas o utilizando funciones de hash débiles (consulte [A02: 2021-Fallas Criptográficas](A02_2021-Cryptographic_Failures.md)). - No posee una autenticación multi-factor o la implementada es ineficaz. - Expone el identificador de sesión en la URL. - Reutiliza el identificador de sesión después de iniciar sesión. - No inválida correctamente los identificadores de sesión. Las sesiones de usuario o los tokens de autenticación (principalmente tokens de inicio de sesión único (SSO)) no son correctamente invalidados durante el cierre de sesión o luego de un período de inactividad. ## Cómo se previene - Cuando sea posible, implemente la autenticación multi-factor para evitar ataques automatizados de reutilización de credenciales conocidas, fuerza bruta y reúso de credenciales robadas. - No incluya o implemente en su software credenciales por defecto, particularmente para usuarios administradores. - Implemente un control contra contraseñas débiles, tal como verificar que una nueva contraseña o la utilizada en el cambio de contraseña no esté incluida en la lista de las 10,000 peores contraseñas. - Alinear las políticas de largo, complejidad y rotación de las contraseñas con las pautas de la sección 5.1.1 para Secretos Memorizados de la guía del NIST 800-63b u otras políticas de contraseñas modernas, basadas en evidencias. - Asegúrese que el registro, la recuperación de las credenciales y el uso de APIs, no permiten los ataques de enumeración de usuarios, mediante la utilización de los mismos mensajes genéricos en todas las salidas. - Limite o incremente el tiempo de espera entre intentos fallidos de inicio de sesión, pero tenga cuidado de no crear un escenario de denegación de servicio. Registre todos los fallos y avise a los administradores cuando se detecten ataques de rellenos automatizados de credenciales, fuerza bruta u otros. - Utilice un gestor de sesión en el servidor, integrado, seguro y que genere un nuevo ID de sesión aleatorio con alta entropía después de iniciar sesión. Los identificadores de sesión no deben incluirse en la URL, deben almacenarse de forma segura y deben ser invalidados después del cierre de sesión, luego de un tiempo de inactividad o por un tiempo de espera absoluto. ## Ejemplos de escenarios de ataque **Escenario #1:** Relleno de credenciales, el uso de listas de contraseñas conocidas, es un ataque común. Supongamos que una aplicación no se implementa protección automatizada de relleno de credenciales. En ese caso, la aplicación puede usarse como oráculo de contraseñas para determinar si las credenciales son válidas. **Escenario #2:** La mayoría de los ataques de autenticación ocurren debido al uso de contraseñas como único factor. Las consideradas mejores prácticas de requerir de una rotación y complejidad de las contraseñas, son vistos como alentadoras del uso y reúso de contraseñas débiles por parte de los usuarios. Se le recomienda a las organizaciones que detengan dichas prácticas y utilicen las prácticas recomendadas en la guía NIST 800-63 y utilicen autenticación multi-factor. **Escenario #3:** Los tiempos de espera (timeouts) de las sesiones de aplicación no están configurados correctamente. Un usuario utiliza una computadora pública para acceder a una aplicación. En lugar de seleccionar "cerrar sesión", el usuario simplemente cierra la pestaña del navegador y se aleja. Un atacante usa el mismo navegador una hora más tarde, y el usuario continúa autenticado. ## Referencias - [OWASP Proactive Controls: Implement Digital Identity](https://owasp.org/www-project-proactive-controls/v3/en/c6-digital-identity) - [OWASP Application Security Verification Standard: V2 authentication](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Application Security Verification Standard: V3 Session Management](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: Identity](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/03-Identity_Management_Testing/README), [Authentication](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/README) - [OWASP Cheat Sheet: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) - [OWASP Cheat Sheet: Credential Stuffing](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) - [OWASP Cheat Sheet: Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) - [OWASP Cheat Sheet: Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) - [OWASP Automated Threats Handbook](https://owasp.org/www-project-automated-threats-to-web-applications/) - NIST 800-63b: 5.1.1 Memorized Secrets ## Lista de CWEs mapeadas [CWE-255 Credentials Management Errors](https://cwe.mitre.org/data/definitions/255.html) [CWE-259 Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html) [CWE-287 Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) [CWE-288 Authentication Bypass Using an Alternate Path or Channel](https://cwe.mitre.org/data/definitions/288.html) [CWE-290 Authentication Bypass by Spoofing](https://cwe.mitre.org/data/definitions/290.html) [CWE-294 Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html) [CWE-295 Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html) [CWE-297 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/297.html) [CWE-300 Channel Accessible by Non-Endpoint](https://cwe.mitre.org/data/definitions/300.html) [CWE-302 Authentication Bypass by Assumed-Immutable Data](https://cwe.mitre.org/data/definitions/302.html) [CWE-304 Missing Critical Step in Authentication](https://cwe.mitre.org/data/definitions/304.html) [CWE-306 Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html) [CWE-307 Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html) [CWE-346 Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html) [CWE-384 Session Fixation](https://cwe.mitre.org/data/definitions/384.html) [CWE-521 Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html) [CWE-613 Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html) [CWE-620 Unverified Password Change](https://cwe.mitre.org/data/definitions/620.html) [CWE-640 Weak Password Recovery Mechanism for Forgotten Password](https://cwe.mitre.org/data/definitions/640.html) [CWE-798 Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) [CWE-940 Improper Verification of Source of a Communication Channel](https://cwe.mitre.org/data/definitions/940.html) [CWE-1216 Lockout Mechanism Errors](https://cwe.mitre.org/data/definitions/1216.html) --- ### 2021 Docs Es A08 2021 Software And Data Integrity Failures (`2021/docs/es/A08_2021-Software_and_Data_Integrity_Failures.md`) # A08:2021 – Fallas en el Software y en la Integridad de los Datos {: style="height:80px;width:80px" align="right"} ## Factores | CWEs mapeadas | Tasa de incidencia máx | Tasa de incidencia prom | Explotabilidad ponderada prom | Impacto ponderado prom | Cobertura máx | Cobertura prom | Incidencias totales | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 10 | 16.67% | 2.05% | 6.94 | 7.94 | 75.04% | 45.35% | 47,972 | 1,152 | ## Resumen Una nueva categoría en la versión 2021 que se centra en hacer suposiciones relacionadas con las actualizaciones de software, los datos críticos y los pipelines de 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). Entre estos, se destacan las siguientes CWEs: *CWE-829: Inclusión de funcionalidades provenientes de fuera de la zona de confianza*, *CWE-494: Ausencia de verificación de integridad en el código descargado*, y *CWE-502: Deserialización de datos no confiables*. ## Descripción Los fallos de integridad del software y de los datos están relacionados con código e infraestructura no protegidos contra alteraciones (integridad). Ejemplos de esto son cuando una aplicación depende de plugins, bibliotecas o módulos de fuentes, repositorios o redes de entrega de contenidos (CDN) no confiables. Un pipeline CI/CD inseguro puede conducir a accesos no autorizados, la inclusión de código malicioso o el compromiso del sistema en general. Además, es común en la actualidad que las aplicaciones implementen funcionalidades de actualización, a través de las cuales se descargan nuevas versiones de la misma sin las debidas verificaciones integridad que fueron realizadas previamente al instalar la aplicación. Los atacantes potencialmente pueden cargar sus propias actualizaciones para que sean distribuidas y ejecutadas en todas las instalaciones. Otro ejemplo es cuando objetos o datos son codificados o serializados en estructuras que un atacante puede ver y modificar, produciéndose una deserialización insegura. ## Cómo se previene - Utilice firmas digitales o mecanismos similares para verificar que el software o datos provienen efectivamente de la fuente esperada y no fueron alterados. - Asegúrese que las bibliotecas y dependencias, tales como npm o maven son utilizadas desde repositorios confiables. Si su perfil de riesgo es alto, considere alojarlas en un repositorio interno cuyo contenido ha sido previamente analizado. - Asegúrese que se utilice una herramienta de análisis de componentes de terceros, cómo OWASP Dependency Check u OWASP CycloneDX, con el fin de verificar la ausencia de vulnerabilidades conocidas. - Asegúrese que se utilice un proceso de revisión de cambios de código y configuraciones para minimizar las posibilidades de que código o configuraciones maliciosas sean introducidos en su pipeline. - Asegúrese que su pipeline CI/CD posee adecuados controles de acceso, segregación y configuraciones que permitan asegurar la integridad del código a través del proceso de build y despliegue. - Asegúrese que datos sin cifrar o firmar no son enviados a clientes no confiables sin alguna forma de verificación de integridad o firma electrónica con el fin de detectar modificaciones o la reutilización de datos previamente serializados. ## Ejemplos de escenarios de ataque **Escenario #1 Actualizaciones no firmadas:** Muchos routers domésticos, decodificadores de televisión, firmware de dispositivos, entre otros, no verifican las firmas de sus actualizaciones de firmware. El firmware sin firmar es un objetivo creciente para los atacantes y se espera que empeore. Esto es una gran preocupación, ya que muchas veces no existe otro mecanismo para remediarlo que corregirlo en una versión futura y esperar a que las versiones anteriores caduquen. **Escenario #2 Actualización maliciosa de SolarWinds:** Se sabe que los Estados-Naciones utilizan como vector de ataque los mecanismos de actualización, siendo un caso reciente de pública notoriedad el sufrido por SolarWinds Orion. La compañía que desarrolla el software poseía procesos seguros de construcción y mecanismos de integridad en sus actualizaciones. Sin embargo, estos fueron comprometidos y, durante varios meses, la firma distribuyó una actualización maliciosa a más de 18.000 organizaciones, de las cuales alrededor de un centenar se vieron afectadas. Se trata de una de las brechas de este tipo de mayor alcance y más importantes de la historia. **Escenario #3 Deserialización insegura:** Una aplicación *React* utiliza un conjunto de microservicios implementados en Spring Boot. Tratándose de programadores funcionales, intentaron asegurarse de que su código fuera inmutable. La solución implementada consistió en serializar el estado de la sesión para el usuario y enviarlo entre los componentes con cada solicitud. Un atacante advierte el uso de un objeto Java serializado y codificado en base64 (identifica un string que comienza con "rO0") y utiliza la herramienta *Java Serial Killer* para obtener una ejecución remota de código en el servidor de aplicación. ## Referencias - \[OWASP Cheat Sheet: Software Supply Chain Security\](Coming Soon) - \[OWASP Cheat Sheet: Secure build and deployment\](Coming Soon) - [OWASP Cheat Sheet: Infrastructure as Code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) - [OWASP Cheat Sheet: Deserialization]( ) - [SAFECode Software Integrity Controls]( https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) - [A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack]() - [CodeCov Bash Uploader Compromise](https://about.codecov.io/security-update) - [Securing DevOps by Julien Vehent](https://www.manning.com/books/securing-devops) ## Lista de CWEs mapeadas [CWE-345 Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html) [CWE-353 Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353.html) [CWE-426 Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) [CWE-494 Download of Code Without Integrity Check](https://cwe.mitre.org/data/definitions/494.html) [CWE-502 Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) [CWE-565 Reliance on Cookies without Validation and Integrity Checking](https://cwe.mitre.org/data/definitions/565.html) [CWE-784 Reliance on Cookies without Validation and Integrity Checking in a Security Decision](https://cwe.mitre.org/data/definitions/784.html) [CWE-829 Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html) [CWE-830 Inclusion of Web Functionality from an Untrusted Source](https://cwe.mitre.org/data/definitions/830.html) [CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html) --- ### 2021 Docs Es A09 2021 Security Logging And Monitoring Failures (`2021/docs/es/A09_2021-Security_Logging_and_Monitoring_Failures.md`) # A09:2021 – Fallas en el Registro y Monitoreo {: style="height:80px;width:80px" align="right"} ## Factores | CWEs mapeadas | Tasa de incidencia máx | Tasa de incidencia prom | Explotabilidad ponderada prom| Impacto ponderado prom | Cobertura máx | Cobertura prom | Incidencias totales | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 4 | 19.23% | 6.51% | 6.87 | 4.99 | 53.67% | 39.97% | 53,615 | 242 | ## Resumen Monitoreo y registro de seguridad provienen de la encuesta de la comunidad (tercer lugar), subió levemente desde la décima posición en el Top 10 2017. El registro y monitoreo pueden ser desafiantes para ser testeados, implicando entrevistas o preguntar si los ataques fueron detectados durante las pruebas de penetración. No hay muchos datos de CVE/CVSS para esta categoría, pero detectar y responder a las brechas es crítico. Aún así, puede tener un gran impacto para la auditabilidad, visibilidad, alertas de incidentes y análisis forense. Esta categoría se expande más allá de *CWE-117 Neutralización de salida incorrecta para registros*, *CWE-223 Omisión de información relevante para la seguridad*, y *CWE-532 Inserción de información sensible en archivo de registro*. ## Descripción Volviendo al OWASP Top 10 2021, la intención es apoyar la detección, escalamiento y respuesta ante brechas activas. Sin registros y monitoreo, las brechas no pueden ser detectadas. Registros, detecciones, monitoreo y respuesta activas insuficientes pueden ocurrir en cualquier momento: - Eventos auditables, tales como los inicios de sesión, fallas en el inicio de sesión y transacciones de alto valor no son registradas. - Advertencias y errores generan registros poco claros, inadecuados y en algunos casos ni se generan. - Registros en aplicaciones y API no son monitoreados para detectar actividades sospechosas. - Los registros son únicamente almacenados en forma local. - Los umbrales de alerta y procesos de escalamiento no están correctamente implementados o no son efectivos. - Las pruebas de penetración y los escaneos utilizando herramientas de pruebas dinámicas de seguridad en aplicaciones (como ser OWASP ZAP) no generan alertas. - Las aplicaciones no logran detectar, escalar, o alertar sobre ataques activos en tiempo real ni cercanos al tiempo real. Se es vulnerable a la fuga de información haciendo registros y eventos de alertas que sean visibles para un usuario o un atacante (consulte [A01: 2021-Pérdida de Control de Acceso](A01_2021-Broken_Access_Control.md)). ## Cómo se previene Los desarrolladores deberían implementar algunos o todos los siguientes controles, dependiendo del riesgo de la aplicación: - Asegúrese de que todos los errores de inicio de sesión, de control de acceso y de validación de entradas de datos del lado del servidor se pueden registrar con suficiente contexto como para identificar cuentas sospechosas o maliciosas y mantenerlo durante el tiempo suficiente para permitir un posterior análisis forense. - Asegúrese de que los registros se generen en un formato fácil de procesar por las herramientas de gestión de registros. - Asegúrese de que los datos de registros son correctamente codificados para prevenir inyecciones o ataques en el sistema de monitoreo o registros. - Asegúrese de que las transacciones de alto valor poseen una traza de auditoria con controles de integridad para evitar la modificación o el borrado, tales como permitir únicamente la inserción en las tablas de base de datos o similares. - Los equipos de DevSecOps debe establecer alertas y monitoreo efectivo tal que se detecte actividades sospechosas y responderlas rápidamente. - Establezca o adopte un plan de respuesta y recuperación, tal como NIST 800-61r2 o posterior. Existen frameworks de protección de aplicaciones comerciales y de código abierto, tales como el conjunto de reglas de ModSecurity de OWASP y el conjunto de programas de correlación de registros de código abierto como ser ELK (Elasticsearch, Logstash, Kibana) con paneles personalizados y alertas. ## Ejemplos de escenarios de ataque **Escenario #1:** El sitio web de un prestador de salud que provee un plan para niños no pudo detectar una brecha debido a la falta de monitoreo y registro. Alguien externo informó al prestador que un atacante había accedido y modificados registros médicos sensibles de más de 3,5 millones de niños. Una revisión post incidente detectó que los desarrolladores del sitio web no habían encontrado vulnerabilidades significativas. Como no hubo ni registro ni monitores del sistema, la brecha de datos pudo haber estado en proceso desde el 2013, por un período de más de 7 años. **Escenario #2:** Una gran aerolínea India tuvo una brecha de seguridad que involucró a la pérdida de datos personales de millones de pasajeros por más de 10 años, incluyendo pasaportes y tarjetas de crédito. La brecha se produjo por un proveedor de servicios de almacenamiento en la nube, quien notificó a la aerolínea después de un tiempo. **Escenario #3:** Una gran aerolínea Europea sufrió un incumplimiento de la GRPD que debe reportar. La causa de la brecha se debió a que un atacante explotó una vulnerabilidad en una aplicación de pago, obteniendo más de 400,000 registros de pagos de usuarios. La aerolínea fue multada con 20 millones de libras como resultado del regulador de privacidad. ## Referencias - [OWASP Proactive Controls: Implement Logging and Monitoring](https://top10proactive.owasp.org/archive/2024/the-top-10/c9-security-logging-and-monitoring/) - [OWASP Application Security Verification Standard: V8 Logging and Monitoring](https://owasp.org/www-project-application-security-verification-standard) - [OWASP Testing Guide: Testing for Detailed Error Code](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_for_Error_Code) - [OWASP Cheat Sheet: Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) - [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) - [Data Integrity: Recovering from Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-11/final) - [Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-25/final) - [Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-26/final) ## Lista de CWEs mapeadas [CWE-117 Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) [CWE-223 Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) [CWE-532 Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html) [CWE-778 Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html) --- ### 2021 Docs Es A10 2021 Server Side Request Forgery (SSRF) (`2021/docs/es/A10_2021-Server-Side_Request_Forgery_(SSRF).md`) # A10:2021 – Falsificación de Solicitudes del Lado del Servidor (SSRF) {: style="height:80px;width:80px" align="right"} ## Factores | CWEs mapeadas | Tasa de incidencia máx | Tasa de incidencia prom | Explotabilidad ponderada prom| Impacto ponderado prom | Cobertura máx | Cobertura prom | Incidencias totales | Total CVEs | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 1 | 2.72% | 2.72% | 8.28 | 6.72 | 67.72% | 67.72% | 9,503 | 385 | ## Resumen Esta categoría se agrega debido a la encuesta de la comunidad Top 10 (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. Como es probable que estas nuevas entradas sean una única o un pequeño grupo de Enumeraciones de debilidades comunes (CWE) para tomar en cuenta y concientizar sobre ellas, la esperanza es que se enfoque la atención en ellas y puedan integrarse en una categoría más amplia en una edición futura. ## Descripción Las fallas de SSRF ocurren cuando una aplicación web está obteniendo un recurso remoto sin validar la URL proporcionada por el usuario. Permite que un atacante coaccione a la aplicación para que envíe una solicitud falsificada a un destino inesperado, incluso cuando está protegido por un firewall, VPN u otro tipo de lista de control de acceso a la red (ACL). Dado que las aplicaciones web modernas brindan a los usuarios finales funciones convenientes, la búsqueda de una URL se convierte en un escenario común. Como resultado, la incidencia de SSRF está aumentando. Además, la gravedad de SSRF es cada vez mayor debido a los servicios en la nube y la complejidad de las arquitecturas. ## Cómo se previene Los desarrolladores pueden prevenir SSRF implementando algunos o todos los siguientes controles de defensa en profundidad: ### **Desde la capa de red** - Segmente la funcionalidad de acceso a recursos remotos en redes separadas para reducir el impacto de SSRF - Haga cumplir las políticas de firewall "denegar por defecto" o las reglas de control de acceso a la red para bloquear todo el tráfico de la intranet excepto el esencial.
*Consejos:*
~ Establezca la propiedad y un ciclo de vida para las reglas de firewall basadas en aplicaciones.
~ Registre en logs todos los flujos de red aceptados y bloqueados en firewalls (consulte [A09: 2021-Fallas en el Registro y Monitoreo](A09_2021-Security_Logging_and_Monitoring_Failures.md)). ### **Desde la capa de aplicación:** - Sanitice y valide todos los datos de entrada proporcionados por el cliente - Haga cumplir el esquema de URL, el puerto y destino a través de una lista positiva de items permitidos - No envíe respuestas en formato "crudo" a los clientes - Deshabilite las redirecciones HTTP - Tenga en cuenta la coherencia de la URL para evitar ataques como el enlace de DNS y las condiciones de carrera de "tiempo de verificación, tiempo de uso" (TOCTOU por sus siglas en inglés) No mitigue SSRF mediante el uso de una lista de denegación o una expresión regular. Los atacantes poseen listas de payloads, herramientas y habilidades para eludir las listas de denegación. ### **Medidas adicionales a considerar:** - No implemente otros servicios relevantes para la seguridad en los sistemas frontales (por ejemplo, OpenID). Controle el tráfico local en estos sistemas (por ejemplo, localhost) - Para frontends con grupos de usuarios dedicados y manejables, use el cifrado de red (por ejemplo, VPN) en sistemas independientes para considerar necesidades de protección muy altas ## Ejemplos de escenarios de ataque Los atacantes pueden usar SSRF para atacar sistemas protegidos detrás de firewalls de aplicaciones web, firewalls o ACLs de red, utilizando escenarios tales como: **Escenario #1:** Escaneo de puertos de servidores internos – Si la arquitectura de red no se encuentra segmentada, los atacantes pueden trazar un mapa de las redes internas y determinar si los puertos están abiertos o cerrados en los servidores internos a partir de los resultados de la conexión o del tiempo transcurrido para conectar o rechazar las conexiones de payload SSRF. **Escenario #2:** Exposición de datos sensibles: los atacantes pueden acceder a archivos locales como servicios internos para obtener información confidencial como `file:///etc/passwd` y `http://localhost:28017/`. **Escenario #3:** Acceso al almacenamiento de metadatos de los servicios en la nube: la mayoría de los proveedores de la nube tienen almacenamiento de metadatos como `http://169.254.169.254/`. Un atacante puede leer los metadatos para obtener información confidencial. **Escenario #4:** Exposición de los servicios internos: el atacante puede abusar de los servicios internos para realizar más ataques, como la ejecución remota de código (RCE) o la denegación de servicio (DoS). ## Referencias - [OWASP - Server-Side Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) - [PortSwigger - Server-side request forgery (SSRF)](https://portswigger.net/web-security/ssrf) - [Acunetix - What is Server-Side Request Forgery (SSRF)?](https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/) - [SSRF bible](https://cheatsheetseries.owasp.org/assets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet_SSRF_Bible.pdf) - [A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) ## Lista de CWEs mapeadas [CWE-918 Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html) --- ### 2021 Docs Es A11 2021 Next Steps (`2021/docs/es/A11_2021-Next_Steps.md`) # A11:2021 – Siguientes pasos Por diseño, el Top 10 de OWASP se limita a los diez riesgos más importantes. Cada Top 10 de OWASP tuvo riesgos "en el umbral" considerados detenidamente para su inclusión, pero al final, no lo fueron. No importando cuánto intentáramos interpretar o tergiversar los datos, los otros riesgos fueron más prevalentes e impactantes. Para aquellas organizaciones que trabajan en pos de un programa de AppSec maduro, consultores de seguridad o proveedores de herramientas que deseen ampliar la cobertura de sus ofertas, vale la pena el esfuerzo de identificar y solucionar los siguientes tres problemas. ## Problemas de calidad de código | CWEs mapeadas  | Tasa de incidencia máx | Tasa de incidencia prom  | Explotabilidad ponderada prom  | Impacto ponderado prom | Cobertura máx  | Cobertura prom | Total de Incidencias   | Total de CVEs  | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 38 | 49.46% | 2.22% | 7.1 | 6.7 | 60.85% | 23.42% | 101736 | 7564 | - **Descripción.** Los problemas de calidad del código incluyen patrones o defectos de seguridad conocidos, reutilización de variables para múltiples propósitos, exposición de información sensible en la salida de depuración, errores por uno (off-by-one), condiciones de carrera de tiempo de verificación/tiempo de uso (TOC/TOU), errores de conversión firmados o no firmados, uso de memoria ya liberada y más. El sello distintivo de esta sección es que generalmente se pueden identificar con estrictas marcas de compilación, herramientas de análisis de código estático y complementos de IDE para análisis de tipo *lint*. Los lenguajes modernos por diseño eliminaron muchos de estos problemas, como la propiedad de la memoria de Rust y el concepto de préstamo, el diseño de hilos de subproceso de Rust y la tipificación estricta y la verificación de límites de Go. - **Cómo se previene**. Habilite y use las opciones de análisis de código estático de su editor específico para cada lenguaje. Considere el uso de una herramienta de análisis de código estático. Considere si fuera posible usar o migrar a un lenguaje o marco que elimine este tipo de errores, como Rust o Go. - **Ejemplos de escenarios de ataque**. Un atacante puede obtener o actualizar información confidencial aprovechando una condición de carrera utilizando una variable compartida estáticamente en varios subprocesos. - **Referencias** - [OWASP Code Review Guide](https://owasp.org/www-pdf-archive/OWASP_Code_Review_Guide_v2.pdf) - [Google Code Review Guide](https://google.github.io/eng-practices/review/) ## Denegación de servicio | CWEs mapeadas  | Tasa de incidencia máx  | Tasa de incidencia prom  | Explotabilidad ponderada prom  | Impacto ponderado prom  | Cobertura máx  | Cobertura prom  | Incidencias totales  | Total CVEs   | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 8 | 17.54% | 4.89% | 8.3 | 5.9 | 79.58% | 33.26% | 66985 | 973 | - **Descripción**. La denegación de servicio siempre es posible con suficientes recursos. Sin embargo, las prácticas de diseño y codificación tienen una influencia significativa en la magnitud de la denegación de servicio. Supongamos que cualquier persona con el enlace puede acceder a un archivo grande, o que se produce una transacción computacionalmente costosa en cada página. En ese caso, la denegación de servicio requiere menos esfuerzo para llevarse a cabo. - **Cómo se previene**. Realizar pruebas de rendimiento para el uso de CPU, E/S y memoria, rediseñar, optimizar o almacenar en caché las operaciones pesadas. Considere los controles de acceso para objetos más grandes para asegurarse de que solo las personas autorizadas puedan acceder a archivos u objetos grandes o servirlos a través de una red de almacenamiento en caché perimetral. - **Ejemplos de escenarios de ataque**. Un atacante podría determinar que una operación tarda entre 5 y 10 segundos en completarse. Cuando se ejecutan cuatro subprocesos simultáneos, el servidor parece dejar de responder. El atacante entonces usa 1000 subprocesos y saca de servicio todo el sistema. - **Referencias** - [OWASP Cheat Sheet: Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) - [OWASP Attacks: Denial of Service](https://owasp.org/www-community/attacks/Denial_of_Service) ## Errores de administración de memoria | CWEs mapeadas  | Tasa de incidencia máx  | Tasa de incidencia prom  | Explotabilidad ponderada prom  | Impacto ponderado prom  | Cobertura máx  | Cobertura prom  | Incidencias totales  | Total CVEs  | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| | 14 | 7.03% | 1.16% | 6.7 | 8.1 | 56.06% | 31.74% | 26576 | 16184 | - **Descripción**. Las aplicaciones web usualmente se escriben en lenguajes de memoria administrada, como Java, .NET o Node.js (JavaScript o TypeScript). Sin embargo, estos lenguajes están escritos en lenguajes de sistema que tienen problemas de administración de memoria, como desbordamientos de búfer o de pila, uso de memoria luego de liberada, desbordamiento de números enteros y más. A lo largo de los años, han habido muchos escapes de espacio aislado (sandbox escapes) que demuestran que aunque el lenguaje de la aplicación web es nominalmente "seguro" para la memoria, la estructura de base no siempre lo es. - **Cómo se previene**. Muchas API modernas ahora están escritas en lenguajes seguros para la memoria como Rust o Go. En el caso de Rust, la seguridad de la memoria es una característica crucial del lenguaje. Para el código existente, el uso de banderas de compilador estrictas, fuerte tipado, análisis de código estático y pruebas de fuzzing puede ser beneficioso para identificar pérdidas de memoria, desbordamientos de matrices y memoria, y más. - **Ejemplos de escenarios de ataque**. Los desbordamientos de búfer y pila han sido un pilar de los atacantes a lo largo de los años. El atacante envía datos a un programa, que almacena en un búfer de pila de tamaño insuficiente. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de retorno de la función. Los datos establecen el valor del puntero de retorno para que cuando la función regrese, transfiera el control al código malicioso contenido en los datos del atacante. - **Referencias** - [OWASP Vulnerabilities: Buffer Overflow](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow) - [OWASP Attacks: Buffer Overflow](https://owasp.org/www-community/attacks/Buffer_overflow_attack) - [Science Direct: Integer Overflow](https://www.sciencedirect.com/topics/computer-science/integer-overflow) --- ### 2021 Docs Fr 0x00 2021 Notice (`2021/docs/fr/0x00_2021-notice.md`) # Publication Publié le 24 septembre 2021 ## Auteurs principaux - [Andrew van der Stock](mailto:vanderaj@owasp.org) (twitter: [@vanderaj](https://x.com/vanderaj)) - [Brian Glas](mailto:brian.glas@owasp.org) (twitter: [@infosecdad](https://x.com/infosecdad)) - [Neil Smithline](mailto:neil.smithline@owasp.org) (twitter: [@appsecneil](https://x.com/appsecneil)) - [Torsten Gigler](mailto:torsten.gigler@owasp.org) (twitter: [@torsten_tweet](https://x.com/torsten_tweet)) ## Contributeurs - Orange Tsai [@orange_8361](https://x.com/orange_8361), Auteur de A10-2021: Falsification de requête côté serveur - Jim Manico [@manicode](https://x.com/manicode) et Jakub Maćkowski [@kubamackowski](https://x.com/kubamackowski) - Coordination avec le projet OWASP CheatSheets ## Comment pouvez-vous aider À ce stade nous recherchons : - Data scientists - veuillez examiner notre analyse - Concepteurs Web - nous avons besoin d'une version mobile - Traducteurs - veuillez revoir le texte anglais pour vous assurer qu'il est traduisible - Leadership ASVS, Testing Guide et Code Review Guide - veuillez utiliser nos données et nous aider à lier nos documents et nos normes ensemble ## Journalisation des erreurs et contributions Veuillez signaler toute correction ou problème : - [https://github.com/OWASP/Top10/issues](https://github.com/OWASP/Top10/issues) --- --- METRICS --- - Files Extracted: 99 - Estimated Token Budget: ~211174 tokens - Canonical Reference: https://codewiki.google/github.com/OWASP/Top10