안전하지 않은 API 또는 라이브러리
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
OWASP 카테고리: MASVS-CODE: 코드 품질
개요
안전하지 않은 API나 라이브러리를 사용하면 애플리케이션의 보안 상태가 크게 저하됩니다. 이러한 종속 항목의 보안이 침해되면 공격자가 다수의 벡터를 활용하여 중간자(MitM) 및 원격 코드 실행(RCE)과 같은 광범위한 공격을 실행할 수 있습니다.
안전하지 않은 종속 항목을 구현할 위협은 개발자가 보안 평가 및 취약점 테스트를 소프트웨어 개발 수명 주기(SDLC)에 통합하지 않거나 경우에 따라 애플리케이션 종속 항목의 자동 업데이트 정책을 구현하지 않을 때 발생합니다.
종속 항목 악용은 일반적으로 애플리케이션 바이너리(.apk)를 분석하여 취약한 라이브러리를 찾는 것으로 시작됩니다. 이 시점에서 오픈소스 인텔리전스(OSINT)를 실행하여 이전에 발견된 악용 가능한 취약점을 찾아냅니다. 그러면 공격자는 일반적인 취약점 및 노출(CVE)과 같이 공개된 취약점 정보를 활용하여 추가 공격을 실행할 수 있습니다.
영향
안전하지 않은 종속 항목을 성공적으로 악용하면 원격 코드 실행(RCE), SQL 삽입(SQLi) 또는 교차 사이트 스크립팅(XSS)과 같은 광범위한 공격으로 이어질 수 있습니다.
따라서 전반적인 영향은 서드 파티 소프트웨어에서 발생하고 공격자가 악용할 수 있는 취약점 유형과 직접적으로 관련이 있습니다.
취약한 종속 항목의 악용으로 정보 유출 또는 서비스 비가용성이 발생할 수 있고 이는 평판과 매출에 상당한 영향을 미칠 수 있습니다.
완화 조치
심층 방어
아래에 나열된 완화 조치는 더 강력한 보안 상태를 보장하고 애플리케이션의 공격 표면을 줄이기 위해 함께 구현되어야 합니다.
정확한 접근 방식은 항상 사례별로 평가해야 합니다.
종속 항목 취약점 평가
개발 수명 주기 초기에 종속 항목 확인을 구현하여 서드 파티 코드 내에서 취약점을 감지하세요. 이 단계에서는 프로덕션 환경에 출시되기 전에 내부에서 빌드되지 않은 코드가 안전한지 테스트합니다.
소프트웨어 개발 수명 주기 내에서 정적 애플리케이션 보안 테스트(SAST) 및 동적 애플리케이션 보안 테스트(DAST) 도구를 구현하여 애플리케이션의 보안 상태를 개선함으로써 검증을 보완할 수 있습니다.
종속 항목 지속적으로 업데이트
코드에 삽입된 종속 항목을 지속적으로 업데이트하도록 항상 주의하세요. 이를 위해 서드 파티 구성요소가 새 보안 패치를 출시할 때마다 프로덕션으로 푸시되는 자동 업데이트를 구현하는 것이 좋습니다.
정기적으로 침투 테스트를 실행하세요. 이러한 유형의 테스트는 독점 코드 또는 서드 파티 종속 항목에 영향을 줄 수 있는 잘 알려진 취약점을 찾는 것을 목표로 합니다.
또한 보안 평가에서는 알 수 없는 취약점(제로 데이)을 파악하는 경우가 많습니다.
침투 테스트는 개발자에게 애플리케이션의 현재 보안 상태 스냅샷을 제공하여 해결해야 하는 악용 가능한 보안 문제의 우선순위를 정할 수 있도록 하므로 유용합니다.
리소스
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2023-12-08(UTC)
[[["이해하기 쉬움","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"]],["최종 업데이트: 2023-12-08(UTC)"],[],[],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)"]]
