API یا کتابخانه ناامن
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
دسته OWASP: MASVS-CODE: کیفیت کد
نمای کلی
استفاده از API ها یا کتابخانه های ناامن وضعیت امنیتی برنامه را به میزان قابل توجهی کاهش می دهد. یک نقض امنیتی در هر یک از این وابستگی ها به مهاجم اجازه می دهد تا از تعدادی بردار برای انجام مجموعه گسترده ای از حملات مانند Man-in-the-Middle (MitM) و اجرای کد از راه دور (RCE) استفاده کند.
تهدید پیاده‌سازی وابستگی‌های ناامن زمانی به وجود می‌آید که توسعه‌دهندگان ارزیابی‌های امنیتی و تست آسیب‌پذیری را در چرخه عمر توسعه نرم‌افزار (SDLC) ادغام نمی‌کنند یا در برخی موارد، یک خط‌مشی به‌روزرسانی خودکار برای وابستگی‌های برنامه‌ها را اجرا نمی‌کنند.
بهره برداری از وابستگی معمولاً با تجزیه و تحلیل باینری برنامه (apk.) برای جستجوی کتابخانه های آسیب پذیر شروع می شود. در این مرحله، اطلاعات منبع باز (OSINT) برای کشف آسیب‌پذیری‌های بالقوه قابل بهره‌برداری که قبلاً کشف شده بودند، انجام می‌شود. سپس مهاجمان می‌توانند از اطلاعات آسیب‌پذیری افشا شده عمومی مانند آسیب‌پذیری‌ها و مواجهه‌های رایج (CVE) برای انجام حملات بیشتر استفاده کنند.
تاثیر
بهره برداری موفقیت آمیز از وابستگی های ناامن می تواند منجر به مجموعه گسترده ای از حملات مانند اجرای کد از راه دور (RCE)، تزریق SQL (SQLi) یا اسکریپت نویسی متقابل (XSS) شود. بنابراین، تأثیر کلی مستقیماً با نوع آسیب‌پذیری که نرم‌افزار شخص ثالث معرفی می‌کند و مهاجمان می‌توانند از آن سوءاستفاده کنند، مرتبط است. پیامدهای احتمالی بهره‌برداری موفقیت‌آمیز از وابستگی‌های آسیب‌پذیر، نقض داده‌ها یا در دسترس نبودن خدمات است که ممکن است به تأثیر قابل‌توجهی بر شهرت و گردش اقتصادی منجر شود.
اقدامات کاهشی
دفاع در عمق
توجه داشته باشید که اقدامات کاهشی ذکر شده در زیر باید به صورت ترکیبی اجرا شوند تا از وضعیت امنیتی قوی‌تر اطمینان حاصل شود و سطح حمله برنامه کاهش یابد. رویکرد دقیق همیشه باید بر اساس مورد به مورد ارزیابی شود.
ارزیابی آسیب پذیری وابستگی
برای شناسایی آسیب‌پذیری‌ها در کد شخص ثالث، تأیید وابستگی را در ابتدای چرخه عمر توسعه پیاده‌سازی کنید. این مرحله آزمایش می کند که آیا کدی که در داخل ساخته نشده است، قبل از عرضه در محیط های تولید، ایمن است یا خیر. راستی‌آزمایی می‌تواند با پیاده‌سازی ابزارهای تست امنیت برنامه استاتیک (SAST) و تست امنیت برنامه کاربردی پویا (DAST) در چرخه عمر توسعه نرم‌افزار برای بهبود وضعیت امنیتی برنامه تکمیل شود.
به طور مداوم وابستگی ها را به روز کنید
همیشه مراقب باشید که به طور مداوم هر وابستگی تعبیه شده در کد را به روز کنید. برای این منظور، توصیه می‌شود که به‌روزرسانی‌های خودکار را پیاده‌سازی کنید که هر زمان که یک مؤلفه شخص ثالث یک وصله امنیتی جدید را منتشر می‌کند، به تولید منتقل می‌شوند.
آزمایش های نفوذ منظم را انجام دهید. هدف این نوع آزمایش‌ها کشف هر آسیب‌پذیری شناخته‌شده‌ای است که می‌تواند بر کد اختصاصی و یا وابستگی‌های شخص ثالث تأثیر بگذارد. علاوه بر این، ارزیابی‌های امنیتی اغلب آسیب‌پذیری‌های ناشناخته (0 روز) را آشکار می‌کنند. تست‌های نفوذ برای توسعه‌دهندگان مفید هستند، زیرا آنها یک عکس فوری از وضعیت امنیتی فعلی برنامه را ارائه می‌دهند و به آنها کمک می‌کنند تا مسائل امنیتی قابل بهره‌برداری را که باید مورد توجه قرار گیرند، اولویت‌بندی کنند.
منابع
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین به‌روزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین به‌روزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Insecure API or Library\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-CODE: Code Quality](https://mas.owasp.org/MASVS/10-MASVS-CODE)\n\nOverview\n--------\n\nUsing insecure APIs or libraries significantly reduces an application's security\nposture. A security breach in any of these dependencies would allow an attacker\nto leverage a number of vectors to conduct a broad set of attacks such as man-\nin-the-middle (MitM) and remote code execution (RCE).\n\nThe threat of implementing insecure dependencies arises when developers don't\nintegrate security assessments and vulnerability testing into the Software\nDevelopment Lifecycle (SDLC) or, in some cases, don't implement an automated\nupdate policy for application dependencies.\n\nDependency exploitation usually starts by analyzing application binary (.apk) to\nsearch for vulnerable libraries. At this point, Open Source Intelligence (OSINT)\nis performed to unearth previously discovered potentially exploitable\nvulnerabilities. Attackers can then leverage publicly disclosed vulnerability\ninformation such as common vulnerabilities and exposures (CVEs) to perform\nfurther attacks.\n\nImpact\n------\n\nThe successful exploitation of insecure dependencies can lead to a broad set of\nattacks such as remote code execution (RCE), SQL injections (SQLi), or cross-\nsite scripting (XSS).\nTherefore, the overall impact is directly related to the type of vulnerability\nthat third-party software introduces and that attackers can exploit.\nPossible consequences of a successful exploitation of vulnerable dependencies\nare data breaches or service unavailability, which may lead to a significant\nimpact on reputation and economic turnover.\n\nMitigations\n-----------\n\n### Defense in depth\n\nNote that the mitigations listed below have to be implemented in combination to\nensure a stronger security posture, and reduce the application's attack surface.\nThe exact approach should always be evaluated on a case-by-case basis.\n\n### Dependency vulnerability assessments\n\nImplement dependency verification at the beginning of the development lifecycle\nto detect vulnerabilities within third-party code. This phase tests whether the\ncode that is not built in-house is secure before being rolled out in production\nenvironments.\nVerification could be complemented by implementing static application security\ntesting (SAST) and dynamic application security testing (DAST) tools within the\nsoftware development lifecycle to improve the security posture of the\napplication.\n\n### Continuously update dependencies\n\nAlways be careful to continuously update any dependency embedded within the\ncode. For this purpose, it is recommended to implement automatic updates that\nare pushed to production whenever a third-party component releases a new\nsecurity patch.\n\n### Perform application penetration testing\n\nConduct regular penetration tests. These kinds of tests aim to uncover any well-\nknown vulnerability that could affect proprietary code and, or third-party\ndependencies.\nAdditionally, security assessments frequently uncover unknown vulnerabilities\n(0-days).\nPenetration tests are helpful for developers, as they provide them with a\nsnapshot of the application's current security posture and help them prioritize\nexploitable security issues that have to be addressed.\n\nResources\n---------\n\n- [How to recognise and manage insecure dependencies](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)\n\n- [GitHub security features](https://docs.github.com/en/code-security/getting-started/github-security-features)\n\n- [How to secure dependencies](https://www.hacksplaining.com/prevention/toxic-dependencies)\n\n- [CWE-1395: Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html)\n\n- [SDK implementation best-practices for Android.](/guide/practices/sdk-best-practices)"]]
