diff --git a/2019/fa/dist/owasp-api-security-top-10.odt b/2019/fa/dist/owasp-api-security-top-10.odt new file mode 100644 index 000000000..b73bac676 Binary files /dev/null and b/2019/fa/dist/owasp-api-security-top-10.odt differ diff --git a/2019/fa/dist/owasp-api-security-top-10.pdf b/2019/fa/dist/owasp-api-security-top-10.pdf new file mode 100644 index 000000000..7b07afc5b Binary files /dev/null and b/2019/fa/dist/owasp-api-security-top-10.pdf differ diff --git a/2019/fa/src/0x00-header.md b/2019/fa/src/0x00-header.md new file mode 100644 index 000000000..2b9950db7 --- /dev/null +++ b/2019/fa/src/0x00-header.md @@ -0,0 +1,24 @@ +
+ +![OWASP LOGO](images/owasp-logo.png) + + +## OWASP API Security Top 10 2019 + +10 ریسک بحرانی امنیت API از منظر OWASP - 2019 + +29 می 2019 + +![WASP Logo URL TBA](images/front-wasp.png) + +
+ + + +| | | | +| - | - | - | +| https://owasp.org |
این اثر تحت مجوز زیر توسعه داده شده است:
 [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: https://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/2019/fa/src/0x00-notice.md b/2019/fa/src/0x00-notice.md new file mode 100644 index 000000000..b0cb79024 --- /dev/null +++ b/2019/fa/src/0x00-notice.md @@ -0,0 +1,16 @@ +
+ +اطلاعیه +====== + +این نسخه متنی OWASP API Security Top 10 است. به عنوان مرجع برای نسخه رسمی منتشر شده، در قالب یک سند قابل حمل (PDF) استفاده می شود. + +مشارکت در پروژه مانند نظرات، اصلاحات یا ترجمه ها باید در اینجا انجام شود. برای جزئیات بیشتر در مورد نحوه مشارکت، لطفاً به CONTRIBUTING.md مراجعه فرمایید. + +
+ +* Erez Yallon +* Inon Shkedy + + + diff --git a/2019/fa/src/0x00-toc.md b/2019/fa/src/0x00-toc.md new file mode 100644 index 000000000..3d46653ba --- /dev/null +++ b/2019/fa/src/0x00-toc.md @@ -0,0 +1,29 @@ +
+ +فهرست مطالب +========================== + +* [ فهرست مطالب](0x00-toc.md) +* [درباره OWASP](0x01-about-owasp.md) +* [ پیش‌گفتار](0x02-foreword.md) +* [ مقدمه](0x03-introduction.md) +* [ یادداشت](0x04-release-notes.md) +* [ ریسک‌های امنیت API](0x10-api-security-risks.md) +* [ ده ریسک امنیت API OWASP 2019](0x11-t10.md) +* [API1:2019 مجوزدهی نادرست در سطح اشیا](0xa1-broken-object-level-authorization.md) +* [API2:2019 احرازهویت نادرست کاربر](0xa2-broken-user-autentication.md) +* [API3:2019 افشای مفرط داده](0xa3-excessive-data-exposure.md) +* [API4:2019 کمبود منابع و نبود محدودیت بر نرخ ارسال](0xa4-lack-of-resources-and-rate-limiting.md) +* [API5:2019 مجوزدهی نادرست در سطح توابع](0xa5-broken-function-level-authorizaion.md) +* [API6:2019 تخصیص جمعی](0xa6-mass-assignment.md) +* [API7:2019 پیکربندی امنیتی نادرست](0xa7-security-misconfiguration.md) +* [API8:2019 تزریق ورودی‌های مخرب](0xa8-injections.md) +* [API9:2019 مدیریت نادرست دارایی‌ها](0xa9-improper-asset-management.md) +* [API10:2019 پایش و نظارت ناکافی](0xaa-insufficient-monitoring.md) +* [ادامه برای توسعه دهندگان](0xb0-next-devs.md) +* [ ادامه برای DevSecOps](0xb1-next-devsecops.md) +* [ متدولوژی و داده](0xd0-about-data.md) +* [سپاسگزاری](0xd1-acknowledgments.md) + + +
diff --git a/2019/fa/src/0x01-about-owasp.md b/2019/fa/src/0x01-about-owasp.md new file mode 100644 index 000000000..9944f975b --- /dev/null +++ b/2019/fa/src/0x01-about-owasp.md @@ -0,0 +1,48 @@ +
+ +درباره OWASP +============ + +پروژه بازمتن امنیت وب اپلیکیشن‌ها (OWASP) جامعه ای باز و آزاد است که اختصاصا در حوزه توانمندسازی سازمان‌ها در حوزه توسعه، تهیه و ایجاد اپلیکیشن‌ها و APIهای قابل اعتماد فعالیت دارد. + + در OWASP، موارد زیر را بصورت رایگان و آزاد خواهید یافت: + +* استانداردها و ابزارهای امنیت اپلیکیشن. +* کتاب‌هایی درباره تست امنیت اپلیکیشن‌ها، توسعه ایمن کد و بازبینی امنیت کد. +* ارائه‌ها و [ویدئوها][1]. +* [راهنما و برگه تقلب][2] برای بسیاری از موضوعات رایج. +* کنترل‌ها و کتابخانه‌های استاندارد در حوزه امنیت. +* [شعب محلی در سرتاسر جهان.][3] +* تحقیقات به روز و پیشرو در حوزه امنیت. +* [کنفرانس‌های تخصصی][4] در سرتاسر جهان. +* [یست‌های پست الکترونیک][5] برای ارسال اخبار. + +اطلاعات بیشتر در: https://owasp.org + +تمامی ابزارها، مستندات، ویدئوها، ارائه‌ها و شعب OWASP رایگان بوده و استفاده از یا مشارکت در آنها برای کلیه افرادی که تمایل به بهبود امنیت اپلیکیشن‌ها دارند، آزاد است. + +در OWASP امنیت اپلیکیشن بعنوان مساله‌ای مهم از منظر افراد، فرایندها و فناوری‌ها در نظر گرفته می‌شود چرا که موثرترین رویکردها در امنیت اطلاعات نیز به بهبود در این حوزه‌ها نیاز دارند. + +OWASP تعریف جدیدی از سازمان ارائه می‌دهد. رهایی از بند فشار مسائل مالی امکان فراهم آوردن اطلاعات بیطرفانه، عملی و مقرون به صرفه در حوزه امنیت اپلیکیشن‌ها را به ما داده است. + +OWASP به هیچ کمپانی فناوری وابستگی ندارد اگرچه از استفاده آگاهانه از فناوری‌های تجاری در حوزه امنیت نیز حمایت می‌کنیم. OWASP انواع مختلفی از اطلاعات را به گونه‌ای همکارانه، شفاف و باز ارائه می‌دهد. + +بنیاد OWASP موجودیتی غیرانتفاعی و عام المنفعه است که توفیق بلند مدت پروژه OWASP را تضمین می‌نماید. تقریبا تمامی کسانی که با OWASP پیوند دارند، از قبیل اعضای هیئت مدیره، روسای شعبه‌ها، راهبران پروژه‌ها و اعضای پروژه‌ها داوطلبانه این همکاری را انجام می‌دهند. همچنین ما از تحقیقات نوآورانه در حوزه امنیت با ارائه کمک‌های مالی و زیرساختی حمایت می‌کنیم. + +به ما بپیوندید! + +## حق چاپ و مجوز + +![license](images/license.png) + +حق چاپ © 2003-2019 بنیاد OWASP. این اثر تحت مجوز [Creative Commons Attribution ShareAlike 4.0 International License][7] توسعه داده شده است. برای هرگونه استفاده مجدد یا انتشار، باید شرایط مجوز این اثر را برای دیگران شفاف نمایید. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://owasp.org/index.php/OWASP_Cheat_Sheet_Series +[3]: https://owasp.org/index.php/OWASP_Chapter +[4]: https://owasp.org/index.php/Category:OWASP_AppSec_Conference +[5]: https://lists.owasp.org/mailman/listinfo +[6]: https://www.owasp.org +[7]: http://creativecommons.org/licenses/by-sa/4.0/ + +
diff --git a/2019/fa/src/0x02-foreword.md b/2019/fa/src/0x02-foreword.md new file mode 100644 index 000000000..8e9bfd695 --- /dev/null +++ b/2019/fa/src/0x02-foreword.md @@ -0,0 +1,39 @@ +
+ +پیش‌گفتار +======== + +در دنیای مبتنی بر App امروز، یکی از ابعاد بنیادین نوآوری واسط برنامه نویسی اپلیکیشن یا همان APIها هستند. از بانک‌‌ها گرفته تا خرده فروشی‌‌ها، حوزه حمل نقل، اینترنت اشیا، وسائل نقلیه خودران و شهرهای هوشمند، APIها بخشی حیاتی از اپلیکیشن‌‌های موبایل، وب و SaaS به شمار می‌آیند. + +ذاتا APIها منطق اپلیکیشن و داده‌‌های حساسی PII (از قبیل داده‌‌هایی که به تنهایی و بدون نیاز به داده اضافی دیگر، هویت یک کاربر را عیان می کنند نظیر شماره ملی) را در معرض دید قرارداده و در نتیجه، به طور روزافزون توجه بخش بیشتری از مهاجمین را به خود جلب می‌نمایند. بدون داشتن APIهایی ایمن، توسعه سریع نوآوری‌‌های فناورانه، امکان پذیر نخواهد بود. + +اگر چه کماکان می‌توان از لیست ده آسیب‌پذیری امنیتی بحرانی وب اپلیکیشن‌‌ها نیز برای امنیت APIها بهره برد، اما با توجه به ماهیت خاص APIها نیاز به لیستی از تهدیدات امنیتی مختص آنها احساس می‌شود. مقوله امنیت API بر راهکارها و استراتژی‌‌های لازم برای فهم و رفع آسیب‌پذیری‌‌ها و تهدیدات امنیتی خاص و منحصر به APIها تمرکز دارد. + +اگر با [پروژه OWASP Top 10][1] آشنایی داشته باشید، شباهت‌‌هایی بین آن و مستند پیش رو خواهید یافت: هر دو با نیت فهم آسان توسط مخاطب و قابلیت بکارگیری و انطباق در سازمان تهیه شده‌اند. در صورتی که با مجموعه‌‌های OWASP Top 10 آشنایی ندارید، بهتر است پیش از رفتن به سراغ لیست اصلی، بخش‌‌های [ریسک‌‌های امنیتی API][2] و [متدلوژی و داده][3] از همین مستند را مطالعه نمایید. + +با پرسش‌‌ها، نظرات و ایده‌‌های خود در GitHub پروژه می توانید در توسعه OWASP API Security Top 10 مشارکت کنید: + +
+ +* https://github.com/OWASP/API-Security/issues +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +
+ +در اینجا می توانید OWASP API Security Top 10 را بیابید: + +
+ +* https://www.owasp.org/index.php/OWASP_API_Security_Project +* https://github.com/OWASP/API-Security + +
+ +بدین وسیله از تمامی مشارکت کنندگان در این پروژه که با تلاش‌‌های خود در بوجود آمدن آن نقش داشته اند سپاسگزاریم. لیست تمامی آنها در [قسمت سپاسگزاری‌‌ها][4] قابل مشاهده است. متشکریم! + +[1]: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md + +
\ No newline at end of file diff --git a/2019/fa/src/0x03-introduction.md b/2019/fa/src/0x03-introduction.md new file mode 100644 index 000000000..66724cb38 --- /dev/null +++ b/2019/fa/src/0x03-introduction.md @@ -0,0 +1,21 @@ +
+ +مقدمه +============ + +## به OWASP API Security Top 10 – 2019 خوش آمدید! + +به اولین ویراست ده ‌‌آسیب‌پذیری برتر امنیت API خوش آمدید. اگر با پروژه OWASP Top 10 آشنایی داشته باشید، شباهت‌هایی بین آن و مستند پیش رو خواهید یافت: هر دو با نیت فهم آسان توسط مخاطب و قابلیت بکارگیری و انطباق در سازمان تهیه شده‌اند. در غیر این صورت، پیش از مطالعه عمیق‌تر ریسک‌‌های بحرانی امنیت API بهتر است [صفحه ویکی پروژه امنیت API][1] را مطالعه نمایید. + +در معماری اپلیکیشن‌‌های مدرن امروزی API نقش خیلی مهمی دارد. از آنجا که آگاهی بخشی امنیتی و نوآوری در این حوزه گام‌‌های مختلفی دارد، تمرکز بر نقاط ضعف رایج APIها اهمیت زیادی خواهد داشت. + +هدف اصلی مستند و پروژه ده ‌‌آسیب‌پذیری بحرانی امنیت API آموزش افراد دخیل در توسعه و نگهداری APIها از قبیل توسعه دهندگان، طراحان، معماران، مدیران و سازمان‌‌ها است. + +در بخش [متدلوژی و داده][2]، اطلاعات بیشتری درباره نحوه ایجاد اولین نسخه از مستند حاضر خواهید یافت. در نسخه‌‌های آتی، جامعه امنیت را نیز دخیل نموده و به منظور دریافت داده‌‌های مرتبط، فراخوان عمومی خواهیم داد. در حال حاضر همگان را به مشارکت در [مخزن Github][3] یا [لیست پست الکترونیک][4] ما از طریق ارسال سوال، نظر و پیشنهاد تشویق می‌کنیم. + +[1]: https://www.owasp.org/index.php/OWASP_API_Security_Project +[2]: ./0xd0-about-data.md +[3]: https://github.com/OWASP/API-Security +[4]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project + +
\ No newline at end of file diff --git a/2019/fa/src/0x04-release-notes.md b/2019/fa/src/0x04-release-notes.md new file mode 100644 index 000000000..cddfb387e --- /dev/null +++ b/2019/fa/src/0x04-release-notes.md @@ -0,0 +1,20 @@ +
+ +یادداشت +======================= + +مستند پیش رو اولین ویراست ده ‌‌آسیب‌پذیری بحرانی امنیت API است و ما بنا برآن داریم که بصورت دوره‌ای، هر سه یا چهارسال یکبار، آن را بروزرسانی نماییم. + +بر خلاف نسخه حاضر، در نسخه‌های آتی برای دریافت داده‌های عمومی فراخوان داده و صنعت امنیت سایبری را نیز در تلاش خود سهیم خواهیم کرد. برای آشنایی بیشتر با نحوه آماده سازی این مستند می‌توانید به بخش [متدولوژی و داده][1] مراجعه نمایید. همچنین جزئیات ریسک‌های امنیتی مرتبط در بخش [ریسک‌‌‌های امنیتی API][2] قابل مطالعه هستند. + +فهم تغییرات اساسی در معماری اپلیکیشن‌ها در سالیان گذشته از اهمیت زیادی برخوردار است. امروره APIها نقشی کلیدی در معماری ریزسرویس‌ها ، اپلیکیشن‌های تک صفحه ای (SPA )، اپلیکیشن‌های موبایل، اینترنت اشیاء و ... دارند. + +پروژه ده آسیب‌پذیری بحرانی امنیت API تلاشی ضروری برای آگاهی بخشی در حوزه مسائل امنیتی APIهای مدرن به شمار می‌رود که بدون تلاش‌های داوطلبانه افراد متعدد، که در بخش [سپاسگزاری‌ها][3] از تمامی آنان نام برده شده، به سرانجام رساندن آن امکان پذیر نبود. متشکریم! + + + +[1]: ./0xd0-about-data.md +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md + +
diff --git a/2019/fa/src/0x10-api-security-risks.md b/2019/fa/src/0x10-api-security-risks.md new file mode 100644 index 000000000..bde06112e --- /dev/null +++ b/2019/fa/src/0x10-api-security-risks.md @@ -0,0 +1,51 @@ +
+ +ریسک‌‌‌های امنیتی API +================================ + +به منظور تحلیل ریسک، از [متدولوژی رتبه بندی ریسک OWASP][1] استفاده شده است. + +جدول زیر، واژگان مرتبط با رتبه ریسک را مختصرا نشان می‌دهد. + + + +| عوامل تهدید | قابلیت بهره برداری | میزان شیوع آسیب‌پذیری| قابلیت شناسایی آسیب‌پذیری | پیامد فنی | تاثیر بر کسب و کار | +|-------------|--------------------|---------------------|---------------------------|---------------|---------------------| +| خاص API | آسان: 3 | گسترده: 3 | آسان: 3 | شدید: 3 | خاص کسب و کار | +| خاص API | متوسط: 2 | متداول: 2 | متوسط: 2 | متوسط: 2 | خاص کسب و کار | +| خاص API | سخت: 1 | سخت: 1 | سخت: 1 | جزئی: 1 | خاص کسب و کار | + +**توجه:** در این رویکرد، نوع فناوری مورد استفاده و احتمال وقوع آسیب‌پذیری در رتبه ریسک تاثیر ندارند؛ بعبارت دیگر در این روش رتبه بندی ریسک، راهکار مورد استفاده برای پیاده سازی API ، با رویکردی مستقل از جزئیات فناوری به ارزیابی ریسک می‌پردازد. هرکدام از عوامل یاد شده می‌تواند در پیداکردن و سواستفاده از یک آسیب‌پذیری به مهاجم کمک بسزایی کند. این رتبه بندی تاثیر واقعی بر کسب و کارها را نشان نداده و این سازمان‌ها هستند که با توجه به نوع کسب و کار و فرهنگ سازمانی خود، در میزان پذیرش خطر امنیتی استفاده از اپلیکیشن‌ها و APIها تصمیم گیرنده هستند. هدف از مستند ده آسیب‌پذیری بحرانی امنیت API، تحلیل ریسک نیست. + +## مراجع + +
+ +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +
+ +### خارجی + +
+ +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: https://www.owasp.org/index.php/Threat_Risk_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 + + diff --git a/2019/fa/src/0x11-t10.md b/2019/fa/src/0x11-t10.md new file mode 100644 index 000000000..676d16ee7 --- /dev/null +++ b/2019/fa/src/0x11-t10.md @@ -0,0 +1,21 @@ +
+ +ده ‌‌‌آسیب‌پذیری بحرانی امنیت API از منظر OWASP – 2019 +=================================================== + + +| ریسک | توضیحات | +|--------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| API1:2019 مجوزدهی نادرست در سطح اشیا | APIها معمولا توابع مدیریت کننده شناسه‌های اشیا را در معرض دید قرار داده و سطح حمله گسترده ای را برای نقض کنترل دسترسی ایجاد می‌نمایند. کنترل‌های مجوزدهی در سطح اشیا بایستی در کلیه توابعی که با گرفتن ورودی از کاربر به منابع داده دسترسی دارند پیاده‌سازی شود. | +| API2:2019 احرازهویت نادرست کاربر | مکانیزم‌های احرازهویت غالبا به درستی پیاده‌سازی نشده و سبب دسترسی مهاجمین به توکن‌های احرازهویت و ربایش موقت یا دائمی هویت سایر کاربران با استفاده از نقایص این مکانیزم‌ها می شوند. نقض توانایی سیستم در شناسایی کلاینت یا کاربر، منجر به نقض امنیت API خواهد شد. | +| API3:2019 افشای مفرط داده | با بکارگیری سرویس‌‌های عمومی API، توسعه دهندگان عملا تمامی ویژگی‌‌های اشیا را بدون درنظر گرفتن حساسیت تک تک آنها و صرفا با تکیه بر فیلترینگ داده پیش از نمایش به کاربر، توسط کلاینت، در معرض دید عموم قرار می‌دهند. | +| API4:2019 کمبود منابع و نبود محدودیت نرخ در ارسال درخواست | معمولا APIها هیچ محدودیتی بر اندازه یا تعداد منابع درخواستی توسط کلاینت یا کاربر اعمال نمی‌نمایند. این موضوع نه تنها با تاثیرگذاری منفی بر عملکرد سرور API می‌تواند منجر به حمله رد سرویس (DoS) شود، بلکه در را برای نقض احرازهویت از طریق حملاتی نظیر Force Brute نیز باز می‌گذارد. | +| API5:2019 مجوزدهی نادرست در سطح توابع | مکانیزم‌‌های پیچیده کنترل دسترسی با سلسله مراتب، گروه‌‌ها و نقش‌‌های متفاوت و مرز نامشخص بین توابع عادی و مدیریتی سبب بروز نقایص مجوزدهی می‌شوند. با بهره برداری از این آسیب‌پذیری‌‌ها مهاجمین به منابع سایر کاربران و یا توابع مدیریتی دست خواهند یافت. | +| API6:2019 تخصیص جمعی | پیوند دادن داده ارائه شده توسط کلاینت (نظیر اشیا JSON) با مدل‌‌های داده بدون فیلترکردن مناسب آنها بر مبنای یک لیست سفید می‌تواند منجر به تخصیص جمعی شود. با تشخیص ویژگی‌‌های اشیا، کاوش سایر توابع، خواندن مستندات یا ارائه ویژگی‌‌های اضافی برای اشیا در بدنه درخواست‌‌ها، مهاجم می‌تواند ویژگی‌‌هایی از اشیا که برای وی مجاز نیست را دستکاری نماید. | +| API7:2019 پیکربندی امنیتی نادرست | پیکربندی امنیتی نادرست پیامدی از بکارگیری پیکربندی ناایمن پیشفرض، پیکربندی ناقص یا غیرمتمرکز، فضای ذخیره سازی ابری باز و محافظت نشده، سرایندهای HTTP با پیکربندی نادرست، متدهای غیرضروری HTTP، خط مشی‌‌های سهل انگارانه برای اشتراک گذاری منابع متقابل (CORS) و پیامهای خطای تفصیلی و مشروح می‌باشد. | +| API8:2019 ‌‌‌آسیب‌پذیری‌‌های تزریق | آسیب‌پذیری‌‌های مبتنی بر تزریق نظیر SQL، NoSQL، تزریق دستور و ... زمانی رخ می‌دهند که داده‌ی نامطمئن بعنوان بخشی از یک دستور یا پرس و جو به مفسر تحویل داده شود. این داده مخرب می‌تواند مفسر را وادار به اجرای دستوری ناخواسته یا دسترسی غیرمجاز به داده‌‌ها نماید. | +| API9:2019 مدیریت نادرست دارایی‌‌ها | APIها معمولا توابع بیشتری را نسبت به وب اپلیکیشن‌‌های سنتی در معرض دید قرار می‌دهند که این موضوع اهمیت مستندسازی مناسب و بروز را دوچندان می‌نماید. داشتن فهرستی از میزبان‌‌ها و نسخه‌‌های بکارگرفته شده API نقش مهمی در رفع ‌‌‌آسیب‌پذیری‌‌های مرتبط با نسخ قدیمی API و توابع مرتبط با debugging ایفا می‌کند. | +| API10:2019 پایش و نظارت ناکافی | پایش و نظارت ناکافی در کنار عدم وجود فرایند پاسخ دهی به وقایع یا پیاده‌سازی ناقص آن به مهاجم امکان تثبیت دسترسی، حمله به سایر سیستم‌‌ها و استخراج/نابودسازی داده‌‌ها را می‌دهد. مطالعات انجام شده بیانگر آن است که زمان آگاهی یافتن از نفوذ انجام شده به طور میانگین بیش از 200 روز پس از انجام نفوذ بوده و تشخیص آن نیز بجای آنکه توسط فرایندهای درونی پایش و نظارت باشد توسط شرکت‌‌های ثالث صورت می‌پذیرد. | + + +
diff --git a/2019/fa/src/0xa1-broken-object-level-authorization.md b/2019/fa/src/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..e49cfaf24 --- /dev/null +++ b/2019/fa/src/0xa1-broken-object-level-authorization.md @@ -0,0 +1,49 @@ +
+ +API1:2019 مجوزدهی نادرست در سطح اشیاء +=========================================== + +| عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**3** : قابلیت تشخیص**2** | پیامد فنی**3** : خاص کسب و کار | +| مهاجمین می‌توانند از نقاط و توابع ‌آسیب‌پذیر (از منظر مجوزدهی نادرست در سطح اشیا) با دستکاری شناسه شیء ارسالی درون درخواست سوءاستفاده و بهره برداری نمایند. این امر می‌تواند منجر به دسترسی غیرمجاز به داده حساس شود. دسترسی غیرمجاز به داده حساس، مساله‌ای رایج در اپلیکیشن‌های مبتنی بر API است چرا که مولفه سرور غالبا به طور کامل وضعیت کلاینت را رهگیری نمی‌کند و در عوض برای تصمیم گیری درباره دسترسی کلاینت به اشیاء از پارامترهایی نظیر شناسه شی که از سوی خود کلاینت ارسال می‌شوند، تکیه دارند. | مهاجمین می‌توانند از نقاط و توابع ‌آسیب‌پذیر (از منظر مجوزدهی نادرست در سطح اشیا) با دستکاری شناسه شیء ارسالی درون درخواست سوءاستفاده و بهره برداری نمایند. این امر می‌تواند منجر به دسترسی غیرمجاز به داده حساس شود. دسترسی غیرمجاز به داده حساس، مساله‌ای رایج در اپلیکیشن‌های مبتنی بر API است چرا که مولفه سرور غالبا به طور کامل وضعیت کلاینت را رهگیری نمی‌کند و در عوض برای تصمیم گیری درباره دسترسی کلاینت به اشیاء از پارامترهایی نظیر شناسه شی که از سوی خود کلاینت ارسال می‌شوند، تکیه دارند. | دسترسی غیرمجاز می‌تواند منجر به افشای اطلاعات به طرف‌های غیرمجاز، از دست رفتن داده یا دستکاری آن شود. همچنین دسترسی غیرمجاز به اشیا می‌تواند سبب تحت کنترل گرفتن کامل حساب کاربری توسط مهاجم گردد. + +## آیا API از نظر مجوزدهی نادرست در سطح اشیاء آسیب‌پذیر است؟ + +مجوزدهی در سطح اشیا مکانیزمی برای کنترل دسترسی است که غالبا در سطح کد ‌‌‌‌پیاده‌سازی شده و دسترسی کاربر به اشیایی که بایستی به آنها دسترسی داشته باشد را تضمین می‌نماید. +هر تابعی در API که یک شناسه شی دریافت نموده و نوعی عملیات بر روی آن شی انجام می‌دهد، بایستی کنترل‌های مجوزدهی در سطح اشیا را بکار گیرد. این کنترل‌ها باید دسترسی کاربرِ واردشده به انجام عمل درخواستی بر روی شی درخواستی را اعتبارسنجی نمایند. +وجود ایراد و نقصان در این مکانیزم منجر به افشای اطلاعات غیرمجاز، تغییر یا از بین رفتن تمامی داده خواهد شد. + + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +یک پلتفرم تجارت الکترونیک، برای فروشگاه‌های آنلاین نمودارهای سود فروشگاه‌های میزبانی شده را در قالب یک لیست چندصفحه‌ای ارائه می‌دهد. مهاجم با بررسی درخواست‌های مرورگر، توابعی از API که نقش منبع داده برای نمودارهای مذبور را دارند و الگوی آنها به صورت `/shops/{shopName}/revenue_data.json` می‌باشد را شناسایی می‌کند. با استفاده از یک تابع دیگر API، مهاجم می‌تواند لیست نام کلیه فروشگاه‌های میزبانی شده را استخراج نماید. همچنین مهاجم با استفاده از یک اسکریپت ساده و جایگزین کردن `{shopName}` در URL خواهد توانست به داده‌ی فروش هزاران فروشگاه دسترسی یابد. + +### سناریو #2 + +با پایش ترافیک شبکه‌ی یک گجت پوشیدنی درخواست HTTP `PATCH` زیر توجه مهاجم را به وجود سرآیند HTTP سفارشی `X-User-Id: 54796` جلب می‌نماید. با جایگزین کردن مقدار `X-User-Id` با `54795`، مهاجم پاسخ HTTP موفقیت آمیز گرفته و قادر به تغییر اطلاعات حساب سایر کاربران خواهد بود. + +## چگونه از آسیب‌پذیری مجوزدهی نادرست در سطح اشیاء پیشگیری کنیم؟ + +* بکارگیری یک مکانیزم مجوزدهی که بر خط مشی و سلسله مراتب کاربری تمرکز دارد. +* استفاده از یک مکانیزم مجوزدهی برای بررسی اینکه آیا کاربر واردشده مجوز لازم برای انجام عملیات درخواستی بر روی رکورد در تمامی توابعی که از کلاینت، ورودی می‌گیرند تا به رکورد مذبور در پایگاه داده دسترسی داشته باشند را دارا است یا خیر؟ +* ارجحیت استفاده از مقادیر تصادفی و غیرقابل پیش بینی بعنوان GUID برای شناسه رکوردها. +* طراحی آزمونهایی برای ارزیابی صحت عملکرد مکانیزم‌های مجوزدهی. + +## مراجع + +### خارجی + +
+ +* [CWE-284: Improper Access Control][1] +* [CWE-285: Improper Authorization][2] +* [CWE-639: Authorization Bypass Through User-Controlled Key][3] + +[1]: https://cwe.mitre.org/data/definitions/284.html +[2]: https://cwe.mitre.org/data/definitions/285.html +[3]: https://cwe.mitre.org/data/definitions/639.html + + diff --git a/2019/fa/src/0xa2-broken-user-autentication.md b/2019/fa/src/0xa2-broken-user-autentication.md new file mode 100644 index 000000000..3083fd375 --- /dev/null +++ b/2019/fa/src/0xa2-broken-user-autentication.md @@ -0,0 +1,73 @@ +
+ +API2:2019 احرازهویت نادرست کاربر +==================================== + +| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**2** : قابلیت تشخیص**2** | پیامد فنی**3** : خاص کسب و کار | +|احرازهویت در APIها مکانیزمی پیچیده و سردرگم کننده است. در نتیجه امکان دارد مهندسین نرم افزار و امنیت تصورات غلطی درباره حد و مرز احرازهویت و نحوه ‌پیاده‌سازی آن داشته باشند. بعلاوه، مکانیزم احرازهویت هدفی بدیهی و آسان برای مهاجمان خواهد بود چرا که در معرض دید عموم قرار دارد. این دو نکته، مولفه احراز هویت را درمقابل بهره برداری‌ها و اکسپلویت‌های متعدد آسیب‌پذیر می‌سازد.|در اینجا دو مساله وجود دارد:1. نبود مکانیزم‌های حفاظتی: رفتار با نقاط و توابع مسئول احراز هویت در API بایستی متفاوت از سایر نقاط و توابع بوده و لایه‌های حفاظتی بیشتری داشته باشد.2. ‌پیاده‌سازی نادرست مکانیزم حفاظتی: مکانیزم حفاظتی بدون لحاظ کردن بردارهای حمله یا با موارداستفاده نادرست (مثلا بکارگیری مکانیزم احرازهویتی که برای IoT طراحی شده در وب اپلیکیشن‌ها) ‌پیاده‌سازی یا استفاده شده‌اند.|مهاجمین می‌توانند به حساب‌های کاربری سایر کاربران دسترسی یافته، اطلاعات شخصی آنها را خوانده و عملیات حساس (نظیر نقل و انتقالات مالی و ارسال پیام‌های شخصی) را از طرف آنها انجام دهد.| + +## آیا API از نظر احرازهویت نادرست کاربر آسیب‌پذیر است؟ + +نقاط، توابع و جریان‌های احرازهویت API دارایی‌هایی هستند که بایستی محافظت شوند. همچنین توابع «فراموشی گذرواژه یا بازیابی گذرواژه» نیز بایستی در زمره مکانیزم‌های احرازهویت در نظر گرفته شوند. + +یک API از منظر احرازهویت نادرست کاربر آسیب‌پذیر است اگر: +* اجازه حمله [درج هویت][1] را بدهد که در آن مهاجم از لیستی از نام‌های کاربری و گذرواژه‌های معتبر استفاده می‌نماید. +* بدون استفاده از مکانیزم‌های CAPTCHA یا قفل کردن حساب کاربری اجازه حمله Brute Force روی یک حساب کاربری را بدهد. +* اجازه استفاده از گذرواژه‌های ضعیف را بدهد. +* جزئیات و داده‌های حساس مرتبط با احرازهویت از قبیل توکن‌های اصالت سنجی و گذرواژه‌ها را از طریق URL ارسال نماید. +* اصالت توکن‌ها را به بوته آزمون نگذارد. +* توکن‌ها JWT ضعیف یا بدون امضا (`"alg”:”none"`) را بپذیرد یا تاریخ انقضای آنها را اعتبارسنجی ننماید. +* از گذرواژه‌های آشکار ، رمزگذاری نشده یا درهم سازی شده بصورت ضعیف استفاده نماید. +* از کلیدهای رمزگذاری ضعیف بهره ببرد. + +## مثال‌هایی از سناریوهای حمله + +## سناریو #1 + +[درج هویت][1] (استفاده از [لیستی از نام‌های کاربری یا گذرواژه‌های شناخته شده][2]) حمله‌ای رایج است. اگر اپلیکیشن از مکانیزم‌های حفاظتی خودکار در مقابل تهدیداتی نظیر درج هویت بهره نبرده باشد، آنگاه اپلیکیشن می‌تواند بعنوان یک پیشگوی گذرواژه یا آزمونگر جهت بررسی صحت اطلاعات هویتی جهت عبور از مکانیزم احرازهویت بکار رود. + +## سناریو #2 + +مهاجم جریان بازیابی گذرواژه را با ارسال یک درخواست POST به `/api/system/verification-codes` و ارائه نام کاربری در بدنه پیام آغاز می‌کند. سپس یک توکن پیامک 6 رقمی به تلفن قربانی ارسال می‌گردد. از آنجا که API خط مشی محدودیت سازی نرخ ارسال درخواست را بکار نگرفته، مهاجم می‌تواند تمامی جایگشت‌ها و ترکیبات محتمل را با استفاده از یک اسکریپت چندنخی با تابع زیر برای یافتن توکن صحیح ظرف چند دقیقه بیازماید `/api/system/verification-codes/{smsToken}`. + +## چگونه از ‌آسیب‌پذیری احرازهویت نادرست کاربر پیشگیری کنیم؟ + +* حصول اطمینان از آنکه تمامی جریان‌های ممکن برای احراز هویت API (موبایل یا وب، سایر لینک‌هایی که از مکانیزم احرازهویت با یک کلیک و غیره) شناسایی شده است. +* مشورت با توسعه دهندگان و مهندسین در ارتباط با جریان‌های احرازهویتی که ممکن است از نظر دور مانده باشند. +* مطالعه و فهم کامل مکانیزم‌های احرازهویت استفاده شده در اپلیکیشن؛ بایستی درنظر داشت که OAuth و کلیدهای API نمی‌توانند بعنوان مکانیزمی برای احرازهویت به شمار آیند. +* در مساله احرازهویت، تولید توکن و ذخیره‌سازی گذرواژه، نباید چرخ را از ابتدا اختراع کرد بلکه بایستی از استانداردها استفاده نمود. +* توابع بازیابی یا فراموشی گذرواژه بایستی از منظر محافظت در مقابل Brute Force، محدودسازی نرخ و قفل شدن حساب کاربری هم ارز با توابع و نقاط ورود در نظر گرفته شود. +* از [راهنمای احرازهویت OWASP][3] استفاده شود. +* بکارگیری احرازهویت چندعاملی، در هر جا که امکان داشت. +* بکارگیری مکانیزم‌های ضد Brute Force برای جلوگیری از حملات درج هویت، Dictionary و Brute Force بر روی توابع و نقاط احرازهویت در API. این مکانیزم بایستی سختگیرانه‌تر از مکانیزم محدودسازی نرخ معمول ‌پیاده‌سازی شود. +* بکارگیری مکانیزم‌های [قفل کردن حساب کاربری][4] / CAPTCHA برای جلوگیری از حمله Brute Force علیه کاربران خاص. +* کلیدهای API نبایستی برای احرازهویت کاربران بکار برده شود اما در عوض می‌تواند برای [احرازهویت اپلیکیشن/پروژه کلاینت][5] استفاده گردد. + +## مراجع + +
+ +### OWASP + +* [OWASP Key Management Cheat Sheet][6] +* [OWASP Authentication Cheatsheet][3] +* [Credential Stuffing][1] + +
+ +### خارجی + +
+ +* [CWE-798: Use of Hard-coded Credentials][7] + +[1]: https://www.owasp.org/index.php/Credential_stuffing +[2]: https://github.com/danielmiessler/SecLists +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[4]: https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) +[5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet +[7]: https://cwe.mitre.org/data/definitions/798.html + diff --git a/2019/fa/src/0xa3-excessive-data-exposure.md b/2019/fa/src/0xa3-excessive-data-exposure.md new file mode 100644 index 000000000..c9bb35c1c --- /dev/null +++ b/2019/fa/src/0xa3-excessive-data-exposure.md @@ -0,0 +1,44 @@ +
+ +API3:2019 افشای مفرط داده +================================= + +| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**2** : قابلیت تشخیص**2** | پیامد فنی**2** : خاص کسب و کار | +| بهره برداری از این آسیب‌پذیری آسان بوده و غالبا با شنود ترافیک به منظور تحلیل پاسخ‌های API برای یافتن داده حساسی که نباید به کاربر بازگردانده شود امکان پذیر است. | APIها برای فیلتر کردن داده به کلاینت‌ها اتکا می‌کنند. از آنجا که APIها به عنوان منابع داده استفاده می‌شوند، توسعه دهندگان گاها آنها را بدون توجه به حساسیت اطلاعاتی که افشا می‌شود بکار می‌گیرند. ابزارهای خودکار غالبا نمی‌توانند این ‌آسیب‌پذیری را کشف کنند چرا که تمایز دادن بین داده مجازی که توسط API بازگردانده می‌شود با داده حساسی که نباید توسط API بازگردانده شود بدون داشتن فهمی عمیق از اپلیکیشن امکان پذیر نیست. | افشای مفرط و بیش از حد داده معمولا منجر به افشای اطلاعات حساس می‌شود. | + +## آیا API از نظر افشای مفرط داده ‌آسیب‌پذیر است؟ + +طراحی API به گونه‌ای است که داده حساس را به کلاینت باز می‌گرداند. این داده غالبا پیش از ارائه و نمایش به کاربر در سمت کلاینت فیلتر می‌شود. در نتیجه مهاجم می‌تواند براحتی و با شنود ترافیک، این داده حساس را مشاهده نماید. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +تیم توسعه موبایل از `/api/articles/{articleId}/comments/{commentId}` برای مشاهده و پردازش فراداده کامنت‌ها بهره می‌برد. با شنود ترافیک اپلیکیشن موبایل، مهاجم در می‌یابد که داده مرتبط با نویسنده کامنت نیز بازگردانده می‌شود. این موضوع به این دلیل است که ‌‌پیاده‌سازی API از یک متد عمومی `toJSON()` برای سریالیزه کردن شیء `User` بهره می‌برد که این شی حاوی داده حساس PII می باشد. + +### سناریو #2 + +یک سیستم نظارتی مبتنی بر IoT به مدیران خود اجازه ایجاد کاربرانی با سطوح مجوز مختلف می‌نماید. یکی از مدیران یک حساب کاربری برای یک نیروی حفاظت فیزیکی (نگهبان) جدید می‌سازد که بر مبنای آن تنها امکان دسترسی به ساختمان‌های مشخصی بایستی وجود داشته باشد. به محض استفاده نگهبان مذبور از اپلیکیشن موبایل خود، یک فراخوانی API به سوی `/api/sites/111/cameras` روانه می‌شود تا اطلاعات مرتبط با دوربین‌های موجود را دریافت نموده و آنها را در دشبورد خود نمایش دهد. پاسخ، لیستی از جزئیات دوربین‌ها با فرمت زیر را در بردارد. `{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}`. +در حالیکه رابط گرافیکی کلاینت فقط دوربین‌هایی که نگهبان مذبور بایستی به آنها دسترسی داشته باشد را نشان می‌دهد، اما لیست کامل این دوربین‌ها در پاسخ API وجود دارد. + +## چگونه از ‌آسیب‌پذیری افشای مفرط داده پیشگیری کنیم؟ + +* عدم تکیه بر کلاینت در مساله فیلتر کردن داده حساس. +* بازبینی پاسخ دریافتی از API به منظور حصول اطمینان از آنکه فقط داده لازم و اصلی در آن نمایش داده می شود. +* پیش از افشا و در معرض دید عموم قراردادن یک API، مهندسین توسعه دهندگان Back-End بایستی از خود بپرسند: مصرف کننده و مخاطب این داده چه کسی است؟ +* اجتناب از استفاده از متدهای عمومی `to_json()` و `to_string()` و در عوض دستچین کردن تک تک ویژگی‌ها و مشخصه‌هایی که برای پاسخ ضروری هستند. +* طبقه بندی اطلاعات حساس و شخصی ذخیره شده در APIها و بازبینی تمامی فراخوانی‌های APIهایی که این اطلاعات را باز می‌گردانند به منظور کشف و شناسایی مواردی که ضعف امنیتی در پی دارند. +* بکارگیری یک مکانیزم اعتبارسنجی الگومحور برای بررسی اعتبار پاسخ‌ها بعنوان یک لایه امنیتی دیگر و همچنین تعریف و اعمال این مکانیزم بر روی داده بازگردانده شده تمامی APIها از جمله خطاها. + +## مراجع + +### خارجی + +
+ +* [CWE-213: Intentional Information Exposure][1] + +[1]: https://cwe.mitre.org/data/definitions/213.html + diff --git a/2019/fa/src/0xa4-lack-of-resources-and-rate-limiting.md b/2019/fa/src/0xa4-lack-of-resources-and-rate-limiting.md new file mode 100644 index 000000000..d32ed7ec8 --- /dev/null +++ b/2019/fa/src/0xa4-lack-of-resources-and-rate-limiting.md @@ -0,0 +1,77 @@ +
+ +API4:2019 کمبود منابع و نبود محدودیت بر نرخ ارسال +=========================================== + +| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**2** | میزان شیوع**3** : قابلیت تشخیص**3** | پیامد فنی**2** : خاص کسب و کار | +| بهره برداری از این آسیب‌پذیری نیاز به ارسال درخواست‌های ساده‌ای به سوی API دارد و به احراز هویت هم نیازی نیست. کافی است تعدادی درخواست هم‌زمان از یک ماشین و یا با استفاده از منابع رایانش ابری به سوی API ارسال گردد تا بتوان از این آسیب‌پذیری بهره برد. | یافتن APIهایی که محدودسازی نرخ ارسال را بکار نگرفته یا محدودیت‌های اعمال شده آنها ناکافی است، کار دشواری نیست. | بهره برداری از این آسیب‌پذیری می‌تواند منجر به بروز DoS شده، در نتیجه API را از پاسخ به درخواست‌ها باز دارد و یا حتی آن را از دسترس خارج نماید.| + +## آیا API از نظر کمبود منابع و نبود محدودیت بر نرخ ارسال ‌‌آسیب‌پذیر است؟ + +درخواست‌‌های ارسال شده به سوی API منابعی از قبیل پهنای باند شبکه، پردازنده، حافظه و فضای ذخیره‌سازی را مصرف می‌کنند. مقدار منابعی که برای پاسخگویی به یک درخواست صرف می‌شود عمدتا به ورودی‌‌های کاربر و منطق تجاری توابع API بستگی دارد. همچنین باید این موضوع را نیز درنظر داشت که درخواست‌‌های کلاینت‌‌های API مختلف برای دریافت منابع رقابت می‌کنند. +اگر دست‌کم یکی از محدودیت‌‌های زیر در سمت API به کلی اعمال نشده یا بطور نادرست (مثلا بیش از حد زیاد یا بیش از حد کم) ‌‌‌‌پیاده‌سازی شده باشد آنگاه API از منظر محدودیت یا کمبود نرخ ارسال، ‌‌آسیب‌پذیر خواهد بود: + +* اجرای محدودیت زمانی (time out) +* حداکثر میزان حافظه قابل تخصیص +* تعداد توصیف‌گر فایل‌‌ها +* تعداد پردازه‌‌ها +* اندازه محموله در درخواست‌‌ها (مثلا در هنگام آپلود) +* تعداد درخواست‌‌ها به ازای کلاینت یا منبع +* تعداد رکوردهایی که به ازای یک درخواست در یک صفحه نمایش داده می‌شوند. + + +## مثال‌‌هایی از سناریوهای حمله + +### سناریو #1 + +مهاجم از طریق ارسال یک درخواست POST به `/api/v1/images` اقدام به آپلود یک تصویر بزرگ می‌نماید. بعد از اتمام آپلود، API از روی تصویر آپلود شده تصاویرانگشتی متعددی با اندازه‌‌های مختلف ایجاد می نماید. به دلیل اندازه تصویر آپلودشده، حافظه‌ی دردسترس در خلال فرایند ایجاد تصاویر انگشتی تحت فشار قرار گرفته و API به وضعیت غیرپاسخگو می‌رسد. + +### سناریو #2 + +اپلیکیشنی لیست کاربران را در UI با محدودیت `200` کاربر در صفحه نمایش می‌دهد. لیست این کاربران از طربق ارسال پرس و جوی زیر از سرور دریافت می‌گردد: `/api/users?page=1&size=200`. در اینجا مهاجم می‌تواند با تغییر پارامتر `size` به `200 000`، مشکلاتی در عملکرد پایگاه داده پدید آورده و API را به وضعیت غیرپاسخگو برساند. در این حالت API قادر به پاسخگویی به هیچ درخواستی نخواهد بود (همان DoS). +همین سناریو را می‌توان به طریق مشابه برای ایجاد حملات سرریز Integer و سرریز Buffer استفاده نمود. + +## چگونه از ‌‌آسیب‌پذیری کمبود منابع و نبود محدودیت بر نرخ ارسال پیشگیری کنیم؟ + +* محدودسازی [حافظه][1]، [پردازنده][2]، [تعداد دفعات راه اندازی مجدد][3]، [توصیف‌گرهای فایل و پردازه‌‌ها][4] با استفاده از Docker. +* اعمال محدودیت بر تعداد دفعاتی که در یک زمان مشخص امکان فراخوانی API وجود دارد. +* پس از ردشدن کلاینت از آستانه مجاز، این موضوع به همراه زمان رفع محدودیت به کلاینت اطلاع داده شود. +* افزودن اعتبارسنجی سمت سرور برای بررسی پارامترهای موجود در بدنه درخواست‌‌ها و رشته‌‌های پرس و جو، خصوصا مواردی که به نحوی با تعداد رکوردهای نمایش داده شده در پاسخ ارتباط دارند. +* تعریف و اِعمال بیشینه اندازه داده (نظیر بیشینه طول برای رشته‌‌ها یا بیشینه تعداد عناصر در آرایه‌‌ها) در درخواست‌‌ها و محموله‌‌های ورودی. + +## مراجع + +
+ +### OWASP + +* [Blocking Brute Force Attacks][5] +* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, + processes, restarts)][6] +* [REST Assessment Cheat Sheet][7] + +
+ +### خارجی + +
+ +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8] +* [CWE-770: Allocation of Resources Without Limits or Throttling][9] +* “_Rate Limiting (Throttling)_” - [Security Strategies for Microservices-based + Application Systems][10], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit +[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks +[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts +[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md +[8]: https://cwe.mitre.org/data/definitions/307.html +[9]: https://cwe.mitre.org/data/definitions/770.html +[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf + + diff --git a/2019/fa/src/0xa5-broken-function-level-authorizaion.md b/2019/fa/src/0xa5-broken-function-level-authorizaion.md new file mode 100644 index 000000000..d605037c3 --- /dev/null +++ b/2019/fa/src/0xa5-broken-function-level-authorizaion.md @@ -0,0 +1,78 @@ +
+ +API5:2019 مجوزدهی نادرست در سطح توابع +============================================= + +| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**2** | میزان شیوع**2** : قابلیت تشخیص**1** | پیامد فنی**2** : خاص کسب و کار | +| بهره برداری از این ‌‌آسیب‌پذیری یعنی ارسال فراخوانی‌های API درست توسط مهاجم به سوی API Endpoint در ارتباط با فراخوانی‌هایی که مهاجم مجوز آنها را ندارد. این Endpointها ممکن است در معرض دید کاربران ناشناس، بدون مجوز یا عادی قرار داشته باشند. برای مهاجم تشخیص وجود چنین نواقصی در API آسان تر است چرا که ساختارمندتر بوده و نحوه دسترسی آنها به توابع، قابل پیش بینی تر است (مثلا تغییر متد HTTP از GET به PUT یا تغییر رشته “users” در URL به “admins”). | کنترل‌های مجوزدهی برای توابع یا منابع غالبا در سطح پیکربندی یا کد مدیریت می شوند. بکارگیری کنترل‌های مناسب می‌تواند گیج کننده باشد چرا که اپلیکیشن‌های مدرن امروزی غالبا دارای انواع مختلفی از نقش‌ها و گروه‌ها و سلسله مراتب کاربری هستند (مثلا کاربران دارای بیش از یک نقش). | چنین مشکلاتی منجر به دسترسی مهاجم به توابع غیرمجاز می‌شود. در این صورت توابع مدیریتی از جمله اهداف کلیدی مهاجم خواهند بود. | + +## آیا API از نظر مجوزدهی نادرست در سطح توابع ‌‌آسیب‌پذیر است؟ + +بهترین راه یافتن مشکلات مجوزدهی در سطح توابع، تحلیل عمیق مکانیزم مجوزدهی با لحاظ کردن سلسله مراتب کاربران، نقش‌‌‌ها و گروهاه‌‌‌های متفاوت موجود در اپلیکیشن و پرسیدن پرسش‌‌‌های زیر است: + +* آیا کاربر عادی می‌تواند به توابع و نقاط مدیریتی در API دسترسی داشته باشد؟ +* آیا کاربری می‌تواند عمل حساسی که مجوز انجام آن را ندارد (نظیر ایجاد، تغییر یا حذف) را صرفا با تغییر متد HTTP (مثلا از `GET` به `DELETE`) انجام دهد؟ +* آیا کاربری از گروه X می‌تواند صرفا با حدس زدن URLهای توابع و پارامترهای آن به مسیری (نظیر `/api/v1/users/export_all`) که فقط باید برای کاربران گروه Y قابل مشاهده باشد دسترسی یابد؟ + +بایستی در نظر داشت که عادی یا مدیریتی بودن یک تابع در API (همان API Endpoint) صرفا بر مبنای مسیر URL تعیین نمی‌شود. + +در حالیکه توسعه دهندگان بیشتر تمایل دارند که توابع مدیریتی را ذیل یک مسیر نسبی معین مانند `api/admins` قرار دهند، اما بسیار دیده می شود که این توابع مدیریتی در کنار توابع عادی در مسیرهایی نظیر `api/users` قرار داده شده‌اند. + +## مثال‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +در خلال فرایند ثبت نام در یک اپلیکیشن که فقط به کاربران دعوت شده اجازه عضویت می‌دهد، اپلیکیشن موبایل، یک فراخوانی API به `GET /api/invites/{invite_guid}` می‌فرستد. پاسخ دریافتی فایل JSONی را دارا است که درون آن اطلاعات دعوتنامه‌‌‌ها شامل نقش کاربر و آدرس ایمیل وی دیده می‌شود. + +مهاجم درخواست مذبور را ضبط کرده و متد HTTP را به `POST /api/invites/new` تغییر می‌دهد. این تابع تنها بایستی از طریق کنسول مدیریت و برای ادمین‌‌‌ها قابل دسترسی باشد که بعلت عدم بکارگیری کنترل‌‌‌های صحیح مجوزدهی درسطح توابع اینگونه نیست. + +در گام بعد مهاجم از این مساله بهره برداری کرده و برای خود دعوتنامه‌ای جهت ساخت یک اکانت ادمین می‌فرستد: + +
+ +``` +POST /api/invites/new + +{“email”:”hugo@malicious.com”,”role”:”admin”} +``` + +
+ +### سناریو #2 + +یک API دارای تابعی است که فقط ادمین‌‌‌ها بایستی آن را ببینند - `GET /api/admin/v1/users/all`. این تابع در پاسخ جزئیات تمامی کاربران اپلیکیشن را برگردانده و کنترل‌‌‌های مجوزدهی در سطح توابع را نیز به درستی ‌‌‌‌پیاده‌سازی نکرده است. مهاجمی که با ساختار API آشنایی پیدا کرده، این مسیر را حدس زده و اطلاعات حساس تمامی کاربران اپلیکیشن را می‌رباید. + +## چگونه از ‌‌آسیب‌پذیری مجوزدهی نادرست در سطح توابع پیشگیری کنیم؟ + +ماژول مجوزدهی اپلیکیشن بایستی بطور یکپارچه توسط تمامی توابع اپلیکیشن فراخوانی شده و تحلیل آن نیز آسان باشد. همچنین در بیشتر مواقع، این روش حفاطتی توسط یک یا چند مولفه بیرونی و خارج از کد اصلی اپلیکیشن فراهم می‌شود. + +* مکانیزم (های) اعمال شده بایستی بطور پیشفرض کلیه دسترسی‌‌‌ها را Deny (رد) نموده و برای دسترسی به هر یک از توابع، مجوزخاص دسترسی نقش مربوطه را طلب نمایند. +* توابع API از منظر عیوب مجوزدهی در سطح تابع با درنظر گرفتن منطق اپلیکیشن و سلسله مراتب گروه‌‌‌های کاربری مورد بازبینی قرار گیرد. +* تمامی کنترلگرهای مدیریتی از یک کنترلگر مدیریتی انتزاعی که مجوزها را بر حسب نقش کاربر یا گروه پیاده‌سازی نموده، ارث بری داشته باشند. +* تمامی توابع مدیریتی درون یک کنترلگر عادی (غیرمدیریتی)، کنترل‌‌‌های مجوز مبتنی بر نقش کاربر یا گروه را بکارگیرند. + +## مراجع + +
+ +### OWASP + +* [OWASP Article on Forced Browsing][1] +* [OWASP Top 10 2013-A7-Missing Function Level Access Control][2] +* [OWASP Development Guide: Chapter on Authorization][3] + +
+ +### خارجی + +
+ +* [CWE-285: Improper Authorization][4] + +[1]: https://www.owasp.org/index.php/Forced_browsing +[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control +[3]: https://www.owasp.org/index.php/Category:Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html + diff --git a/2019/fa/src/0xa6-mass-assignment.md b/2019/fa/src/0xa6-mass-assignment.md new file mode 100644 index 000000000..07e72bbfc --- /dev/null +++ b/2019/fa/src/0xa6-mass-assignment.md @@ -0,0 +1,79 @@ +
+ +API6:2019 - تخصیص جمعی +=========================== + +| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**2** | میزان شیوع**2** : قابلیت تشخیص**2** | پیامد فنی**2** : خاص کسب و کار | +| بهره برداری از این آسیب‌پذیری غالبا نیاز به فهم منطق تجاری، روابط مابین اشیا و ساختار API از سوی مهاجم دارد. بهره برداری از مقوله تخصیص جمعی در APIها ساده تر است چرا که در مرحله طراحی، پیاده‌سازی زیرین اپلیکیشن به همراه نام ویژگی‌های اشیا افشا می‌شود و در معرض دید عموم قرار می‌گیرد.| چارچوبهای جدید غالبا توسعه دهندگان را به استفاده از توابعی تشویق می‌کنند که بطور خودکار، ورودی‌های دریافتی از کلاینت را به متغیرهای کد و اشیاء داخلی آن پیوند می‌دهند. مهاجمین با سواستفاده از این متدلوژی می‌توانند به گونه ای اقدام به بروزرسانی یا بازنویسی ویژگی‌های اشیاء (داده) حساس نمایند که توسعه دهنده هیچگاه قصد افشای آن ویژگی‌ها را نداشته است. | بهره برداری از این ‌‌‌آسیب‌پذیری می‌تواند منجر به افزایش سطح دسترسی، دستکاری داده، عبور از مکانیزم‌های امنیتی و ... شود. | + +## آیا API از نظر تخصیص جمعی ‌‌‌آسیب‌پذیر است؟ + +اشیا در اپلیکیشن‌‌‌های مدرن می‌توانند ویژگی‌‌‌های متعددی داشته باشند. برخی از این ویژگی‌‌‌ها بایستی مستقیما توسط کلاینت قابل بروزرسانی باشند (مثلا `user.first_name` یا `user.address`) در حالی که کلاینت نباید بتواند سایر ویژگی‌‌‌ها را دستکاری نماید (مثلا پرچم `user.is_vip`). + +یک تابع درAPI اگر بطور خودکار پارامترهای کلاینت را بدون لحاظ کردن حساسیت و سطح افشای ویژگی‌‌‌های آن، مستقیما تبدیل به ویژگی‌‌‌های اشیای داخلی نماید، از منظر تخصیص جمعی ‌‌‌آسیب‌پذیر خواهد بود. این ‌‌‌آسیب‌پذیری به مهاجم اجازه می‌دهد تا بتواند ویژگی‌‌‌هایی از اشیا را که نباید به آنها دسترسی داشته باشد، بروزرسانی نماید. + +نمونه‌‌‌هایی از «ویژگی‌‌‌های حساس» عبارتند از: + +* **ویژگی‌‌‌های مرتبط با مجوزها**: پرچم‌‌‌هایی نظیر `user.is_admin` و `user.is_vip` فقط بایستی توسط ادمین‌‌‌ها تنظیم شوند. +* **ویژگی‌‌‌های وابسته به فرایند**: `user.cash` فقط باید بصورت داخلی و پس از تایید پرداخت بروزرسانی شود. +* **ویژگی‌‌‌های داخلی**: `article.created_time` فقط باید بصورت داخلی و توسط اپلیکیشن تنظیم گردد. + +## مثال‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک اپلیکیشن هم‌سفری به کاربر امکان ویرایش اطلاعات پایه‌ای پروفایل خود را می‌دهد. در خلال این فرایند، یک فراخوانی API به `PUT /api/v1/users/me` با شی مجاز JSON زیر فرستاده می‌شود: + +
+ +```json +{"user_name":"inons","age":24} +``` +
+ +اما درخواست `GET /api/v1/users/me` ویژگی اضافی credit_balance را نیز در خود دارد: + +
+ +```json +{"user_name":"inons","age":24,"credit_balance":10} +``` +
+ +در اینجا مهاجم درخواست اول را با محتوای مخرب زیر بازارسال می‌نماید: + +
+ +```json +{"user_name":"attacker","age":60,"credit_balance":99999} +``` +
+ +به دلیل وجود آسیب‌پذیری تخصیص جمعی در endpoint، مهاجم می‌تواند بدون انجام پرداخت اعتبار دریافت کند. + +### سناریو #2 + +یک پلتفرم اشتراک‌گذاری ویدئو به کاربران خود اجازه دانلود محتوا با فرمت‌‌‌های مختلفی را می‌دهد. مهاجم که در حال بررسی API است، در می‌یابد که `GET /api/v1/videos/{video_id}/meta_data` یک شیء JSON با ویژگی‌‌‌های ویدئو را باز می‌گرداند. یکی از این ویژگی‌‌‌ها، `"mp4_conversion_params”:”-v codec h264" ` است که نشان می‌دهد اپلیکیشن از یک دستور Shell برای تبدیل ویدئو بهره می‌برد. + +همچنین مهاجم متوجه می‌شود که `POST /api/v1/videos/new` در برابر تخصیص جمعی ‌‌‌آسیب‌پذیر بوده و به کلاینت اجازه می‌دهد که هریک از ویژگی‌‌‌های شیءویدئو را با به صورت دلخواه تنظیم نماید. در نتیجه مهاجم مقدار مخربی را به صورت `"mp4_conversion_params":"-v codec h264 && format C:/"` در قست ویژگی ویدئو وارد می‌کند که در نتیجه آن با دانلود ویدئو با فرمت MP4 توسط مهاجم حمله تزریق دستور Shell اجرا خواهد شد. + + +## چگونه از ‌‌‌آسیب‌پذیری تخصیص جمعی پیشگیری کنیم؟ + +* در صورت امکان، از بکارگیری توابعی که ورودی کلاینت را بصورت خودکار تبدیل به متغیرهای کد یا اشیای داخلی اپلیکیشن می کنند خودداری شود. +* تنها ویژگی‌‌‌های ضروری که باید توسط کلاینت بروزرسانی شوند در لیست سفید قرار گیرد. +* از قابلیت‌‌‌های تعبیه شده در اپلیکیشن‌‌‌ها برای قراردادن ویژگی‌‌‌هایی که تغییر آنها برای کلاینت غیرمجاز است در لیست سیاه استفاده شود. +* در صورت امکان، الگوهای واضح و بدون ابهام برای داده ورودی تعریف و اعمال شود. + +## مراجع + +### خارجی + +
+ +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][1] + +[1]: https://cwe.mitre.org/data/definitions/915.html + diff --git a/2019/fa/src/0xa7-security-misconfiguration.md b/2019/fa/src/0xa7-security-misconfiguration.md new file mode 100644 index 000000000..01b810cf1 --- /dev/null +++ b/2019/fa/src/0xa7-security-misconfiguration.md @@ -0,0 +1,97 @@ +
+ +API7:2019 پیکربندی امنیتی نادرست +================================= + +|عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**3** : قابلیت تشخیص**3** | پیامد فنی**2** : خاص کسب و کار | +| مهاجمین غالبا در تلاش برای یافتن حفره‌های وصله نشده، توابع رایج یا فایل‌ها و مسیرهای محافظت نشده به منظور دسترسی غیرمجاز به سیستم هستند.| پیکربندی امنیتی نادرست می‌تواند در هر سطحی از API، از سطح شبکه تا سطح اپلیکشن روی دهد. ابزارهای خودکاری وجود دارند که فرایند تشخیص و بهره برداری از پیکربندی‌های نادرست نظیر تشخیص سرویس‌های غیرضروری را انجام می‌دهند. | پیکربندی امنیتی نادرست نه تنها می‌تواند اطلاعات حساس کاربر را افشا کند بلکه جزئیاتی از سیستم که ممکن است به از دست رفتن کامل سرور منجر شود را نیز در معرض خطر قرار می‌دهد. + +## آیا API از نظر پیکربندی امنیتی نادرست ‌‌‌آسیب‌پذیر است؟ + +از منظر پیکربندی امنیتی نادرست api آسیب پذیر است اگر: + +* ایمن سازی امنیتی مناسب در هر قسمت از پشته اپلیکیشن رعایت نشده یا اپلیکیشن مجوزهای با پیکربندی نادرست روی سرویس‌‌‌‌های ابری داشته باشد. +* جدیدترین وصله‌‌‌‌های امنیتی نصب نشده و سیستم‌‌‌‌ها کاملا بروز نباشند. +* ویژگی غیرضروری (نظیر افعال اضافی HTTP) فعال باشند. +* امنیت لایه انتقال (TLS) غیرفعال باشد. +* دستورات و الزامات امنیتی (نظیر [سرایندهای امنیتی][1]) به سوی کلاینت ارسال نشوند. +* خط مشی اشتراک متقابل منابع (CORS ) وجود نداشته یا به درستی ‌پیاده‌سازی نشده باشد. +* پیام‌‌‌‌های خطا ردپای پشته یا اطلاعات حساس دیگر را افشا نمایند. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +مهاجم فایل `.bash_history` را (که دستورات مورد استفاده تیم DevOps برای دسترسی به API را در خود دارد) در مسیر root سرور می‌یابد: + +
+ +``` +$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg==' +``` +
+ +همچنین مهاجم خواهد توانست توابعی از API که تنها توسط تیم DevOps مورد استفاده قرارگرفته و مستند نشده‌اند را نیز بیابد. + + +### سناریو #2 + +برای هدف قراردادن یک سرویس مشخص، مهاجم از موتورهای جستجوی رایج برای یافتن کامپیوترهایی که مستقیما توسط اینترنت قابل دسترسی هستند بهره می‌برد. در نتیجه، مهاجم میزبانی را می‌یابد که از یک سیستم مدیریت پایگاه داده محبوب استفاده نموده و اقدام به شنود روی پورت پیشفرض آن dbms می‌کند. از آنجا که میزبان از پیکربندی پیشفرض (که احراز هویت را بطور پیشفرض غیرفعال نموده) استفاده کرده، مهاجم می‌تواند به میلیون‌‌‌‌ها رکورد حاوی PII، داده‌‌‌‌های احرازهویت و ... دست یابد. + +### سناریو #3 + +مهاجم با بررسی ترافیک یک اپلیکیشن موبایل متوجه می‌شود که تمامی ترافیک HTTP بر بستر یک پروتکل ایمن (نظیر TLS) منتقل نمی‌شود و این موضوع خصوصا در زمان دانلود تصاویر پروفایل صدق می‌کند. از آنجا که تعامل کاربر با اپلیکیشن دودویی است، علیرغم انتقال ترافیک API بر بستر پروتکلی ایمن، مهاجم خواهد توانست الگویی را در اندازه پاسخ API شناسایی نموده و از آن برای رهگیری ترجیحات کاربر در خصوص محتوای ارائه شده به اپلیکیشن (مثلا تصاویر پروفایل) بهره ببرد. + + +## چگونه از ‌‌‌آسیب‌پذیری پیکربندی امنیتی نادرست پیشگیری کنیم؟ + +چرخه حیات API بایستی شامل موارد زیر باشد: + +* فرایندی تکرار شونده برای ایمن سازی API که منجر به ‌پیاده‌سازی سریع و آسان یک محیط ایمن شود. +* فرایندی برای بازبینی و بروزرسانی پیکربندی‌‌‌‌ها در سراسر پشته API؛ این بازبینی بایستی موارد از جمله بازبینی هماهنگی بین فایل‌‌‌‌ها، مولفه‌‌‌‌های API و سرویس‌‌‌‌های ابری (نظیر مجوزهای باکت‌‌‌‌های S3) را دربرگیرد. +* برقراری یک کانال ارتباطی ایمن برای دسترسی تمامی تعاملات API به دارایی‌‌‌‌های ایستا (نظیر تصاویر). +* خودکار جهت ارزیابی پیوسته و مداوم اثربخشی پیکربندی و تنظیمات اعمال شده در سراسر محیط API و اپلیکیشن. + +بعلاوه: + +* برای جلوگیری از ارسال رهگیری رویدادهای استثنا و سایر داده‌‌‌‌های ارزشمند به مهاجم، در صورت امکان برای تمامی پاسخ‌‌‌‌های API (از جمله خطاها) الگوهای محموله مشخص تعریف و اعمال گردد. +* حصول اطمینان از اینکه API فقط به افعال HTTP مدنظر توسعه دهنده پاسخ می دهد و غیرفعال کردن سایر افعال (نظیر `HEAD`). +* APIهایی که انتظار می‌رود دسترسی به آنها از طریق کلاینت‌‌‌‌های مبتنی بر مرورگر (مثلا فرانت WebApp) باشد، بایستی خط مشی CORS مناسب را بکار گیرند. + + +## مراجع + +
+ +### OWASP + +* [OWASP Secure Headers Project][1] +* [OWASP Testing Guide: Configuration Management][2] +* [OWASP Testing Guide: Testing for Error Codes][3] +* [OWASP Testing Guide: Test Cross Origin Resource Sharing][9] + +
+ +### خارجی + +
+ +* [CWE-2: Environmental Security Flaws][4] +* [CWE-16: Configuration][5] +* [CWE-388: Error Handling][6] +* [Guide to General Server Security][7], NIST +* [Let’s Encrypt: a free, automated, and open Certificate Authority][8] + +[1]: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project +[2]: https://www.owasp.org/index.php/Testing_for_configuration_management +[3]: https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) +[4]: https://cwe.mitre.org/data/definitions/2.html +[5]: https://cwe.mitre.org/data/definitions/16.html +[6]: https://cwe.mitre.org/data/definitions/388.html +[7]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[8]: https://letsencrypt.org/ +[9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) + + diff --git a/2019/fa/src/0xa8-injections.md b/2019/fa/src/0xa8-injections.md new file mode 100644 index 000000000..3224c30e6 --- /dev/null +++ b/2019/fa/src/0xa8-injections.md @@ -0,0 +1,122 @@ +
+ +API8:2019 تزریق ورودی‌های مخرب +============================== + + + +|عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**2** : قابلیت تشخیص**3** | پیامد فنی**3** : خاص کسب و کار | +| مهاجمین تلاش می‌کنند تا هرچه مسیر‌ برای تزریق (از جمله، ورودی‌های مستقیم، متغییرها و سرویس‌های یکپارچه) وجود دارد را با داده‌های مخرب پر کنند و انتظار دارند این اطلاعات بدست لایه مفسر برسد.| وجود ‌آسیب‌پذیری تزریق ورودی‌های مخرب، امری متداول بوده و معمولا در پرس و جو‌های SQL، LDAP یا NoSQL، دستورات سیستم عامل، تجزیه کنندگان XML و ORM یافت می‌شود. این نقص‌ها به سادگی در زمان بازبینی کد منبع قابل کشف می‌باشند. مهاجمین نیز برای این منظور از اسکنرها و Fuzzerها استفاده می‌کنند. | ‌آسیب‌پذیری تزریق ورودی‌های مخرب می‌تواند منجر به افشای اطلاعات و یا از دست رفتن اطلاعات شود. همچنین ممکن است این ضعف منجر به اختلال در سرویس‌دهی شده و یا حتی باعث از دست رفتن کامل دسترسی میزبان شود. + +## آیا API از نظر نقص تزریق ورودی‌های مخرب آسیب‌پذیر است؟ + +از منظر نقصِ تزریق ورودی‌های مخرب API ‌آسیب‌پذیر است اگر: + +* اطلاعات وارد شده توسط کاربر توسط API اعتبار سنجی، فیلتر یا پاکسازی نشود. +* اطلاعات وارد شده توسط کاربر به صورت مستقیم استفاده شده و یا به انواع دستورات پرس و جو (SQL یا NoSQL یا LDAP) یا دستورات سیستم عامل، تجزیه‌کنندگان XML، ORM یا ORM افزوده شود. +* اطلاعات دریافت شده از سیستم‌های خارجی توسط API اعتبار سنجی، فیلتر یا پاکسازی نشود. + + + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +میان‌افزار یک دستگاه کنترل (فرزندان) توسط والدین تابعی را در مسیر `/api/CONFIG/restore` ارائه می‌کند، که انتظار دارد مقدار appId ارسال شده به سمت آن، دارای مقادیر چند متغیره باشد. با استفاده از یک دیکامپایلر، مهاجم در می‌یابد مقدار appId بدون هیچ‌گونه تغییر یا پاکسازی‌ به یک فراخوانی سیستمی ارسال می‌شود. + +
+ +``` +snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d", + "/mnt/shares/usr/bin/scripts/", appid, 66); +system(cmd); +``` + +
+ +دستور زیر به مهاجم این امکان را می‌دهد تا هر دستگاهی با این میان افزار ‌آسیب‌پذیر را خاموش کند. + +
+ +``` +$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)' +``` +
+ + + + +### سناریو #2 + +سامانه تحت وب ساده‌ای با عملکرد‌های اولیه CRUD ، برای انجام عملیات‌های رزرو وجود دارد. مهاجم موفق به شناسایی تزریق NoSQL از طریق متغیر `bookingId` در رشته پرس و جو و در درخواست حذف رزرو شده است. درخواست مذکور شبیه به `DELETE /api/bookings?bookingId=678` می‌باشد. + +سرور API از تابع زیر برای رسیدگی کردن به درخواست‌های حذف استفاده می‌کند: + +
+ +```javascript +router.delete('/bookings', async function (req, res, next) { + try { + const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId}); + res.status(200); + } catch (err) { + res.status(400).json({error: 'Unexpected error occured while processing a request'}); + } +}); +``` +
+ +مانند آنچه در زیر مشاهده می‌کنید، مهاجم پس از رهگیری درخواست و تغییر مقدار `bookingId` استفاده شده در رشته پرس و جو، می‌تواند رزرو انجام شده توسط کاربر دیگری را حذف نماید. + +
+ +``` +DELETE /api/bookings?bookingId[$ne]=678 +``` + +
+ +## چگونه از آسیب‌پذیری تزریق ورودی‌های مخرب پیشگیری کنیم؟ + +جلوگیری از ‌آسیب‌پذیری تزریق ورودی‌های مخرب، نیازمند جداسازی اطلاعات از دستورات و پرس و جو‌ها می‌باشد. + +* داده‌ها باید توسط یک کتابخانه پایدار، فعال و قابل اطمینان اعتبار سنجی شود. +* تمامی اطلاعات وارد شده توسط کاربران و دیگر سیستم‌های یکپارچه باید اعتبار سنجی، فیلتر یا پاکسازی شود. +* کاراکترهای خاص باید توسط قوانین مشخص برای مفسران نهایی تغییر داده شود. +* همواره تعداد رکوردهای بازگردانده شده باید محدود شود تا در صورت وجود نقص تزریق ورودی‌های مخرب، از افشای انبوه اطلاعات جلوگیری شود. +* داده‌های ورودی باید توسط فیلترهای مناسب اعتبار سنجی شود تا تنها مقادیر معتبر برای هر پارامتر ورودی مجاز به وارد شدن باشند. +* برای تمامی متغییر‌های رشته‌ای، نوع داده و الگوی سخت‌گیرانه‌ای تعریف شود. + + + +## مراجع + +
+ +### OWASP + +* [OWASP Injection Flaws][1] +* [SQL Injection][2] +* [NoSQL Injection Fun with Objects and Arrays][3] +* [Command Injection][4] + +
+ +### خارجی + +
+ +* [CWE-77: Command Injection][5] +* [CWE-89: SQL Injection][6] + +[1]: https://www.owasp.org/index.php/Injection_Flaws +[2]: https://www.owasp.org/index.php/SQL_Injection +[3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf +[4]: https://www.owasp.org/index.php/Command_Injection +[5]: https://cwe.mitre.org/data/definitions/77.html +[6]: https://cwe.mitre.org/data/definitions/89.html + + + diff --git a/2019/fa/src/0xa9-improper-asset-management.md b/2019/fa/src/0xa9-improper-asset-management.md new file mode 100644 index 000000000..9e4fb928b --- /dev/null +++ b/2019/fa/src/0xa9-improper-asset-management.md @@ -0,0 +1,61 @@ +
+ +API09:2019 مدیریت نادرست دارایی‌ها +=================================== + +|عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**3** : قابلیت تشخیص**2** | پیامد فنی**2** : خاص کسب و کار | +|نسخه‌های قدیمی API غالبا اصلاح و بروزرسانی نشده‌اند و از آنجا که از مکانیزم‌های دفاعی نوین موجود در APIهای جدید بهره نمی‌برند، راهی آسان برای دسترسی به سیستم‌ها برای مهاجمین فراهم می‌سازند.|مستندات قدیمی و بروزرسانی نشده، امکان یافتن و یا رفع آسیب‌پذیری‌ها را دشوار می‌سازند. همچنین نبود فهرستی از دارایی‌ها و فقدان یک استراتژی مدون برای از دور خارج کردن نسخه‌های قدیمی منجر به وجود سیستم‌های وصله یا تعمیر نشده و نهایتا نشت اطلاعات خواهد شد. امروزه با کمک مفاهیم نوینی نظیر مایکروسرویس‌ها که امکان بکارگیری اپلیکیشن‌ها بصورت مستقل را تسهیل نموده‌اند (نظیر رایانش ابری، k8s یا کوبرنیتس و ...)، یافتن APIهایی که به صورت غیرضروری در معرض دید همگان قرار دارند تبدیل به امری رایج و آسان شده است.|مهاجم می‌تواند از طریق نسخه‌های قدیمی API که کماکان به پایگاه داده‌ی اصلی متصل هستند، به داده‌ی حساس و یا حتی سرور دسترسی یابد. + +## آیا API از نظر مدیریت نادرست دارایی‌ها ‌آسیب‌پذیر است؟ + +در صورتی که یکی ازشرایط زیر وجود داشته باشد، API ‌آسیب‌پذیر خواهد بود: + +* اهدف از وجود API نامشخص بوده و پاسخی برای سوال‌های زیر وجود نداشته باشد: + - در چه محیطی API در حال اجرا است (مثلا محیط تست، توسعه، اجرا یا عملیات )؟ + - چه کسانی بایستی دسترسی شبکه‌ای به API داشته باشند (همه، افراد دخیل یا شرکا)؟ + - چه نسخه‌ای از API در حال اجرا است؟ + - چه داده‌ای (نظیر PII) توسط API در حال جمع آوری و پردازش است؟ + - جریان داده به چه صورت است؟ +* مستندی برای API وجود ندارد یا بروز نیست. +* برنام‌ ای برای بازنشستگی و از دور خارج شدن هریک از نسخه‌های API وجود ندارد. +* فهرست میزبان‌ها وجود ندارد یا قدیمی است. +* فهرست سرویس‌های یکپارچه ، چه سرویس‌های متعلق به خود سازمان و چه سرویس‌های شرکت‌های ثالث، وجود ندارد یا قدیمی است. +* نسخه‌های قدیمی یا پیشین API بدون اصلاح و وصله شدن کماکان در حال اجرا هستند. + + + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +پس از بازطراحی یک اپلیکیشن، یک سرویس جستجوی Local وجود دارد که از یک نسخه قدیمی API (`api.someservice.com/v1`) به صورت محافظت نشده بهره می‌برد که در عین حال این API قدیمی به پایگاه داده کاربران دسترسی دارد. مهاجم که جدیدترین نسخه اپلیکیشن را به عنوان هدف درنظر گرفته، آدرس API (`api.someservice.com/v2`) را می‌یابد. جایگزینی `v2` با `v1` در URL سبب دسترسی مهاجم به API محافظت نشده و قدیمی می‌شود که در نتیجه‌ی آن، اطلاعات شناسایی شخصی (PII) بیش از 100 میلیون کاربر افشا گردیده است. + +### سناریو #2 + +یک شبکه اجتماعی از مکانیزم محدودسازی نرخ ارسال درخواست برای جلوگیری از انجام حملات Brute Force توسط مهاجمین جهت حدس توکن‌های تغییر گذرواژه بهره می‌برد. این مکانیزم نه به عنوان بخشی از کد API، بلکه به عنوان مولفه ای مابین کلاینت و API اصلی (در `www.socialnetwork.com`) ‌پیاده‌سازی شده است. مهاجم یک نسخه بتا از میزبان API (`www.mbasic.beta.socialnetwork.com`) می‌یابد که از API یکسانی بهره می‌برد و رویه تغییر گذرواژه یکسانی دارد با این تفاوت که در آن هیچ مکانیزمی جهت محدودسازی نرخ درخواست تعبیه نشده است؛ در نتیحه مهاجم قادر خواهد بود که گذرواژه هر یک از کاربران را طی یک عملیات Brute Force ساده با حدس زدن یک توکن 6 رقمی تغییر دهد. + +## چگونه از آسیب‌پذیری مجوزدهی نادرست در سطح اشیاء پیشگیری کنیم؟ + +* فهرستی از تمامی میزبان‌های API تهیه شده و جنبه‌های مهم هرکدام با تمرکز بر محیط API (محیط تست، توسعه، اجرا یا عملیات)، افراد مجاز به دسترسی شبکه‌ای به میزبان (همه، افراد دخیل یا شرکا) و نسخه API مستند شود. +* فهرستی از سرویس‌های یکپارچه تهیه شده و جنبه‌های مهم این سرویس‌ها نظیر نقش آنها، داده‌ی مبادله شده (جریان داده) و میزان حساسیت آنها مستند شود. +* تمامی جنبه‌های API نظیر نحوه احراز هویت، خطاها، ریدایرکت‌ها، محدودسازی نرخ درخواست، خط مشی‌های اشتراک گذاری منابع متقابل (CORS) و نقاط پایانی یا توابع (Endpointها) شامل پارامترها، درخواست‌ها و پاسخ‌ها مستند شوند. +* با بکارگیری و انطباق با استانداردهای باز، فرایند تولید مستند بطور خودکار انجام شده و این فرایند در CI/CD Pipeline تعبیه گردد. +* مستندات API در اختیار افرادی که مجاز به دسترسی به API هستند قرار گیرد. +* از مکانیزم‌های محافظتی خارجی از جمله فایروال‌های امنیت API برای محافظت از تمامی نسخه‌های در معرض دید API (نه فقط نسخه فعلی) استفاده گردد. +* از استفاده همزمان نسخه‌های عملیاتی شده و عملیاتی نشده API اجتناب شود. اگر این همزمانی اجتناب ناپذیر است، برای نسخه‌های عملیاتی نشده API نیز باید همان حفاظت‌های امنیتی نسخه‌های عملیاتی شده برقرار باشد. +* هنگامی که در نسخه‌های جدیدتر API بهبودهای امنیتی اعمال می‌شود، بایستی فرایند تحلیل ریسک نیز صورت پذیرد تا بتوان تصمیمات لازم در خصوص اقدامات جبرانی برای رفع مشکلات امنیتی نسخه‌های قدیمی‌تر را اتخاذ نمود. بعنوان نمونه، آیا می‌توان بدون تحت‌الشعاع قراردادن انطباق‌پذیری API بهبودهای امنیتی را در نسخه‌های قدیمی نیز وارد نمود یا اینکه بایستی تمامی نسخه‌های قدیمی به سرعت از دسترس خارج شده و تمامی کلاینت‌های مجبور به استفاده از آخرین نسخه شوند؟ + + +## مراجع + +### خارجی +
+ +* [CWE-1059: Incomplete Documentation][1] +* [OpenAPI Initiative][2] + +[1]: https://cwe.mitre.org/data/definitions/1059.html +[2]: https://www.openapis.org/ + diff --git a/2019/fa/src/0xaa-insufficient-monitoring.md b/2019/fa/src/0xaa-insufficient-monitoring.md new file mode 100644 index 000000000..35cf48a20 --- /dev/null +++ b/2019/fa/src/0xaa-insufficient-monitoring.md @@ -0,0 +1,68 @@ +
+ +API10:2019 پایش و نظارت ناکافی +======================================== + +|عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**2** | میزان شیوع**3** : قابلیت تشخیص**1** | پیامد فنی**2** : خاص کسب و کار | +| مهاجمین می توانند از فقدان فرایند ثبت وقایع و پایش برای سوءاستفاده پنهانی از سیستم‌ها بهره ببرند.| بدون ثبت وقایع و پایش آنها یا با ثبت و پایش ناکافی، رهگیری فعالیت‌های مخرب و پاسخ آنها در زمان مناسب تقریبا غیرممکن خواهد بود. | بدون پایش فعالیت‌های مخربی که در حال انجام است، مهاجمین زمان زیادی برای نفوذ به سیستم‌ها خواهند داشت. + +## آیا API از نظر پایش و نظارت ناکافی ‌آسیب‌پذیر است؟ + +در صورتی که یکی ازشرایط زیر وجود داشته باشد، API ‌آسیب‌پذیر خواهد بود: + +* هیچگونه Logای توسط API تولید نشود، سطح ثبت وقایع به درستی تنظیم نشده باشد یا پیام‌‌های Log، حاوی جزئیات کافی نباشند.. +* جامعیت Logها تضمین نشده باشد (مثلا [Log Injection][1] رخ دهد). +* به طور پیوسته Logها پایش نشوند. +* زیرساخت API به طور پیوسته پایش نشود. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +کلیدهای دسترسی به یک API مدیریتی در یک انباره عمومی افشا شده و در اختیار همگان قرار گرفته است. مالک انباره از طریق یک ایمیل از این افشای احتمالی مطلع می‌شود اما بیش از 48 ساعت طول می‌کشد تا اقدام مقتضی انجام شود که در این حدفاصل، افشای کلید دسترسی ممکن سبب دسترسی غیرمجاز به داده حساس شده باشد. از آنجا که پایش کافی وجود نداشته است، سازمان نخواهد توانست بفهمد عوامل مخرب به چه داده‌ای دسترسی پیدا کرده‌اند. + +### سناریو #2 + +یک پلتفرم اشتراک گذاری ویدئو با یک حمله درج هویت در مقیاسی بزرگ مواجه می‌شود. علیرغم آنکه تلاش‌‌های ناموفق ورود ثبت می‌شوند، اما هیچگونه هشداری در طول زمان حمله اعلام نشده است؛ بلکه تنها در واکنش به شکایت‌‌های کاربران، Logهای API تحلیل و حمله کشف شده است. در نتیجه سازمان مجبور به صدور اعلامیه‌ای رسمی شده و از تمامی کاربران می‌خواهد که گذرواژه‌‌های خود را تغییر دهند. همچنین سازمان بایستی به مراجع نظارتی درخصوص این حادثه گزارش داده و پاسخگوی آنها باشد. + +## چگونه از ‌آسیب‌پذیری پایش و نظارت ناکافی پیشگیری کنیم؟ + +* تمامی تلاش‌‌های ناموفق احراز هویت، دسترسی‌‌های غیرمجاز و خطاهای اعتبارستجی ورودی بایستی ثبت شوند. +* Logها باید به گونه ای تهیه شوند که توسط راهکارهای مدیریت Log قابل استفاده بوده و همچنین جزئیات کافی جهت شناسایی عامل مخرب را در خود داشته باشند. +* با Logها بایستی به عنوان داده حساس رفتار شده و جامعیت آنها هم در زمان ذخیره سازی و هم در زمان انتقال تضمین شود. +* یک سیستم پایش پیکربندی و راه اندازی شود تا بتوان بطور مداوم و پیوسته عملکرد زیرساخت، شبکه و API را پایش نمود. +* از یک سیستم مدیریت رویدادها و اطلاعات امنیتی (SIEM) برای تجمیع و مدیریت Logهای دریافتی از تمامی مولفه‌‌های پشته API و میزبان‌‌های آن استفاده شود. +* از Dashboardها و هشدارها یا اعلان‌‌های سفارشی‌سازی شده به منظور تشخیص و پاسخ سریع به فعالیت‌‌های مشکوک استفاده شود. + + +## مراجع + +
+ +### OWASP + +* [OWASP Logging Cheat Sheet][2] +* [OWASP Proactive Controls: Implement Logging][3] +* [OWASP Application Security Verification Standard: V7: Error Handling and Logging Verification Requirements][4] + +
+ +### خارجی + +
+ +* [CWE-1059: Incomplete Documentation][5] +* [OpenAPI Initiative][6] + + +[1]: https://owasp.org/index.php/Log_Injection +[2]: https://owasp.org/index.php/Logging_Cheat_Sheet +[3]: https://owasp.org/www-project-proactive-controls/ +[4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md + +[5]: https://cwe.mitre.org/data/definitions/1059.html +[6]: https://www.openapis.org/ + + diff --git a/2019/fa/src/0xb0-next-devs.md b/2019/fa/src/0xb0-next-devs.md new file mode 100644 index 000000000..602cf9223 --- /dev/null +++ b/2019/fa/src/0xb0-next-devs.md @@ -0,0 +1,37 @@ +
+ +گام بعدی برای توسعه‌دهندگان +============================ + +وظایف مرتبط با ایجاد و نگهداری ایمن از نرم افزارها یا تعمیر نرم افزارهای موجود می‌تواند دشوار باشد و APIها نیز از قضیه مستثنی نیستند. + +بر این باوریم که آموزش و آگاه سازی، گامی کلیدی در راستای نوشتن و توسعه نرم افزارهای ایمن هستند. تمامی الزامات دیگر در راستای نیل به هدف فوق به **ایجاد و استفاده از فرایندهای امنیتی تکرارپذیر و کنترل‌های امنیتی استاندارد بستگی دارد.** + +OWASP منابع آزاد و رایگان متعددی برای پاسخ به مسائل امنیتی از ابتدای پروژه ایجاد نموده است. به منظور آشنایی با لیست جامع پروژه‌‌های دردسترس، [صفحه پروژه‌‌های OWASP][1] را ملاحظه نمایید. + + +| | | +|-|-| +| **آموزش** | برای شروع می‌توان از [پروژه مطالب آموزشی OWASP][2] بسته به علاقه و نوع حرفه آغاز نمود. برای آموزش عملیاتی، crAPI را نیز به [نقشه راه][3] خود افزوده‌ایم. تست‌‌های مربوط به WebAppSec را می‌توان با [OWASP DevSlop Pixi Module][4] که یک WebApp و سرویس API آزمایشگاهی آسیب‌پذیر است، انجام داد. استفاده از چنین ابزارهایی سبب یادگیری نحوه تست وب اپلیکیشن‌‌ها و APIهای مدرن از منظر مسائل امنیتی و چگونگی توسعه APIهای مدرن در آینده خواهد شد. همچنین امکان شرکت در جلسات آموزشی [کنفرانس AppSec][5] و عضویت در [شَعب محلی OWASP][6] نیز برای علاقه مندان وجود دارد.| +| **الزامات امنیتی** | امنیت باید بعنوان بخشی تفکیک ناپذیر در تمامی پروژه‌‌ها از ابتدا درنظر گرفته شود. در هنگام استخراج الزامات امنیتی، باید معنی واژه «ایمن» برای هر پروژه مشخصا تعریف شود. OWASP استفاده از [استاندارد امنیت سنجی اپلیکیشن (ASVS)][7] را بعنوان راهنمایی برای تعیین الزامات امنیتی توصیه می‌کند. در صورت برون سپاری نیز، استفاده از [ضمیمه قرارداد نرم افزار ایمن OWASP][8] (که بایستی با قوانین و رگولاتوری‌‌های محلی انطباق یابد) می‌تواند انتخاب مناسبی باشد. | +| **معماری امنیتی** | امنیت بایستی در تمامی مراحل توسعه پروژه‌‌ها اهمیت داشته باشد. [برگه‌‌های راهنمای پیشگیری OWASP][9] نقطه شروع مناسبی برای چگونگی طراحی ایمن در خلال فاز طراحی معماری به شمار آید. [همچنین برگه راهنمای امنیت REST][10] و [برگه راهنمای ارزیابی REST][11] نیز گزینه‌‌های مناسبی در این راستا هستند. | +| **کنترل‌‌های امنیتی استاندارد** | بکارگیری و انطباق با کنترل‌‌های امنیتی استاندارد ریسک ایجاد ضعف‌‌های امنیتی در خلال ایجاد برنامه‌‌ها با منطق سازمانی را کاهش می‌دهد. علیرغم اینکه بسیاری از چارچوب‌های مدرن امروزی با استانداردهای توکار و موثر امنیتی توزیع می‌شوند، اما [کنترل‌‌های پیشگیرانه و فعال OWASP][12] دید خوبی از کنترل‌‌هایی که باید در پروژه‌‌ها لحاظ شوند بدست می‌دهد. OWASP کتابخانه و ابزارهای متعددی از جمله در حوزه کنترل‌‌های اعتبارسنجی در اختیار عموم قرار می‌دهد که می‌توانند مفید باشند.| +| **چرخه حیات توسعه نرم افزار ایمن** | به منظور بهبود فرایندها در هنگام ایجاد و ساخت APIها می‌توان از [مدل ضمانت کمال نرم افزار OWASP (SAMM)][13] بهره برد. همچنین پروژه‌‌های متعدد دیگری نیز در OWASP وجود دارند که می‌توانند در فازهای مختلف توسعه API مفید باشند که از جمله آنها می‌توان، [پروژه بازبینی کد OWASP][14] را نام برد. | + + +[1]: https://www.owasp.org/index.php/Category:OWASP_Project +[2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized +[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map +[4]: https://devslop.co/Home/Pixi +[5]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[6]: https://www.owasp.org/index.php/OWASP_Chapter +[7]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[8]: https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex +[9]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[10]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md +[11]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md +[12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 +[13]: https://www.owasp.org/index.php/OWASP_SAMM_Project +[14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project + +
diff --git a/2019/fa/src/0xb1-next-devsecops.md b/2019/fa/src/0xb1-next-devsecops.md new file mode 100644 index 000000000..c7760ce17 --- /dev/null +++ b/2019/fa/src/0xb1-next-devsecops.md @@ -0,0 +1,31 @@ +
+ +گام بعدی برای DevSecOps +============================= + +با توجه به اهمیت APIها در معماری اپلیکیشن‌های جدید، ایجاد APIهای ایمن امری حیاتی می‌باشد. مقوله امنیت را نمی‌توان نادیده گرفت و باید آن را جزئی از کل چرخه توسعه اپلیکیشن در نظر گرفت. انجام اسکن و تست‌ نفود، آن هم به صورت سالیانه به هیچ عنوان کافی نمی‌باشد. + +باید به فرایند توسعه DevSecOps افزوده شده و در تمام زمان‌های توسعه نرم افزار، انجام تست‌های امنیتی مداوم را تسهیل کند. هدف آنها بهره‌گیری از خودکارسازی‌ فرایندهای امنیتی در جهت بهبود فرایند تولید نرم افزار بوده به شکلی که تاثیری بر سرعت توسعه نداشته باشد. اگر شک دارید، [مانیفست DevSecOps][1] را بررسی کنید تا در جریان باشید. + +| | | +|--------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| درک مدل تهدیدات | اولویت‌ تست‌ها از مدل تهدیدات بدست می‌آید. اگر شما مدل تهدیدات ندارید می‌توانید از [OWASP Application Security Verification Standard (ASVS)][2] و [OWASP Testing Guide][3] به عنوان ورودی استفاده کنید. همچنین مشارکت دادن تیم توسعه می‌تواند باعث شود آنها نسبت به موضوعات امنیتی آگاه‌تر شوند. | +| درک چرخه توسعه نرم افزار | تیم توسعه را به فرایند اضافه کنید تا آنها نیز درک بهتری از چرحه توسعه نرم افزار پیدا کنند. مشارکت شما در انجام تست‌های مداوم امنیتی باید همراستا با افراد، فرایند‌ها و ابزارها باشد. همه باید با فرایند موافق باشند تا هیچ گونه اصطکاک و مقاومتی وجود نداشته باشد. | +| راهبرد انجام تست | با توجه به اینکه کار شما نباید تاثیری بر سرعت توسعه داشته باشد. بنابراین باید خیلی آگاهانه بهترین تکنیک (ساده، سریع‌ترین و دقیق‌ترین)‌ را برای تایید الزامات امنیتی انتخاب کنید. [OWASP Security Knowledge Framework][4] و [OWASP Application Security Verification Standard][5] می‌توانند منابع خوبی برای الزامات عملکردی و غیر عملکردی باشند. منابع خوب دیگری از [پروژه‌ها][6] و [ابزارها][7] مشابه با مواردی که توسط [DevSecOps community][8] پیشنهاد می‌شود، وجود دارد. | +| دستیابی به جامعیت و دقت | شما پلی هستید بین تیم‌ توسعه دهنده و ‌‌‌پیاده‌سازی، برای اینکه به این مهم دست یابید نه تنها باید بر روی عملکرد و قابلیت‌ها تمرکز کنید بلکه باید به هماهنگی نیز توجه کنید. از ابتدا به صورت نزدیک با هر دو تیم توسعه و ‌‌‌پیاده‌سازی کار کنید تا بتوانید زمان و تلاش‌تان را بهینه نمایید. شما باید برای حالتی که الزامات امنیتی به صورت مداوم بررسی شوند، هدف گذاری کنید. | +| به وضوح یافته‌‌‌ها را به اشتراک بگذارید | با کمترین اصطکاک یا بدون اصطکاک مشارکت داشته باشید. یافته‌‌ها را در بازه زمانی مشخص و در قالب ابزارهای مورد استفاده توسط تیم توسعه (نه فایل‌های PDF) تحویل دهید. به تیم توسعه اضافه شوید تا یافته‌ها را به آن‌ها نشان دهید. از این فرصت برای آموزش آنها استفاده کنید، به صورت شفاف در مورد نقطه ضعف و روش‌های سوء استفاده از آن (که شامل سناریو‌های حملات می‌باشند) توضیح دهید تا واقعی به نظر برسد. | + + + + + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: https://owasp.org/www-project-application-security-verification-standard/ +[6]: http://devsecops.github.io/ +[7]: https://github.com/devsecops/awesome-devsecops +[8]: https://www.devsecops.org/ + +
diff --git a/2019/fa/src/0xd0-about-data.md b/2019/fa/src/0xd0-about-data.md new file mode 100644 index 000000000..e1e8b06c4 --- /dev/null +++ b/2019/fa/src/0xd0-about-data.md @@ -0,0 +1,28 @@ +
+ +متدلوژی و داده +==================== + +## بررسی اجمالی + +از آنجا که صنعت AppSec مشخصا بر امنیت اپلیکیشن‌‌های معماری نوین که در آنها API نقشی حیاتی دارد، تمرکز ننموده، ایجاد لیستی از ده ریسک امنیتی بحرانی امنیت API بر مبنای فراخوان عمومی کاری سخت خواهد بود. علیرغم اینکه فراخوانی برای داده‌‌های عمومی داده نشده، اما لیست فعلی بر مبنای داده‌های در دسترس عموم، مشارکت کارشناسان امنیتی و نظرات متخصصان حوزه امنیت، تهیه گردیده است. + +## متدلوژی + +در فاز اول، داده‌‌های در دسترس عموم در حوزه رخداده‌‌های مرتبط با امنیت API توسط گروهی از متخصصین امنیت جمع آوری، بازبینی و دسته بندی شدند. این داده‌‌ها از پلتفرم‌‌های شکار باگ و پایگاه‌‌های داده آسیب‌پذیری در یک چارچوب زمانی یک ساله به منظور تحلیل آماری جمع آوری شده اند. + +در فاز بعد، از متخصصین امنیت با سویه عملیاتی و تجربه تست نفوذ خواسته شد تا آنان نیز لیست ده ریسک امنیتی بحرانی API از منظر خود را با گروه به اشتراک گذارند. + +به منظور انجام فرایند تحلیل ریسک از [متدلوژی رتبه بندی ریسک OWASP][1] استفاده و نتایج آن نیز توسط متخصصین امنیتی بازبینی قرار گرفت. برای مطالعه بیشتر در این حوزه به بخش [ریسک‌‌های امنیتی API][2] مراجعه نمایید. + +پیش نویس اولیه ده ریسک امنیتی بحرانی APIها در 2019 از منظر OWASP از اجماع بین نتایج آماری فاز اول و لیست مدنظر متخصصین بدست آمده است و سپس به منظور بازبینی مجدد در اختیار گروه دیگری از متخصصین (با تجربه مرتبط در حوزه امنیت API) قرار گرفته است. + +مستند ده ریسک امنیتی بحرانی APIها در 2019 از منظر OWASP اولین بار در رویداد جهانیOWASP AppSec در تل‌آویو (می 2019) ارائه شده و پس از آن برای بحث و مشارکت عموم در GitHub قرار گرفت. + +لیست مشارکت کنندگان در بخش [سپاسگزاری‌‌ها][3] قابل مشاهده است. + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md + +
\ No newline at end of file diff --git a/2019/fa/src/0xd1-acknowledgments.md b/2019/fa/src/0xd1-acknowledgments.md new file mode 100644 index 000000000..d4c69b8eb --- /dev/null +++ b/2019/fa/src/0xd1-acknowledgments.md @@ -0,0 +1,48 @@ +
+ +سپاسگزاری‌ها +=========== + +## سپاسگزاری از مشارکت کنندگان + +بدینوسیله از تمامی مشارکت کنندگانی که به طور عمومی در GitHub و به سایر طرق در توسعه این مستند نقش داشته‌اند تشکر می‌نماییم + +
+ +* 007divyachawla +* Abid Khan +* Adam Fisher +* anotherik +* bkimminich +* caseysoftware +* Chris Westphal +* dsopas +* DSotnikov +* emilva +* ErezYalon +* flascelles +* Guillaume Benats +* IgorSasovets +* Inonshk +* JonnySchnittger +* jmanico +* jmdx +* Keith Casey +* kozmic +* LauraRosePorter +* Matthieu Estrade +* Mr-Listener +* nathanawmk +* PauloASilva +* pentagramz +* philippederyck +* pleothaud +* r00ter +* Raj kumar +* RNPG +* Sagar Popat +* Stephen Gates +* This-is-neo +* thomaskonrad +* xycloops123 + diff --git a/2019/fa/src/images/cover.jpg b/2019/fa/src/images/cover.jpg new file mode 100644 index 000000000..5ef93f221 Binary files /dev/null and b/2019/fa/src/images/cover.jpg differ diff --git a/2019/fa/src/images/front-cc.png b/2019/fa/src/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/2019/fa/src/images/front-cc.png differ diff --git a/2019/fa/src/images/front-wasp.png b/2019/fa/src/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/2019/fa/src/images/front-wasp.png differ diff --git a/2019/fa/src/images/license.png b/2019/fa/src/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/2019/fa/src/images/license.png differ diff --git a/2019/fa/src/images/owasp-logo.png b/2019/fa/src/images/owasp-logo.png new file mode 100644 index 000000000..caeb47bdf Binary files /dev/null and b/2019/fa/src/images/owasp-logo.png differ diff --git a/2019/fa/src/images/rnpg-logo.png b/2019/fa/src/images/rnpg-logo.png new file mode 100644 index 000000000..77f975780 Binary files /dev/null and b/2019/fa/src/images/rnpg-logo.png differ