OWASP Top 10 چیست؟

زمان مطالعه: 40 دقیقه

آشنایی با پروژه OWASP

Open Web Application Security Project، که به اختصار آن را OWASP گویند. پروژه‌ای جامعه‌باز (OpenCommunity) است که به سازمان‌ها امکان توسعه، خریداری و نگه‌داشت برنامه‌ و API های قابل اعتماد می‌دهد.
تمامی ابزار‌ها، مستندات، ویدیو‌ها، ارائه‌ها و بخش‌های OWASP رایگان است و هر فردی که علاقمند به بهبود امنیت برنامه‌های کاربردی است، مجاز به استفاده از تمامی موارد ذکر شده می‌باشد.
آزادی OWASP در مورد فشارها و مسائل مالی باعث ارائه اطلاعاتی بی طرف، عملی و مقرون به صرفه می‌شود و از آن، نوع جدیدی از سازمان‌ها را می‌سازد. OWASP به هیچ یک از شرکت‌های فناوری اطلاعات وابسته نمی‌باشد. از طرفی تقریبا همه‌ی افرادی که با OWASP در ارتباط هستند، به صورت داوطلبانه این کار را انجام می‌دهند؛ از جمله هیئت مدیره، لیدرهای بخش‌، لیدرهای پروژه و اعضای آن.

مواردی که شما می‌توانید به صورت رایگان و باز (Open) در OWASP بیابید عبارت است از:

• ابزارها و استانداردهایی برای ایجاد امنیت در برنامه‌های کاربردی
• تحقیقاتی مطابق با آخرین روش‌های علمی
• استانداردهای کنترل‌های امنیتی و کتابخانه‌ها
• کتاب‌هایی کامل در مورد آزمایش‌های امنیت برنامه کاربردی، توسعه و مرور کد ایمن.
• ارائه‌ و فیلم‌ها
• برگه‌های تقلب در مورد بسیاری از موضوعات رایج
• رویدادها، آموزش‌ها و کنفرانس‌ها
• بسیاری از موارد دیگر

رویکرد جامعه‌باز یا OpenCommunity تعمیمی از مفاهیم OpenSource و OpenContent می‌باشد که به منظور طراحی انواع مشارکت تعریف شده اند. اصطلاح Open در OpenCommunity به فرصتی برای هر فرد برای پیوستن به مشارکت در پروژه اشاره دارد.

OWASP Top 10 چیست؟

OWASP Top 10 به معنی ده آسیب پذیری برتر OWASP می‌باشد. این سند که سندی مرجع است، یکی از اسناد پروژه OWASP که 10 مورد از مهم‌ترین نگرانی‌های امنیتی برنامه‌های کاربردی وب را معرفی می‌کند. OWASP Top 10 در واقع گزارشی جمع آوری شده توسط تیمی از متخصصان امنیتی در سراسر جهان است و داده‌های آن تجزیه و تحلیلی از گزارشات بدست آمده تعدادی از سازمان‌ها می‌باشد.
تاکنون 6 نسخه از این سند به ترتیب در سال‌های 2003، 2007، 2010، 2013، 2017 و 2021 انتشار یافت. موارد ارائه شده در این اسناد را در تصویر زیر مشاهده می‌نمایید.

در مرحله اول نگاهی می‌اندازیم به تغییرات اعمال شده روی این سند در سال 2021 و در ادامه موارد تاثیرگذار بر این تغییرات را بررسی می‌کنیم.

آنچه در OWASP Top 10 سال 2021 تغییر کرد

در این سال علاوه بر اضافه شدن سه دسته جدید، چهار دسته‌بندی با نام‌ها و محدوده‌های (Scop) تازه تعریف شد؛ در کنار اینها برخی از دسته‌بندی‌‌ها ترکیب شدند. این تغییر نام‌ها و ترکیب‌ها اعمال شدند تا بر علت اصلی وقوع این آسیب پذیری‌ها تمرکز شود.

متودولوژی انتخاب بخش‌ها:

این بخش از OWASP Top 10 بیشتر از باقی بخش‌ها داده محور است. انتخاب داده‌ها به صورت مهندسی شده صورت می‌گیرد بدینگونه که هشت بخش آن از داده‌های مشارکت‌کننده‌ها جمع‌آوری می‌شود و دوبخش آن از طریق برگزاری یک نظرسنجی عمومی انتخاب می‌شود (در مجموع ده بخش). در واقع استفاده از داده‌های مشارکت‌کننده‌ها، نگاهی است به گذشته زیرا متخصصین امنیتی برای یافتن راه‌ها و آسیب پذیری‌های جدید، نیازمند زمان زیادی برای ارزیابی هستند. همچنین ادغام این آزمون‌ها با ابزارها و فرایندها نیز زمان بر است.
از طرفی برای متعادل کردن این دیدگاه از یک جامعه آماری مستقیم بهره گرفته می‌شود و از توسعه‌دهندگان حرفه‌ای و متخصصان امنیت در یک نظرسنجی خواسته می‌شود تا بگویند چه چیز‌های را دیده‌اند که ممکن است در داده‌های قبلی وجود نداشته باشد. می‌توان مشاهده کرد که به منظور به بلوغ رسانی OWASP Top 10 تصمیماتی اساسی و برنامه‌ریزی شده‌ای تصویب شده است.

چگونگی ساختار دسته‌بندی‌ها:

به نسبت آخرین نسخه از OWASP Top 10، برخی از دسته‌ها تغییر کردند. در این بخش به بررسی خلاصه‌ای از تغییرات اعمال شده می‌پردازیم.

در OWASP Top 10 سال 2017 مشاهده شد که جمع‌آوری داده‌ها متمرکز بر زیرشاخه‌های تقریبا 30 عدد CWE یا Common Weakness Enumeration بود. زیرا طی بررسی‌های انجام شده مشاهده می‌شد که سازمان‌ها در درجه اول بر همین 30 CWE بیشتر از هر موردی تمرکز می‌کنند و به ندرت مشاهده می‌شود که به CWE های دیگر توجهی داشته باشند.

در این بازگفت از OWASP Top 10، محدودیتی اعمال نشد و داده‌های درخواستی می‌توانست هر CWE را شامل شود. به منظور جمع‌آوری اطلاعات، تعداد برنامه‌های آزموده شده در سالی مشخص (برای مثال 2017) و تعداد برنامه‌های آسیب‌پذیر به حداقل یکی از CWEها بررسی شد. جمع آوری این اطلاعات به آن‌ها امکان محاسبه شیوع یک ضعف را می‌دهد.

از طرفی نمونه‌های تکراری از یک CWE در این محاسبات نقشی ندارد و مهم نیست که برنامه کاربردی فقط به نمونه‌ای از یک ضعف امنیتی، یا 4000 نمونه از آن آسیب‌پذیر باشد. با این وجود وسعت CWEهای تاثیر گذار در محاسبات از سال 2017 به 2021، از 30 عدد به تقریبا 400 عدد ضعف امنیتی رسید.

برای انجام گروه‌ و دسته‌بندی CWEها چندین ماه صرف شد. در انتها به دو دسته کلی علل ریشه‌ای و علائم مشهود تقسیم‌بندی گردید. از علل اصلی ضعف‌های امنیتی می‌توان به شکست در رمزنگاری (Cryptographic Failure) و پیکربندی نادرست (Misconfiguration) اشاره نمود و همچنین می‌توان از دسته علائم مشهود به افشاء داده‌های حساس (Sensitive Data Exposure) و انکار سرویس (Denial of Service) اشاره نمود. همچنین قابل ذکر از که تمرکز اصلی OWASP Top 10 روی علل ریشه‌ای می‌باشد زیرا ارائه راهکارهای شناسایی و رفع در این حوزه بسیار منطقی‌تر است.

تمرکز بر علل ریشه‌ای به نسبت علائم مشهود در مباحث امنیتی مفهوم تازه‌ای نیست. مشاهده می‌شود در نسخ پیشین OWASP Top 10 از ترکیب این دو دسته بهره گرفته شد؛ CWEها هم ترکیب این دسته می‌باشند؛ OWASP Top 10 نیز به سادگی از این دسته‌بندی بهره گرفته و تمرکز خود را روی علل ریشه‌ای این ضعف‌ها قرار داده است.

به صورت میانگین هر مورد از OWASP Top 10 تعداد 19.6 ضعف امنیتی (CWE) را شامل می‌شود. کمترین تعداد CWE ها در یک دسته متعلق به مورد Server-site Request Forgery با تعداد 1 عدد و بیشترین تعداد آن مربوط به مورد Insercure Design با تعداد 40 CWE می‌باشد.

چگونگی استفاده از داده‌ها برای برگزینی دسته‌بندی‌ها:

در سال 2017 مشاهده گردید که موارد براساس نرخ وقوع انتخاب گردید و در ادامه با ایجاد بحث‌های گروهی با در نظرگیری احتمال وقوع، بهره‌داری و تاثیرات فنی رتبه‌بندی گردید. در سال 2021 از داده‌ها برای محاسبه احتمال بهره‌برداری و تاثیرات فنی استفاده شد.

برای اینکار با استفاده از OWASP Dependency-Check امتیازات و CVSS ضعف‌ها بر اساس CWE های مرتبط گروه‌بندی گردید. در این مرحله چالش‌هایی قرار داشت که روند کار را آهسته‌تر می‌نمود. یکی از آن‌ها استفاده از CVSSv2 در ثبت امتیازات آسیب‌پذیری‌ها (CVE ها) بود و نیاز بود تمامی آن‌ها به CVSSv3 تبدیل گردند. علاوه بر این محدوده امتیازدهی و همچنین فرمول‌های بین CVSSv2 و CVSSv3 بروز شدند.

در CVSSv2، هم قسمت قابلیت بهره‌برداری و همچنین تاثیرات فنی می‌توانند تا ده نمره را شامل شوند ولی فرمول نمره‌دهی بگونه‌ای می‌باشد که تاثیرات این فیلدها را تا 60% برای قابلیت بهره برداری و 40% برای تاثیرات فنی کاهش می‌دهد. نمرات این دو مورد در CVSSv3 به ترتیب به 6 و 4 محدود شده‌اند ولی با در نظر گرفتن ضرایب و فرمول نهایی، این دو مورد تاثیر بیشتری را در امتیاز نهایی خواهند گذاشت (تقریبا 1.5 امتیاز بیشتر در امتیاز نهایی).

در OWASP Top 10 سال 2021، با توجه به دستورالعمل زیر میانگین امتیاز بهره‌برداری و تاثیرگذاری، محاسبه می‌شود.
در ابتدا تمامی CVE ها همراه امتیازهای CVSS آن‌ براساس CWE گروه‌بندی می‌شود؛ میزان بهره‌وری و تاثیر (exploit و impact) براساس درصد غلظت ضعف امنیتی مربوطه در کل داده، اعتباردهی می‌شوند؛ با استفاده از مجموع مقدار نهایی با باقی داده‌هایی که محاسبه CVSSv2 آن‌ها موجود است، میانگینی از امتیازهای بهره‌برداری و تاثیرگذاری یک ضعف امنیتی محاسبه می‌شود. این مقادیر در محاسبه نیمه دیگر معادله ریسک هم استفاده می‌شوند.

تفاوت بین CVE و CWE

CVE مختصر عبارت common vulnerabilities and exposures می‌باشد و در تعریفی کوتاه تفاوت میان CVE و CWE در این است که یکی در مورد علائم و دیگری در مورد علت است. در صورتی که CWE انواع آسیب‌پذیری‌های نرم افزاری را تعریف نماید، CVE فقط فهرستی از ضعف‌های شناخته شده در مورد سیستم‌ها و محصولاتی خاص است.
انجام این پروژه با اسپانسری US-CERT و نظارت Mitre صورت می‌گیرد. توسط CVE نگهداشت کنترل‌های امنیتی برای اطمینان از برنامه کاربردی صورت می‌گیرد ولی به اندازه CWE یکپارچگی ندارد. با این حال، CVE براحتی با CWE سازگار است.

دلیل اهمیت نرخ بروز در برنامه‌های مختلف (rate) بجای میزان تکرارها (frequency)

سه منبع اصلی داده را می‌توان معتبر شمرد که آن‌ها را با عنوان HaT (Human-assisted Tooling)، TaH (Tool-assisted Human) و Raw tooling شناسایی می‌کنند.

Raw tooling و HaT ها منابعی هستند که قادرند به راحتی تکرار‌ها را کشف و شناسایی کنند. ابزارها معمولا بدنبال آسیب پذیری مشخص هستند و در صورت شناسایی می‌توانند تمامی نمونه‌های آن را در یک برنامه‌ کاربردی یافت کنند. برای مثال به آسیب پذیری Cross-site scripting توجه نمایید؛ معمولا دوحالت رخ خواهد داد: XSS توسط یک اشتباه سیستمی ایجاد می‌شود که در این شرایط می‌تواند هزاران هزار نمونه را در یک برنامه کاربردی واحد شامل شود یا توسط یک اشتباه جزئی در نقطه‌ای از برنامه رخ داده است که حالت‌های کمتری را شامل می‌شود.

از سوی دیگر TaH طیف گسترده‌تری را از انواع آسیب پذیری‌ها جمع آوری می‌کند ولی معمولا به دلیل محدودیت‌های زمانی با میزان تکرار‌های بسیار کمتری. برای درک هدف استفاده از این ابزارها دوباره به آسیب پذیری Cross-site scripting توجه نمایید؛ زمانی که انسان‌ها چنین آسیب پذیری را آزمایش می‌کنند معمولا موفق می‌شوند سه یا چهار نمونه از آن را کشف نمایند. آن‌ها قادرند مشکلی سیستماتیک را کشف کنند و تمامی تکرار‌ها با ارائه یک توصیه رفع نمایند و نیازی به یافتن تمامی تکرارهای آسیب پذیری ندارند.

فرض کنید می‌خواهیم این دو مجموعه متمایز را براساس تکرارها ادغام کنیم. در این صورت داده‌های منابع Tooling و HaT داده‌های منابع TaH را که دقیق‌تر ولی گسترده‌ترند از بین خواهند برد و این بخش که می‌تواند تعریف درستی از میزان وقوع آسیب‌پذیری‌هایی مانند Cross-site scripting باشد را کم اهمیت می‌کند. این اتفاق بدلیل حجم زیاد داده‌ها در منابع HaT و Tooling رخ می‌دهد.

روش استفاده از نرخ بروز از سال 2017 در OWASP Top 10 معرفی شد تا نگاهی متفاوت به داده‌ها انداخته شود و داده‌های Tooling و HaT به طریقی درست، با داده‌های TaH ترکیب شوند. سوالی که روش نرخ بروز مطرح می‌نماید این است که چند درصد از برنامه‌ها حداقل به یک نمونه از یک نوع آسیب‌پذیری دچار هستند. در این سیستم اهمیتی ندارد که آسیب پذیری کشف شده تکرارهای بالایی در یک برنامه کاربردی دارد یا برنامه فقط از طریق یک نقطه به این آسیب پذیری دچار است. یکی از مزیت‌های این روش مرتبط بودن نگاه این شیوه با یک نگاه محاسبه ریسک است که در آن ذکر می‌شود که یک مهاجم برای پیاده‌سازی یک حمله فقط نیازمند یک نمونه از آسیب پذیری واحد است.

عاملین داده

برای هر یک از موارد OWASP Top 10 عواملی موجود است که در ادامه از آن‌ها بهره گرفته می‌شود. در این بخش معانی این عوامل را بررسی می‌نماییم.

• CWEs Mapped: تعداد CWE های طبقه‌بندی شده برای یک گروه
• Incidence Rate: به معنی میزان یا نرخ بروز می‌باشد و درصد برنامه‌های آسیب پذیر به CWE‌های دسته‌بندی شده در یک مورد از Top 10 که از بین جمعیت برنامه‌های مورد آزمایش در آن سال می‌باشد.
• Coverage (Testing): درصد برنامه‌های کاربردی که توسط تمامی سازمان‌ها برای یک CWE معین مورد آزمایش قرار گرفته‌اند.
• Weighted Exploit: نمره فرعی بهره برداری (Exploit)، از CVSSv2 و CVSSv3 که به CVEها اختصاص داده شده و در CWEها طبقه‌بندی شده، عادی سازی شده و در مقیاسی 10 امتیازی، محاسبه شده.
• Weighted Impact: نمره فرعی تاثیرات فنی (Impact)، از CVSSv2 و CVSSv3 که به CVEها اختصاص داده شده و در CWEها طبقه‌بندی شده، عادی سازی شده و در مقیاسی 10 امتیازی، محاسبه شده.
• Total Occurrences: تعداد کل برنامه‌های کاربردی که دارای CWEهای طبقه‌بندی شده در یک ردیف هستند.
• Total CVEs: تعداد کل CVE های ثبت شده در پایگاه‌داده NVD که براساس CWEهای هر مورد، طبقه بندی شدند.

شیوه استفاده از OWASP Top 10 به عنوان یک استاندارد امنیتی

OWASP Top 10 در مرحله اول یک سند به منظور آگاهی است. به هرحال این موضوع باعث نشد تا از زمان آغاز انتشار این سند در سال 2003، سازمان‌ها از آن به عنوان یک استاندارد برای امنیت برنامه کاربردی بهره نگیرند. در صورتی که شما هم می‌خواهید از OWASP Top 10 به عنوان یک استاندارد در کدنویسی یا آزمایش‌های نفوذپذیری استفاده کنید، باید بدانید که این عمل فقط شروعی کوچک در راستای تولید محصولی امن می‌باشد.

از مشکلات استفاده از OWASP Top 10 به عنوان یک استاندارد امنیتی این است که در آن صرفا خطرات موجود در برابر امنیت برنامه کاربردی مستند می‌شود؛ نه مسائلی که به راحتی قابل آزمایش هستند. برای مثال یکی از موارد این سند A04:2021-Insecure Design می‌باشد که موردی فراتر از محدوده اکثر انواع آزمایشات امنیتی می‌باشد. مثالی دیگر از این مسائل می‌تواند آزمون‌هایی باشد که نیاز است در محل صورت گیرند؛ نظارت و واقع‌نگاری (monitoring و logging) تنها در صورتی که همراه با مصاحبات و درخواست‌هایی مبنی بر نمونه برداری از پاسخ‌های موثر در حادثه باشد، نتیجه بخش واقع خواهد بود.
یک ابزار تجزیه و تحلیل کدهای استاتیک قادر است به دنبال عدم وجود Logging شود ولی این موضوع غیرممکن است که این ابزار‌ها قادر به تشخیص نقض در واقع‌نگاری منطق‌های تجاری (business logic) یا کنترل‌های دسترسی (access control) باشند.

در ادامه توصیه‌هایی را برای استفاده از OWASP Top 10 در زمان مناسب مشاهده می‌نمایید:

زمان استفاده	OWASP Top 10	OWASP Application Security Verification Standard
اطلاعات و هشیاری (Awareness)	بله
تمرین (Training)	مقدماتی	به صورت جامع
طراحی و معماری (Design and architecture)	برخی از اوقات	بله
استاندارد کد نویسی (Coding standard)	به طور حداقلی	بله
بررسی کد امن (Secure Code review)	به طور حداقلی	بله
چک‌ لیست بررسی دقیق (Peer revie checklist)	به طور حداقلی	بله
تست واحد (Unit testing)	برخی از اوقات	بله
تست یکپارچگی (Integration testing)	برخی از اوقات	بله
تست نفوذ (Penetration testing)	به طور حداقلی	بله
پشتیبانی از ابزار (Tool support)	به طور حداقلی	بله
زنجیره عرضه امن (Secure Supply Chain)	برخی از اوقات	بله

 

پیشنهاد می‌شود در صورتی که می‌خواهید از یک استاندارد امنیتی برنامه‌های کاربردی بهره بگیرید از OWASP Application Security Verification Standard یا ASVS استفاده نمایید زیرا این استاندارد برای تایید و آزمایش برنامه‌های کاربردی طراحی شده است و می‌تواند در تمام بخش‌های چرخه زندگی توسعه امن محصول استفاده شود.

تنها انتخاب قابل قبول برای فروشندگان ابزارها ASVS می‌باشد. در طراحی ابزارها بدلیل ماهیت چندین مورد از ریسک‌های نامبرده در OWASP Top 10 نمی‌توان از این سند به عنوان استانداردی برای شناسایی، آزمایش و محافظت استفاده نمود. مثالی از این موارد همانطور که در پیش ذکر شد A04:2021-Insecure Design می‌باشد.

ده آسیب پذیری برتر OWASP در سال 2021

در این بخش لیستی از ده آسیب پذیری پراهمیت OWASP یعنی OWASP Top 10 در سال 2021 مورد بررسی و ارزیابی قرار می‌گیرد. در هر مورد از موارد این بخش به عوامل، بررسی اجمالی، تشریح، راهکارهای پیشگیری و نمونه‌هایی از آن دسته، پرداخته می‌شود و در کنار آن لیستی از CWE های طبقه بندی شده در بخش مربوطه معرفی می‌گردد.

1. Broken Access Control – 2021

عوامل

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

بررسی اجمالی

این مورد از جایگاه پنجم به جایگاه اول انتقال یافت. 94 درصد از برنامه‌های کاربردی که برای نوعی از ضعف Broken Access Control بررسی شدند با نرخ بروز 3.81 درصد و با بیش از 318 هزار مورد، بیشترین وقوع را میان مجموعه داده‌های ارائه شده دارند. قابل ذکر است این مورد شامل CWE های CWE-200: Exposure of Sensitive Information to an Unauthorized Actor، CWE-201: Exposure of Sensitive Information Through Sent Data و CWE-352: Cross-Site Request Forgery می‌باشد.

تشریح

کنترل دسترسی (Access control) سیاست‌هایی را اعمال می‌نماید که کاربران نتوانند خارج از مجوز‌های صادره، عملی انجام دهند. تخریب این سیاست‌ها می‌تواند منجر به افشای اطلاعات غیرمجاز، اصلاح یا تخریب تمامی داده‌ها و یا انجام یک عمل تجاری خارج از محدودیت‌های کاربر شود. آسیب پذیری‌های رایج access control عبارت‌اند از:

• کوچک‌ترین تخطی از سطوح دسترسی تعریف شده، که در آن دسترسی باید تنها برای قابلیت‌ها، نقش‌ها و یا کاربرانی خاص مجاز باشد؛ ولی برای هرکس قابل دسترس است.
• دور زدن سطوح دسترسی تعریف شده با ایجاد تغییر در URL (parameter tampering یا force browsing)، وضعیت برنامه‌کاربردی داخلی یا صفحه HTML و یا با استفاده از ابزارهای حمله برای تغییر در درخواست‌‌های API
• مشاهده و ویرایش حساب فردی دیگر، با استفاده از شناسه‌های منحصر به فرد آن حساب (insecure direct object references یا IDOR)
• دسترسی به API، زمانی که کنترل‌های دسترسی روی متد‌های POST، PUT و DELETE تعریف نشده است.
• ارتقای سطح دسترسی یا فعالیت به عنوان یک کاربر، زمانی که ورود انجام نشده است و فعالیت به عنوان یک ادمین، زمانی که با حساب کاربری معمولی ورود صورت گرفته است.
• دستکاری Metadata؛ به عنوان مثال بازتولید یا دستبرد در توکن‌های کنترل دسترسی JWT یا JSON Web Token، کوکی‌ها و یا فیلد‌های پنهان به منظور ارتقای سطح دسترسی یا سوء استفاده از JWT های نامعتبر.
• پیکربندی نادرست CORS که به منابع نامعتبر و غیرقابل اعتماد اجازه دسترسی به APIها را می‌دهد.
• دسترسی به صفحات معتبر با استفاده از حساب کاربری نامعتبر یا دسترسی به صفحات رده بالا به عنوان کاربر استاندارد (عادی).

راهکارهای پیشگیری

باید توجه داشت که کنترل سطح دسترسی تنها در کد سمت سرور یا API های Server-less موثر خواهد بود زیرا فقط در این صورت نفوذگر قادر به کنترل یا تغییر Metadata نخواهد بود.

• دسترسی به منابع را جز هنگام استفاده از منابع عمومی به صورت پیشفرض رد نمایید.
• اجرای یکباره مکانیزم‌های کنترل سطوح دسترسی و استفاده مجدد آن در برنامه کاربردی و به حداقل رسانی استفاده از Cross-Origin Resource Sharing (اشتراک منابع با مبدا‌های خارجی) یا CORS
• مدل‌های کنترل دسترسی باید روی مالکیت رکورد‌ها تاکید داشته باشد و نباید ایجاد، خواندن، بروزرسانی یا حذف رکورد‌ها را توسط کاربر بپذیرد.
• الزامات یکتا محدودیت کسب و کار برنامه (application business limit) باید توسط Domain models اجرا شوند.
• اطمینان از عدم فعال بودن directory listing، Metadata فایل‌ها، وجود فایل‌های پشتیبان در آدرس ریشه (Root).
• واقع‌نگاری (log) شکست‌های کنترل دسترسی و ارسال هشدار به مدیر در مواقع مناسب (برای مثال هنگام شکست‌های متعدد).
• محدودسازی سرعت API و دسترسی به کنترلرها به منظور عدم ایجاد مشکل توسط ابزارهای حمله خودکار.
• شناسه‌ نشت‌های Stateful پس از خروج از سیستم باید در سمت سرور بی‌اعتبار شوند. توکن‌های Stateless JWT باید عمری کوتاه داشته باشند بطوری که فرصت‌ها برای نفوذ مهاجم به حداقل رسانیده شود. در صورتی که نیاز به توکن‌های JWT با عمری بالا دارید، پیشنهاد می‌شود از استاندارد‌های OAuth برای ابطال دسترسی پیروی کنید.

نمونه‌هایی از سناریو حمله

1. برنامه کاربردی از داده‌های اعتبارسنجی نشده برای یک تماس SQL که به اطلاعات حساب‌ دسترسی دارد، بهره می‌گیرد:

pstmt.setString(1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

یک مهاجم می‌تواند به راحتی با تغییر پارامتر acct در مرورگر هر عدد دلخواهی را ارسال کند و درصورتی که این پارامتر به درستی اعتبارسنجی نشده باشد، مهاجم قادر خواهد بود که به حساب کاربری مذکور دسترسی یابد.

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

2. یک مهاجم بسادگی آدرس‌های زیر را در ابتدا کشف و سپس به آن ورود می‌کند اما برای دسترسی به صفحات مدیریتی نیاز به دسترسی ادمین می‌باشد.

https://example.com/app/getappInfo

https://example.com/app/admin_getappInfo

در صورتی که کاربری بدون انجام احراز هویت و یا بدون داشتن سطح دسترسی ادمین به این صفحات دسترسی یابد، یک نقض خواهد بود.

 

2. Cryptographic Failures – 2021

عوامل

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

 بررسی اجمالی

این دسته با صعود یک واحدی به موقعیت دوم تغییر مکان داد. پیش از این با نام Sensitive Data Exposure شناخته می‌شد که بیشتر یک نشانه بود تا یک علت ریشه‌ای؛ ولی حال تمرکز روی شکست‌های مرتبط با رمزنگاری یا فقدان آن می‌باشد که اغلب منجر به افشای اطلاعات حساس می‌شود. این مورد شامل CWE های CWE-259: Use of Hard-coded Password، CWE-327: Broken or Risky Crypto Algorithm و CWE-331 Insufficient Entropy می‌باشد.

تشریح

مرحله نخست تعیین نیاز‌ها در مورد حفاظت از داده‌ها هنگام انتقال یا دیگر مواقع است. به عنوان مثال رمز‌های عبور، شماره‌های کارت اعتباری، سوابق سلامتی، اطلاعات شخصی و اسرار تجاری نیازمند محافظت بیشتری می‌باشد؛ عموما در صورتی که داده زیرمجموعه‌ای از قوانین حفظ حریم خصوصی باشد حساس تلقی می‌شود؛ داده‌های تعریف شده توسط General Data Protection Regulation اروپا یا آیین نامه‌‌های financial data protection مانند PCI Data Security Standard، نیازمند محافظت ویژه‌تری هستند. باید به موارد زیر توجه ویژه‌ای داشته باشیم:

• آیا داده‌ای وجود دارد که به صورت Clear در حال انتقال باشد؟ این موضوع در مورد پروتکل‌هایی نظیر FTP، SMTP و HTTP همچنین در مورد استفاده از TLS های بروزشده مانند STARTTLS می‌باشد. به صورت کلی ترافیک‌های اینترنت‌های خارجی خطرناک خواهد بود. تمامی ترافیک‌های داخلی مانند ترافیک‌های بین load balancerها، وب سرورها و یا سیستم‌های Back-end باید تایید شوند
• آیا درحال استفاده از الگوریتم‌های رمزنگاری قدیمی یا ضعیف و یا پروتکل‌هایی که به صورت پیشفرض یا در کدهای قدیمی مورد استفاده قرار می‌گرفتند، هستیم؟
• آیا کلیدهای رمزنگاری پیشفرض در حال استفاده است؟ یا کلیدهای رمزنگاری ضعیف تولید یا استفاده مجدد می‌شود؟ آیا مدیریت کلید‌ها یا چرخش و تغییر آن‌ها به صورت مناسب صورت می‌گیرد؟ آیا کلیدهای رمزنگاری در repositoryهای کدمنبع بررسی می‌شوند؟
• ایا مکانی وجود دارد که در آن رمزنگاری به درستی یا به صورت کامل اجرا نشود؟ به عنوان مثال هدر امنیتی HTTP وجود دارد که مفقود شده باشد؟
• آیا گواهی سرور دریافت شده و trust chain به درستی تایید شده‌اند؟
• آیا initialization vectorها نادیده گرفته می‌شود؟ یا مجددا مورد استفاده قرار می‌گیرد؟ و یا برای cryptographic modeها به اندازه کافی ایمن نیستند؟ آیا یک حالت عملیاتی (mode of operation) ناامن مانند ECB در حال استفاده است؟ آیا رمزنگاری عادی زمانی که رمزنگاری معتبر مناسب‌تر است مورد استفاده قرار می‌گیرد؟
• ایا رمزعبور در زمان عدم وجود PBKDF یا Password-Based Key Derivation Function به عنوان کلیدهای رمزنگاری مورد استفاده قرار می‌گیرد؟
• آیا برای اهدافی که در راستای رمزنگاری است، هیچگونه پارامتر تصادفی مورد استفاده قرار می‌گیرد که به منظور برآورده کردن الزامات رمزنگاری طراحی نشده باشد؟ حتی در صورت استفاده از تابع صحیح آیا نیاز است که توسط برنامه نویس مقداردهی شود؟ در صورتی که نیازی نیست، آیا توسعه دهنده تابعی قدرمند به منظور مقداردهی به صورت بی‌نظم یا غیرقابل پیشبینی، طراحی کرده است؟
• آیا توابعی به منظور ساخت هش‌هایی مانند MD5 یا SHA1 در حال استفاده است؟ آیا زمانی که CHF یا cryptographic hash functions مورد نیاز است از NCHF یا non-cryptographic hash function استفاده می‌شود؟
• آیا روش‌های cryptographic padding منسوخ شده مانند PCKS number 1 v1.5 در حال استفاده است؟
• آیا پیام‌های خطای رمزنگاری یا اطلاعات کانال‌های جانبی، به عنوان مثال در قالب حملات padding oracle، قابل بهره برداری هستند؟

راهکارهای پیشگیری

موارد زیر را به صورت حداقلی دنبال کنید.

• داده‌های پردازش شده، ذخیره شده یا منتقل شده توسط برنامه را دسته‌بندی نمایید. داده‌هایی که طبق قوانین امنیتی، الزامات مدیریتی یا نیازهای کسب و کار حساس هستند را شناسایی کنید.
• داده‌های حساس رو جز در مواقع ضروری ذخیره ننمایید. در سریع ترین زمان آن‌ها را دور بیاندازید و یا از PCI DSS منطبق با توکنیزاسیون یا روش‌های کوتاه‌سازی بهره گیرید زیرا اطلاعاتی که ذخیره نشوند را نمی‌توان ربود.
• در زمان استراحت داده‌های حساس مطمئن شوید که به صورت رمزگذاری شده قرار دارند.
• مطمئن شوید که از استاندارد‌های بروز شده و قوی برای الگوریتم‌ها، پروتکل‌ها و کلیدها بهره گرفته می‌شود. از سیستم‌های مدیریت کلید مناسب استفاده نمایید.
• تمامی داده‌های در حال انتقال با پروتکل‌های امن مانند TLS همراه رمزهای FS یا forward secrecy، اولویت‌بندی رمزها توسط سرور (cipher prioritization by the server) و پارامترهای امن (secure parameters) باید رمزنگاری شده باشند. اجرای رمزنگاری باید با استفاده از دستورالعمل‌هایی مانند HSTS (HTTPStrictTransportSecurity) صورت گیرد.
• قابلیت Caching برای پاسخ‌های حساس باید غیرفعال باشد.
• اعمال کنترل‌های امنیتی مورد نیاز منطبق با دسته‌بندی داده‌ها.
• از پروتکل‌های قدیمی مانند FTP یا SMTP برای انتقال داده‌های حساس استفاده ننمایید.
• رمزهای عبور را با استفاده از توابع ساخت هش با salt، همراه با یک work factor یا delay factor مانند Argon2، scrypt، bcrypt یا PBKDF2 ذخیره کنید.
• IVها باید برای حالت عملیات (mode of operation) انتخاب شوند. برای بسیاری از Mode ها به معنی استفاده از یک CSPRNG یا cryptographically secure pseudo random number generator می‌باشد و در Mode هایی که نیازمند به nonce هستند، IVها به CSPRNG نیازی ندارند. باید به این نکته توجه شود که در تمامی موارد IV نباید دوباره برای کلیدی ثابت مورد استفاده قرار گیرد.
• همیشه از AE یا authenticated encryption به جای رمزنگاری معمولی بهره گیرید.
• کلیدها باید به صورت رمزنگاری شده و تصادفی تولید شده و به صورت ارایه‌های بایتی در مموری ذخیره شوند. در صورتی که یک پسورد در حال استفاده است باید توسط یک PBKDF (Password-Based Key Derivation Function) تبدیل به یک کلید شود.
• از تصادفی بودن رمزنگاری که در مکان‌های مناسب استفاده مطمئن شوید و توجه نمایید نیازی به مقداردهی اولیه به صورت قابل پیشبینی نیست. اکثر APIهای مدرن، توسعه دهنده را وادار به انجام مقداردهی اولیه CSPRNG برای رسیدن به امنیت نمی‌کنند.
• از بهره‌گیری از توابع رمزنگاری و طرح‌های padding منسوخ شده مانند MD5، SHA1 و PKCS number 1 v1.5 اجتناب کنید.
• تاثیرگذاری پیکربندی و تنظیمات را به صورت مستقل تایید نمایید.

نمونه‌هایی از سناریو حمله

1. برنامه کاربردی را فرض کنید که شماره‌های کارت اعتباری را در پایگاه داده به صورت خودکار و رمزگذاری شده، ذخیره می‌کند. با این حال این برنامه هنگام استفاده از داده‌ها، آن‌ها را به صورت خودکار رمزگشایی می‌کند.
   در این برنامه در صورت وجود نقض امنیتی SQL injection، شماره‌های کارت اعتباری همواره افشاء خواهد شد.
2. سایتی که از TLS استفاده نمی‌کند یا کاربر را ملزم به استفاده از آن در تمام صفحات نمی‌کند و یا از رمزنگاری ضعیفی پشتیبانی می‌کند را فرض کنید. نفوذگر قادر به انجام موارد زیر می‌باشد:

• مانیتور کردن ترافیک (به عنوان مثال در یک شبکه Wireless ناامن)
• downgrades کردن اتصالات از HTTPS به HTTP
• شنود درخواست‌ها (intercepts requests)
• ربودن کوکی کاربران و سپس اعمال آن بر سیستم خود به منظور hijack نشست تصدیق شده (authenticated) کاربر

3. پایگاه داده رمزعبوری را فرض کنید که در آن تمامی پسوردها به صورت هش شده و بدون داشتن Salt ذخیره شده‌اند. در صورتی که ان برنامه به نقض امنیتی در اپلود فایل آسیب پذیر باشد، نفوذگر قادر به استخراج هش‌ها و پیاده‌سازی حملات rainbow table برای رسیدن به رمزهای عبور اصلی خواهد بود. ضمنا هش‌هایی که توسط توابع ساده و یا سریع تولید هش به وجود آیند، ممکن است توسط GPUها کرک شوند؛ حتی در صورت استفاده از Salt

 

3. Injection – 2021

عوامل

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

بررسی اجمالی

این دسته در سال 2021 به جایگاه سوم نزول پیدا کرد. 94 درصد از برنامه‌های کاربردی که برای نوعی از ضعف Injection بررسی شدند با نرخ بروز 3 درصد و با بیش از 274 هزار مورد وقوع، سبب شدند که این دسته در این جایگاه قرار گیرد. این مورد شامل CWE های CWE-79: Cross-site Scripting، CWE-89: SQL Injection و CWE-73: External Control of File Name or Path می‌باشد.

تشریح

یک برنامه کاربردی زمانی به حملات Injection آسیب پذیر است که:

• داده‌های ارائه شده توسط کاربر اعتبارسنجی، فیلترگذاری و sanitize نشوند.
• کوئری‌های پویا و یا تماس‌های non-parameterized بدون انجام Escaping در مفسر جایگذاری شوند.
• استفاده از داده‌های مخرب در پارامترهای جستجو ORM یا همان object-relational mapping به منظور استخراج رکوردهای حساس و اضافی
• داده‌های مخرب به صورت مستقیم مورد استفاده قرار می‌گیرند یا به متغیرهای دیگر می‌پیوندند (concatenated). SQL یا دستورات در کوئری‌های پویا، دستورات پویا یا SPهای پویا حاوی داده‌ای مخرب یا ترکیبی از آن باشند.

برخی از معمول ترین حملات این دسته عبارت‌اند از: SQL inejction، NoSQL injection، OS command Injection، ORM Injection، LDAP Injection، EL Injection و OGNL Injection

این مفهوم در میان تمام مفسران یکسان می‌باشد و بازبینی کدمنبع بهترین روش برای شناسایی این نوع حملات است. آزمایش خودکار روی تمامی پارامترهای ورودی، هدرها، URLها، کوکی‌ها، JSON، SOAP و ورودی‌های XML بشدت پیشنهاد می‌شود. سازمان‌ها می‌توانند با استفاده از ابزارهای آزمون‌ امنیتی ایستا (SAST)، پویا (DAST)، تعاملی (IAST) در پایپ لاین‌ CI/CD خود، به منظور تشخیص حملات تزریق پیش از استقرار محصول اقدام نمایند.

راهکارهای پیشگیری

جلوگیری از حملات Injection مستلزم جدا نگه داشتن داده‌ها از دستورات و کوئری‌ها است:

• بهترین راهکار بهره‌گیری از یک API امن است؛ API ای که به صورت کامل از مفسر استفاده نمی‌کند؛ یک رابط پارامتری (parameterized interface) را فراهم آورد یا از ORM بهره می‌گیرد.

• از اعتبارسنجی Whitelist بروی ورودی‌ها در سمت سرور بهره گیرید. البته این یک دفاع کامل نیست زیرا بسیاری از برنامه‌ها به کارکتر‌های خاص نیازمند هستند.
• برای تمامی کوئری‌های وابسته به داده‌های ورودی کاربر، عمل Escaping را منطبق با مفسر اجرایی روی تمامی کارکتر‌های خاص انجام دهید.

• با استفاده از کنترلر LIMIT یا دیگر کنترلر‌ها در کوئری از افشای حجیم رکورد‌ها در حملات SQL Injection جلوگیری نمایید.

نمونه‌هایی از سناریو حمله

1. برنامه کاربردی را فرض بگیرید که در ساختار تماس SQL از داده‌های غیرقابل اعتماد بهره میگیرد.

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

2. به صورت مشابه اعتماد کورکورانه برنامه به فریم‌ورک‌ها می‌تواند منجر به بروز آسیب پذیری‌های Injection شود.

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

در هر دو مثال مهاجم با تغییر پارامتر ID قادر به انجام حمله است. مقدار ارسالی:

‘ or ‘1’=’1

به عنوان مثال:

http://example.com/app/accountView?id=' or '1'='1

نفوذگر با این تغییر می‌تواند به طور کامل معنای این دو کوئری را تغییر و باعث شود تمام رکورد‌های جدول accounts بازگردد.

همچنین می‌تواند حملات خطرناک‌تری را با تغییر یا حذف داده‌ها و یا اجرای SPها پیاده‌سازی کند.

 

4. Insecure Design – 2021

عوامل

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

 بررسی اجمالی

این مورد یکی از دسته‌های جدید در سال 2021 که مربوط به نقض در طراحی و ساختار برنامه است. تمرکز این دسته بر توجه به مدل‌سازی‌های تهدید، الگوهای طراحی ایمن و معماری‌های مرجع می‌باشد. پافشاری این مورد بر گام نهادن فراتر از shift-left در فضاهای کدنویسی پیش از شروع آن به دلیل اهمیت principles of Secure در طراحی برنامه کاربردی می‌باشد. قابل ذکر است که این مورد شامل CWE های CWE-209: Generation of Error Message Containing Sensitive Information، CWE-256: Unprotected Storage of Credentials، CWE-501: Trust Boundary Violation و CWE-522: Insufficiently Protected Credentials می‌باشد.

تشریح

Insecure Design مقوله‌ای گسترده که نشان دهنده ضعف‌های متفاوتی است که به عنوان “Control Design ناقص یا غیر موثر” بیان می‌شود.
باید دانست که insecure design دسته‌ای مادر برای تمام دسته‌های دیگر OWASP Top 10 نیست زیرا در واقع نقض در طراحی با نقض در اجرا متفاوت است چون این دو مورد، علل ریشه‌ای متفاوتی دارند. یک طراحی امن می‌تواند همواره نقض‌هایی در اجرا داشته باشد که منجر به آسیب پذیری‌های ناشی می‌شود. یک طرح ناامن را نمی‌توان با بی‌نقص‌ترین اجراها امن نمود و مطابق تعریف، کنترل‌های امنیتی لازم هیچ وقت به منظور جلوگیری از حملات مربوط به نقض در طراحی، ساخته نشده‌اند.
یکی از مهم‌ترین عوامل در تعریف یک طرح ناامن، عدم وجود business risk profiling در نرم‌افزار یا سیستم درحال توسعه می‌باشد و عدم تعیین صحیح سطح طراحی امنیتی مورد نیاز می‌باشد.

مدیریت الزامات و منابع:

جمع‌آوری و مذاکره در مورد الزامات کسب و کار در یک برنامه کاربردی، شامل الزامات حفاظتی در رابطه با محرمانگی، یکپارچگی و قابل دسترس بودن در کنار اصالت تمامی دارایی‌ها و منطق‌‌های تجاری مورد انتظار می‌باشد. این را در نظر بگیرید، در صورتی که برنامه کاربردی شما به تفکیک tenantها نیازمند (علاوه بر کنترل سطوح) است برنامه شما چگونه خواهد شد. الزامات فنی از جمله الزامات امنیتی functional یا non-functional را جمع‌آوری نمایید. در مورد بودجه‌ای که برای طراحی، ساخت، آزمایش، بهره‌برداری از جمله در موارد امنیتی، صرف می‌شود برنامه ریزی و مذاکره نمایید.

طراحی امن:

طراحی امن یک فرهنگ و متدولوژی به منظور ارزیابی مداوم تهدیدات می‌باشد و تضمین می‌کند که کد برنامه در برابر روش‌های شناخته شده حملات آزمایش و طراحی شده است. Threat modeling باید در جلسات اصلاحی (و یا فعالیت‌های مشابه) ادغام شود؛ به دنبال تغییرات در data flowها، access control و باقی کنترل‌های امنیتی باشید. در توسعه User story، جریان‌های صحیح و حالت‌های شکست را تعیین نمایید و اطمینان حاصل نمایید که به خوبی درک می‌شوند و مورد توافق طرفین قرار می‌گیرند. فرضیات و شرایط را برای استثنائات و شکست‌ها تحلیل نمایید و مطمئن شوید که آن‌ها همواره صحیح و مطلوب هستند. تعیین نمایید که فرضیات محتمل چگونه تایید یا رد می‌شوند و شرایط مورد نیاز را برای رفتار‌های مناسب اعمال نمایید. اطمینان حاصل نماید که نتایج در User Story مستند خواهند شد. از اشتباهات درس بگیرید و انگیزه‌های مثبتی را برای ارتقا در بهبود‌ها در نظر گیرید. طراحی امن، یک add-on یا ابزار نیست تا قادر باشید آن را به برنامه خود اضافه کنید.

چرخه توسعه امن:

یک برنامه امن نیازمند یک چرخه توسعه امن (SDL)، نوعی الگوی طراحی امن، متولوژی‌ای تایید شده، کتابخانه‌های ایمن برای component، مدل‌سازی تهدید و استفاده از ابزار‌های پویش می‌باشد. از متخصصان امنیتی خود از آغاز یک پروژه نرم‌افزاری و در تمام مدت ساخت آن و همچنین در زمان نگهداشت برنامه بهره گیرید. همچنین از OWASP Software Assurance Maturity Model یا SAMM به منظور کمک به ساختار توسعه ایمن نرم افزار خود، بهره گیرید.

راهکارهای پیشگیری

• تولید و استفاده از یک چرخه عمر (lifecycle) ایمن با کمک‌گیری از متخصصان در حوزه امنیت برنامه کاربردی (AppSec) به منظور طراحی و ارزیابی امنیت و کنترل‌های مربوط به حریم خصوصی
• فراهم‌آوری و استفاده از یک کتابخانه از الگو‌های طراحی امن، که قابل پیاده‌سازی در کنار componentهای برنامه باشد.
• از مدل‌سازی تهدید در احرازهویت‌های حیاتی، کنترل سطوح دسترسی، منطق‌های تجاری و جریان‌های کلیدی بهره گیرید.
• کنترل‌ها و گفتار‌های امنیتی را با User Story ادغام نمایید.
• در هر سطح از برنامه خود به صورت مستقل اعتبارسنجی کنید (از Frontend تا Backend)
• آزمونی یکپارچه و واحد را به منظور تایید مقاوم بودن تمام جریان‌های بحرانی در برابر مدل تهدید خود پیاده‌سازی کنید.
• جداسازی سطوح لایه‌های سیستم و شبکه با توجه به نیازهای حافظتی
• جداسازی سختگیرانه tenantها با استفاده از طراحی در تمام سطح‌ها
• مصرف منابع توسط کاربران و یا سرویس‌ها را محدود نمایید.

نمونه‌هایی از سناریو حمله

• روند بازیابی اعتبارنامه‌ها (مانند رمزعبور) می‌تواند شامل روش پرسش و پاسخ باشد. باید دانست که این روش توسط NIST 800-63b، OWASP ASVS و OWASP Top 10 رد شده و نوعی نقض در امنیت طلقی می‌شود زیرا به صورت کلی این سوال‌ها به‌گونه‌ای هستند که پاسخ‌‌آن را می‌تواند کسی جز صاحب حساب هم بداند و مدرکی به منظور تایید هویت در نظر گرفته نمی‌شود. این بخش به صورت کلی نباید در برنامه کاربردی مورد استفاده قرار گیرد.
• یک سینما زنجیره‌ای را تصور نمایید که اجازه رزرو گروهی را می‌دهد و تا حداکثر 15 نفر می‌توانند پیش پرداختی نداشته باشند. نفوذگر می‌تواند با ارسال چندین درخواست آزمایش نماید که آیا می‌توان به عنوان مثال 600 صندلی از این سینما را اشغال نمایید تا باعث از دست دادن درآمدی کلان شود.
• یک وب‌سایت خرده‌فروشی انلاین را فرض نمایید که در برابر ربات‌های scalpers (ربات‌هایی که معمولا توسط نفوذگران استفاده می‌شود تا در صف‌‌های انلاین جز اولین نفرات باشند) محافظت نشده‌ است. نفوذگر با این ربات قادر خواهد بود که محصولاتی را که در حراج است از این وب‌ سایت‌ به منظور فروش مجدد خریداری کند. این موضوع تبلیغ بدی برای صاحبان این کسب و کار خواهد بود و علاقمندانی که توانایی خرید این محصولات را با قیمت‌های اصلی ندارند خاطر خوشی از این حراج‌ها نخواهند داشت. طراحی دقیق و ضد ربات‌ می‌تواند این خرید‌ها که معمولا بلافاصله پس از منتشر شدن محصولات حراج، انجام می‌شود را شناسایی و چنین تراکنش‌هایی را رد نماید.

 

5. Security Misconfiguration – 2021

عوامل

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

 بررسی اجمالی

ارتقاع یافته از رتبه ششم نسخه قبلی از OWASP Top 10؛ 90 درصد از برنامه‌های کاربردی که برای نوعی از ضعف Misconfiguration بررسی شدند با نرخ بروز 4 درصد و با بیش از 208 هزار مورد ظهور، باعث ثبت شدن این مورد در جایگاه پنجم بودند. یکی از مسبب‌های چنین رتبه‌ای برنامه‌هایی بودند که تنظیمات و کانفیگ‌های زیاد و پیچیده‌ای داشتند. این مورد شامل CWEهای CWE-16 Configuration و CWE-611 Improper Restriction of XML External Entity Reference می‌باشد.

تشریح

برنامه شما در صورتی به این مورد آسیب پذیر خواهد بود که:

• عدم توجه به hardening در هر بخشی از برنامه کابردی مانند پشته (stack) یا پیکربندی نادرست در مجوز‌های سرویس‌های ابری
• نصب یا فعال سازی سرویس‌های غیرضروری (مانند پورت‌ها، خدمات، صفحات، حساب‌ها و یا سطوح دسترسی غیرضروری)
• فعال بودن حساب‌های پیشفرض با رمزعبور پیشفرض
• عدم مدیریت در نمایش خطاها و نتیجتا نمایش stack trace یا خطاهایی که اطلاعات زیادی را فاش می‌نماید.
• در سیستم‌های ارتقاع یافته، قابلیت‌های امنیتی غیرفعال هستند و یا به صورت ایمن پیکربندی نشده‌اند.
• تنظیمات امنیتی در سرور‌، frameworkها، کتابخانه‌ها، پایگاه‌های داده برنامه کاربردی روی مقادیر امن تنظیم نشده‌اند
• سرور، headerهای امنیتی را ارسال نمی‌کند و یا مقادیر امن برای ‌آن‌ها در نظر گرفته نمی‌شود.
• نرم افزار بروز نباشد و یا آسیب پذیر باشد. ( به بخش A06:2021-Vulnerable and Outdated Components مراجعه کنید.)

برنامه کاربردی بدون داشتن یک پروسه پیکربندی امن منسجم و قابل تکرار در معرض خطرات حیاتی قرار خواهد گرفت.

راهکارهای پیشگیری

اجرای فرآیندهای نصب امن شامل موارد زیر می‌باشد:

• یک فرآیند hardening قابل تکرار می‌تواند پیاده‌سازی محیط دیگری را که به خوبی قفل یا امن شده است، آسان‌تر و سریع‌تر نماید. محیط‌های توسعه، QA و تولید باید به صورت یکسان پیکربندی شوند و در هر محیطی به صورت جداگانه باید اعتبارسنجی صورت گیرد. این فرآیند باید خودکارسازی شود تا تلاش‌های مورد نیاز برای ایجاد یک محیط امن جدید به حداقل برسد.
• یک پلتفرم حداقلی و بدون هیچ قابلیت، component، سند و نمونه غیرضروری را پیاده‌سازی کنید. تمامی قابلیت‌ها و فریم‌ورک غیرکاربردی را حذف نمایید و یا آن‌ها را نصب ننمایید.
• تعریف یک وظیفه به منظور بررسی و بروزرسانی پیکربندی‌های مطلوب برای تمامی یادداشت‌ها، بروزرسانی‌ها و patchها به عنوان بخشی از فرآیند patch management process (به بخش A06:2021-Vulnerable and Outdated Components مراجعه کنید). مجوزهای ذخیره‌سازی ابری را مرور نمایید.
• یک برنامه کاربردی با معماری بخش‌بندی شده، جداسازی موثر و امنی را میان componentها و tenantها با تقسیم‌بندی، کانتینرسازی و گروه‌بندی‌های امنیتی ابری (ASLها) ارائه می‌دهد.
• ارسال دستورالعمل‌های امنیتی به Clientها مانند headerهای امنیتی.
• داشتن یک فرآیند خودکارسازی شده برای تایید اثربخشی پیکربندی و تنظیمات در تمامی محیط‌ها (environments).

نمونه‌هایی از سناریو حمله

1. سرور برنامه‌کاربردی را فرض نمایید که در آن برنامه‌های کاربردی نمونه از سرور محصول حذف نشده است. این برنامه‌های نمونه نقض‌های امنیتی را بصورت پیشفرض دارند و نفوذگر از آن برای به خطر انداختن سرور بهره می‌گیرد. فرض نمایید که یکی از این برنامه‌ها کنسول ادمین است و یا در آن رمزهای عبور پیشفرض تغییر نکرده. در این صورت مهاجم با استفاده از رمزعبور پیشفرض قادر به داشتن حسابی با سطح دسترسی بالا خواهد بود.
2. در این مثال فرض نمایید directory listing در سرور غیرفعال نشده است. در این صورت نفوذگر به راحتی می‌تواند مسیر‌ها را لیست نماید و ممکن است کلاس‌های جاوا کمپایل شده را دانلود کند و با انجام دی-کمپایل به کد اصلی دسترسی یابد. در ادامه مهاجم با جستجو برای نقض امینتی در سورس برنامه، حمله خود را شروع می‌نماید.
3. برنامه کاربردی را فرض نمایید که در آن، کاربر قادر است خطاهایی را حاوی جزئیات کامل آن و یا همراه با Stacktrace دریافت نماید. در این حالت ممکن است اطلاعات حساسی مانند نسخه فریم‌ورک‌های درحال استفاده فاش شود.
4. یک ارائه دهنده خدمات ابری را فرض نمایید که در آن مجوزهای اشتراک گذاری پیشفرض توسط سایر هدرهای CSP یا همان Content Security Policy کاربران برای اینترنت قابل پذیرش باشد. این موضوع داده‌های حساس ذخیره شده در فضای ابری را برای نفوذگر قابل دسترس می‌نماید.

 

6. Vulnerable and Outdated Components – 2021

عوامل

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

بررسی اجمالی

این مورد در نظرسنجی عمومی OWASP Top 10 در جایگاه دوم قرار گرفت ولی همواره داده‌های کافی برای حضور در OWASP Top 10 را از طریق داده‌ها هم داشت. Componentهای آسیب پذیر همیشه جز مسائل شناخته شده بود که معمولا توسط آزمایش کنندگان مورد بررسی قرار می‌گیرد و تنها دسته‌ای از OWASP Top 10 می‌باشد که هیچ CVE ثبت شده‌ای در CWEهای موجود ندارد. به همین دلیل مشاهده می ‌شود که دو عامل Avg Weighted Impact و Avg Weighted Exploit با مقادیر پیشفرض خود یعنی 5.00 تنظیم شده‌اند. این مورد شامل CWE-1104: Use of Unmaintained Third-Party Components و دو CWE از سال‌های 2013 و 2017 می‌باشد.

تشریح

شما احتمالا در صورت‌های زیر آسیب پذیر خواهید بود:

• در صورتی که شما نسخه componentهای مورد استفاده خود را ندانید (چه componentهای سمت کاربر و چه componentهای سمت سرور). این شامل componentهایی که به صورت مستقیم یا غیر مستقیم در حال استفاده‌اند می‌شود هم است.
• در صورتی که نرم‌افزار آسیب پذیر باشد یا شرکت توسعه دهنده دیگر از آن پشتیبانی نکند و یا نسخه مورد استفاده بروز شده نباشد. این شامل سیستم عامل، سرور برنامه کاربردی وب، سیستم مدیریت پایگاه داده (DBMS)، برنامه‌های کاربردی، APIها و تمامی componentها، کتابخانه‌ها و RTE یا همان runtime environmentها می‌شود.
• در صورتی که شما به صورت منظم برنامه خود را برای آسیب پذیری اسکن نمی‌نمایید و یا bulletinهای امنیتی را مطابق با componentهای مورد نیاز دنبال ننمایید.
• در صورتی که شما پلتفرم، فریم‌ورک‌ها، وابستگی‌ (dependencie)های زیربنایی را به موقع و به صورت risk-based تعمیر ننمایید یا ارتقاع ندهید. این موضوع معمولا در محیط‌هایی رخ می‌دهد که عمل patching به صورت ماهانه یا فصلی انجام می‌شود و سازمان‌ها، خود را برای دیرکرد در انجام این عمل آزاد می‌گذارند.
• در صورتی که توسعه دهندگان سازگاری بروزرسانی‌ها، ارتقاع‌ها یا patch ها را آزمایش نکنند.
• در صورتی که شما پیکربندی Componentهای خود را امن سازی ننمایید.

راهکارهای پیشگیری

باید فرآیندی به منظور مدیریت patch وجود داشته باشد تا:

• Dependencyهایی که مورد استفاده قرار نمی‌گیرد، قابلیت‌ها، فایل‌ها، مستندات و componentهای غیرضروری را حذف نمایید.
• به صورت مداوم نسخه componentهای مورد استفاده در سمت سرور یا کلاینت را به کمک ابزارهایی مانند versions، OWASP Dependency Check، retire.js و … را بررسی و لیست نمایید. به طور منظم منابع معتبر مانند Common Vulnerability and Exposures و National Vulnerability Database را برای Componentهای مورد استفاده رصد نمایید. از SCA یا Software composition analysisها به منظور خودکارسازی فرایند استفاده نمایید. با دنبال کردن منابع مختلف به صورت هشداری ایمیلی از آسیب پذیری‌های Componentهای مورد استفاده بهره گیرید.
• Componentها را فقط از منابع رسمی و پیوند‌های امن دریافت نمایید. ترجیحا از بسته‌های دارای امضا استفاده کنید تا احتمال اضافه شدن Component آسیب پذیر به حداقل برسد ( به بخش A08:2021-Software and Data Integrity Failures مراجعه کنید.)
• کتابخانه‌ها و کامپوننت‌هایی که پشتیبانی نمی‌شوند و یا برای آن‌ها پچ‌های امنیتی ساخته نمی‌شود باید به صورت مداوم بررسی شوند. در صورتی که patching غیرقابل انجام است از پچ‌های مجازی به منظور بررسی، تشخیص و مقابله با آسیب پذیری‌های کشف شده استفاده نمایید.

هر سازمان باید از یک برنامه مدوام به منظور نظارت، الویت‌بندی و اعمال بروزرسانی‌ها و یا انجام تغییرات پیکربند‌ی‌ها برای رسیدن به نگهداشت امن برنامه، داشته باشد.

نمونه‌هایی از سناریو حمله

1. کامپوننت‌ها معمولا با سطح دسترسی خود برنامه، اجرا می‌شوند بنابراین هرگونه نقض امنیتی در کامپوننت‌ها می‌توان منجر به تاثیرات جدی شود. چنین نقض‌هایی می‌تواند تصادفی (مانند خطاهای کد) یا عمدی (مانند یک Back-Door در کامپوننت) باشد. برخی از کامپوننت‌های آسیب پذیر کشف شده عبارت‌اند از:

• CVE-2017-5638 یک آسیب پذیری remote code execution در Struts 2 می‌باشد که به نفوذگر اجازه می‌دهد کد‌های دلخواه خود را در سرور اجرا نماید.
• درحالی که patching در اینترنت چیزها (IoT) اغلب دشوار یا غیرممکن است، همواره اهمیت patching درآن بسیار زیاد است (مانند دستگاه‌های زیست پزشکی)

ابزار‌های خودکاری وجود دارند که به نفوذگر اجازه می‌دهد تا سیستم‌های پچ نشده و یا سیستم‌هایی که بدرستی پیکربندی نشده‌اند را یافت نماید.

 

7. Identification and Authentication Failures – 2021

عوامل

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

بررسی اجمالی

این دسته که پیش‌تر با نام Broken Authentication شناخته می‌شد از جایگاه سوم سقوط کرد. این مورد در OWASP Top 10 2021 شامل CWEهای مربوط به identification failures هم می‌باشد. برخی CWEهای که این دسته را شامل می‌شوند عبارت‌اند از CWE-297: Improper Validation of Certificate with Host Mismatch، CWE-287: Improper Authentication و CWE-384: Session Fixation

تشریح

تایید و احراز هویت و همچنین مدیریت نشست‌ها یک عمل حیاتی برای مقابله در برابر حملات مربوط به احراز هویت می‌باشد. شما احتمالا به حملات احراز هویت آسیب پذیر خواهید بود در صورتی که:

• به حملاتی مانند credential stuffing که در آن مهاجم قادر به تولید لیستی از نام‌های کاربردی و رمزهای عبور هست، اجازه پیاده‌سازی دهید.
• به حملاتی مانند brute force و یا سایر حملات خودکار اجازه پیاده‌سازی دهید.
• به کاربر اجازه استفاده از رمز‌های عبور پیشفرض، ضعیف و یا شناخته شده بدهید. مانند “Password1” یا “admin/admin”
• از فرایند‌های بازیابی یا فراموشی رمزعبور ضعیف یا ناکارآمد بهره گیرید. مانند پاسخ‌های مبتنی بر آگاهی قبلی که استفاده از آن‌ها ایمن نیست.
• رمز‌های عبور را بصورت Clear-text و یا با استفاده از رمزنگاری‌هایی ضعیف ذخیره نمایید (به بخش A02:2021-Cryptographic Failures مراجعه نمایید.).
• از احراز هویت به صورت چند مرحله‌ای (چند عاملی) استفاده نشود یا بطور بی‌اثر پیاده‌سازی شود.
• شناسه نشست در URL استفاده شود.
• از شناسه نشست پیش از ورود به صورت مجدد پس از ورود استفاده می‌شود.
• شناسه نشست بصورت صحیح ابطال نمی‌شود. نشست و یا توکن احراز هویت (عمدتا توکن‌های SSO) کاربر زمان خروج یا پس از گذشتن زمانی معین غیرمعتبر نمی‌شود.

راهکارهای پیشگیری

• در صورت امکان از احرازهویت چند عاملی به منظور جلوگیری از حملات خودکار credential stuffing، brute force و stolen credential reuse بهره گرفته شود.
• هیچ اعتبارنامه پیشفرضی نباید برای حساب‌ها خصوصا حساب ادمین وجود داشته باشد.
• بررسی برای رمزهای عبور ضعیف باید پیاده‌سازی شود. مانند بررسی و مقایسه رمزعبور انتخابی با 10000 رمزعبور ضعیف برتر.
• سیاست‌های طول، پیچیدگی و چرخشی بودن رمزعبور را با دستورالعمل‌های بخش 5.1.1 در National Institute of Standards and Technology (NIST) 800-63 هماهنگ نمایید. این استاندارد به منظور نگهداشت اسرار و همچنین پیاده‌سازی سیاست‌های رمزعبور مبتنی بر شواهد طراحی شده است.
• اطمینان حاصل نمایید که فرایند‌های ثبت نام، بازیابی اطلاعات و مسیر‌های APIها توسط ارسال خطاهایی منسجم و مبهم در برابر حملات account enumeration ایمن هستند.
• تلاش‌های متعدد برای ورود به برنامه را محدود نمایید یا با استفاده از فرایند‌هایی میان آن‌ها تاخیری در نظر بگیرید. همچنین مراقب باشید که با این کار، سناریو‌‌های پیاده‌سازی حملات Dos ایجاد نشود. تمامی شکست‌ها را ثبت نمایید و اطمینان حاصل نمایید که مدیرکل سایت، زمان تشخیص credential stuffing، brute force و سایر حمله‌ها مطلع خواهد شد.
• از یک سیستم مدیریت نشت سمت سرور، ایمن و داخلی بهره گیرید که در آن پس از ورود کاربر، شناسه نشستی جدید با درصد تصادفی بودن بالا تولید شود. شناسه نباید در URL استفاده شود، باید به صورت امن ذخیره شود و پس از خروج کاربر یا گذشت زمانی مشخص پس از عدم استفاده از شناسه، نامعتبر باشد.

نمونه‌هایی از سناریو حمله

1. Credential stuffing همان استفاده از لیستی از رمزهای عبور شناخته شده، حمله ای رایج است. فرض نمایید که یک برنامه کاربردی هیچ سیاستی در برابر چنین حملاتی پیاده‌سازی نکرده است. در این صورت نفوذگر می‌تواند اعتبارنامه‌های معتبر را جمع‌آوری نماید.
2. اکثر حملات مربوط به احراز هویت به دلیل استفاده از رمزعبور به عنوان عامل واحد در فرایند احراز هویت رخ می‌دهد. زمانی که سیستمی از احراز هویت تک عاملی بهره می‌گیرد کاربر را به نوعی تشویق به استفاده از رمزهای عبور ضعیف می‌نماید. براساس NIST 800-63 توصیه می‌شود که از این کار خودداری شود و احراز هویت چند عاملی مد نظر قرار گرفته شود.
3. برنامه‌ای را فرض نمایید که در آن زمان انقضا نشست به درستی تنظیم نشده است. در صورتی که یک کاربر با استفاده از یک سیستم عمومی (مانند کامپیوتر‌های کافی‌نت‌ها) به برنامه کاربردی ورود نماید و در صورتی که بجای استفاده از فرآیند خروج به بستن صفحه مرورگر اکتفا نماید، نفوذگر به آسانی قادر خواهد بود با استفاده از همان سیستم و همان مرورگر در ساعاتی بعد از حساب کاربر استفاده نماید.

 

8. Software and Data Integrity Failures – 2021

عوامل

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

بررسی اجمالی

این مورد یک دسته‌بندی جدید در سال 2021 می‌باشد و تمرکز آن بر بررسی احتمالات مربوط به بروزرسانی‌ نرم‌افزار‌ها، داده‌های حیاتی، CI/CD بدون تصدیق یکپارچگی می‌باشد. این مورد در داده‌های CVE و CVSSها از weighted impact بالایی برخوردار است. Software and Data Integrity Failures شامل CWEهای CWE-829: Inclusion of Functionality from Untrusted Control Sphere، CWE-494: Download of Code Without Integrity Check و CWE-502: Deserialization of Untrusted Data می‌باشد.

تشریح

حملات و زیر‌مجموعه‌های این دسته مرتبط با نقض‌های محافظت از یکپارچگی داده‌ در کد یا زیرساخت برنامه می‌باشد. نمونه‌ای از مورد را می‌توان برنامه‌ای فرض نمود که در آن به پلاگین، کتابخانه، ماژول‌هایی از منابع غیرقابل اعتماد، repositorie، CDNها اتکا می‌شود. یک فرایند CI/CD ناامن می‌تواند احتمال دسترسی‌های غیر مجاز، تزریق کد مخرب و به خطر اندازی سیستم را ایجاد کند.
بسیاری از برنامه‌ها در حال حاضر دارای قابلیت بروزرسانی خودکار هستند. معمولا در این نوع برنامه‌ها، بروزرسانی بدون تایید برای یکپارچگی با باقی منابع انجام می‌شود. مهاجم ممکن است بروزرسانی خود را توزیع نماید و تمامی برنامه‌ها با قابلیت بروزرسانی خودکار نسخه جدید را دریافت خواهند کرد. مثالی دیگر زمانی است که شی‌ها و داده‌ها در ساختاری Encode یا serializiation می‌شوند که توسط نفوذگر قابل مشاهده و تغییر باشد.

راهکارهای پیشگیری

• از امضاهای دیجیتال یا مکانیزم‌های مشابه آن برای تایید منبع برنامه‌های مورد استفاده، بهره گیرید.
• اطمینان حاصل نمایید که dependencyها و کتابخانه‌هایی مانند npm یا Maven از مخازن قابل اعتمادی استفاده می‌کنند. در صورتی که Risk Profile بالاتری دارید، یک مخزن داخلی تایید شده گزینه قابل قبولی خواهد بود.
• اطمینان حاصل نمایید که از ابزاری مانند OWASP Dependency Check or OWASP CycloneDX برای تایید عدم وجود آسیب‌پذیری‌های شناخته شده در componentهای مورد استفاده بهره می‌گیرید.
• اطمینان حاصل نمایید که فرایندی برای بررسی کد و تغییرات پیکربندی وجود دارد که احتمال وارد شدن کد یا تنظیمات مخرب را به محصول به حداقل رساند.
• اطمینان حاصل نمایید که CI/CD شما دارای تفکیک‌بندی، پیکربندی و کنترل دسترسی مناسب است تا از یکپارچگی کدهای که در فرایند ساخت و استقرار هستند اطمینان حاصل کنید.
• اطمینان حاصل نمایید که داده‌های سریالی بدون امضا یا رمزنگاری و همچنین بدون امضای دیجیتال و بررسی برای یکپارچگی به دست مشتریان غیرقابل اعتماد سپرده نمی‌شود تا اطمینان حاصل نماید که داده‌های سریالی دستکاری یا استفاده مجدد نمی‌شوند.

نمونه‌هایی از سناریو حمله

1. بروزرسانی بدون امضا: بسیاری از روتر‌های خانگی، دستگاه‌های گیرنده تلوزیونی، میان افزارها و … بروزرسانی را از طریق میان افزار امضا شده تایید نمی‌کنند. میان‌افزار بدون امضا یک هدف رو به رشد برای مهاجمان است و همواره نگرانی‌ها در مورد آن بیشتر می‌شود زیرا در بسیاری از مواقع هیچ مکانیزمی برای اصلاح این موضوع وجود ندارد. مگر اینکه اصلاح در نسخ بعدی صورت بگیرد.
2. بروزرسانی تخریب‌گر در SolarWinds: دولت‌ها معمولا به ضعف در مکانیزم‌های بروزرسانی معروف هستند که یکی از قابل ملاحضه‌ترین حملات اخیر، حمله به SolarWinds است. شرکت توسعه دهنده این نرم‌افزار فرایندهای یکپارچگی و بروزرسانی را تضمین می‌نماید. با این حال، شرکت SolarWinds با یک بروزرسانی مخرب، که به بیش از 18000 سازمان اعمال شد، باعث تحت تاثیر قرار گرفتن بیشتر از 100 سازمان، توسط این توزیع مخرب شد.
3. Dserialization به صورت ناامن: یک برنامه React را فرض نمایید که مجموعه‌‌ای از میکروسرویس‌های Spring Boot (یکی از فریم‌ورک‌های زبان برنامه‌نویسی جاوا) را فراخوانی می‌نماید. توسعه دهندگان این برنامه سعی نموده‌اند اطمینان حاصل نمایند که کد آن‌ها غیرقابل تغییر است. راه حلی که آنان پیاده‌سازی کرده‌اند سریالی کردن user state (وضعیت کاربر) و انتقال آن با هر درخواست بود. یک نفوذگر، می‌تواند با کشف استفاده از امضای شی “r00” (در جاوا) در قالب base64 و استفاده از ابزار Serial killer به منظور اجرای کد از راه دور، بهره گیرد.

9. Security Logging and Monitoring Failure – 2021

عوامل

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

 بررسی اجمالی

Security Logging and Monitoring Failure (شکست در واقع‌نگاری و نظارت امنیتی) یکی از مواردی که از نظرسنجی مربوط به OWASP Top 10 به این لیست افزوده شد و جایگاه نهم را به خود اختصاص داد. آزمایش برای واقع‌نگاری و نظارت می‌تواند چالش برانگیز باشد و اغلب به صورت پرسش در مورد تشخیص و عدم تشخیص حملات در طول فرایند تست نفود می‌باشد. CVE یا CVSS هایی زیادی برای این دسته وجود ندارد ولی تشخیص و پاسخ به این نقض امنیتی موضوعی حیاتی است. باید دانست که توجه به این دسته در accountability، visibility، هشدار در حوادث و بحث جرم‌یابی موثر خواهد بود. حال این دسته بیشتر از CWE-778 Insufficient Logging پیش می‌رود و شامل CWE-117 Improper Output Neutralization for Logs، CWE-223 Omission of Security-relevant Information و CWE-532 Insertion of Sensitive Information into Log File می‌شود.

تشریح

براساس OWASP Top 10 2021، این دسته به منظور کمک به شناسایی، تعدیل و پاسخگویی به نقص‌های فعال برنامه اهمیت دارد. بدون واقع‌نگاری و مانتیورینگ، نقض‌ها قابل شناسایی نیستند. واقع‌نگاری، شناسایی، مانیتورینگ، active response زمانی نامناسب و ناکارآمد می‌باشد که:

• رویدادهای قابل حسابرسی مانند ورود کاربر، شکست در ورود و تراکنش‌هایی با ارزش‌های بالا در جایی ثبت نمی‌شوند.
• اخطارها و خطاها به صورت نامناسب یا نامفهوم ثبت می‌شوند.
• عدم نظارت بر وقایع ثبت شده برنامه‌کاربردی و APIها برای رصد فعالیت‌های مشکوک.
• ذخیره وقایع صرفا به صورت محلی
• Thresholds alerting مناسب و پروسه‌های response escalation در جای مناسب قرار ندارند و یا کارآمد نیستند.
• تست نفوذ و پویش برنامه کاربردی توسط ابزارهای DAST مانند OWASP ZAP برنامه را تحریک به ثبت وقایع نمی‌نمایند.
• برنامه کاربردی نمی‌تواند حملات فعال یا نزدیک به وقوع را تشخیص، تعدیل یا هشدار دهد.

همچنین باید بدانید که اگر کابر یا نفوذگری به وقایع و هشدارهای ثبت شده دسترسی یابد شما همواره آسیب پذیر هستید (بخش A01:2021-Broken Access Control را مطالعه فرمایید.)

راهکارهای پیشگیری

توسعه دهنگان باید همه و یا برخی از موارد زیر را بسته به احتمال در خطر بودن برنامه کاربردی، اجرا نمایند:

• اطمینان حاصل نمایید که تمام شکست‌ها در ورود، کنترل‌های سطوح دسترسی و اعتبارسنجی‌های سمت سرور طوری ثبت شود که اطلاعات کافی برای شناسایی کاربر و حساب‌های مخرب وجود داشته باشد و همچنین این اطلاعات باید به مدت کافی نگهداری شوند تا در صورت نیاز تیم‌هایی مانند تیم جرم‌یابی به آن دسترسی داشته باشد.
• اطمینان حاصل نمایید که وقایع در قالبی ثبت می‌شوند که راه‌حل‌های مدیریت لاگ (log management) به راحتی قابل استفاده باشند.
• اطمینان حاصل نمایید که داده‌های لاگ به درستی کدگذاری می‌شوند تا از حملات تزریق و یا حملات مربوط به سیستم‌های ثبت وقایع و نظارت جلوگیری نمایید.
• اطمینان حاصل نمایید که تراکنش‌هایی که دارای ارزش بالایی هستند دارای یک audit trail (به منظور مشخص کردن دقیق اعمال انجام شده) با کنترل‌های یکپارچگی به منظور جلوگیری از دستکاری یا حذف هستند. مانند جداول append-only در پایگاه‌های داده و یا چیزی مشابه آن.
• تیم‌های DevSecOps باید سیستم‌های monitoring و هشداردهی موثری را فراهم آورند که فعالیت‌های مشکوک را تشخیص و به آن‌ها پاسخی سریع دهد.
• یک نقشه برای incident response و بازیابی اطلاعات فراهم آورید. به عنوان مثال National Institute of Standards and Technology (NIST) 800-61r2 یا استاندارد‌های جدید تر

شما می‌توانید به راحتی از فریم‌ورک‌های حفاظت از برنامه‌های کاربردی تجاری که به صورت منبع‌باز قابل دسترس است (مانند OWASP ModSecurity Core Rule Set) و نرم افزارهای log correlation منبع‌باز ( مانند the Elasticsearch، Logstash، Kibana (ELK) stack که دارای داشبورد‌ها و هشدار‌های سفارشی هستند) استفاده نمایید.

نمونه‌هایی از سناریو حمله

1. یک اپراتور وب‌سایت ارائه‌دهنده طرح سلامت کودکان را فرض نمایید که به دلیل عدم ثبت و نظارت بر وقایع نتوانست نقصی را تشخیص دهد. یک بخش خارجی به ارائه‌دهنده برنامه‌های سلامتی اطلاع داد که یک نفوذگر به رکورد‌های حساس سلامت بیش از 3.5 میلیون کودک دسترسی پیدا کرده و آن‌ها را تغییر داده. در ادامه یک بررسی post-incident (پس از حادثه) نشان داد که توسعه‌دهندگان این وب سایت آسیب پذیر‌ی‌های مهمی را رفع نکرده بودند و از آنجایی که هیچ سیستم واقع‌نگار و نظارتی وجود نداشت نتیجه گرفته شد که این نقص می‌تواند در هر سالی، از سال 2013 تا به کنون به وجود آمده باشد.
2. شرکت هواپیمایی هندی بزرگی دارای نقص داده در خود است که در آن داده‌های شخصی میلیون‌ها کابر از جمله اطلاعات پاسپورت و کارت اعتباری طی بیش از 10 سال جمع‌‌آوری شده است. نقض داده در ارائه‌دهنده میزبانی فضای ابری شخص ثالث رخ داده است و شرکت هواپیمایی این موضوع را پس از مدتی از طریق این شرکت متوجه شد.
3. یک شرکت هواپیمایی اروپایی دارای یک نقض قابل گزارش GDPR می‌باشد و گزارش‌ها حاکی از آن است که این رخته به دلیل آسیب پذیری برنامه کاربردی مربوط به پرداخت وجود دارد و توسط مهاجمان مورد سوء استفاده قرار می‌گیرد و نفوذگران توسط این موضوع بیش از 400 هزار رکورد پرداخت توسط مشتری را جمع‌آوری کرده‌اند. در نتیجه این رخنه، شرکت توسط مقررکننده سیاست‌های حافظت از داده اروپا با پرداخت 20 میلیون پوند جریمه شد.

10. Server-Side Request Forgery (SSRF) – 2021

عوامل

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

بررسی اجمالی

از دسته از نظرسنجی جامع OWASP Top 10 به این لیست افزوده شده است. با وجود Testing coverage، average Exploit و average Impact بالاتر داده‌ها نرخ بروز نسبتا پایینی را دارا است. این دسته مجموعه کوچک و منفردی از CWE ها است و بهتر خواهد بود اگر به همین تعداد کم توجه ویژه‌ای شود. احتمالا در نسخه بعدی OWASP Top 10 این مورد در دسته‌ای بزرگ‌تر جای خواهد گرفت.

تشریح

نقص‌های SSRF زمانی رخ می‌دهد که یک برنامه کابردی در حال واکشی کرد داده از یک منبع خارجی باشد و هیچ اعتبارسنجی روی URL ارائه شده توسط کاربر وجود نداشته باشد. این موضوع به نفوذگر اجازه ارسال درخواست‌های دستکاری شده از سوی برنامه کاربردی به مقصدی غیرمنتظره می‌دهد، حتی زمانی که برنامه توسط یک فایروال، VPN و یا نوع دیگری از ACLها محافظت می‌شود.

از آنجایی که برنامه‌های کاربردی وب که به صورت مدرن پیاده‌سازی می‌شودند، ویژگی‌های مناسبی را در اختیار کاربر قرار می‌دهند، واکشی از یک URL خارجی یه یک عمل رایج تبدیل شده است و در نتیجه آن بروز حمله SSRF در حال افزایش است؛ و همچنین بدلیل استفاده از سرویس‌های ابری و پیچیدگی در معماری وب سایت‌های مدرن شدت و تخریب SSRFها بیشتر شده است.

راهکارهای پیشگیری

توسعه‌دهنگان می‌توانند با اجرای برخی و یا همه‌ی موارد زیر از SSRF جلوگیری نمایند.

راهکارها در لایه شبکه:

• تقسیم‌بندی جداگانه دسترسی به عملکرد منابع راه‌دور به منظور کاهش تاثیر SSRF
• سیاست‌های فایروال و قوانین کنترل سطوح دسترسی در شبکه را به صورت deny by default قرار دهید تا همه ترافیک‌های اینترنت به جز ترافیک‌های ضروری مسدود شوند.

راهکارها در لایه برنامه کاربردی:

• تمام داده‌های ارائه شده توسط کاربر را اعتبارسنجی و Sanitize نمایید.
• از طرح URL یا همان URL schema، پورت و مقصد با استفاده از یک لیست سفید بهره گیرید.
• پاسخ خام را برای مشتری (client) ارسال ننمایید.
• HTTP redirections را غیرفعال نمایید.
• برای جلوگیری از حملاتی مانند DNS rebinding و Time-of-check Time-of-use (TOCTOU) Race Condition از سازگاری URL یا URL consistency آگاه باشید.

باید دانست که کاهش SSRF با ایجاد یک لیست سیاه یا regular expression امکان پذیر نیست. نفوذگران با استفاده از لیست‌های payload، ابزارها و مهارت‌هایی که دارند این موارد را دور می‌زنند.

اقدامات اضافی:

سایر خدمات مرتبط با امنیت را در سیستم‌های Front (مانند OpenID) مستقر ننمایید. و فقط ترافیک‌های محلی باید در این سیستم‌ها کنترل شوند.

برای فرانت‌اند‌هایی با گروه کاربری اختصاصی و قابلیت‌های مدیریت، از رمزگذاری‌های درون شبکه (مانند VPN) به منظور برطرف سازی نیاز‌های حفاظتی بسیار بالا بهره گیرید.

نمونه‌هایی از سناریو حمله

نفوذگران قادرند با استفاده از SSRF به سیستم‌های حفاظت شده در پشت WAFها، فایروال‌ها و ACL‌های شبکه حمله نمایند. سناریو‌هایی از آن را در زیر مشاهده می‌نمایید:

1. اسکن پورت‌ سرور‌های داخلی: در صورتی که معماری شبکه بدون segmentation پیاده‌سازی شده باشد، مهاجمان می‌توانند معماری شبکات داخلی را ترسیم نمایند و از طریق نتایج اتصال، زمان سپری شده برای اتصال و یا payloadهای رد شده، باز یا بسته بودن یک پورت را حدس بزنند.
2. افشا اطلاعات حساس: نفوذگر می‌تواند به فایل‌های محلی مانند file:///etc/passwd و سرویس‌های که اطلاعات حساس فاش می‌کند مانند http://localhost:28017 دسترسی داشته باشد.
3. دسترسی به metadata فضای ذخیره‌سازی سرویس‌های ابری: اکثر ارائه‌دهندگان خدمات ابری دارای metadata storage مانند http://169.254.169.254/ هستند و یک نفوذگر می‌تواند از این موضوع برای دستیابی به اطلاعات حساس بهره پیرد.
4. به خطر انداختن سرویس‌های داخلی: نفوذگر می‌تواند از خدمات داخلی ارائه شده به منظور انجام حملات بیشتر مانند اجرای کد از راه دور RCE یا DoS