diff --git a/2025/docs/ko/0x00_2025-Introduction.md b/2025/docs/ko/0x00_2025-Introduction.md new file mode 100644 index 000000000..f356f005f --- /dev/null +++ b/2025/docs/ko/0x00_2025-Introduction.md @@ -0,0 +1,113 @@ +![OWASP Logo](../assets/TOP_10_logo_Final_Logo_Colour.png) + +# 가장 위험한 10대 웹 애플리케이션 보안 위험 + +# 소개 + +OWASP Top 10의 8번째 버전에 오신 것을 환영합니다! + +데이터와 설문 조사를 통해 견해를 나눠주신 모든 분께 깊은 감사를 드립니다. 여러분의 도움 없이는 이번 버전을 만들 수 없었을 것입니다. **감사합니다!** + +## OWASP Top 10:2025 소개 + + + +* [A01:2025 - 불충분한 접근 제어](A01_2025-Broken_Access_Control.md) +* [A02:2025 - 보안 설정 오류](A02_2025-Security_Misconfiguration.md) +* [A03:2025 - 소프트웨어 공급망 실패](A03_2025-Software_Supply_Chain_Failures.md) +* [A04:2025 - 암호 실패](A04_2025-Cryptographic_Failures.md) +* [A05:2025 - 인젝션](A05_2025-Injection.md) +* [A06:2025 - 안전하지 않은 설계](A06_2025-Insecure_Design.md) +* [A07:2025 - 인증 실패](A07_2025-Authentication_Failures.md) +* [A08:2025 - 소프트웨어 또는 데이터 무결성 실패](A08_2025-Software_or_Data_Integrity_Failures.md) +* [A09:2025 - 보안 로깅 및 알림 실패](A09_2025-Security_Logging_and_Alerting_Failures.md) +* [A10:2025 - 부적절한 예외 처리](A10_2025-Mishandling_of_Exceptional_Conditions.md) + + +## 2025년 Top 10의 변화 + +2025년 Top 10에는 두 개의 신규 카테고리가 추가되고 하나의 카테고리가 통합되었으며, 증상보다는 근본 원인에 초점을 두었다. 소프트웨어 엔지니어링과 소프트웨어 보안의 복잡성을 고려할 때, 서로 중복되지 않는 10개의 카테고리를 만드는 것은 사실상 불가능했다. + + +![Mapping](../assets/Top10Mapping-ko.png) + +* **[A01:2025 - 불충분한 접근 제어](A01_2025-Broken_Access_Control.md)**는 가장 심각한 애플리케이션 보안 위험으로 1위를 유지하였다. 제공된 데이터에 따르면 테스트 된 애플리케이션의 평균 3.73%가 이 카테고리에 해당하는 40개 CWE(Common Weakness Enumeration) 중 하나 이상을 가지고 있었다. 위 그림의 점선으로 표시된 것처럼, 서버 측 요청 위조(Server-Side Request Forgery)가 이 카테고리에 통합되었다. +* **[A02:2025 - 보안 설정 오류](A02_2025-Security_Misconfiguration.md)**는 2021년 5위에서 2025년 2위로 상승하였다. 이번 주기에 제공된 데이터에서는 설정 오류가 더 많이 발견되었으며, 테스트 된 애플리케이션 중 3.00%가 이 카테고리에 해당하는 16개 CWE 중 하나 이상을 포함하고 있었다. 이는 소프트웨어 엔지니어링에서 애플리케이션의 동작이 설정에 기반하는 비중이 지속적으로 증가하고 있는 현황을 반영하는 결과이다. +* **[A03:2025 - 소프트웨어 공급망 실패](A03_2025-Software_Supply_Chain_Failures.md)**는 기존의 [A06:2021-취약하고 오래된 구성 요소](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)의 범위를 확장하여, 소프트웨어 의존성, 빌드 시스템, 배포 인프라 전반에서 발생하는 광범위한 공급망 침해 사례를 포함한다. 본 카테고리는 커뮤니티 설문조사에서 가장 중요한 항목으로 압도적인 지지를 받았다. 이 카테고리에는 총 5개의 CWE가 포함되어 있으며, 수집된 데이터에서는 발생률이 상대적으로 낮게 나타났으나, 이는 테스트의 어려움에 기인한 것으로 판단된다. 향후 이 영역에 대한 테스트가 보완될 것으로 기대된다. 해당 카테고리는 데이터상 발생 빈도는 가장 낮았으나, CVE 기준으로는 평균적인 악용 가능성과 영향 점수가 가장 높은 것으로 확인되었다. +* **[A04:2025 - 암호 실패](A04_2025-Cryptographic_Failures.md)**는 2위에서 4위로 두 단계 하락하였다. 제공된 데이터에 따르면, 평균적으로 전체 애플리케이션의 3.80%가 이 카테고리에 속하는 32개의 CWE 중 하나 이상을 포함하고 있는 것으로 나타났다. 암호 실패가 발생하면 민감한 데이터의 노출이나 시스템 침해로 빈번하게 이어진다. +* **[A05:2025 - 인젝션](A05_2025-Injection.md)**은 3위에서 5위로 하락하였으나, 암호 실패와 안전하지 않은 설계 등 인접한 항목들과의 순위에는 변동이 없었다. 이 카테고리는 테스트가 가장 활발히 수행된 카테고리 중 하나로, 38개 CWE에 대응되는 CVE가 가장 많이 제보되었다. 인젝션은 발생 빈도는 높지만 영향이 비교적 적은 크로스 사이트 스크립팅(높은 빈도/낮은 영향)부터, 발생 빈도는 낮으나 피해 규모가 큰 SQL 인젝션(낮은 빈도/높은 영향)까지 폭넓은 유형을 포함한다. +* **[A06:2025 - 안전하지 않은 설계](A06_2025-Insecure_Design.md)**는 보안 설정 오류와 소프트웨어 공급망 실패에 밀려 4위에서 6위로 두 단계 하락했다. 이 카테고리는 2021년에 도입되었으며, 이후 업계에서 위협 모델링과 안전한 설계에 대한 인식이 높아지면서 상당한 개선이 이루어졌다. +* **[A07:2025 - 인증 실패](A07_2025-Authentication_Failures.md)**는 7위를 유지하였으며, 해당 카테고리에 속하는 36개의 CWE를 보다 정확히 반영하기 위해 명칭("[신원 확인 및 인증 실패](https://owasp.org/Top10/2021/A07_2021-Identification_and_Authentication_Failures/)")이 일부 변경되었다. 이 카테고리는 여전히 중요한 항목이지만, 인증을 위한 표준화된 프레임워크의 활용이 증가하면서 인증 실패 사례의 발생 빈도 감소에 긍정적인 영향을 미친 것으로 보인다. +* **[A08:2025 - 소프트웨어 또는 데이터 무결성 실패](A08_2025-Software_or_Data_Integrity_Failures.md)**는 이번에도 8위를 차지하였다. 이 카테고리는 소프트웨어 공급망 실패보다 상대적으로 더 낮은 수준(lower level)에서 소프트웨어, 코드, 데이터 등의 무결성을 검증하고 트러스트 바운더리(Trust Boundary)를 유지하는 과정에서 발생하는 실패에 초점을 두고 있다. +* **[A09:2025 - 보안 로깅 및 알림 실패](A09_2025-Security_Logging_and_Alerting_Failures.md)**는 9위를 유지하였다. 이 카테고리는 로깅 이벤트에 대한 적절한 대응을 가능하게 하는 알림(alert) 기능의 중요성을 강조하기 위해 명칭이 변경되었다(기존 [보안 로깅 및 모니터링 실패](https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring)). 알림 체계가 없는 로깅만으로는 보안 사고를 효과적으로 식별하기 어렵다. 이 카테고리는 특성상 데이터에 과소반영되는 경향이 있으며, 이번에도 커뮤니티 설문을 통해 순위가 결정되었다. +* **[A10:2025 - 부적절한 예외 처리](A10_2025-Mishandling_of_Exceptional_Conditions.md)**는 2025년에 새롭게 도입된 카테고리이다. 이 카테고리는 시스템이 비정상적인 상태에 직면했을 때 발생할 수 있는 부적절한 오류 처리, 논리적 오류, 페일 오픈(fail open) 등을 포함하는 상태에서 비롯되는 24개 CWE를 포함하고 있다. + +## 방법론 + +이번 Top 10은 데이터에 기반하되, 데이터에 맹목적으로 의존하지는 않는다. 수집된 데이터를 기반으로 12개 카테고리의 순위를 산정하였으며, 커뮤니티 설문조사 결과를 통해 2개 카테고리를 추가로 선정하였다. 이러한 접근 방식을 채택한 근본적인 이유는, 수집된 데이터를 분석하는 것은 본질적으로 과거를 돌아보는 작업이기 때문이다. 애플리케이션 보안 연구자들은 새로운 취약점을 발굴하고 새로운 테스트 방법을 개발하는 데 많은 시간을 투자하고 있다. 이러한 테스트를 도구와 프로세스에 통합하기까지는 몇 주에서 몇 년이 소요된다. 특정 취약점을 대규모로 신뢰성 있게 테스트할 수 있게 될 때쯤이면 이미 몇 년이 경과한 경우가 많다. 또한 신뢰성 있게 테스트하기가 어려워 데이터에 반영되지 않는 중요한 위험 항목도 존재한다. 이러한 한계를 보완하기 위해, 현장의 애플리케이션 보안 및 개발 실무자들을 대상으로 커뮤니티 설문을 진행하여, 테스트 데이터에서 충분히 드러나지 않지만 실제로 직면하고 있는 핵심 위험을 파악한다. + +## 카테고리 구성 방식 + +이번 OWASP Top 10에서는 이전 버전과 비교하여 일부 카테고리가 변경되었다. 아래는 주요 변경 사항에 대한 요약이다. + +이번 2025년 버전에서는 2021년 버전과 마찬가지로 CWE 범위를 제한하지 않고 자료를 수집하였다. 2021년부터 매년 테스트 된 애플리케이션 수와 테스트 결과 하나 이상의 CWE가 발견된 애플리케이션 수를 기준으로 집계하였다. 이러한 방식은 각 CWE가 전체 애플리케이션에 얼마나 널리 분포하는지 파악할 수 있게 한다. 또한 CWE의 발생 빈도를 분석에서 제외하였다. 빈도 정보는 다른 상황에서는 유의미할 수 있으나, 전체 애플리케이션에 분포한 정도를 왜곡할 수 있기 때문이다. 따라서, 한 애플리케이션에서 CWE가 4건 발견되든 4,000건 발견되든 순위 산정에 영향을 주지 않는다. 이는 수동으로 테스트하는 사람은 반복 취약점을 한 번만 기록하는 반면, 자동화 도구는 모든 취약점을 개별 취약점으로 기록하기 때문이다. 분석 대상 CWE 수는 2017년 약 30개, 2021년 약 400개에서 이번 버전에서는 589개로 크게 확대되었다. 향후 추가 분석을 통해 보완할 계획이며, 이러한 데이터 규모 증가는 카테고리 구조의 변경을 불가피하게 만들었다. + +CWE를 그룹화하고 분류하는 작업에는 수개월이 소요되었으며, 추가로 몇 개월을 더 투입할 수도 있었으나 적절한 시점에서 마무리하였다. CWE에는 근본 원인(root cause) 유형과 증상(symptom) 유형이 있다. 근본 원인 유형에는 "암호 실패", "설정 오류" 등이 있고, 증상 유형에는 "민감한 정보 노출", "서비스 거부" 등이 있다. 식별 및 개선 지침을 제공하는 데 있어 근본 원인에 초점을 맞추는 것이 더 논리적이므로 가능한 한 이를 우선시하였다. 증상보다 근본 원인에 집중하는 것은 새로운 개념이 아니며, 기존 Top 10도 증상과 근본 원인이 혼재되어 있었다. CWE 역시도 마찬가지로 혼재되어 있으며, 이번에는 이를 보다 명확하게 구분하고자 하였다. 이번 버전에서 카테고리당 평균 CWE 수는 25개이며, 최소 5개(A03:2025-소프트웨어 공급망 실패, A09:2025-보안 로깅 및 알림 실패)에서 최대 40개(A01:2025-불충분한 접근 제어)까지 분포한다. 카테고리당 CWE 수는 40개를 상한으로 설정하였다. 이러한 카테고리 구조 개편을 통해 기업들이 사용하는 언어나 프레임워크에 적합한 CWE에 집중할 수 있어 교육 효과가 향상될 것으로 기대된다. + +MITRE가 선정한 가장 위험한 소프트웨어 취약점 25개와 유사하게 단순히 10개의 CWE 목록으로 전환하는 것이 어떠냐는 질문을 받은 바 있다. 카테고리 내에 여러 CWE를 포함하는 데는 두 가지 주된 이유가 있다. 첫째, 모든 프로그래밍 언어 및 프레임워크에 따라 해당 CWE가 존재하지 않을 수 있다. Top 10의 일부가 적용되지 않으면 도구나 교육/인식 개선 프로그램 측면에서 공백이 생길 수 있다. 둘째, 일반적인 취약점에 대해 여러 CWE가 존재한다. 예를 들어, 일반적인 인젝션, 커맨드 인젝션, 크로스 사이트 스크립팅, 하드코딩된 패스워드, 검증 부재, 버퍼 오버플로우, 민감 정보의 평문 저장 등에 대해 각각 여러 CWE가 있다. 조직이나 테스터에 따라 서로 다른 CWE를 사용할 수 있다. 여러 CWE를 포함하는 카테고리를 사용함으로써 공통된 카테고리명 하에 발생할 수 있는 다양한 유형의 취약점에 대한 기준선과 인식을 높일 수 있다. 이번 Top 10 2025에는 10개 카테고리 내에 248개의 CWE가 포함되어 있다. 본 문서 발행 시점 기준으로 [MITRE에서 제공하는 CWE 사전](https://cwe.mitre.org)에는 총 968개의 CWE가 등록되어 있다. + + +## 카테고리 선정을 위한 데이터 사용법 + +2021년 버전과 마찬가지로 *악용 가능성* 및 *(기술적) 영향*에 대해 CVE 데이터를 활용하였다. OWASP Dependency Check를 다운로드하여 CVSS 익스플로잇 및 영향 점수를 추출하고, CVE에 연결된 관련 CWE별로 그룹화하였다. 모든 CVE에 CVSSv2 점수가 포함되어 있으나 CVSSv2에는 CVSSv3에서 해결된 결함이 있어 상당한 연구와 노력이 필요하였다. 특정 시점 이후의 모든 CVE에는 CVSSv3 점수도 함께 부여된다. 또한 CVSSv2와 CVSSv3 사이에 점수 범위와 산정 공식이 변경되었다. + +CVSSv2에서는 익스플로잇과 (기술적) 영향 점수 모두 최대 10.0까지 가능했으나, 산정 공식에 의해 익스플로잇 점수는 60%, 영향 점수는 40%로 낮춰졌다. CVSSv3에서는 이론상 최대값이 익스플로잇 점수 6.0, 영향 점수 4.0으로 제한되었다. 이러한 가중치를 고려하면, CVSSv3에서 영향 점수는 더 높아져 평균적으로 거의 1.5점 상승했고, 2021 Top 10 분석을 수행했을 때 악용 가능성은 평균적으로 거의 0.5점 하락한 것으로 나타났다. + +OWASP Dependency Check에서 추출한 미국 정부가 운영하는 취약점 데이터베이스(National Vulnerability Database) 데이터에는 CWE에 매핑된 CVE 기록이 약 175,000건(2021년 125,000건에서 증가) 존재한다. 또한 CVE에 매핑된 고유 CWE는 643개(2021년 241개에서 증가)이다. 추출된 약 220,000건의 CVE 중 160,000건은 CVSS v2 점수를, 156,000건은 CVSS v3 점수를, 6,000건은 CVSS v4 점수를 보유하고 있다. 다수의 CVE가 복수의 점수를 보유하고 있어 합계가 220,000건을 초과한다. + +Top 10 2025에서는 다음과 같은 방식으로 평균 익스플로잇 및 영향 점수를 산정하였다. CVSS 점수가 있는 모든 CVE를 CWE별로 그룹화하고, CVSSv3 점수를 보유한 비율과 CVSSv2 점수를 보유한 나머지 비율에 따라 익스플로잇 및 영향 점수에 가중치를 부여하여 전체 평균을 산출하였다. 이 평균값을 데이터셋의 CWE에 매핑하여 위험 산정 공식의 나머지 절반인 익스플로잇 및 (기술적) 영향 점수로 활용하였다. + +CVSS v4.0을 사용하지 않은 이유가 궁금할 수 있다. 이는 점수 산정 알고리즘이 근본적으로 변경되어 CVSS v2 및 v3처럼 *익스플로잇* 또는 *영향* 점수를 쉽게 도출할 수 없기 때문이다. 향후 Top 10 버전에서는 CVSS v4.0 점수 활용 방안을 모색할 계획이나, 2025년 버전에서는 적절한 시점에 적용할 수 있는 방법을 찾지 못하였다. + + +## 커뮤니티 설문 조사를 사용하는 이유 + +조사된 데이터는 주로 업계에서 자동화된 방식으로 테스트할 수 있는 범위에 한정되어 있다. 경험 많은 애플리케이션 보안 전문가들과 대화해 보면 아직 데이터에 반영되지 않은 취약점 유형과 트렌드가 존재함을 알 수 있다. 특정 취약점 유형에 대한 테스트 방법론을 개발하는 데 시간이 소요되며, 이러한 테스트를 자동화하여 대규모 애플리케이션에 적용하는 데는 더 많은 시간이 필요하다. 현재 확인할 수 있는 모든 것은 과거를 돌아보는 것이며, 그 과정에서 지난해의 트렌드가 충분히 반영되지 않았을 가능성이 있다. + +따라서 데이터가 불완전하기 때문에 10개 카테고리 중 8개만 데이터에서 선정한다. 나머지 2개 카테고리는 Top 10 커뮤니티 설문조사에서 도출되었다. 이를 통해 현장 실무자들이 데이터에 포함되지 않거나 데이터로 표현되기 어려운 주요 위험에 대해 직접 투표할 수 있도록 하였다. + + +## 데이터 제공자들께 드리는 감사의 글 + +다음 조직들은 익명 기부자 다수와 함께 280만 건 이상의 애플리케이션 데이터를 제공하여 역대 가장 방대하고 포괄적인 애플리케이션 보안 데이터 세트 구축에 기여하였다. 이들의 도움 없이는 불가능한 작업이었다. + +* Accenture (Prague) +* Anonymous (multiple) +* Bugcrowd +* Contrast Security +* CryptoNet Labs +* Intuitor SoftTech Services +* Orca Security +* Probely +* Semgrep +* Sonar +* usd AG +* Veracode +* Wallarm + +## 주요 저자 +* Andrew van der Stock - X: [@vanderaj](https://x.com/vanderaj) +* Brian Glas - X: [@infosecdad](https://x.com/infosecdad) +* Neil Smithline - X: [@appsecneil](https://x.com/appsecneil) +* Tanya Janca - X: [@shehackspurple](https://x.com/shehackspurple) +* Torsten Gigler - Mastodon: [@torsten_gigler@infosec.exchange](https://infosec.exchange/@torsten_gigler) + +## 이슈 및 풀 리퀘스트 제출 + +수정 사항이나 이슈는 아래의 링크에 언제든지 제출할 수 있다. + +### 프로젝트 링크 +* [홈페이지](https://owasp.org/www-project-top-ten/) +* [GitHub 저장소](https://github.com/OWASP/Top10) + + diff --git a/2025/docs/ko/0x01_2025-About_OWASP.md b/2025/docs/ko/0x01_2025-About_OWASP.md new file mode 100644 index 000000000..e1ee54e25 --- /dev/null +++ b/2025/docs/ko/0x01_2025-About_OWASP.md @@ -0,0 +1,35 @@ +# OWASP 소개 + +오픈 월드와이드 애플리케이션 보안 프로젝트(Open Worldwide Application Security Project, OWASP)는 각 조직이 신뢰할 수 있는 애플리케이션과 API를 개발, 도입, 유지할 수 있도록 지원하는 오픈 커뮤니티이다. + +OWASP에서는 아래와 같은 무료로 공개된 자료를 제공하고 있다. + +- 애플리케이션 보안 도구 및 표준 +- 최첨단 연구 +- 표준 보안 통제 항목 및 라이브러리 +- 애플리케이션 보안 테스팅, 시큐어 코딩, 코드 보안 리뷰에 관한 서적 +- 프레젠테이션 및 [동영상](https://www.youtube.com/user/OWASPGLOBAL) +- 다양한 주제의 보안 [치트 시트](https://cheatsheetseries.owasp.org/) +- 전 세계 및 온라인에서 개최되는 [챕터 모임](https://owasp.org/chapters/) +- [이벤트, 교육 및 컨퍼런스](https://owasp.org/events/) +- [Google Groups](https://groups.google.com/g/owasp) + +자세한 내용은 [https://owasp.org](https://owasp.org)에서 확인할 수 있다. + +OWASP의 모든 도구, 문서, 동영상, 프레젠테이션을 애플리케이션 보안 개선에 관심이 있는 누구나 자유롭게 이용하고 공유할 수 있도록 공개하고 있다. 각 지역 챕터의 생성 및 참여도 자유롭게 가능하다. + +OWASP는 애플리케이션 보안을 사람, 프로세스, 기술의 문제로 접근해야 한다고 믿는다. 이러한 모든 영역을 개선하는 것이 애플리케이션 보안에 대한 가장 효과적인 접근 방식이기 때문이다. + +OWASP는 일반적인 조직과는 다른 성격을 지닌다. 상업적 이해관계에서 자유롭기 때문에 편향되지 않고 실용적이며 비용 효율적인 애플리케이션 보안 정보를 제공할 수 있다. + +OWASP는 특정 기술 기업과 제휴하지 않지만, 상용 보안 기술의 올바른 활용을 지지한다. OWASP는 다양한 유형의 자료를, 협력을 통해 투명하며 개방적인 방식으로 제작한다. + +OWASP 재단은 프로젝트의 지속적인 발전을 뒷받침하는 비영리 단체다. OWASP에는 이사회부터 지부 리더, 프로젝트 구성원까지 대부분이 자원봉사자로 참여하고 있으며, 기존의 틀을 깨는 보안 연구를 후원하고 필요한 인프라를 제공한다. + +저희와 함께해요! + +## 저작권 및 라이선스 + +![License](../assets/license.png) + +Copyright © 2003-2025 The OWASP® Foundation, Inc. 이 문서는 Creative Commons Attribution-ShareAlike 4.0 라이선스에 따라 배포된다. 이 자료를 재사용하거나 배포할 경우, 반드시 해당 저작물의 라이선스 조건을 명확히 밝혀야 한다. diff --git a/2025/docs/ko/0x02_2025-What_are_Application_Security_Risks.md b/2025/docs/ko/0x02_2025-What_are_Application_Security_Risks.md new file mode 100644 index 000000000..df16bc6a1 --- /dev/null +++ b/2025/docs/ko/0x02_2025-What_are_Application_Security_Risks.md @@ -0,0 +1,100 @@ +# 애플리케이션 보안 위험이란 무엇인가? +공격자는 애플리케이션을 통해 다양한 경로로 비즈니스 또는 조직에 피해를 입힐 수 있다. 각 경로는 잠재적 위험을 수반하며, 이를 조사해야 한다. + +![Calculation diagram](../ko/assets/2025-algorithm-diagram-ko.png) + + + + + + + + + + + + + + + + + + +
+ 위협 행위자 + + 공격 벡터 + + 악용 가능성 + + 보안 통제 미비 가능성 + + 기술적 영향 + + 비즈니스 영향 +
+ 환경에 따라, 상황에 따라 동적으로 변화 + + 애플리케이션 노출 수준에 따라(환경 기준) + + 평균 가중 익스플로잇 점수 + + 통제 누락을 평균 발생률로 산정하고 커버리지로 가중 + + 평균 가중 영향 점수 + + 비즈니스 기준 +
+ + +본 위험 등급은 악용 가능성, 보안 통제가 누락될 가능성의 평균, 그리고 기술적 영향을 공통 평가 요소로 반영하여 산정되었다. + +조직은 각기 고유하며, 해당 조직을 대상으로 하는 위협 행위자, 그들의 목표, 그리고 침해 발생 시 영향도 또한 고유하다. 공익 단체가 대외 정보 제공을 위해 콘텐츠 관리 시스템(Content Management System, CMS)을 사용하는 경우와, 의료 시스템에서 동일한 CMS를 민감한 의료 정보에 사용하는 경우를 비교하면, 같은 소프트웨어라 하더라도 위협 행위자와 비즈니스 영향은 크게 달라질 수 있다. 애플리케이션의 노출 수준, 상황별 위협 행위자(비즈니스 및 지역에 따른 표적 공격과 비표적 공격), 그리고 개별 비즈니스 영향을 바탕으로 조직의 위험을 이해하는 것이 중요하다. + + +## 카테고리를 선택하고 순위를 매기기 위해 데이터가 사용되는 방식 + +2017년에는 발생률을 기준으로 가능성을 산정하여 카테고리를 선정한 뒤, 수십 년의 경험을 바탕으로 한 팀 논의를 통해 악용 가능성, 탐지 가능성, 기술적 영향을 기준으로 순위를 매겼다. 2021년에는 미국 정부가 운영하는 취약점 데이터베이스(National Vulnerability Database, NVD)의 CVSSv2 및 CVSSv3 점수에서 악용 가능성과 (기술적) 영향을 나타내는 데이터를 활용하였다. 2025년에는 2021년에 수립한 동일한 방법론을 계속 적용하였다. + +우리는 OWASP Dependency-Check를 다운로드하여 관련 CWE(Common Weakness Enumeration)별로 그룹화된 CVSS 익스플로잇 점수와 영향 점수를 추출하였다. 모든 CVE에는 CVSSv2 점수가 존재하지만, CVSSv2에는 결함이 있으며 CVSSv3에서 이를 보완하였으나 상당한 조사와 노력이 필요했다. 또한 일정 시점 이후에는 모든 CVE에 CVSSv3 점수도 함께 부여된다. 더불어 CVSSv2와 CVSSv3 사이에는 점수 범위와 산정 공식이 업데이트되었다. + +CVSSv2에서는 익스플로잇과 (기술적) 영향 점수 모두 최대 10.0까지 가능했으나, 산정 공식에 의해 익스플로잇 점수는 60%, 영향 점수는 40%로 낮춰졌다. CVSSv3에서는 이론상 최대값이 익스플로잇 점수 6.0, 영향 점수 4.0으로 제한되었다. 이러한 가중치를 고려하면, CVSSv3에서 영향 점수는 더 높아져 평균적으로 거의 1.5점 상승했고, 2021 Top 10 분석을 수행했을 때 악용 가능성은 평균적으로 거의 0.5점 하락한 것으로 나타났다. + +OWASP Dependency-Check에서 추출한 데이터에 따르면, NVD에는 CWE에 매핑된 CVE 레코드가 약 17만 5천 건(2021년의 12만 5천 건에서 증가) 존재한다. 또한 CVE에 매핑된 고유 CWE는 643개(2021년의 241개에서 증가)이다. 추출된 약 22만 건의 CVE 중 16만 건에는 CVSS v2 점수가, 15만 6천 건에는 CVSS v3 점수가, 6천 건에는 CVSS v4 점수가 있었다. 다수의 CVE가 여러 버전의 점수를 동시에 보유하므로, 점수 건수 합계는 22만 건을 초과한다. + +Top 10 2025에서는 다음과 같은 방식으로 익스플로잇과 영향의 평균 점수를 산정하였다. CVSS 점수가 있는 모든 CVE를 CWE별로 그룹화한 뒤, 익스플로잇 점수와 영향 점수 모두에 대해 CVSSv3 점수를 보유한 비율과 나머지 CVSSv2 점수 보유 비율을 가중치로 적용하여 전체 평균을 산출하였다. 이렇게 산출한 평균을 데이터셋의 CWE에 매핑하여, 위험 방정식의 나머지 절반에 해당하는 익스플로잇 및 기술적 영향 점수로 사용하였다. + +CVSS v4.0을 사용하지 않은 이유는 점수 산정 알고리즘이 근본적으로 변경되어, CVSSv2와 CVSSv3처럼 *익스플로잇* 또는 *영향* 점수를 쉽게 도출할 수 없기 때문이다. 향후 Top 10 버전에서는 CVSS v4.0 점수를 활용할 수 있는 방법을 모색할 예정이지만, 2025년판에서는 이를 적시에 반영할 방안을 도출하지 못했다. + +발생률은 일정 기간 동안 조직이 테스트한 애플리케이션 모집단에서, 각 CWE에 취약한 애플리케이션의 비율로 산정하였다. 다시 말해, 우리는 빈도, 즉 한 애플리케이션에서 문제가 몇 번 발견되는지는 사용하지 않는다. 관심 대상은 애플리케이션 모집단 중 각 CWE가 발견된 애플리케이션의 비율이다. + +커버리지는 특정 CWE에 대해 모든 조직이 테스트한 애플리케이션의 비율로 산정한다. 커버리지가 높을수록 표본 크기가 모집단을 더 잘 대표하므로, 산정된 발생률이 정확하다는 보증 수준이 더 강해진다. + +이번 버전에서 사용한 공식은 2021년과 유사하되, 일부 가중치가 변경되었다. +(최대 발생률 % * 1000) + (최대 커버리지 % * 100) + (평균 익스플로잇 점수 * 10) + (평균 영향 점수 * 20) + (발생 건수 합 / 10000) = 위험 점수 + +산정된 점수는 불충분한 접근 제어 카테고리에서 621.60으로 가장 높았고, 메모리 관리 실패 카테고리에서 271.08로 가장 낮았다. + +이는 완벽한 체계는 아니지만, 위험 카테고리의 순위를 매기는 데 유용하다. + +추가로 커지고 있는 과제 중 하나는 "애플리케이션"의 정의이다. 업계가 마이크로서비스와 같이 전통적인 애플리케이션보다 더 작은 구성 요소로 이루어진 아키텍처로 전환함에 따라, 산정이 더 어려워지고 있다. 예를 들어 조직이 코드 리포지토리를 테스트하는 경우, 무엇을 애플리케이션으로 간주해야 하는가? CVSSv4의 확산과 마찬가지로, Top 10의 다음 판에서는 끊임없이 변화하는 산업 환경을 반영하기 위해 분석과 점수 산정을 조정해야 할 수 있다. + +## 데이터 요소 + +Top 10 각 카테고리에는 다음과 같은 데이터 요소가 제시되며, 의미는 다음과 같다. + +**해당 CWE 개수:** Top 10 팀이 해당 카테고리에 매핑한 CWE의 개수. + +**발생률:** 발생률은 해당 연도에 그 조직이 테스트한 모집단에서, 해당 CWE에 취약한 애플리케이션의 비율이다. + +**가중 익스플로잇 점수:** CWE에 매핑된 CVE에 부여된 CVSSv2 및 CVSSv3 점수의 익스플로잇 하위 점수를 정규화하여 10점 척도에 맞춘 값이다. + +**가중 영향 점수:** CWE에 매핑된 CVE에 부여된 CVSSv2 및 CVSSv3 점수의 영향 하위 점수를 정규화하여 10점 척도에 맞춘 값이다. + +**테스트 커버리지:** 특정 CWE에 대해 모든 조직이 테스트한 애플리케이션의 비율이다. + +**총 발생 건수:** 카테고리에 매핑된 CWE가 발견된 애플리케이션의 총 개수. + +**총 CVE 건수:** 해당 카테고리에 매핑된 CWE에 매핑된 NVD DB 내 CVE의 총 개수. + +**공식:** (최대 발생률 % * 1000) + (최대 커버리지 % * 100) + (평균 익스플로잇 점수 * 10) + (평균 영향 점수 * 20) + (발생 건수 합 / 10000) = 위험 점수 diff --git a/2025/docs/ko/0x03_2025-Establishing_a_Modern_Application_Security_Program.md b/2025/docs/ko/0x03_2025-Establishing_a_Modern_Application_Security_Program.md new file mode 100644 index 000000000..894d4df01 --- /dev/null +++ b/2025/docs/ko/0x03_2025-Establishing_a_Modern_Application_Security_Program.md @@ -0,0 +1,301 @@ +# 현대적 애플리케이션 보안 체계 수립 + +OWASP Top 10 항목들은 보안 인식을 제고하기 위한 문서로, 각 항목에서 다루는 중요한 위험의 인식을 높이기 위함이다. 이는 모든 위험을 빠짐없이 다룬 목록이 아니라, 대응을 시작하기 위한 출발점으로 활용하도록 구성되어 있다. 따라서, 이전 버전에서부터 각 항목에 해당하는 위험을 예방하고 더 나아가 전반적인 보안 수준을 높이기 위한 최선의 방법으로 애플리케이션 보안 체계를 시작하는 것을 권고해 왔다. 이 페이지에서는 현대적 애플리케이션 보안 체계 수립을 어떻게 시작하고 구축하는지를 다룬다. + + + +이미 애플리케이션 보안 체계를 운영 중이라면, [OWASP 소프트웨어 보증 성숙도 모델(Software Assurance Maturity Model, SAMM)](https://owasp.org/www-project-samm/) 또는 DSOMM(DevSecOps Maturity Model) 같은 성숙도 모델을 활용하여 현재 수준에 대한 성숙도 평가를 수행하는 것을 고려한다. 해당 모델들은 포괄적이며 세부 항목까지 빠짐없이 다루고 있어, 체계를 고도화하는 과정에서 어디에 집중해야 하는지 파악하는 데 활용할 수 있다. OWASP SAMM 및 DSOMM의 모든 항목을 수행해야 좋은 보안 체계라고 할 수 있는 것은 아니며, 이는 방향을 제시하고 다양한 선택지를 제공하기 위한 것이다. 따라서 이는 현실적으로 달성하기 어려운 기준을 제시하거나 과도한 비용이 드는 체계를 수립하는 것이 목적이 아니라, 개선을 위한 다양한 아이디어를 제공하기 위해 폭넓게 구성되어 있다. + + + +애플리케이션 보안 체계를 처음 구축하는 단계이거나, 현재 팀의 상황에서 OWASP SAMM 또는 DSOMM가 과도하다고 느껴진다면, 아래 내용을 참고한다. + + +### 1. 위험 기반 포트폴리오 관리 체계 수립 + +* 비즈니스 관점에서 가지고 있는 애플리케이션의 포트폴리오에서 보안 요구사항을 식별한다. 이때 보호하고자 하는 데이터 자산에 적용되는 개인정보보호 법령 및 관련 규제를 주요 기준으로 삼아 요구사항을 도출한다. + +* 조직의 위험 수용 수준에 맞춰, 가능성과 영향도 기준을 표준화한 [통합 위험 평가 모델](https://owasp.org/www-community/OWASP_Risk_Rating_Methodology)을 수립한다. + +* 위에서 정의된 모델에 따라 전체 애플리케이션 및 API의 위험을 평가하고 우선순위를 결정한 뒤, 결과를 구성 관리 데이터베이스(Configuration Management Database, CMDB)에 등록한다. + +* 적용 범위와 요구되는 엄격도 수준을 정의하기 위한 가이드라인을 수립한다. + + +### 2. 탄탄한 기반을 통한 실행 체계 확보 + +* 모든 개발 조직이 준수할 애플리케이션 보안 최소 기준을 위한 정책 및 표준을 수립한다. + +* 수립한 정책 및 표준을 따를 수 있도록 재사용 가능한 공통 보안 통제를 정의하고 설계 및 개발 지침을 함께 제공한다. + +* 개발자의 역할과 주제에 맞춘 필수 애플리케이션 보안 교육 체계를 마련한다. + + +### 3. 기존 프로세스에 보안 내재화 + +* 기존 개발 및 운영 프로세스에 안전한 구현 및 검증 활동을 정의하고 내재화한다. + +* 구현 및 검증 활동에는 위협 모델링, 안전한 설계 및 설계 검토, 시큐어 코딩 및 코드 리뷰, 침투 테스트, 그리고 취약점 조치가 포함된다. + +* 개발 및 프로젝트 팀이 각 활동을 성공적으로 수행할 수 있도록 주제별 분야 전문가와 지원 서비스를 제공한다. + +* 현행 시스템 개발 생명 주기와 모든 소프트웨어 보안 활동, 도구, 정책, 프로세스를 검토한 후 이를 문서화한다. + +* 새로운 소프트웨어 개발 시에는 시스템 개발 생명 주기의 각 단계에 하나 이상의 보안 활동을 추가한다. 아래에서 수행 가능한 다양한 활동을 제시한다. 제시된 활동을 수행하여 모든 새로운 프로젝트 또는 소프트웨어에 조직의 요구 사항에 부합하는 보안 수준이 제공되도록 한다. + +* 최종 산출물이 조직의 수용 가능한 위험 수준을 만족하도록 활동을 선정한다. + +* 기존(때로는 레거시라고 함)의 소프트웨어의 경우 체계적인 유지관리 계획을 수립한다. 안전한 애플리케이션을 유지하는 방법은 아래의 '운영 및 변경 관리' 섹션을 참고한다. + + +### 4. 애플리케이션 보안 교육 + +* 개발 조직의 보안 역량 강화를 위해 보안 챔피언(Security Champion) 제도 또는 개발자 대상 보안 교육 프로그램(보안 인식 프로그램이라고 부르기도 함)을 도입하는 방안을 검토한다. 이를 통해 개발자에게 필요한 지식을 교육할 수 있다. 최신 보안 지식을 지속적으로 습득하며, 업무를 안전하게 수행할 수 있도록 지원하고, 보안 문화를 더욱 긍정적으로 만든다. 또한, 보안팀과의 신뢰를 높이고 더 만족스러운 협업 관계를 형성할 수 있다. 관련 가이드는 [OWASP 보안 챔피언 가이드](https://securitychampions.owasp.org/)를 참고하며, 해당 가이드는 단계적으로 보강되고 있다. + +* OWASP 교육 프로젝트는 개발자에게 웹 애플리케이션 보안을 교육하는 데 필요한 교육 자료를 제공한다. 취약점에 대한 실습 중심 학습을 위해 [OWASP Juice Shop 프로젝트](https://owasp.org/www-project-juice-shop/) 또는 [OWASP WebGoat](https://owasp.org/www-project-webgoat/)를 활용한다. 최신 동향을 유지하기 위해 [OWASP AppSec 컨퍼런스](https://owasp.org/events/), [OWASP 컨퍼런스 트레이닝](https://owasp.org/events/), 또는 지역 [OWASP Chapter](https://owasp.org/chapters/) 모임에 참여한다. + + +### 5. 운영 가시성 확보 + +* 지표를 기반으로 관리한다. 수집된 지표 및 분석 데이터를 기반으로 개선 활동과 예산 의사결정을 추진한다. 지표로는 보안 관행 및 활동 준수, 신규 취약점 유입, 취약점 조치, 테스트 된 애플리케이션 범위, 결함 유형별 밀도 및 발생 건수 등이 있다. + +* 구현 및 검증 활동에서 축적된 데이터를 분석하여, 근본 원인과 취약점 패턴을 식별하고, 전사 차원의 전략 및 시스템적 개선을 추진한다. 실수로부터 학습하고, 개선을 촉진하기 위해 긍정적 인센티브를 제공한다. + + +## 반복 가능한 보안 프로세스 및 표준 보안 통제 수립 및 적용 + +### 요구사항 및 리소스 관리 단계 + +* 비즈니스 부서와 함께 애플리케이션의 비즈니스 요구사항을 수집하고 조율한다. 이 요구사항은 모든 데이터 자산에 대한 기밀성, 인증성, 무결성, 가용성 관점의 보호 요구사항과, 기대되는 비즈니스 로직이 포함된다. + +* 기능/비기능적 보안 요구사항을 포함하여 기술 요구사항을 취합한다. OWASP는 애플리케이션의 보안 요구사항을 설정하기 위한 가이드로 [OWASP 애플리케이션 보안 검증 표준(Application Security Verification Standard, ASVS)](https://owasp.org/www-project-application-security-verification-standard/) 활용을 권고한다. + +* 보안 활동을 포함하여 설계, 구축, 테스트, 운영의 모든 측면을 포괄하는 예산을 계획하고 조율한다. + +* 프로젝트 일정에 보안 활동을 명시적으로 편성한다. + +* 프로젝트 킥오프에서 프로젝트의 보안 담당을 소개하여, 관련자가 누구와 소통해야 하는지 알 수 있도록 한다. + +### 제안요청서(RFP) 및 계약 단계 + +* 내외부 개발자와 요구사항을 사전에 합의하며, 조직의 보안 체계(예: SDLC 적용, 보안 모범사례 준수)에 부합하는 가이드라인 및 보안 요구사항을 포함한다. + +* 기획 및 설계 단계를 포함하여, 모든 기술 요구사항의 충족 여부를 평가한다. + +* 설계, 보안, 서비스 수준 계약(SLA)을 포함하여 모든 기술 요구사항을 협의한다. + +* [OWASP 보안 소프트웨어 계약 부록](https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex)과 같은 템플릿 및 체크리스트를 적용한다. +
**참고:** *해당 문서는 미국 계약법을 전제로 하므로, 해당 문서를 사용하기 전에 자격을 갖춘 법률 전문가의 자문을 구한다.* + + +### 기획 및 설계 단계 + +* 개발자 및 내부 이해관계자(예: 보안 전문가)와 기획 및 설계를 협의한다. + +* 보호 요구사항과 예상 위협 수준에 적합한 보안 아키텍처, 통제, 대책 및 설계 검토를 정의한다. 이는 보안 전문가의 지원을 받아야 한다. + +* 애플리케이션 및 API가 개발된 이후에 보안을 추가하는 것보다, 시작 단계부터 보안을 설계에 포함하는 것이 비용 효율성이 훨씬 높다. 보안을 초기부터 내재화하는 출발점으로 [OWASP 치트 시트](https://cheatsheetseries.owasp.org/index.html) 및 [OWASP 사전 예방 통제](https://top10proactive.owasp.org/) 사용을 권고한다. + +* 위협 모델링(threat modelling)을 수행한다. 자세한 사항은 [OWASP 치트 시트: 위협 모델링](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html)을 참고한다. + +* 소프트웨어 아키텍트에게 안전한 설계 개념과 패턴을 교육하고, 가능할 경우 설계에 이를 반영하도록 요청한다. + +* 개발자와 함께 데이터 흐름(data flow)을 검토한다. + +* 기존 사용자 스토리에 보안 사용자 스토리를 추가한다. + + +### 안전한 개발 생명 주기 + +* 조직이 애플리케이션 및 API를 구축할 때 따르는 프로세스를 개선하기 위해, [OWASP 소프트웨어 보증 성숙도 모델(SAMM)](https://owasp.org/www-project-samm/)을 권장한다. 이 모델은 조직이 직면한 특정 위험에 맞춘 소프트웨어 보안 전략을 수립하고 구현하는 데 도움이 된다. + +* 소프트웨어 개발자에게 시큐어 코딩 교육을 제공하고, 보다 견고하고 안전한 애플리케이션을 만드는 데 도움이 되는 기타 교육도 제공한다. + +* 코드 리뷰를 수행한다. [OWASP 치트 시트: 시큐어 코드 리뷰](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html)를 참고한다. + +* 개발자에게 보안 도구를 제공하고 사용 방법을 교육한다. 특히 정적 분석, 소프트웨어 구성 분석(software composition analysis, SCA), 시크릿 및 [코드형 인프라(Infrastructure-as-Code, IaC)](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) 스캐너 도구를 포함한다. + +* 개발자가 보안상 안전한 선택을 기본으로 하도록, 가드레일을 적용한다. + +* 강력하면서도 사용 가능한 보안 통제를 구축하는 것은 어렵다. 가능한 경우 안전한 기본값을 제공하고, 가능한 경우 '포장된 도로(가장 쉽고 선호되는 방법이 동시에 가장 안전한 방법이 되도록 하는 것)'를 만든다. [OWASP 치트 시트](https://cheatsheetseries.owasp.org/index.html)는 개발자에게 좋은 출발점이며, 많은 현대적 프레임워크는 인가, 검증, 교차 사이트 요청 위조(CSRF) 방지 등과 관련한 표준적이고 효과적인 보안 통제를 제공한다. + +* 개발자에게 보안 관련 IDE 플러그인을 제공하고 사용을 권장한다. + +* 시크릿 관리 도구, 라이선스, 그리고 사용 방법에 대한 문서를 제공한다. + +* 개발자가 사용할 수 있는 프라이빗 AI를 제공한다. 이상적으로는 유용한 보안 문서로 채워진 RAG 서버, 더 나은 결과를 위해 팀이 작성한 프롬프트, 그리고 조직에서 선택한 보안 도구를 호출하는 MCP 서버로 구성되도록 설정한다. 또한 개발자에게 AI를 안전하게 사용하는 방법을 교육한다. 개발자는 보안팀의 선호도와 무관하게 AI를 사용할 것이기 때문이다. + +### 지속적 애플리케이션 보안 테스트 체계 구축 + +* 애플리케이션의 기술적 기능과 IT 아키텍처와의 연동을 테스트하고, 비즈니스 테스트와 문제가 없도록 조율한다. + +* 기술 및 비즈니스 관점에서 "정상 사용" 및 "악용" 테스트 케이스를 생성한다. + +* 내부 프로세스, 보호 요구 사항 및 애플리케이션의 예상 위협 수준에 따라 보안 테스트를 관리한다. + +* 개발팀이 사용할 보안 테스트 도구(퍼저, 동적 애플리케이션 보안 테스트 등)와 안전한 테스트 환경, 사용 교육을 제공한다. 또는 개발팀을 대신해 테스트를 수행하거나 테스터를 투입한다. + +* 높은 수준의 보증(assurance)이 필요한 경우, 공식 침투 테스트와 함께 스트레스 테스트 및 성능 테스트를 고려한다. + +* 개발자와 협업하여 버그 리포트에서 어떤 내용을 수정해야 하는지 가이드하고, 그들의 관리자와 협의해 수정 시간을 일정에 확보할 수 있도록 한다. + + +### 배포 + +* 애플리케이션을 운영 환경에 배포하고, 필요 시 기존 시스템에서 신규 시스템으로 마이그레이션을 수행한다. + +* 구성 관리 데이터베이스와 보안 아키텍처를 포함한 모든 문서를 최종 확정한다. + + +### 운영 및 변경 관리 + +* 운영 시 애플리케이션의 보안 관리를 위한 가이드라인(예: 패치 관리)이 포함되어야 한다. + +* 사용자의 보안 인식을 제고하고, 사용성과 보안성 간의 상충을 관리한다. + +* 변경을 계획하고 관리한다. 예를 들어 애플리케이션의 신규 버전 또는 OS, 미들웨어, 라이브러리와 같은 기타 구성 요소로의 버전 업데이트를 포함한다. + +* 모든 애플리케이션이 인벤토리에 등록되어 있으며, 모든 중요 세부 사항이 문서화되어 있음을 보장한다. 구성 관리 데이터베이스 및 보안 아키텍처, 통제 항목, 대응 방안, 런북(runbook) 또는 프로젝트 문서를 포함한 모든 문서를 최신 상태로 유지한다. + +* 모든 애플리케이션에 대해 로깅, 모니터링, 알림을 수행한다. 누락된 경우 추가한다. + +* 효과적이고 효율적인 업데이트 및 패치를 위한 프로세스를 수립한다. + +* 정기 스캐닝 일정(가능하면 동적, 정적, 시크릿, IaC, 소프트웨어 구성 분석)을 수립한다. + +* 보안 버그 수정에 대한 SLA를 수립한다. + +* 임직원(가능하면 고객도 포함)이 버그를 신고할 수 있는 방법을 제공한다. + +* 소프트웨어 공격과 옵저버빌리티(observability) 도구를 이해하는, 훈련된 침해사고 대응팀을 구성한다. + +* 자동화 공격을 차단하기 위한 차단 또는 방어 도구를 운영한다. + +* 설정에 대한 연 1회(또는 그 이상) 하드닝을 수행한다. + +* 애플리케이션에 요구되는 보증 수준에 따라, 최소 연 1회 침투 테스트를 수행한다. + +* 소프트웨어 공급망을 하드닝하고 보호하기 위한 프로세스 및 도구를 수립한다. + +* 비즈니스 연속성 계획(BCP) 및 재해복구(DR) 계획을 수립하고 정기적으로 갱신한다. 해당 계획에는 핵심 애플리케이션과 이를 유지관리하는 데 사용하는 도구를 포함해야 한다. + +### 시스템 폐기 + +* 필요한 데이터는 아카이빙해야 한다. 그 외 모든 데이터는 완전 삭제해야 한다. + +* 미사용 계정, 역할, 권한 삭제를 포함하여 애플리케이션을 안전하게 폐기 처리한다. + +* 구성 관리 데이터베이스 애플리케이션 상태를 폐기 변경한다. + + +## OWASP Top 10의 표준 활용 가이드 + +OWASP Top 10은 주로 인식 제고 문서이다. 그러나 이는 2003년 처음 발표된 이후로 조직들이 이를 사실상(de facto) 업계 애플리케이션 보안 표준으로 사용해 온 상황을 막지 못했다. OWASP Top 10을 코딩 또는 테스트 표준으로 사용하려는 경우, 이것이 최소 수준의 베이스라인이며 단지 출발점에 불과하다는 점을 인지해야 한다. + +OWASP Top 10을 표준으로 쓰기 어려운 이유는, 각 항목이 애플리케이션 보안 위험을 문서화한 것이며, 쉽게 테스트 가능한 위험을 다루는 것은 아니라는 점이다. 예를 들어 [A06:2025 - 안전하지 않은 설계](A06_2025-Insecure_Design.md)는 대부분의 테스트 방식으로는 검증하기가 어렵다. 또 다른 예로, 로깅 및 모니터링이 실제로 적용되어 있고, 사용 중이며, 효과적으로 동작하는지 여부를 테스트하는 것은 인터뷰와 사고 대응 사례를 샘플링하는 방식으로만 가능하다. 정적 코드 분석 도구는 로깅 부재를 탐지할 수 있으나, 비즈니스 로직 또는 접근 통제가 위험한 보안 사고를 로깅하는지 여부를 판단하는 것은 불가능할 수 있다. 침투 테스트 역시 테스트 환경에서의 탐지/대응 확인에 그칠 수 있으며, 테스트 환경은 운영 환경과 동일한 수준이 아닌 경우가 많다. + +아래의 표는 OWASP Top 10을 표준으로 활용하기에 적절한 상황에 대한 권고사항이다. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
사용 사례 + OWASP Top 10 2025 + OWASP 애플리케이션 보안 검증 표준 +
인식 제고 + 예 + +
교육 + 입문 수준 + 포괄적인 +
설계와 아키텍처 + 드물게 + 예 +
코딩 표준 + 최소한 + 예 +
보안 코드 리뷰 + 최소한 + 예 +
피어 리뷰(peer review) 체크리스트 + 최소한 + 예 +
유닛 테스트 + 드물게 + 예 +
통합 테스트 + 드물게 + 예 +
침투 테스트 + 최소한 + 예 +
도구 지원 + 최소한 + 예 +
안전한 공급망 + 드물게 + 예 +
+ +애플리케이션 보안 표준을 채택하려는 경우, 요구사항을 검증(테스트) 가능하게 정의하도록 설계되었고 보안 안전한 개발 생명 주기(SDLC) 전 단계에 적용 가능한 [OWASP 애플리케이션 보안 검증 표준(ASVS)](https://owasp.org/www-project-application-security-verification-standard/)을 기준으로 활용하는 것을 권고한다. + +특히 보안 도구 벤더 관점에서는 ASVS를 기준으로 삼는 것이 유일한 선택지이다. OWASP Top 10은 위험 중심으로 구성되어 있기에, [A06:2025 - 안전하지 않은 설계](A06_2025-Insecure_Design.md) 사례와 마찬가지로 자동화 도구만으로 모든 Top 10 항목을 포괄적으로 탐지, 테스트, 방어하기 어렵다. 따라서, 벤더들은 Top 10을 전부 보장한다고 주장하지 않았으면 한다. 왜냐하면 이는 사실이 아니기 때문이다. diff --git a/2025/docs/ko/A01_2025-Broken_Access_Control.md b/2025/docs/ko/A01_2025-Broken_Access_Control.md new file mode 100644 index 000000000..e60fc9dda --- /dev/null +++ b/2025/docs/ko/A01_2025-Broken_Access_Control.md @@ -0,0 +1,219 @@ +# A01:2025 불충분한 접근 제어 ![icon](../assets/TOP_10_Icons_Final_Broken_Access_Control.png){: style="height:80px;width:80px" align="right"} + + + +## 배경 + +불충분한 접근 제어는 OWASP TOP 10에서 1위를 유지하고 있다. 테스트 된 모든 애플리케이션에서 불충분한 접근 제어 취약점이 발견되었으며, 주목할 만한 CWE는 *CWE-200: 비인가자에게 민감 정보 노출*, *CWE-201: 전송된 데이터로부터의 민감 정보 노출*, *CWE-918: 서버 측 요청 위조(SSRF)*, 그리고 *CWE-352: 크로스 사이트 요청 위조(CSRF)*가 있다. 해당 카테고리는 제공받은 데이터 기준 발생 건수가 가장 많았으며, 관련된 CVE 건수는 두 번째로 많았다. + +## 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
40 + 20.15% + 3.74% + 100.00% + 42.93% + 7.04 + 3.84 + 1,839,701 + 32,654 +
+ + + +## 설명 + +접근 제어는 사용자가 의도된 권한을 벗어나는 행위를 하지 못하도록 정책을 강제한다. 접근 제어 실패는 일반적으로 비인가자 정보 유출, 데이터 수정 및 삭제, 또는 사용자 제한사항을 벗어나는 비즈니스 기능을 수행으로 이어질 수 있다. 흔히 발견되는 불충분한 접근 제어 취약점 목록은 다음과 같다. + +* 최소 권한 원칙 위반, 우선 거부 정책(Deny by Default)이 적용되지 않아 제한된 기능, 역할, 사용자들에게만 허용된 접근 권한이 불특정 다수에게 허용되는 경우. +* URL 조작(파라미터 변조 및 강제 브라우징), 애플리케이션 내부 상태값 변조, HTML 페이지 변조, 공격 도구를 통한 API 요청 변조와 같은 방식으로 접근 제어가 우회될 수 있다. +* 고유 식별자를 이용해 타인의 계정을 조회 및 수정하는 경우. 즉, 안전하지 않은 직접 객체 참조(Insecure Direct Object References) 취약점. +* 접근 가능한 API의 POST, PUT 및 DELETE 메서드에 대한 접근 제어가 없는 경우. +* 권한 상승. 로그인 과정 없이 다른 사용자로 가장하거나 또는 사용자가 보유한 이상의 권한(예: 관리자 권한)을 획득하는 경우. +* 메타데이터 조작. 예를 들어 JSON Web Token(JWT) 접근 제어 토큰을 재전송하거나 변조하는 경우, 권한을 상승시키기 위해 쿠키 또는 히든 필드 값을 조작하는 행위, 또는 JWT 무효화가 없거나 우회하여 악용하는 경우. +* 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)의 잘못된 설정으로 비인가자 또는 신뢰할 수 없는 출처(Origin)에서 API에 접근할 수 있는 경우. +* 강제 브라우징(URL 추측)을 통해 인증이 필요한 페이지에 인증 없이 접근하거나, 일반 사용자가 권한이 필요한 페이지에 접근할 경우. + + +## 대응 방안 + +접근 제어는 공격자가 접근 제어 검사나 메타데이터를 변조할 수 없는 곳에서 신뢰할 수 있는 서버 측 코드나 서버리스 API들로 수행될 때 실효성이 있다. + + + +* 공개 리소스를 제외한 모든 리소스는 우선 거부 정책(Deny By Default)을 따라야 한다. +* 접근 제어 메커니즘을 구현한 후에는 전체 애플리케이션에 재사용하고 교차 출처 리소스 공유(CORS) 사용을 최소화한다. +* 모델 수준의 접근 제어는 레코드 소유자 기준으로 접근 권한을 제한하도록 한다. 다른 사용자가 임의의 레코드에 대해 생성, 조회, 수정, 삭제를 수행하도록 하지 못하게 한다. +* 애플리케이션의 고유한 비즈니스 제약사항은 도메인 모델에 의해 검사한다. +* 웹 서버의 디렉터리 리스팅(directory listing)를 비활성화하고, 웹 루트(web root) 내에 파일 메타데이터(예: .git) 및 백업 파일이 존재하지 않도록 해야 한다. +* 접근 제어 실패를 로깅하고 필요한 경우(예: 반복적인 실패 발생 시)에 관리자에게 알린다. +* 자동화된 공격 도구로 인한 피해를 최소화하기 위해 API 및 컨트롤러 접근에 대한 속도 제한(rate limit)을 구현한다. +* 상태 기반 세션 식별자는 로그아웃 후 무효화한다. 상태를 저장하지 않는 JWT 토큰의 경우 짧은 유효 시간을 부여하여 공격을 위한 기회를 최소화하고, 유효 기간이 긴 JWT 토큰은 리프레시 토큰 사용을 고려하며, OAuth 표준에 따른 토큰 취소도 고려한다. +* 간단하고 선언적 접근 제어를 제공하는 확립된 툴킷과 패턴을 사용한다. + +개발자와 QA 담당자는 단위 및 통합 테스트에서 접근 제어를 포함해야 한다. + +## 공격 시나리오 예시 + +**시나리오 1:** 이 애플리케이션은 계정 정보에 접근하는 SQL 요청에서 검증되지 않은 데이터를 사용한다. + + +``` +pstmt.setString(1, request.getParameter("acct")); +ResultSet results = pstmt.executeQuery( ); +``` + + +공격자는 원하는 계정 정보를 전달하기 위해 단순하게 'acct' 파라미터를 변조할 수 있으며, 만약 해당 파라미터가 완벽하게 검증되지 않았을 시 공격자는 모든 사용자 계정 정보에 접근 가능하다. + + +``` +https://example.com/app/accountInfo?acct=notmyacct +``` + + +**시나리오 2:** 공격자는 단순하게 대상 URL로 브라우저를 이용해 접속할 수 있다. 하지만 관리자 페이지에 접근하기 위해선 관리자 권한이 요구된다. + + +``` +https://example.com/app/getappInfo +https://example.com/app/admin_getappInfo +``` + + +만약 인증되지 않은 사용자가 두 페이지 중 하나에 접근할 수 있다면, 보안 취약점으로 간주한다. 만약 관리자가 아닌 자가 관리자 페이지 접근이 가능하다면 이 또한 마찬가지다. + + +**시나리오 3:** 애플리케이션이 모든 접근 제어를 프론트엔드에서만 구현할 경우. 공격자가 브라우저에서 동작하는 자바스크립트 코드 때문에 `https://example.com/app/admin_getappInfo` 에 접근할 수 없지만, 커맨드 라인에서 단순하게 curl 명령어를 실행하면 접속할 수 있다. + +``` +$ curl https://example.com/app/admin_getappInfo +``` + + + + +## 참조 + +* [OWASP Proactive Controls: C1: Implement Access Control](https://top10proactive.owasp.org/archive/2024/the-top-10/c1-accesscontrol/) +* [OWASP Application Security Verification Standard: V8 Authorization](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x17-V8-Authorization.md) +* [OWASP Testing Guide: Authorization Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README) +* [OWASP Cheat Sheet: Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) +* [PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) +* [OAuth: Revoking Access](https://www.oauth.com/oauth2-servers/listing-authorizations/revoking-access/) + + +## 해당되는 CWE 목록 + +* [CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) + +* [CWE-23 Relative Path Traversal](https://cwe.mitre.org/data/definitions/23.html) + +* [CWE-36 Absolute Path Traversal](https://cwe.mitre.org/data/definitions/36.html) + +* [CWE-59 Improper Link Resolution Before File Access ('Link Following')](https://cwe.mitre.org/data/definitions/59.html) + +* [CWE-61 UNIX Symbolic Link (Symlink) Following](https://cwe.mitre.org/data/definitions/61.html) + +* [CWE-65 Windows Hard Link](https://cwe.mitre.org/data/definitions/65.html) + +* [CWE-200 Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html) + +* [CWE-201 Exposure of Sensitive Information Through Sent Data](https://cwe.mitre.org/data/definitions/201.html) + +* [CWE-219 Storage of File with Sensitive Data Under Web Root](https://cwe.mitre.org/data/definitions/219.html) + +* [CWE-276 Incorrect Default Permissions](https://cwe.mitre.org/data/definitions/276.html) + +* [CWE-281 Improper Preservation of Permissions](https://cwe.mitre.org/data/definitions/281.html) + +* [CWE-282 Improper Ownership Management](https://cwe.mitre.org/data/definitions/282.html) + +* [CWE-283 Unverified Ownership](https://cwe.mitre.org/data/definitions/283.html) + +* [CWE-284 Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) + +* [CWE-285 Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) + +* [CWE-352 Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html) + +* [CWE-359 Exposure of Private Personal Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/359.html) + +* [CWE-377 Insecure Temporary File](https://cwe.mitre.org/data/definitions/377.html) + +* [CWE-379 Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +* [CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak')](https://cwe.mitre.org/data/definitions/402.html) + +* [CWE-424 Improper Protection of Alternate Path](https://cwe.mitre.org/data/definitions/424.html) + +* [CWE-425 Direct Request ('Forced Browsing')](https://cwe.mitre.org/data/definitions/425.html) + +* [CWE-441 Unintended Proxy or Intermediary ('Confused Deputy')](https://cwe.mitre.org/data/definitions/441.html) + +* [CWE-497 Exposure of Sensitive System Information to an Unauthorized Control Sphere](https://cwe.mitre.org/data/definitions/497.html) + +* [CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory](https://cwe.mitre.org/data/definitions/538.html) + +* [CWE-540 Inclusion of Sensitive Information in Source Code](https://cwe.mitre.org/data/definitions/540.html) + +* [CWE-548 Exposure of Information Through Directory Listing](https://cwe.mitre.org/data/definitions/548.html) + +* [CWE-552 Files or Directories Accessible to External Parties](https://cwe.mitre.org/data/definitions/552.html) + +* [CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key](https://cwe.mitre.org/data/definitions/566.html) + +* [CWE-601 URL Redirection to Untrusted Site ('Open Redirect')](https://cwe.mitre.org/data/definitions/601.html) + +* [CWE-615 Inclusion of Sensitive Information in Source Code Comments](https://cwe.mitre.org/data/definitions/615.html) + +* [CWE-639 Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html) + +* [CWE-668 Exposure of Resource to Wrong Sphere](https://cwe.mitre.org/data/definitions/668.html) + +* [CWE-732 Incorrect Permission Assignment for Critical Resource](https://cwe.mitre.org/data/definitions/732.html) + +* [CWE-749 Exposed Dangerous Method or Function](https://cwe.mitre.org/data/definitions/749.html) + +* [CWE-862 Missing Authorization](https://cwe.mitre.org/data/definitions/862.html) + +* [CWE-863 Incorrect Authorization](https://cwe.mitre.org/data/definitions/863.html) + +* [CWE-918 Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html) + +* [CWE-922 Insecure Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/922.html) + +* [CWE-1275 Sensitive Cookie with Improper SameSite Attribute](https://cwe.mitre.org/data/definitions/1275.html) diff --git a/2025/docs/ko/A02_2025-Security_Misconfiguration.md b/2025/docs/ko/A02_2025-Security_Misconfiguration.md new file mode 100644 index 000000000..5b7038598 --- /dev/null +++ b/2025/docs/ko/A02_2025-Security_Misconfiguration.md @@ -0,0 +1,143 @@ +# A02:2025 보안 설정 오류 ![icon](../assets/TOP_10_Icons_Final_Security_Misconfiguration.png){: style="height:80px;width:80px" align="right"} + + +## 배경 + +지난 버전에서 3단계 상승해 2위로 올라왔으며, 테스트 된 모든 애플리케이션에서 잘못된 설정 중 한 가지 이상이 발견되었다. 이번 카테고리 내에서의 평균 발생률은 3%이며, 총 CWE는 1,375개이고 71만 9천 개가 넘는 취약점이 발견되었다. 최근 설정 가능한 소프트웨어 쪽으로 트렌드가 이동함에 따라 이번 카테고리 순위 변동은 크게 놀라울 만한 일이 아니다. 주목할 만한 CWE로는 *CWE-16: 설정* 그리고 *CWE-611: XML 외부 엔티티 참조의 부적절한 제한(XXE)*가 있다. + + +## 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
16 + 27.70% + 3.00% + 100.00% + 52.35% + 7.96 + 3.97 + 719,084 + 1,375 +
+ + + +## 설명 + +보안 설정 오류는 보안 관점에서 시스템, 애플리케이션, 클라우드 서비스 설정이 잘못되어 취약점이 발생하는 것을 말한다. + +다음과 같은 경우 애플리케이션은 취약할 수 있다. + + +* 애플리케이션 스택 전반에 적절한 보안 하드닝이 적용되지 않았거나, 클라우드 서비스 내 보안 설정이 잘못 구성된 경우. +* 불필요한 기능(예: 불필요 포트, 서비스, 페이지, 계정, 테스트 프레임워크 또는 권한)이 활성화 또는 설치된 경우. +* 기본 계정, 패스워드가 활성화되어 있거나 변경되지 않은 경우. +* 과도한 에러 메시지를 처리할 공통 설정이 부족하여 에러 처리 과정에서 스택 트레이스(stack trace)나 과도한 에러 정보 메시지가 사용자에게 전달되는 경우. +* 업그레이드된 시스템에서 최신 보안 기능이 비활성화되어 있거나 안전하게 설정되지 않은 경우. +* 이전 버전과의 호환성을 우선시하여 안전하지 않은 설정을 하는 경우. +* 애플리케이션 서버 내 보안 설정, 애플리케이션 프레임워크(예: 스트럿츠(Struts), 스프링(Spring), ASP.NET), 라이브러리, 데이터베이스 등에서 보안 설정이 되지 않은 경우. +* 서버가 보안 헤더 또는 지시문을 전달하지 않거나 안전하지 않은 설정값으로 전달되는 경우. + +일관되고 재사용 가능한 애플리케이션 보안 설정 하드닝 절차가 없다면 시스템은 더 높은 위험에 놓인다. + + +## 대응 방안 + +다음과 같은 항목들을 포함하여 보안성이 반영된 구성 절차를 수립한다. + +* 재사용할 수 있는 하드닝 프로세스를 구축하여 필요한 보안 통제가 적용된 동일한 형태의 신규 환경을 빠르고 쉽게 배포할 수 있어야 한다. 개발, QA, 운영 환경은 모두 동일한 구성으로 설정하며, 각각의 환경에서 서로 다른 자격 증명을 사용한다. 이 프로세스는 자동화하여 요구되는 새로운 보안 환경을 구성하는 데 필요한 노력을 최소화한다. +* 사용하지 않은 기능, 컴포넌트, 문서, 샘플을 포함하지 않는 최소한의 플랫폼을 구현한다. 사용하지 않는 기능과 프레임워크는 삭제하거나 설치되지 않아야 한다. +* 패치 관리 프로세스(참고: [A03 소프트웨어 공급망 실패](A03_2025-Software_Supply_Chain_Failures.md)) 수행 시 모든 보안 공지, 업데이트, 패치에 따른 적절한 검토 및 업데이트를 한다. 또한, 클라우드 스토리지 권한(예: S3 버킷 권한)을 점검한다. +* 구성 요소 간 또는 테넌트 간을 효과적으로 격리할 수 있도록 세분화, 컨테이너화, 클라우드 보안 그룹(ACL)을 활용해 애플리케이션 아키텍처를 설계함으로써 효과적이고 안전한 분리 구조를 보장한다. +* 보안 지시문을 클라이언트로 보내야 한다. (예: 보안 헤더) +* 자동화된 프로세스를 구축하여 모든 환경에서 해당 설정들의 안전성을 검증한다. +* 만일의 경우를 대비해, 과도한 에러 메시지가 사용자에게 노출되지 않도록 공통 설정을 사전에 구성한다. +* 만약 이런 검증 사항들이 자동화되지 않았다면, 최소한 매년 1회는 수동으로 검증한다. +* 코드, 설정 파일, 파이프라인 내 정적인 키나 시크릿을 저장하는 대신 플랫폼에서 제공하는 아이덴티티 페더레이션, 단기 유효 자격 증명, 또는 역할 기반 접근 메커니즘을 사용한다. + + +## 공격 시나리오 예시 + +**시나리오 1:** 운영 서버에서 테스트용 애플리케이션이 지워지지 않았다. 테스트용 애플리케이션은 공격자가 해당 서버를 공격할 수 있는 보안 취약점이 존재한다고 알려져 있으며, 그중 하나의 애플리케이션은 관리자용 콘솔이라 가정해 보겠다. 그리고 기본 계정은 변경되지 않았다. 이런 경우 공격자는 기본 계정으로 로그인한 뒤 시스템 장악이 가능하다. + +**시나리오 2:** 서버에서 디렉터리 리스팅이 활성화되었을 때 공격자는 단순하게 디렉터리 목록을 탐색할 수 있다. 공격자는 컴파일된 자바 클래스들을 찾거나 다운로드할 수 있고, 이런 클래스들을 디컴파일하거나 리버싱 엔지니어링을 통해 코드를 볼 수 있다. 그 뒤 공격자는 애플리케이션 내에서 서버 접근 제어 취약점을 찾은 뒤 악용 가능하다. + +**시나리오 3:** 사용자에게 반환되는 스택 트레이스 같은 자세한 에러 메시지가 표시되도록 설정되면 민감한 정보나 해당 컴포넌트 버전에 알려진 취약점 같은 근본적 취약점이 노출될 가능성이 있다. + +**시나리오 4:** 클라우드 서비스 제공자(Cloud service provider, CSP)는 인터넷에 자원을 공유하는 권한이 기본 설정이다. 이는 민감한 정보가 공개된 클라우드 스토리지 내에 저장될 시 관계자 외 접근을 허용할 수 있다. + +## 참조 + +* [OWASP Testing Guide: Configuration Management](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) +* [OWASP Testing Guide: Testing for Error Codes](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) +* [Application Security Verification Standard V13 Configuration](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x22-V13-Configuration.md) +* [NIST Guide to General Server Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) +* [CIS Security Configuration Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) +* [Amazon S3 Bucket Discovery and Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) +* ScienceDirect: Security Misconfiguration + +## 해당되는 CWE 목록 + +* [CWE-5 J2EE Misconfiguration: Data Transmission Without Encryption](https://cwe.mitre.org/data/definitions/5.html) + +* [CWE-11 ASP.NET Misconfiguration: Creating Debug Binary](https://cwe.mitre.org/data/definitions/11.html) + +* [CWE-13 ASP.NET Misconfiguration: Password in Configuration File](https://cwe.mitre.org/data/definitions/13.html) + +* [CWE-15 External Control of System or Configuration Setting](https://cwe.mitre.org/data/definitions/15.html) + +* [CWE-16 Configuration](https://cwe.mitre.org/data/definitions/16.html) + +* [CWE-260 Password in Configuration File](https://cwe.mitre.org/data/definitions/260.html) + +* [CWE-315 Cleartext Storage of Sensitive Information in a Cookie](https://cwe.mitre.org/data/definitions/315.html) + +* [CWE-489 Active Debug Code](https://cwe.mitre.org/data/definitions/489.html) + +* [CWE-526 Exposure of Sensitive Information Through Environmental Variables](https://cwe.mitre.org/data/definitions/526.html) + +* [CWE-547 Use of Hard-coded, Security-relevant Constants](https://cwe.mitre.org/data/definitions/547.html) + +* [CWE-611 Improper Restriction of XML External Entity Reference](https://cwe.mitre.org/data/definitions/611.html) + +* [CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute](https://cwe.mitre.org/data/definitions/614.html) + +* [CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')](https://cwe.mitre.org/data/definitions/776.html) + +* [CWE-942 Permissive Cross-domain Policy with Untrusted Domains](https://cwe.mitre.org/data/definitions/942.html) + +* [CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag](https://cwe.mitre.org/data/definitions/1004.html) + +* [CWE-1174 ASP.NET Misconfiguration: Improper Model Validation](https://cwe.mitre.org/data/definitions/1174.html) diff --git a/2025/docs/ko/A03_2025-Software_Supply_Chain_Failures.md b/2025/docs/ko/A03_2025-Software_Supply_Chain_Failures.md new file mode 100644 index 000000000..c609f10e5 --- /dev/null +++ b/2025/docs/ko/A03_2025-Software_Supply_Chain_Failures.md @@ -0,0 +1,166 @@ +# A03:2025 소프트웨어 공급망 실패 ![icon](../assets/TOP_10_Icons_Final_Vulnerable_Outdated_Components.png){: style="height:80px;width:80px" align="right"} + + +## 배경 + +소프트웨어 공급망 실패는 TOP 10 커뮤니티 조사에서 정확히 50%의 응답자가 1위로 선정하였다. 2013년 TOP 10에 "A9 - 사용 중인 컴포넌트 내 알려진 취약점"으로 처음 등장한 이후, 해당 카테고리는 "알려진 취약점" 외에도 "모든 공급망 실패"를 포함하도록 범위가 확장되었다. 범위가 확대됨에도 불구하고, 공급망 실패는 여전히 식별이 어려우며, 관련 CWE와 매핑된 CVE가 11개에 불과하다. 그러나, 수집한 데이터를 테스트하고 보고한 결과에 따르면 이번 카테고리는 5.19%라는 가장 높은 평균 발생률을 보였고, 관련된 CWE로는 *CWE-477: 더 이상 사용되지 않는 기능 사용*, *CWE-1104: 관리되지 않은 외부 컴포넌트 사용*, *CWE-1329: 업데이트할 수 없는 컴포넌트에 대한 의존*, 그리고 *CWE-1395: 취약한 외부 컴포넌트 의존*이 있다. + +## 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
6 + 9.56% + 5.72% + 65.42% + 27.47% + 8.17 + 5.23 + 215,248 + 11 +
+ + + +## 설명 + +소프트웨어 공급망 실패는 소프트웨어를 개발, 배포, 업데이트하는 과정에서 발생하는 장애 또는 침해를 의미한다. 이는 주로 외부 코드, 도구, 시스템이 신뢰하는 의존성이 악의적으로 변조되거나 의존성에 존재하는 취약점이 원인이 된다. + +다음과 같은 경우 취약하다. + +* 사용하는 모든 컴포넌트(클라이언트 측, 서버 측 모두) 버전을 추적하지 않는 경우. 여기에서 컴포넌트는 직접 사용하는 컴포넌트뿐만 아니라 중첩 의존성(중첩 전이 의존성)도 포함한다. +* 소프트웨어가 취약하거나, 더 이상 지원하지 않거나, 오래된 버전인 경우. 이는 OS, 웹/애플리케이션 서버, 데이터베이스 관리 시스템(DBMS), 애플리케이션, API, 모든 컴포넌트, 런타임 환경 그리고 모든 라이브러리를 포함한다. +* 사용 중인 컴포넌트에 대해 주기적으로 취약점을 스캔하지 않거나 보안 공지를 구독하지 않는 경우. +* 공급망의 변경을 관리하는 절차가 없거나, 변경 이력을 추적하지 못하는 경우. 여기에는 사용 중인 IDE와 IDE 확장 프로그램(extension) 및 업데이트를 추적하는 것, 조직의 코드 저장소에서 발생하는 변경 사항, 샌드박스, 이미지 및 라이브러리 저장소, 아티팩트가 생성되고 보관되는 방식 등도 모두 포함된다. 공급망을 이루는 모든 요소는 문서화되어야 하며, 특히 변경 사항은 반드시 기록으로 남겨야 한다. +* 공급망에 대한 모든 영역에 보안 하드닝이 없는 경우. 특히 접근 제어 부분과 애플리케이션 최소 권한 원칙 적용을 신경 쓰지 않은 경우. +* 공급망 시스템에 직무 분리가 없는 경우. 다른 사람의 검토와 승인 없이 작성된 코드를 운영 환경에 배포해서는 안 된다. +* 기술 스택의 어느 계층에서든 신뢰할 수 없는 출처의 컴포넌트가 사용되고 있거나, 이에 따라 운영 환경이 영향받는 경우. +* 기반이 되는 플랫폼, 프레임워크, 의존성을 위험도에 따라 또는 적시에 수정하거나 업그레이드하지 않는 경우. 이는 보통 변경 관리 절차 때문에 패치를 매월, 매 분기 단위로 작업할 때 흔히 발생하며, 취약점 조치 전까지 조직에 불필요한 위험을 수일 또는 수개월간 노출할 수 있다. +* 소프트웨어 개발자가 업데이트, 업그레이드, 패치된 라이브러리의 호환성을 테스트하지 않는 경우. +* 시스템의 모든 구성 요소에 대한 설정이 안전하지 않은 경우. (참고. [A02:2025-보안 설정 오류](https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/)) +* CI/CD 파이프라인의 보안이 빌드하고 배포하는 시스템보다 취약한 경우, 특히 파이프라인이 복잡할수록 취약하다. + +## 대응 방안 + +패치 관리 프로세스 내 다음과 같은 사항이 포함되어야 한다. + + + +* 전체 소프트웨어에 대한 소프트웨어 자재 명세서(Software Bill of Materials, SBOM)를 중앙에서 생성 및 관리한다. +* 직접 추가한 의존성만 추적할 것이 아니라, 그 의존성의 (전이) 의존성, 그리고 그다음 단계 의존성까지 추적한다. +* 사용하지 않는 의존성, 불필요한 기능, 컴포넌트, 파일 그리고 문서를 지움으로써 공격 표면을 축소한다. +* OWASP Dependency Track, OWASP Dependency Check, retire.js 등과 같은 도구를 활용해서 클라이언트 측과 서버 측 컴포넌트(예: 프레임워크, 라이브러리) 및 그 의존성의 버전 정보를 지속적으로 목록화한다. +* 사용 중인 컴포넌트에 대한 취약점들을 CVE(Common Vulnerabilities and Exposures), 미국 정부가 운영하는 취약점 데이터베이스(National Vulnerability Database), [OSV(Open Source Vulnerabilities)](https://osv.dev/)와 같은 출처를 지속적으로 모니터링한다. 이를 위해 소프트웨어 구성 분석(software composition analysis, SCA) 도구, 소프트웨어 공급망 도구, 보안에 초점이 맞춰진 SBOM 도구를 사용해 이 과정을 자동화한다. 사용 중인 컴포넌트와 관련된 보안 취약점 알림을 구독한다. +* 공식(신뢰할 수 있는) 출처에서 암호화가 적용된 링크를 통해서만 컴포넌트를 획득한다. 변조되었거나 악성 컴포넌트가 포함될 가능성을 줄이기 위해 서명된 패키지를 우선시한다. (참고. [A08:2025-소프트웨어, 데이터 무결성 실패](https://owasp.org/Top10/2025/A08_2025-Software_or_Data_Integrity_Failures/)) +* 의존성의 어떤 버전을 사용할지 의도적으로 선택하고, 필요가 있을 때만 업그레이드한다. +* 관리되지 않거나 보안 패치가 이루어지지 않는 오래된 버전의 라이브러리, 컴포넌트 사용 여부를 모니터링한다. 만약 패치가 불가능하다면 대체품으로 마이그레이션하는 것을 고려한다. 그것 또한 불가능하다면 가상 패치(virtual patch)를 적용해 발견된 문제에 대해 모니터링, 탐지, 방어하는 방안을 고려한다. +* CI/CD, IDE, 기타 개발 도구를 주기적으로 업데이트한다. +* 모든 시스템에 업데이트를 동시에 배포하는 것을 피한다. 신뢰하는 벤더가 침해된 경우를 대비하여 공격의 영향을 제한하기 위해 점진적 배포나 카나리 배포를 수행한다. + +다음과 같은 항목의 변경 사항을 추적하기 위해 변경 관리 프로세스 또는 추적 시스템을 마련한다. + +* CI/CD 설정(모든 빌드 도구와 파이프라인) +* 코드 저장소 +* 샌드박스 영역 +* 개발자 IDE +* 소프트웨어 자재 명세서(SBOM) 도구와 생성된 아티팩트 +* 로깅 시스템과 로그 +* SaaS 등 외부 서비스와의 연동 +* 아티팩트 저장소 +* 컨테이너 레지스트리 + + +다음과 같은 시스템을 하드닝한다. 하드닝에는 MFA를 활성화하고 IAM의 권한을 제한하는 조치가 포함된다. + +* 코드 저장소: 시크릿 커밋 금지, 브랜치 보호, 백업 설정 +* 개발자 워크스테이션: 주기적 패치, 다중 인증(MFA), 모니터링 등 +* 빌드 서버와 CI/CD 서버: 직무 분리, 접근 제어, 서명된 빌드, 환경변수 내 시크릿, 변조 감지 로그(tamper-evident log) 등 +* 아티팩트: 프로비넌스(provenance), 서명, 타임스탬프를 통해 무결성을 보장. 환경마다 재빌드하지 않고 동일한 아티팩트를 사용, 빌드의 불변성 보장 +* 코드형 인프라(Infrastructure as Code): 다른 모든 코드와 마찬가지로 PR과 버전 관리를 포함해 코드로 관리 + +모든 조직은 해당 애플리케이션 또는 포트폴리오의 생명 주기 동안, 업데이트나 설정 변경 사항을 계속 감시하고 중요도를 판단해 우선순위를 정한 뒤 적시에 반영할 수 있는 상시적인 운영 계획을 갖춰야 한다. + +## 공격 시나리오 예시 + +**시나리오 1:** 신뢰하는 벤더가 악성코드에 감염되어, 업데이트하는 과정에서 내부 시스템까지 침해되는 경우. 가장 유명한 사례는 다음과 같다. + +* 2019년에 발생한 솔라윈즈(Solarwinds) 침해 사고로 약 18,000개 조직이 침해된 사례. [https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) + +**시나리오 2:** 신뢰하는 벤더가 침해되어, 특정 조건에서만 악성 행위가 동작하는 경우. + +* 2025년에 바이빗(Bybit)은 [월렛 소프트웨어에서의 공급망 공격](https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/)으로 15억 달러가량을 탈취당했다. 해당 공격은 표적 월렛이 사용될 때만 실행되도록 작동했다. + +**시나리오 3:** 2025년에 발생한 [`Shai-Hulud` 공급망 공격](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem)은 최초로 성공한 자기복제형 npm 웜이다. 공격자는 인기 패키지에 악성코드를 심어 배포했으며, 이 패키지들은 post-install 스크립트를 통해 민감 정보를 수집하여 공개된 GitHub 저장소로 유출했다. 해당 악성코드는 피해자 환경에서 npm 토큰을 탐지하고, 이를 이용해 접근할 수 있는 모든 패키지에 자동으로 악성 버전을 배포했다. 이 웜은 npm에 의해 차단되기 전까지 500개 이상의 패키지에 확산했다. 이 공급망 공격은 고도화된 공격이며 빠르게 전파되어 심각한 피해를 줬으며, 개발자 환경을 직접 표적으로 삼아 개발자 자신이 공급망 공격의 주요 대상이 될 수 있음을 보여주었다. + +**시나리오 4:** 컴포넌트는 일반적으로 애플리케이션과 동일한 권한으로 실행되므로, 컴포넌트의 취약점이 있으면 심각한 영향을 미칠 수 있다. 이러한 취약점은 우발적(예: 코딩 에러)이거나, 의도적(예: 컴포넌트 내 백도어)일 수 있다. 지금까지 발견된 악용 가능한 컴포넌트 취약점 사례는 다음과 같다. + +* CVE-2017-5638: Struts 2의 원격 코드 실행 취약점으로, 서버에서 임의 코드 실행 가능하여 다수의 심각한 침해 사고의 원인이 되었다. +* CVE-2021-44228("Log4Shell"): Apache Log4j의 제로데이 원격 코드 실행 취약점으로, 랜섬웨어, 암호화폐 채굴 등 다양한 공격 캠페인에 악용되었다. + + +## 참조 + +* [OWASP Application Security Verification Standard: V15 Secure Coding and Architecture](https://owasp.org/www-project-application-security-verification-standard/) +* [OWASP Cheat Sheet Series: Dependency Graph SBOM](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html) +* [OWASP Cheat Sheet Series: Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) +* [OWASP Dependency-Track](https://owasp.org/www-project-dependency-track/) +* [OWASP CycloneDX](https://owasp.org/www-project-cyclonedx/) +* [OWASP Application Security Verification Standard: V1 Architecture, design and threat modelling](https://owasp-aasvs.readthedocs.io/en/latest/v1.html) +* [OWASP Dependency Check (for Java and .NET libraries)](https://owasp.org/www-project-dependency-check/) +* OWASP Testing Guide - Map Application Architecture (OTG-INFO-010) +* [OWASP Virtual Patching Best Practices](https://owasp.org/www-community/Virtual_Patching_Best_Practices) +* [The Unfortunate Reality of Insecure Libraries](https://www.scribd.com/document/105692739/JeffWilliamsPreso-Sm) +* [MITRE Common Vulnerabilities and Exposures (CVE) search](https://www.cve.org) +* [National Vulnerability Database (NVD)](https://nvd.nist.gov) +* [Retire.js for detecting known vulnerable JavaScript libraries](https://retirejs.github.io/retire.js/) +* [GitHub Advisory Database](https://github.com/advisories) +* Ruby Libraries Security Advisory Database and Tools +* [SAFECode Software Integrity Controls (PDF)](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +* [Glassworm supply chain attack](https://thehackernews.com/2025/10/self-spreading-glassworm-infects-vs.html) +* [PhantomRaven supply chain attack campaign](https://thehackernews.com/2025/10/phantomraven-malware-found-in-126-npm.html) + + +## 해당되는 CWE + +* [CWE-477 Use of Obsolete Function](https://cwe.mitre.org/data/definitions/477.html) + +* [CWE-1035 2017 Top 10 A9: Using Components with Known Vulnerabilities](https://cwe.mitre.org/data/definitions/1035.html) + +* [CWE-1104 Use of Unmaintained Third Party Components](https://cwe.mitre.org/data/definitions/1104.html) + +* [CWE-1329 Reliance on Component That is Not Updateable](https://cwe.mitre.org/data/definitions/1329.html) + +* [CWE-1357 Reliance on Insufficiently Trustworthy Component](https://cwe.mitre.org/data/definitions/1357.html) + +* [CWE-1395 Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html) diff --git a/2025/docs/ko/A04_2025-Cryptographic_Failures.md b/2025/docs/ko/A04_2025-Cryptographic_Failures.md new file mode 100644 index 000000000..13958ce43 --- /dev/null +++ b/2025/docs/ko/A04_2025-Cryptographic_Failures.md @@ -0,0 +1,194 @@ +# A04:2025 암호 실패 ![icon](../assets/TOP_10_Icons_Final_Crypto_Failures.png){: style="height:80px;width:80px" align="right"} + +> 옮긴이: 본 문서에서는 "cryptographic"을 "암호"로 번역한다. 이는 종종 "암호화"로 번역되나, 해당 용어는 암호화뿐 아니라 복호화, 해시, 전자서명 등 암호 기술 전반을 포괄하므로 본 문서의 번역어를 "암호"로 통일한다. + + +## 배경 + +암호 실패 카테고리는 이전 버전에서 2단계 내려가 4위가 되었다. 이 카테고리는 암호 부재, 불충분한 암호 강도, 암호키 유출 및 관련 오류에 중점을 둔다. 이 위험에서 가장 흔한 CWE 3개는 약한 의사 난수 생성기(PRNG) 사용과 관련이 있다: *CWE-327: 취약하거나 위험한 암호 알고리즘 사용*, *CWE-331: 불충분한 엔트로피*, *CWE-1241: 난수 생성기 내 예측 가능한 알고리즘 사용*, *CWE-338: 암호학적으로 약한 의사 난수 생성기(PRNG) 사용*. + + +## 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
32 + 13.77% + 3.80% + 100.00% + 47.74% + 7.23 + 3.90 + 1,665,348 + 2,185 +
+ + + +## 설명 + +일반적으로, [전송 계층](https://en.wikipedia.org/wiki/Transport_layer) ([OSI 4계층](https://en.wikipedia.org/wiki/OSI_model))에서의 모든 데이터는 암호화되어 전송해야 한다. 과거에는 CPU 성능과 프라이빗 키/인증서 관리가 장벽이었다. 현재는 암호 연산 가속을 위한 CPU 전용 명령어(예: [AES support](https://en.wikipedia.org/wiki/AES_instruction_set))가 도입되었고, [LetsEncrypt.org](https://letsencrypt.org/) 같은 서비스와 대형 클라우드 공급업체가 자사 플랫폼에 긴밀히 통합된 인증서 관리 서비스를 제공하면서 프라이빗 키와 인증서 관리도 간소화되었다. + +전송 계층 보안 외에도 어떤 데이터가 저장 시 암호화가 필요한지, 그리고 전송 중([애플리케이션 계층](https://en.wikipedia.org/wiki/Application_layer), OSI 7계층)에 추가적인 암호화가 필요한지 결정하는 것이 중요하다. 예를 들어 패스워드, 신용카드 번호, 건강 기록, 개인 정보, 비즈니스 기밀은 추가 보호가 필요하다. 특히 해당 데이터가 개인정보 보호법(예: EU의 GDPR)이나 규정(예: PCI-DSS)의 적용을 받는 경우 더욱 중요하다. 이러한 모든 데이터에 대해 다음을 확인해야 한다. + + + +* 약하거나 오래된 암호 알고리즘 또는 프로토콜이 기본값으로 사용되거나 레거시 코드에서 사용되고 있는가? +* 기본 암호키가 사용되는가? 약한 암호키가 생성되는가? 키가 재사용되는가? 적절한 키 관리 및 키 순환 주기가 없는가? +* 사용되는 암호키가 소스코드 저장소에 커밋되어 있는가? +* 암호화가 강제되지 않는가? (예: HTTP 헤더[브라우저]의 보안 지시문이 누락되어 있는가?) +* 수신한 서버 인증서와 신뢰 체인이 적절히 검증되는가? +* 초기화 벡터(IV)가 무시되거나, 재사용되거나, 암호 운영 모드에 맞게 충분히 안전하게 생성되지 않는가? ECB 같은 안전하지 않은 운영 모드를 사용하는가? 인증 암호화(Authenticated Encryption)가 더 적절한 상황에서 기본 암호화를 사용하는가? +* 패스워드 기반 키 파생 함수 없이 패스워드를 암호키로 직접 사용하는가? +* 암호 요구사항을 충족하도록 설계되지 않은 난수를 사용하는가? 올바른 함수를 선택하더라도 개발자가 시드를 지정해야 하는가? 그렇지 않다면, 내장된 강력한 시드 기능을 엔트로피(무작위성)가 부족한 시드로 덮어쓰지 않았는가? +* MD5, SHA1 같은 더 이상 사용하지 않는 해시 함수를 사용하는가? 암호학적 해시 함수가 필요한 곳에 비암호학적 해시 함수를 사용하는가? +* 암호 오류 메시지나 사이드 채널 정보가 패딩 오라클 공격 등으로 악용될 수 있는가? +* 암호 알고리즘이 다운그레이드되거나 우회될 수 있는가? + +레퍼런스 참고 ASVS: Cryptography (V11), Secure Communication (V12) and Data Protection (V14). + + +## 대응 방안 + +최소한 다음 사항들을 수행하고 레퍼런스를 참고한다. + + + +* 애플리케이션이 처리, 저장, 전송하는 데이터를 분류하고 라벨링한다. 개인정보 보호법, 규제 요구사항, 비즈니스 필요에 따라 어떤 데이터가 민감한지 식별한다. +* 가장 민감한 키는 하드웨어 또는 클라우드 기반 HSM(하드웨어 보안 모듈)에 보관한다. +* 암호 알고리즘은 가능하면 신뢰할 수 있는 구현체(라이브러리)를 사용한다. +* 불필요한 민감 데이터는 저장하지 않는다. 저장 시 가능한 한 빨리 폐기하거나 PCI DSS 준수 토큰화(PCI DSS compliant tokenization) 또는 마스킹(truncation)을 적용한다. 저장하지 않은 데이터는 탈취될 수 없다. +* 저장된 모든 민감 데이터가 암호화되었는지 확인한다. +* 최신의 강력한 표준 알고리즘, 프로토콜, 키가 적용되어 있는지 확인하고, 적절한 키 관리를 수행한다. +* 전송 중인 모든 데이터는 TLS 1.2 이상의 프로토콜로만 암호화하고, 전방향 비밀성(Forward Secrecy) 암호를 사용하며, CBC(Cipher Block Chaining) 암호에 대한 지원을 중단하고, 양자 내성 키 교환 알고리즘을 지원한다. HTTPS는 HSTS(HTTP Strict Transport Security)를 사용해 강제한다. 도구를 활용해 모든 항목을 검사한다. +* 민감 데이터가 포함된 응답의 캐싱을 비활성화한다. 이는 콘텐츠 전송 네트워크(CDN), 웹 서버, 모든 애플리케이션 캐싱(예: Redis)을 포함한다. +* 데이터 분류에 따라 필요한 보안 통제를 적용한다. +* FTP 나 STARTTLS 같은 암호화되지 않는 프로토콜을 사용하지 않는다. SMTP로 기밀 정보를 전송하는 것은 피한다. +* 패스워드는 작업 요소(지연 요소)를 갖춘 강력한 적응형 솔트 해싱 함수를 사용해 저장한다. Argon2, yescrypt, scrypt, PBKDF2-HMAC-SHA-512 등이 있다. 레거시 시스템에서 bcrypt를 사용하는 경우 [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)를 참고한다. +* 초기화 벡터(IV)는 운영 모드에 적합하게 선택해야 한다. 이는 CSPRNG(Cryptographically Secure Pseudo Random Number Generator) 사용을 의미할 수 있다. 논스(nonce)를 요구하는 모드의 경우 IV에 CSPRNG가 필요하지 않다. 모든 경우에 IV는 고정 키에 대해 두 번 사용해서는 안 된다. +* 기본 암호화 대신 항상 인증 암호화(Authenticated Encryption)를 사용한다. +* 키는 암호학적으로 무작위로 생성하고, 메모리에 바이트 배열로 저장해야 한다. 패스워드를 암호키로 사용하는 경우 적절한 패스워드 기반 키 파생 함수(PBKDF)를 통해 키로 변환해야 한다. +* 적절한 곳에서 암호학적 무작위성이 사용되는지, 그리고 예측 가능하거나 엔트로피가 낮은 방식으로 시드되지 않았는지 확인한다. 대부분의 최신 API는 보안을 위해 개발자가 CSPRNG에 시드를 설정할 필요가 없다. +* MD5, SHA1, CBC(Cipher Block Chaining), PKCS #1 v1.5 등 더 이상 사용되지 않는 암호 함수, 블록 빌딩 메서드, 패딩 스키마 사용을 피한다. +* 보안 전문가, 전용 도구, 또는 둘 다를 활용해 설정과 구성이 보안 요구사항을 충족하는지 검토한다. +* 지금부터 양자 내성 암호(PQC)를 준비해야 한다(ENISA 참고). 고위험 시스템은 늦어도 2030년 말까지 안전하게 보호되도록 해야 한다. + + +## 공격 시나리오 예시 + +**시나리오 1:** 어떤 사이트가 모든 페이지에 TLS를 사용하지 않거나 강제하지 않고, 약한 암호화를 지원한다. 공격자는 네트워크 트래픽을 모니터링하고(예: 안전하지 않은 무선 네트워크), HTTPS 연결을 HTTP로 다운그레이드한 뒤, 요청을 가로채 사용자의 세션 쿠키를 탈취한다. 공격자는 이 쿠키를 재전송해 사용자의 인증된 세션을 하이재킹하여 개인 데이터에 접근하거나 수정한다. 위 방법 외에도 전송되는 모든 데이터를 변조할 수 있다(예: 송금 수신자). + +**시나리오 2:** 패스워드 데이터베이스가 솔트 없이 또는 단순한 해시로 모든 사용자의 패스워드를 저장한다. 파일 업로드 취약점으로 공격자가 패스워드 데이터베이스를 탈취할 수 있다. 솔트가 없는 해시는 사전 계산된 레인보우 테이블로 노출될 수 있다. 단순하거나 빠른 해시 함수로 생성된 해시는 솔트가 있더라도 GPU로 크랙할 수 있다. + + +## 참조 + + +* [OWASP Proactive Controls: C2: Use Cryptography to Protect Data ](https://top10proactive.owasp.org/archive/2024/the-top-10/c2-crypto/) +* [OWASP Application Security Verification Standard (ASVS): ](https://owasp.org/www-project-application-security-verification-standard) [V11,](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x20-V11-Cryptography.md) [12, ](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x21-V12-Secure-Communication.md) [14](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x23-V14-Data-Protection.md) +* [OWASP Cheat Sheet: Transport Layer Protection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) +* [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) +* [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) +* [OWASP Testing Guide: Testing for weak cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README) +* [ENISA: A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography) +* [NIST Releases First 3 Finalized Post-Quantum Encryption Standards](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards) + + +## 해당되는 CWE 목록 + +* [CWE-261 Weak Encoding for Password](https://cwe.mitre.org/data/definitions/261.html) + +* [CWE-296 Improper Following of a Certificate's Chain of Trust](https://cwe.mitre.org/data/definitions/296.html) + +* [CWE-319 Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) + +* [CWE-320 Key Management Errors (Prohibited)](https://cwe.mitre.org/data/definitions/320.html) + +* [CWE-321 Use of Hard-coded Cryptographic Key](https://cwe.mitre.org/data/definitions/321.html) + +* [CWE-322 Key Exchange without Entity Authentication](https://cwe.mitre.org/data/definitions/322.html) + +* [CWE-323 Reusing a Nonce, Key Pair in Encryption](https://cwe.mitre.org/data/definitions/323.html) + +* [CWE-324 Use of a Key Past its Expiration Date](https://cwe.mitre.org/data/definitions/324.html) + +* [CWE-325 Missing Required Cryptographic Step](https://cwe.mitre.org/data/definitions/325.html) + +* [CWE-326 Inadequate Encryption Strength](https://cwe.mitre.org/data/definitions/326.html) + +* [CWE-327 Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html) + +* [CWE-328 Reversible One-Way Hash](https://cwe.mitre.org/data/definitions/328.html) + +* [CWE-329 Not Using a Random IV with CBC Mode](https://cwe.mitre.org/data/definitions/329.html) + +* [CWE-330 Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html) + +* [CWE-331 Insufficient Entropy](https://cwe.mitre.org/data/definitions/331.html) + +* [CWE-332 Insufficient Entropy in PRNG](https://cwe.mitre.org/data/definitions/332.html) + +* [CWE-334 Small Space of Random Values](https://cwe.mitre.org/data/definitions/334.html) + +* [CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/335.html) + +* [CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/336.html) + +* [CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/337.html) + +* [CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/338.html) + +* [CWE-340 Generation of Predictable Numbers or Identifiers](https://cwe.mitre.org/data/definitions/340.html) + +* [CWE-342 Predictable Exact Value from Previous Values](https://cwe.mitre.org/data/definitions/342.html) + +* [CWE-347 Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html) + +* [CWE-523 Unprotected Transport of Credentials](https://cwe.mitre.org/data/definitions/523.html) + +* [CWE-757 Selection of Less-Secure Algorithm During Negotiation('Algorithm Downgrade')](https://cwe.mitre.org/data/definitions/757.html) + +* [CWE-759 Use of a One-Way Hash without a Salt](https://cwe.mitre.org/data/definitions/759.html) + +* [CWE-760 Use of a One-Way Hash with a Predictable Salt](https://cwe.mitre.org/data/definitions/760.html) + +* [CWE-780 Use of RSA Algorithm without OAEP](https://cwe.mitre.org/data/definitions/780.html) + +* [CWE-916 Use of Password Hash With Insufficient Computational Effort](https://cwe.mitre.org/data/definitions/916.html) + +* [CWE-1240 Use of a Cryptographic Primitive with a Risky Implementation](https://cwe.mitre.org/data/definitions/1240.html) + +* [CWE-1241 Use of Predictable Algorithm in Random Number Generator](https://cwe.mitre.org/data/definitions/1241.html) diff --git a/2025/docs/ko/A05_2025-Injection.md b/2025/docs/ko/A05_2025-Injection.md new file mode 100644 index 000000000..a996ed31f --- /dev/null +++ b/2025/docs/ko/A05_2025-Injection.md @@ -0,0 +1,207 @@ +# A05:2025 인젝션 ![icon](../assets/TOP_10_Icons_Final_Injection.png){: style="height:80px;width:80px" align="right"} + +## 배경 + +인젝션은 3위에서 5위로 두 단계 하락했으며, A04:2025-암호 실패 및 A06:2025-안전하지 않은 설계 대비 상대적 위치는 변동이 없다. 인젝션은 가장 많이 테스트 된 카테고리 중 하나로, 조사된 모든 애플리케이션에서 최소 한 번 이상 테스트가 수행되었다. 인젝션은 다른 카테고리보다 가장 많은 수의 CVE를 보유했으며, 총 37개의 CWE가 포함되었다. 이 카테고리에는 총 3만 건아 넘는 CVE가 보고된 크로스 사이트 스크립팅(높은 빈도/낮은 영향)과 1만 4천 건이 넘는 CVE가 보고된 SQL 인젝션(낮은 빈도/높은 영향)이 포함되었다. CWE-79 웹 페이지 생성 중 입력값의 부적절한 중립화('크로스 사이트 스크립팅')의 CVE 수가 매우 많아 이 카테고리의 평균 가중 영향 점수를 낮추는 요인이 되었다. + +## 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
37 + 13.77% + 3.08% + 100.00% + 42.93% + 7.15 + 4.32 + 1,404,249 + 62,445 +
+ + + +## 설명 + +인젝션 취약점은 신뢰할 수 없는 사용자 입력이 인터프리터(예: 브라우저, 데이터베이스, 커맨드 라인)로 전송되어 인터프리터가 해당 입력의 일부를 명령으로 실행하도록 허용하는 애플리케이션 결함이다. + +다음과 같은 경우 인젝션 공격에 취약할 수 있다. + +* 사용자가 제공한 데이터가 애플리케이션에 의해 검증, 필터링 또는 새니타이징되지 않는 경우. +* 동적 쿼리 또는 파라미터 바인딩이 없는 호출을 해당 컨텍스트에 맞는 이스케이프 없이 인터프리터에 직접 전달하는 경우. +* 객체 관계형 매핑(object-relational mapping, ORM) 검색 파라미터에 새니타이징되지 않은 입력값을 사용하여, 의도하지 않은 추가 민감 데이터 레코드를 조회하는 경우. +* 잠재적으로 악의적일 수 있는 데이터가 그대로 사용되거나, 기존 SQL 또는 커맨드 뒤에 문자열로 이어 붙여지는 경우. 그 결과 동적 쿼리, 커맨드, 또는 저장 프로시저에서 원래의 구문과 공격자가 주입한 악성 데이터가 함께 포함되게 된다. +대표적인 인젝션 유형으로는 SQL, NoSQL, OS 커맨드, 객체 관계형 매핑(ORM), LDAP, 그리고 EL(Expression Language) 및 OGNL(Object Graph Navigation Library) 인젝션이 있다. 인터프리터 종류와 관계없이 핵심 원리는 동일하다. 효과적인 탐지를 위해서는 소스 코드 리뷰와 함께, 모든 파라미터, 헤더, URL, 쿠키, JSON, SOAP, 및 XML 데이터 입력에 대한 자동화 테스트(퍼징 포함)를 수행하는 것이 좋다. CI/CD 파이프라인에 정적(SAST), 동적(DAST), 및 인터랙티브(IAST) 애플리케이션 보안 테스트 도구를 통합하여, 운영 환경 배포 전에 인젝션 결함을 사전에 식별할 수 있다. + +한편 LLM 환경에서도 유사한 계열의 인젝션 취약점이 흔해지고 있다. 이는 [OWASP LLM Top 10](https://genai.owasp.org/llm-top-10/)에서 별도로 다룬다. 특히 [LLM01:2025 프롬프트 인젝션](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) 항목에서 관련 내용을 확인할 수 있다. + + +## 대응 방안 + +인젝션 공격을 예방하는 최선의 방법은 데이터를 명령 및 쿼리로부터 분리하여 유지하는 것이다. + +* 가장 권장되는 방식은 안전한 API를 사용하는 것이다. 이는 인터프리터를 전혀 사용하지 않거나, 입력값을 파라미터화하도록 하는 인터페이스를 제공하거나, 객체 관계형 매핑(ORM) 도구를 사용하는 방식을 통해 이를 달성할 수 있다. +**참고:** 저장 프로시저는 파라미터화되어 있더라도, PL/SQL 또는 T‑SQL 내부에서 문자열 결합으로 쿼리와 데이터를 연결하거나, EXECUTE IMMEDIATE / exec()처럼 동적 실행 기능으로 적대적 입력을 실행하면 SQL 인젝션이 발생할 수 있다. + +데이터를 커맨드로부터 분리하는 것이 불가능한 경우, 다음 방법을 사용하여 위협을 줄일 수 있다. + +* 서버 측 입력값 검증은 허용 목록 기반(positive validation)을 사용한다. 다만 텍스트 입력란이나 모바일 API처럼 특수문자 입력이 필요한 경우가 많아, 이러한 방법만으로는 완전한 방어가 되기 어렵다. +* 불가피하게 동적 쿼리를 사용하는 지점이 남아 있다면, 사용 중인 인터프리터에서 사용하는 규칙에 맞춰 특수문자를 이스케이프 처리한다. +**참고:** 테이블 명과 칼럼 명 같은 SQL 구문들은 이스케이프할 수 없으므로, 사용자가 제공한 입력값을 쓰는 것은 위험하다. 이런 문제는 보고서 생성 기능에서 자주 나타난다. + +**경고** 위 방법들은 문자열을 파싱하고 이스케이프하는 복잡한 처리를 전제로 하며, 구현 실수가 발생하기 쉽고 시스템 내부 동작이 조금만 바뀌어도 방어가 쉽게 무력화될 수 있다. + +## 공격 시나리오 예시 + +**시나리오 1:** 애플리케이션이 신뢰할 수 없는 데이터를 사용하여 다음과 같은 취약 방식으로 SQL을 호출한다. + +``` +String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; +``` + +공격자는 'id' 값에 `' OR '1'='1`와 같은 페이로드를 주입하여 다음과 같이 요청을 보낼 수 있다. + +``` +http://example.com/app/accountView?id=' OR '1'='1 +``` + +그 결과 쿼리의 내용이 변경되어 accounts 테이블의 전체 레코드가 조회될 수 있다. 상황에 따라 공격자는 데이터 변경 및 삭제 또는 저장된 프로시저 실행 등 더 심각한 행위를 유도할 수도 있다. + +**시나리오 2:** 프레임워크를 사용하더라도 이를 과신하면, 여전히 인젝션에 취약할 수 있다. 취약한 하이퍼네이트 쿼리 언어(Hibernate Query Language, HQL)의 경우를 보자. + +``` +Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); +``` + +공격자는 입력값으로 `' OR custID IS NOT NULL OR custID='`를 입력한다. 이는 필터를 우회하고 모든 계정의 레코드를 반환한다. HQL은 로우(raw) SQL보다 위험한 함수가 더 적지만, 사용자 입력 값이 쿼리의 문자열로 연결될 때 여전히 권한이 없는 데이터에 접근할 수 있다. + +**시나리오 3:** 애플리케이션이 사용자 입력을 OS 커맨드로 사용한다. + +``` +String cmd = "nslookup " + request.getParameter("domain"); +Runtime.getRuntime().exec(cmd); +``` + +공격자는 `example.com; cat /etc/passwd`를 입력하여 서버에서 임의의 명령을 실행한다. + +## 참조 + +* [OWASP Proactive Controls: Secure Database Access](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database) +* [OWASP ASVS: V5 Input Validation and Encoding](https://owasp.org/www-project-application-security-verification-standard) +* [OWASP Testing Guide: SQL Injection,](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection) [Command Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection), and [ORM Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection) +* [OWASP Cheat Sheet: Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) +* [OWASP Cheat Sheet: SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) +* [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) +* [OWASP Automated Threats to Web Applications – OAT-014](https://owasp.org/www-project-automated-threats-to-web-applications/) +* [PortSwigger: Server-side template injection](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) +* [Awesome Fuzzing: a list of fuzzing resources](https://github.com/secfigo/Awesome-Fuzzing) + + + +## 해당 CWE 목록 + +* [CWE-20 Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html) + +* [CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')](https://cwe.mitre.org/data/definitions/74.html) + +* [CWE-76 Improper Neutralization of Equivalent Special Elements](https://cwe.mitre.org/data/definitions/76.html) + +* [CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')](https://cwe.mitre.org/data/definitions/77.html) + +* [CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')](https://cwe.mitre.org/data/definitions/78.html) + +* [CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html) + +* [CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)](https://cwe.mitre.org/data/definitions/80.html) + +* [CWE-83 Improper Neutralization of Script in Attributes in a Web Page](https://cwe.mitre.org/data/definitions/83.html) + +* [CWE-86 Improper Neutralization of Invalid Characters in Identifiers in Web Pages](https://cwe.mitre.org/data/definitions/86.html) + +* [CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')](https://cwe.mitre.org/data/definitions/88.html) + +* [CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')](https://cwe.mitre.org/data/definitions/89.html) + +* [CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')](https://cwe.mitre.org/data/definitions/90.html) + +* [CWE-91 XML Injection (aka Blind XPath Injection)](https://cwe.mitre.org/data/definitions/91.html) + +* [CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')](https://cwe.mitre.org/data/definitions/93.html) + +* [CWE-94 Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html) + +* [CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')](https://cwe.mitre.org/data/definitions/95.html) + +* [CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')](https://cwe.mitre.org/data/definitions/96.html) + +* [CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page](https://cwe.mitre.org/data/definitions/97.html) + +* [CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')](https://cwe.mitre.org/data/definitions/98.html) + +* [CWE-99 Improper Control of Resource Identifiers ('Resource Injection')](https://cwe.mitre.org/data/definitions/99.html) + +* [CWE-103 Struts: Incomplete validate() Method Definition](https://cwe.mitre.org/data/definitions/103.html) + +* [CWE-104 Struts: Form Bean Does Not Extend Validation Class](https://cwe.mitre.org/data/definitions/104.html) + +* [CWE-112 Missing XML Validation](https://cwe.mitre.org/data/definitions/112.html) + +* [CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')](https://cwe.mitre.org/data/definitions/113.html) + +* [CWE-114 Process Control](https://cwe.mitre.org/data/definitions/114.html) + +* [CWE-115 Misinterpretation of Output](https://cwe.mitre.org/data/definitions/115.html) + +* [CWE-116 Improper Encoding or Escaping of Output](https://cwe.mitre.org/data/definitions/116.html) + +* [CWE-129 Improper Validation of Array Index](https://cwe.mitre.org/data/definitions/129.html) + +* [CWE-159 Improper Handling of Invalid Use of Special Elements](https://cwe.mitre.org/data/definitions/159.html) + +* [CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')](https://cwe.mitre.org/data/definitions/470.html) + +* [CWE-493 Critical Public Variable Without Final Modifier](https://cwe.mitre.org/data/definitions/493.html) + +* [CWE-500 Public Static Field Not Marked Final](https://cwe.mitre.org/data/definitions/500.html) + +* [CWE-564 SQL Injection: Hibernate](https://cwe.mitre.org/data/definitions/564.html) + +* [CWE-610 Externally Controlled Reference to a Resource in Another Sphere](https://cwe.mitre.org/data/definitions/610.html) + +* [CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')](https://cwe.mitre.org/data/definitions/643.html) + +* [CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax](https://cwe.mitre.org/data/definitions/644.html) + +* [CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')](https://cwe.mitre.org/data/definitions/917.html) diff --git a/2025/docs/ko/A06_2025-Insecure_Design.md b/2025/docs/ko/A06_2025-Insecure_Design.md new file mode 100644 index 000000000..faa137cb4 --- /dev/null +++ b/2025/docs/ko/A06_2025-Insecure_Design.md @@ -0,0 +1,200 @@ +# A06:2025 안전하지 않은 설계 ![icon](../assets/TOP_10_Icons_Final_Insecure_Design.png){: style="height:80px;width:80px" align="right"} + + +## 배경 + +안전하지 않은 설계는 **[A02:2025-보안 설정 오류](A02_2025-Security_Misconfiguration.md)**와 **[A03:2025-소프트웨어 공급망 실패](A03_2025-Software_Supply_Chain_Failures.md)**가 이를 추월함에 따라, 순위에서 4위에서 6위로 두 칸 하락했다. 이 카테고리는 2021년에 도입되었으며, 이후 업계 전반에서 위협 모델링의 적용이 확대되고 보안 설계에 대한 강조가 강화되는 등 눈에 띄는 개선이 관찰되었다. 이 카테고리는 설계 및 아키텍처 결함과 관련된 위험에 초점을 맞추며, 더 많은 위협 모델링, 안전한 설계 패턴, 그리고 레퍼런스 아키텍처 사용을 요구한다. 이 카테고리에는 비즈니스 로직 취약점도 포함된다. 예를 들어, 애플리케이션이 가질 수 있는 단계(상태)와 각 단계가 서로 바뀔 수 있는 조건을 명확히 정의하지 않으면, 예상치 못한 변경을 유도하여 시스템을 공격할 수 있다. 커뮤니티 차원에서 코딩 단계의 "시프트-레프트(shift-left)"에 머무르지 않고, 설계상 안전(Secure by Design, SbD)의 원칙에 중요하게 기여하는 코딩 이전의 활동(예: 요구사항 작성 및 애플리케이션 설계)까지 확장해야 한다. 이를 위해 **[현대적 애플리케이션 보안 체계 수립: 기획 및 설계 단계](0x03_2025-Establishing_a_Modern_Application_Security_Program.md)**를 참고한다. 대표적인 CWE로는 *CWE-256: 자격 증명 저장 보호 미흡, CWE-269: 권한 관리 오류, CWE-434: 위험한 파일 형식 업로드 제한 미흡, CWE-501: 신뢰 경계 위반, 그리고 CWE-522: 자격 증명 보호 불충분*이 있다. + + + +## 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
39 + 22.18% + 1.86% + 88.76% + 35.18% + 6.96 + 4.05 + 729,882 + 7,647 +
+ + + +## 설명 + +안전하지 않은 설계는 다양한 유형의 약점을 포괄하는 범주로, 주로 "누락되었거나 비효과적인 통제 설계"로 나타난다. 또한 이 카테고리가 다른 모든 Top 10 위험의 근본 원인이라고 보기는 어렵다. 안전하지 않은 설계와 안전하지 않은 구현은 차이가 있어 구분되어야 하며, 설계 결함과 구현 결함은 근본 원인이 다르며, 개발 과정에서의 발생 시점이 다르고, 그리고 개선 방법도 다르다. 안전한 설계를 하더라도 구현상 결함을 가질 수 있으며, 이에 따라 취약점이 발생할 수 있다. 안전하지 않은 설계는 필요한 보안 통제가 특정 공격에 대해 방어하기 위해 대비되지 않았기 때문에, 완벽한 구현만으로는 수정될 수 없다. 안전하지 않은 설계의 원인 중 하나는 개발 대상 소프트웨어 및 시스템에 대한 비즈니스 리스크 프로파일링이 부족한 것이며, 그 결과 요구되는 보안 설계 수준을 적절히 산정하지 못하는 것이다. + +보안 설계를 갖추기 위한 세 가지 핵심 구성요소는 다음과 같다. + +* 요구사항 수집 및 리소스 관리 +* 안전한 설계 수립 +* 보안 개발 생명 주기(Secure Development Lifecycle, SDLC) 보유 + + +### 요구사항 수집 및 리소스 관리 + +비즈니스 부서와 협업하여 애플리케이션의 비즈니스 요구사항을 수집 및 조율하며, 모든 데이터 자산과 예상되는 비즈니스 로직에 대해 기밀성, 무결성, 가용성, 인증성 관점의 보호 요구사항을 함께 정의한다. 애플리케이션의 대외 노출 수준을 고려하고, 그리고 단순 접근 제어 수준을 넘어서는 테넌트 격리가 필요한지 고려한다. 기능 요구사항뿐 아니라 비기능 보안 요구사항까지 포함해 기술 요구사항을 정리한다. 또한, 보안 활동을 포함한 설계, 구축, 테스트, 운영 전반을 포괄하는 예산을 계획하고 협의한다. + + +### 안전한 설계 + +안전한 설계는 지속적으로 위협을 평가하고, 알려진 공격 기법을 방지하기 위해 코드가 견고하게 설계되고 테스트 되도록 보장하는 문화이자 방법론이다. 위협 모델링은 요구사항 개선 단계(혹은 유사한 활동)에 내재화되어야 하며, 이 과정에서 데이터 흐름과 접근 제어 또는 기타 보안 통제의 변화를 중심으로 검토해야 한다. 유저 스토리를 작성할 때 정상 흐름과 실패 흐름을 결정하고, 책임 당사자 및 영향받는 당사자가 이를 충분히 이해하고 합의했는지 확인한다. 또한 정상과 실패 흐름에 대한 가정과 조건을 분석하여 정확하고 바람직한 상태로 유지되는지 확인한다. 올바른 동작을 위해 필요한 가정과 조건을 어떻게 검증하고 강제할지 결정한다. 이 결과는 유저 스토리에 문서화되어야 한다. 과정 중에 발생하는 실수로부터 학습하고, 개선을 촉진하기 위해 긍정적 인센티브를 제공한다. 마지막으로, 안전한 설계는 개발이 완료된 이후에 추가할 수 있는 부가 기능도 아니고 도구도 아니다. + + +### 보안 개발 생명 주기 + +안전한 소프트웨어에는 보안 개발 생명 주기, 안전한 설계 패턴, 포장된 도로(가장 쉽고 선호되는 방법이 동시에 가장 안전한 방법이 되도록 하는 것) 방법론, 안전한 컴포넌트 라이브러리, 적절한 도구, 위협 모델링, 그리고 프로세스를 개선하기 위해 사용되는 사고 포스트모템(post-mortem)이 필요하다. 소프트웨어 프로젝트 초기부터 보안 전문가와 협업하고, 개발 전체 과정 및 소프트웨어 유지보수 단계에서도 지속적으로 협업해야 한다. 보안 개발 활동을 체계화하기 위해 [OWASP 소프트웨어 보증 성숙도 모델(Software Assurance Maturity Model, SAMM)](https://owaspsamm.org/)와 같은 성숙도 모델을 참고하는 방안을 고려한다. + +개발자가 보안에 대해 주도적으로 책임져야 한다는 인식이 종종 부족하다. 보안 인식과 책임감을 강화하고, 위험을 사전에 완화하려는 문화를 조성한다. 보안에 관한 정기적인 교류(예: 위협 모델링 세션 도중)는 모든 중요한 설계 의사결정에 보안을 포함시키기 위한 마인드셋을 형성할 수 있다. + + +## 대응 방안 + + +* 보안 및 프라이버시 관련 통제를 평가하고 설계하는 데 도움받기 위해 애플리케이션 보안 전문가와 함께 안전한 개발 생명 주기(SDLC)를 수립하고 운영한다. +* 안전한 설계 패턴과 포장된 도로 컴포넌트를 라이브러리화하여 사용한다. +* 인증, 접근 제어, 비즈니스 로직, 핵심 처리 흐름과 같은 애플리케이션의 중요한 부분을 위협 모델링한다. +* 보안 마인드셋을 생성하기 위한 교육 도구로서 위협 모델링을 사용한다. +* 유저 스토리에 보안 요구사항과 보안 통제를 반영한다. +* 애플리케이션의 각 계층(프론트엔드부터 백엔드까지)에 요청과 데이터가 타당한지 검증하는 절차를 추가한다. +* 위협 모델에 기반해 핵심 흐름이 안전한지 검증하는 단위 및 통합 테스트를 구현하고, 애플리케이션 계층별 정상 시나리오*와* 악용 시나리오를 취합한다. +* 외부 노출 수준과 보호 필요도에 따라 시스템 및 네트워크 레벨에서 분리한다. +* 전 계층에 걸쳐 설계 단계부터 테넌트 격리를 강하게 보장한다. +* 전 계층에서 테넌트를 구조적으로 격리되도록 한다. + + +## 공격 시나리오 예시 + +**시나리오 1:** 계정 복구 절차에 "질문-답변 방식"을 넣는 경우가 있는데, 이는 NIST 800-63b, OWASP ASVS 및 OWASP Top 10에서 금지하는 설계다. 질문-답변은 여러 사람이 답을 알고 있을 수 있어 본인 확인의 근거로 신뢰하기 어렵다. 따라서 해당 기능은 제거하고, 보다 안전한 복구 설계로 대체하는 것이 바람직하다. + +**시나리오 2:** 한 영화관 체인이 단체 예매 할인 정책을 운용하며, 예매 인원이 15명을 초과하면 보증금을 요구한다고 가정한다. 공격자는 이 예약 흐름을 위협 모델링한 뒤 비즈니스 로직의 허점을 찾아, 몇 번의 요청(14명으로 여러번)만으로 전 지점에 걸쳐 좌석 600석을 동시에 예약해 매출 손실을 유발할 수 있다. + +**시나리오 3:** 한 유통 체인의 전자상거래 사이트가 리셀러 구매 봇을 차단하지 못하면, 고가 그래픽카드가 대량 매집되어 리셀 채널로 흘러갈 수 있다. 이는 제조사와 유통사 모두에 대한 부정적 여론을 초래하고, 해당 제품을 어떤 가격에서도 구할 수 없었던 마니아층의 반감을 장기화한다. 제품 판매 개시 직후 극단적으로 짧은 시간 내 구매, 비정상 다량 구매 등 도메인 규칙 기반의 봇 방어 설계를 적용하면, 비정상 구매를 탐지해 거래를 거절할 수 있다. + + +## 참조 + + + +* [OWASP Cheat Sheet: Secure Design Principles](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) +* [OWASP SAMM: Design | Secure Architecture](https://owaspsamm.org/model/design/secure-architecture/) +* [OWASP SAMM: Design | Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/) +* [NIST – Guidelines on Minimum Standards for Developer Verification of Software](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) +* [The Threat Modeling Manifesto](https://threatmodelingmanifesto.org/) +* [Awesome Threat Modeling](https://github.com/hysnsec/awesome-threat-modelling) + + +## 해당 CWE 목록 + +* [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) + +* [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) + +* [CWE-256 Unprotected Storage of Credentials](https://cwe.mitre.org/data/definitions/256.html) + +* [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) + +* [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) + +* [CWE-286 Incorrect User Management](https://cwe.mitre.org/data/definitions/286.html) + +* [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) + +* [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) + +* [CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) + +* [CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) + +* [CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html) + +* [CWE-382 J2EE Bad Practices: Use of System.exit()](https://cwe.mitre.org/data/definitions/382.html) + +* [CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) + +* [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) + +* [CWE-436 Interpretation Conflict](https://cwe.mitre.org/data/definitions/436.html) + +* [CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')](https://cwe.mitre.org/data/definitions/444.html) + +* [CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) + +* [CWE-454 External Initialization of Trusted Variables or Data Stores](https://cwe.mitre.org/data/definitions/454.html) + +* [CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) + +* [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) + +* [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) + +* [CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) + +* [CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) + +* [CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) + +* [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) + +* [CWE-628 Function Call with Incorrectly Specified Arguments](https://cwe.mitre.org/data/definitions/628.html) + +* [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) + +* [CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) + +* [CWE-653 Insufficient Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) + +* [CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) + +* [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) + +* [CWE-676 Use of Potentially Dangerous Function](https://cwe.mitre.org/data/definitions/676.html) + +* [CWE-693 Protection Mechanism Failure](https://cwe.mitre.org/data/definitions/693.html) + +* [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) + +* [CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) + +* [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) + +* [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) + +* [CWE-1022 Use of Web Link to Untrusted Target with window.opener Access](https://cwe.mitre.org/data/definitions/1022.html) + +* [CWE-1125 Excessive Attack Surface](https://cwe.mitre.org/data/definitions/1125.html) diff --git a/2025/docs/ko/A07_2025-Authentication_Failures.md b/2025/docs/ko/A07_2025-Authentication_Failures.md new file mode 100644 index 000000000..755edd13c --- /dev/null +++ b/2025/docs/ko/A07_2025-Authentication_Failures.md @@ -0,0 +1,198 @@ +# A07:2025 인증 실패 ![icon](../assets/TOP_10_Icons_Final_Identification_and_Authentication_Failures.png){: style="height:80px;width:80px" align="right"} + + +## 배경 + +인증 실패는 동일하게 7위를 유지하고 있으며, 이 카테고리에 해당되는 36개의 CWE를 보다 정확하게 반영하기 위해 명칭을 약간 변경했다. 표준화된 프레임워크로부터의 이점에도 불구하고, 이 카테고리는 2021년부터 7위를 유지해 왔다. 대표적인 CWE로는 *CWE-259: 하드코딩된 비밀번호 사용*, *CWE-297: 호스트 불일치 상황에서의 인증서 검증 미흡*, *CWE-287: 부적절한 인증*, *CWE-384: 세션 고정(Session Fixation)*, 그리고 *CWE-798: 하드코딩된 자격 증명 사용*이 포함된다. + + +## 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
36 + 15.80% + 2.92% + 100.00% + 37.14% + 7.69 + 4.44 + 1,120,673 + 7,147 +
+ + + +## 설명 + +공격자가 시스템을 속여 유효하지 않거나 잘못된 사용자 정보를 정상 사용자로 인증되도록 만들 수 있는 경우, 해당 취약점이 존재한다고 판단한다. 특히 애플리케이션이 아래와 같은 행위를 실질적으로 방어하지 못하면 인증 관련 약점이 있을 수 있다. + +* 공격자가 유출된 사용자명과 비밀번호 목록을 이용해 수행하는 크리덴셜 스터핑(credential stuffing)과 같은 자동화 공격을 방어하지 못하는 경우. 최근에는 이러한 공격 유형이 하이브리드 비밀번호 공격(비밀번호 스프레이 공격)으로 확장되었으며, 공격자가 유출된 자격 증명을 변형하거나 숫자를 추가하여 접근 권한을 획득하는 방식이다. 예를 들어 획득된 비밀번호가 Password1!인 경우 Password2!, Password3! 등을 순차적으로 시도하는 것이다. + +* 무차별 대입(brute force) 또는 기타 자동화된 스크립트 기반 공격을 방어하지 못하는 경우 혹은 이러한 공격이 신속하게 차단되지 않는 경우. + +* 기본 비밀번호, 취약한 비밀번호 또는 널리 알려진 비밀번호를 허용하는 경우. 예를 들어 "Password1"와 같은 비밀번호나 "admin" 사용자명과 "admin" 비밀번호와 같은 조합이 있다. + +* 이미 유출된 아이디 및 비밀번호로 사용자가 새 계정을 생성할 수 있는 경우. + +* 안전하지 않은 "질문-답변 방식 비밀번호 찾기"과 같은 취약하거나 비효율적인 자격 증명 복구 및 비밀번호 찾기 프로세스를 사용하는 경우. + +* 평문, 암호화된, 또는 약한 해시(hash)로 해시된 비밀번호를 사용하는 경우. [A04:2025-암호 실패](https://owasp.org/Top10/2025/A04_2025-Cryptographic_Failures/) 참고. + +* 다중 인증(MFA)이 누락되어 있거나 효과적이지 않은 경우. + +* 다중 인증을 사용할 수 없을 때 적용되는 대체 수단(fallback)이 취약하거나 효과적이지 않은 경우. + +* 세션 식별자가 URL, 히든 필드, 또는 클라이언트가 접근 가능한 기타 안전하지 않은 위치에 노출되는 경우. + +* 로그인 성공 후에도 동일한 세션 식별자를 재사용하는 경우. + +* 로그아웃 또는 비활성 기간 동안 사용자 세션 또는 인증 토큰(싱글 사인온[SSO] 토큰)을 올바르게 무효화하지 않는 경우. + +* 제공된 자격 증명의 범위(scope) 및 의도된 대상(audience)을 올바르게 검증하지 않는 경우. + +## 대응 방안 + +* 가능하다면 MFA를 도입하고 강제 적용하여 자동화된 크리덴셜 스터핑, 무차별 대입 공격 및 탈취된 자격 증명의 재사용 공격을 차단한다. + +* 가능하다면 사용자가 더 나은 선택을 할 수 있도록 비밀번호 관리자의 사용을 장려하고 활성화한다. + +* 배포 시점에 기본 계정 및 기본 비밀번호가 남아있지 않도록 하며, 특히 관리자 더 주의를 기울인다. + +* 신규 및 변경 비밀번호에 대해 최악의 비밀번호 Top 10,000에 기반하여 해당 비밀번호를 설정하지 못하도록 적용한다. + +* 신규 계정 생성 및 비밀번호 변경 시, 알려진 유출 자격 증명 목록에 있는지 검증한다. (예: [haveibeenpwned.com](https://haveibeenpwned.com) 사용.) + +* 비밀번호 정책(길이, 복잡도, 주기적 변경)은 [NIST 800-63B 섹션 5.1.1](https://pages.nist.gov/800-63-3/sp800-63b.html#:~:text=5.1.1%20Memorized%20Secrets) 등 현대적 근거 기반 가이드에 맞춰 수립한다. + +* 유출이 의심되지 않는 한, 사람에게 비밀번호를 주기적으로 변경하도록 강제하지 않는다. 유출이 의심되는 경우, 즉시 비밀번호 재설정을 강제한다. + +* 계정 열거 공격에 계정 존재 여부가 드러나지 않도록 회원가입, 비밀번호 복구, API 응답 메시지를 결과와 무관하게 동일(예: "올바르지 않은 유저명 혹은 패스워드")하게 유지한다. + +* 로그인 실패에 대해 횟수 제한 또는 점진적인 지연을 적용하되, 과도한 통제로 서비스 거부 공격이 유발되지 않도록 설계한다. 또한 실패 이벤트를 로깅하고 크리덴셜 스터핑이나 무차별 대입 공격 징후 탐지 시 관리자에게 알림을 발송한다. + +* 세션은 높은 엔트로피를 가진 새로운 무작위 세션 ID를 생성하는 서버 측의 안전한 내장 세션 관리자를 사용한다. 세션 식별자는 URL에 포함되지 않아야 하며, 쿠키에 안전하게 저장되고, 로그아웃하거나 유휴 시간 및 최대 세션 시간 초과 시 무효가 되어야 한다. + +* 가능하면 인증, 아이덴티티, 세션 관리를 자체 구현하기보다 사전 제작된, 신뢰할 수 있는 시스템을 사용한다. 가능하다면 검증되고 충분히 테스트 된 도구를 구매/활용해 구현 위험을 줄인다. + +* 제공된 자격 증명의 의도된 용도를 검증한다. 예를 들어 JWT의 경우 `aud`와 `iss` 클레임 및 범위를 검증한다. + +## 공격 시나리오 예시 + +**시나리오 1:** 크리덴셜 스터핑은 유출된 계정-비밀번호 조합을 자동으로 대입하는 대표적인 공격이다. 최근에는 사람들의 습관을 악용해 비밀번호의 숫자를 증가 및 감소시켜 가며 공격하는 사례가 확인되고 있다. 예를 들어 'Winter2025'를 'Winter2026'으로 바꾸거나, 'ILoveMyDog6'를 'ILoveMyDog7' 또는 'ILoveMyDog5'로 바꾸는 식이다. 이러한 공격을 하이브리드 크리덴셜 스터핑 공격 또는 패스워드 스프레이 공격이라고 하며, 기존의 크리덴셜 스터핑보다 더 효과적일 수 있다. 애플리케이션이 자동화된 위협(무차별 대입, 스크립트, 봇) 또는 크리덴셜 스터핑에 대한 방어를 구현하지 않으면, 해당 애플리케이션은 자격 증명이 유효한지 여부를 판별하는 패스워드 오라클로 악용되어 비인가 접근을 획득하는 데 사용될 수 있다. + +**시나리오 2:** 인증 공격의 상당수는 비밀번호만으로 인증을 구성하는 구조에서 발생한다. 과거에 권장되던 주기적 비밀번호 변경 및 과도한 복잡도 정책은 오히려 비밀번호 재사용을 늘리고 기억하기 쉬운 취약 패턴을 만들 수 있다. 따라서 NIST 800-63의 권고에 맞춰 불필요한 정책을 지양하고, 중요 시스템에는 다중 인증(MFA)을 기본으로 강제 적용하는 것이 바람직하다. + +**시나리오 3:** 애플리케이션의 세션 타임아웃이 올바르게 구현되지 않았다. 사용자가 공용 컴퓨터에서 애플리케이션에 접근한 뒤 "로그아웃" 버튼 대신 브라우저 탭을 닫고 자리를 떠난다. 또 다른 예로, SSO(Single Sign-On) 환경에서 단일 로그아웃(Single Logout)이 지원되지 않는 경우가 있다. 즉, SSO로 메일, 문서 시스템, 채팅 시스템에 한 번에 로그인되지만, 로그아웃은 현재 사용 중인 시스템에서만 로그아웃 처리된다. 이 상태에서 공격자가 동일한 브라우저를 사용하면, 다른 애플리케이션에는 세션이 남아 있어 피해자 계정에 접근할 수 있다. 동일한 문제는 민감한 애플리케이션이 적절히 종료되지 않은 상태에서 동료가 잠금 해제된 컴퓨터에 일시적으로 접근할 수 있는 사무실 환경에서도 발생할 수 있다. + +## 참조 + +* [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) + +* [OWASP Secure Coding Practices](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/01-introduction/05-introduction) + + +## 해당 CWE 목록 + +* [CWE-258 Empty Password in Configuration File](https://cwe.mitre.org/data/definitions/258.html) + +* [CWE-259 Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html) + +* [CWE-287 Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) + +* [CWE-288 Authentication Bypass Using an Alternate Path or Channel](https://cwe.mitre.org/data/definitions/288.html) + +* [CWE-289 Authentication Bypass by Alternate Name](https://cwe.mitre.org/data/definitions/289.html) + +* [CWE-290 Authentication Bypass by Spoofing](https://cwe.mitre.org/data/definitions/290.html) + +* [CWE-291 Reliance on IP Address for Authentication](https://cwe.mitre.org/data/definitions/291.html) + +* [CWE-293 Using Referer Field for Authentication](https://cwe.mitre.org/data/definitions/293.html) + +* [CWE-294 Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html) + +* [CWE-295 Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html) + +* [CWE-297 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/297.html) + +* [CWE-298 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/298.html) + +* [CWE-299 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/299.html) + +* [CWE-300 Channel Accessible by Non-Endpoint](https://cwe.mitre.org/data/definitions/300.html) + +* [CWE-302 Authentication Bypass by Assumed-Immutable Data](https://cwe.mitre.org/data/definitions/302.html) + +* [CWE-303 Incorrect Implementation of Authentication Algorithm](https://cwe.mitre.org/data/definitions/303.html) + +* [CWE-304 Missing Critical Step in Authentication](https://cwe.mitre.org/data/definitions/304.html) + +* [CWE-305 Authentication Bypass by Primary Weakness](https://cwe.mitre.org/data/definitions/305.html) + +* [CWE-306 Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html) + +* [CWE-307 Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html) + +* [CWE-308 Use of Single-factor Authentication](https://cwe.mitre.org/data/definitions/308.html) + +* [CWE-309 Use of Password System for Primary Authentication](https://cwe.mitre.org/data/definitions/309.html) + +* [CWE-346 Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html) + +* [CWE-350 Reliance on Reverse DNS Resolution for a Security-Critical Action](https://cwe.mitre.org/data/definitions/350.html) + +* [CWE-384 Session Fixation](https://cwe.mitre.org/data/definitions/384.html) + +* [CWE-521 Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html) + +* [CWE-613 Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html) + +* [CWE-620 Unverified Password Change](https://cwe.mitre.org/data/definitions/620.html) + +* [CWE-640 Weak Password Recovery Mechanism for Forgotten Password](https://cwe.mitre.org/data/definitions/640.html) + +* [CWE-798 Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) + +* [CWE-940 Improper Verification of Source of a Communication Channel](https://cwe.mitre.org/data/definitions/940.html) + +* [CWE-941 Incorrectly Specified Destination in a Communication Channel](https://cwe.mitre.org/data/definitions/941.html) + +* [CWE-1390 Weak Authentication](https://cwe.mitre.org/data/definitions/1390.html) + +* [CWE-1391 Use of Weak Credentials](https://cwe.mitre.org/data/definitions/1391.html) + +* [CWE-1392 Use of Default Credentials](https://cwe.mitre.org/data/definitions/1392.html) + +* [CWE-1393 Use of Default Password](https://cwe.mitre.org/data/definitions/1393.html) diff --git a/2025/docs/ko/A08_2025-Software_or_Data_Integrity_Failures.md b/2025/docs/ko/A08_2025-Software_or_Data_Integrity_Failures.md new file mode 100644 index 000000000..6b9843ed0 --- /dev/null +++ b/2025/docs/ko/A08_2025-Software_or_Data_Integrity_Failures.md @@ -0,0 +1,121 @@ +# A08:2025 소프트웨어 또는 데이터 무결성 실패 ![icon](../assets/TOP_10_Icons_Final_Software_and_Data_Integrity_Failures.png){: style="height:80px;width:80px" align="right"} + +## 배경 + +소프트웨어 또는 데이터 무결성 실패는 8위를 유지했으며, "소프트웨어 *및* 데이터 무결성 실패"에서 약간의 명확화를 위해 명칭이 소폭 변경되었다. 해당 카테고리는 소프트웨어 공급망 실패보다 더 하위 수준에서, 신뢰 경계를 유지하지 못하고 소프트웨어, 코드, 데이터 아티팩트의 무결성을 검증하지 못하는 문제에 초점을 둔다. 즉, 무결성을 확인하지 않은 채 소프트웨어 업데이트와 중요 데이터에 대해 가정하는 행위를 다룬다. 대표적인 CWE로는 *CWE-829: 신뢰할 수 없는 통제 영역에서 기능 포함*, *CWE-915: 동적 결정 객체 속성의 부적절하게 통제된 수정*, *CWE-502: 신뢰할 수 없는 데이터의 역직렬화*가 있다. + + +## 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
14 + 8.98% + 2.75% + 78.52% + 45.49% + 7.11 + 4.79 + 501,327 + 3,331 +
+ + + +## 설명 + +소프트웨어 및 데이터 무결성 실패는 검증되지 않은 코드나 데이터가 신뢰 가능한 것으로 취급되는 일을 막지 못하는 코드 및 인프라에서 발생하는 문제다. 예를 들어, 애플리케이션이 신뢰할 수 없는 출처, 저장소, 콘텐츠 전송 네트워크(CDN)에서 제공되는 플러그인, 라이브러리, 모듈에 의존하는 경우가 이에 해당한다. 소프트웨어 무결성 검증을 수행하지 않거나 제공하지 않는 불안전한 CI/CD 파이프라인은 비인가 접근, 불안전하거나 악의적인 코드, 또는 시스템 손상으로 이어질 잠재적 위험을 초래할 수 있다. 또 다른 예로, CI/CD가 신뢰할 수 없는 장소에서 코드나 아티팩트를 가져오고, 사용 전에 서명 확인 등 유사한 메커니즘으로 이를 검증하지 않는 경우가 있다. 마지막으로, 많은 애플리케이션에는 자동 업데이트 기능이 포함되어 있는데, 업데이트가 충분한 무결성 검증 없이 다운로드되어 기존에 신뢰하던 애플리케이션에 그대로 적용되는 경우가 있다. 이런 구조에서는 공격자가 자신의 업데이트를 업로드해 이를 모든 설치본에 배포, 실행되도록 만들 수 있다. 또 다른 예로, 객체나 데이터가 공격자가 확인하고 수정할 수 있는 형태로 인코딩되거나 직렬화된 경우, 역직렬화 취약점이 발생할 수 있다. + +## 대응 방안 + + + +* 디지털 서명 또는 유사한 메커니즘을 사용하여 소프트웨어나 데이터가 예상된 출처에서 왔고 변조되지 않았음을 검증한다. +* npm이나 Maven과 같은 라이브러리 및 의존성이 신뢰할 수 있는 저장소만 사용하도록 보장한다. 위험 수준이 높은 시스템이라면, 잘 검증된 저장소를 내부에 호스팅하는 방안을 고려한다. +* 악의적인 목적의 코드 또는 설정이 소프트웨어 파이프라인에 유입될 가능성을 최소화하기 위해, 코드 및 설정 변경에 대한 검토 절차를 마련한다. +* 빌드 및 배포 과정에서 흐르는 코드의 무결성을 보장할 수 있도록, CI/CD 파이프라인에 적절한 격리, 구성, 접근 제어를 적용한다. +* 서명되지 않았거나 암호화되지 않은 직렬화 데이터가 신뢰할 수 없는 클라이언트로부터 전달된다면, 변조 또는 재전송 여부를 탐지하기 위한 무결성 검사나 전자 서명 없이는 사용하지 않는다. + + +## 공격 시나리오 예시 + +**시나리오 1 신뢰할 수 없는 외부 웹 기능 연동:** 한 회사가 고객 지원 기능 제공을 위해 외부 서비스 제공업체를 사용한다. 편의상 `myCompany.SupportProvider.com`을 `support.myCompany.com`으로 DNS 매핑해 두었다. 그 결과 `myCompany.com` 도메인에 설정된 모든 쿠키(인증 쿠키 포함)가 이제 고객 지원 제공업체로 전송된다. 고객 지원 제공업체의 인프라에 접근할 수 있는 누구든 `support.myCompany.com`을 방문한 모든 사용자의 쿠키를 탈취하여 세션 하이재킹 공격을 수행할 수 있다. + +**시나리오 2 서명 없이 업데이트:** 많은 가정용 라우터, 셋톱박스, 장치 펌웨어 등은 업데이트를 위해 서명된 펌웨어를 사용하지 않는다. 서명되지 않은 펌웨어는 공격자에게 점점 더 매력적인 표적이 되고 있으며, 앞으로도 이러한 상황은 악화될 것으로 예상된다. 이는 대개 향후 버전에서 수정한 뒤 이전 버전이 자연스럽게 사라질 때까지 기다려야 수밖에 없는 경우가 많다는 점에서 큰 우려 사항이다. + +**시나리오 3 신뢰할 수 없는 출처의 패키지 사용:** 한 개발자가 찾고 있는 패키지의 최신 버전을 구하기 어렵자, 일반적으로 사용하는 신뢰할 수 있는 패키지 관리자가 아니라 온라인 웹사이트에서 패키지를 다운로드한다. 해당 패키지는 서명되어 있지 않으므로 무결성을 보장할 방법이 없다. 해당 패키지에는 악의적인 코드가 포함되어 있다. + +**시나리오 4 불안전한 역직렬화:** 한 React 애플리케이션이 여러 Spring Boot 마이크로서비스를 호출한다. 함수형 프로그래밍을 지향하던 이들은 코드의 불변성을 보장하려고 했다. 그들이 선택한 해결책은 사용자 상태를 직렬화하여 각 요청마다 이를 주고받는 것이었다. 공격자는 (base64로 인코딩된) "rO0" 자바 객체 시그니처를 발견하고, [Java Deserialization Scanner](https://github.com/federicodotta/Java-Deserialization-Scanner)를 사용해 애플리케이션 서버에서 원격 코드 실행(RCE)을 획득한다. + +## 참조 + +* [OWASP Cheat Sheet: Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Infrastructure as Code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Deserialization](https://wiki.owasp.org/index.php/Deserialization_Cheat_Sheet) +* [SAFECode Software Integrity Controls](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +* [A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) +* [CodeCov Bash Uploader Compromise](https://about.codecov.io/security-update) +* [Securing DevOps by Julien Vehent](https://www.manning.com/books/securing-devops) +* [Insecure Deserialization by Tenendo](https://tenendo.com/insecure-deserialization/) + + +## 해당 CWE 목록 + +* [CWE-345 Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html) + +* [CWE-353 Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353.html) + +* [CWE-426 Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) + +* [CWE-427 Uncontrolled Search Path Element](https://cwe.mitre.org/data/definitions/427.html) + +* [CWE-494 Download of Code Without Integrity Check](https://cwe.mitre.org/data/definitions/494.html) + +* [CWE-502 Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) + +* [CWE-506 Embedded Malicious Code](https://cwe.mitre.org/data/definitions/506.html) + +* [CWE-509 Replicating Malicious Code (Virus or Worm)](https://cwe.mitre.org/data/definitions/509.html) + +* [CWE-565 Reliance on Cookies without Validation and Integrity Checking](https://cwe.mitre.org/data/definitions/565.html) + +* [CWE-784 Reliance on Cookies without Validation and Integrity Checking in a Security Decision](https://cwe.mitre.org/data/definitions/784.html) + +* [CWE-829 Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html) + +* [CWE-830 Inclusion of Web Functionality from an Untrusted Source](https://cwe.mitre.org/data/definitions/830.html) + +* [CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html) + +* [CWE-926 Improper Export of Android Application Components](https://cwe.mitre.org/data/definitions/926.html) diff --git a/2025/docs/ko/A09_2025-Security_Logging_and_Alerting_Failures.md b/2025/docs/ko/A09_2025-Security_Logging_and_Alerting_Failures.md new file mode 100644 index 000000000..26a1f4a93 --- /dev/null +++ b/2025/docs/ko/A09_2025-Security_Logging_and_Alerting_Failures.md @@ -0,0 +1,135 @@ +# A09:2025 보안 로깅 및 알림 실패 ![icon](../assets/TOP_10_Icons_Final_Security_Logging_and_Monitoring_Failures.png){: style="height:80px;width:80px" align="right"} + + +## 배경 + +보안 로깅 및 알림 실패는 9위를 유지한다. 명칭이 약간 변경되었는데, 로그에서 발생한 이벤트의 조치를 유도하는 데 필요한 알림 기능을 강조하기 위함이다. 이 카테고리는 특성상 데이터상 순위가 낮게 나타나기 쉬우며, 커뮤니티 설문 투표를 통해 이번이 세 번째로 Top 10에 포함되었다. 또한 테스트가 극도로 어렵고, CVE/CVSS 데이터에서의 비중이 매우 낮지만(총 723개의 CVE), 가시성 확보, 인시던트 알림, 그리고 포렌식 측면에서 큰 영향을 미칠 수 있다. 해당 카테고리에 포함되는 CWE는 *CWE-117: 로그 기록 시 출력 인코딩 처리 미흡, CWE-532: 로그 파일에 민감 정보 삽입, 그리고 CWE-778: 불충분한 로깅*이다. + + +## 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
5 + 11.33% + 3.91% + 85.96% + 46.48% + 7.19 + 2.65 + 260,288 + 723 +
+ + + +## 설명 + +로깅과 모니터링이 없으면 공격 및 침해를 탐지할 수 없으며, 알림이 없으면 보안 인시던트 발생 시 신속하고 효과적으로 대응하기가 매우 어렵다. 아래와 같은 경우, 능동적 대응을 위한 로깅, 지속적 모니터링, 탐지, 알림이 부족한 것으로 볼 수 있다. + +* 로그인, 로그인 실패, 중요 거래 데이터 등 감사가 필요한 대상의 이벤트가 누락되거나 기준이나 일관성이 없이(예: 성공 로그인만 기록) 로깅되는 경우. +* 경고 및 오류가 로그 메시지를 생성하지 않거나, 부적절하거나, 불명확한 로그를 생성하는 경우. +* 로그가 위변조되지 않도록 무결성 보호가 적용되지 않는 경우. +* 애플리케이션 및 API 로그를 기반으로 한 이상징후 모니터링이 수행되지 않는 경우. +* 로그가 로컬에만 보관되고 백업이 적절히 수행되지 않는 경우. +* 적절한 알림 임계값 및 대응 에스컬레이션 절차가 마련되어 있지 않거나 효과적이지 않은 경우. 알림이 적시에 확인되지 않거나 검토되지 않는 경우. +* 동적 애플리케이션 보안 테스트(DAST) 도구(예: Burp 또는 ZAP)에 의한 침투 테스트 및 스캔이 알림을 트리거하지 않는 경우. +* 진행 중인 공격을 실시간 혹은 준실시간으로 탐지하지 못하거나 상위 단계로 에스컬레이션하거나 알림을 발생시키지 못하는 경우. +* 로그 및 알림을 사용자 또는 공격자에게 노출하거나([A01:2025-불충분한 접근 제어](A01_2025-Broken_Access_Control.md) 참조), 로깅되면 안 되는 민감정보(예: PII 또는 PHI)를 로깅함으로써 민감 정보 유출에 취약한 경우. +* 로그 데이터 인코딩이 부적절해 로깅 또는 모니터링 시스템 자체가 인젝션 등 공격 대상이 되는 경우. +* 애플리케이션이 오류 및 예외 처리를 누락 또는 오처리하여 시스템이 오류 발생 자체를 인지하지 못하고, 결과적으로 문제를 로그로 남길 수 없는 경우. +* 특정 상황을 탐지해 알림을 발생시키기 위한 인시던트 유스케이스가 없거나, 갱신이 되지 않아 현행 환경을 충분히 반영하지 못하는 경우. +* 너무 많은 오탐 알림으로 인해 중요한 알림과 중요하지 않은 알림을 구분할 수 없게 되어, 알림이 너무 늦게 인지되거나 전혀 인지되지 않는 경우(SOC 팀의 물리적 과부하). +* 유스케이스에 대한 플레이북이 불완전하거나, 최신이 아니거나, 누락되어 감지된 알림을 올바르게 처리할 수 없는 경우. + + +## 대응 방안 + +개발자는 애플리케이션의 위험도에 따라 아래 통제 항목 중 일부 또는 전체를 구현해야 한다. + +* 모든 로그인, 접근 통제 및 서버 측 입력 검증 실패에 대해 로그를 남기며, 의심스럽거나 악성인 계정을 식별할 수 있을 만큼 충분한 유저 컨텍스트를 포함하고, 사후 포렌식 분석을 위해 충분한 기간 동안 저장한다. +* 보안 통제가 적용된 구간은 성공 및 실패 여부와 무관하게 모두 로깅 대상에 포함한다. +* 로그는 중앙 로그 플랫폼이 쉽게 수집할 수 있는 표준화된 포맷으로 생성한다. +* 로그 데이터는 인코딩을 확실히 적용해 로깅 및 모니터링 시스템의 로그 기반 인젝션 및 공격을 예방한다. +* 모든 트랜잭션에 대해 감사 로그를 남기고, 추가만 가능한(append-only) 데이터베이스 테이블 등으로 삭제 및 변조를 어렵게 하는 무결성 통제를 적용한다. +* 오류가 발생한 모든 트랜잭션은 롤백되고 다시 시작되도록 한다. 또한, 페일 클로즈드(fail closed)되도록 한다. +* 애플리케이션 또는 사용자 행위가 의심스러운 경우 알림을 발행한다. 개발자가 이를 코드로 구현할 수 있도록 가이드를 제공하거나, 이를 위한 시스템을 구매한다. +* DevSecOps 및 보안 팀은 SOC(Security Operations Center) 팀이 의심 활동을 신속히 탐지하고 대응할 수 있도록, 플레이북을 포함한 효과적인 모니터링 및 알림 유스케이스를 수립해야 한다. +* 공격자를 위한 함정으로 '허니 토큰'을 애플리케이션에 추가한다. 예를 들어 데이터베이스 내에 실제 사용자 및/또는 시스템 계정 형태의 데이터 또는 식별자를 삽입한다. 허니토큰은 정상 업무에서는 사용되지 않으므로, 접근이 발생하면 관련 이벤트가 로그로 남고 오탐이 거의 없는 알림 조건으로 활용할 수 있다. +* 필요 시 행위 기반 분석 및 AI를 보조 수단으로 활용해 오탐을 낮추고 알림 품질을 개선한다. +* NIST 800-61r2 이상 수준의 인시던트 대응 및 복구 계획을 마련하고, 개발자에게 공격/인시던트 징후를 교육해 보고 및 초기 대응이 가능하도록 한다. + + +추가로, OWASP ModSecurity 핵심 규칙 세트(Core Rule Set)와 같은 상용 및 오픈소스 애플리케이션 보호 제품, 그리고 사용자 정의 대시보드 및 알림 기능을 제공하여 대응에 도움이 될 수 있는 Elasticsearch, Logstash, Kibana(ELK) 스택과 같은 오픈소스 로그 상관분석 소프트웨어가 있다. 공격에 준실시간으로 대응하거나 이를 차단하는 데 도움이 되는 상용 옵저버빌리티 도구도 존재한다. + + +## 공격 시나리오 예시 + +**시나리오 1:** 한 아동 건강보험 제공업체의 웹사이트 운영자는 모니터링 및 로깅 부재로 인해 침해 사고를 탐지하지 못했다. 외부 제3자가 해당 제공업체에 공격자가 350만 명이 넘는 아동의 건강 정보 기록 수천 건에 접근하여 이를 수정했다고 통보했다. 사후 분석에서는 웹사이트 개발자가 중대한 취약점을 장기간 방치된 정황이 확인되었으며, 시스템 로그가 모니터링되고 있지 않아 침해가 2013년부터 7년 이상 지속되었을 가능성도 존재한다. + +**시나리오 2:** 인도의 주요 항공사에서 여권 및 신용카드 데이터를 포함해 수백만 명 승객의 10년 이상 분량 개인정보가 유출되었다. 해당 유출은 제3자 클라우드 호스팅 제공업체에서 발생했으며, 해당 제공업체는 일정 시간이 지난 뒤에야 항공사에 침해 사실을 통보했다. + +**시나리오 3:** 유럽의 주요 항공사는 GDPR 신고 의무가 있는 침해 사고를 겪었다. 보고에 따르면, 결제 애플리케이션 보안 취약점이 공격자에 의해 악용되었고, 공격자는 40만 건이 넘는 고객 결제 기록이 탈취되었다. 그 결과 항공사는 개인정보 감독기관으로부터 2,000만 파운드의 벌금을 부과받았다. + + +## 참조 + +- [OWASP Proactive Controls: C9: Implement Logging and Monitoring](https://top10proactive.owasp.org/archive/2024/the-top-10/c9-security-logging-and-monitoring/) + +- [OWASP Application Security Verification Standard: V16 Security Logging and Error Handling](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md) + +- [OWASP Cheat Sheet: Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) + +- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) + +- [Data Integrity: Recovering from Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-11/final) + +- [Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-25/final) + +- [Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-26/final) + +- [Real world example of such failures in Snowflake Breach](https://www.huntress.com/threat-library/data-breach/snowflake-data-breach) + + +## 해당 CWE 목록 + +* [CWE-117 Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) + +* [CWE-221 Information Loss of Omission](https://cwe.mitre.org/data/definitions/221.html) + +* [CWE-223 Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) + +* [CWE-532 Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html) + +* [CWE-778 Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html) \ No newline at end of file diff --git a/2025/docs/ko/A10_2025-Mishandling_of_Exceptional_Conditions.md b/2025/docs/ko/A10_2025-Mishandling_of_Exceptional_Conditions.md new file mode 100644 index 000000000..fd02f9d51 --- /dev/null +++ b/2025/docs/ko/A10_2025-Mishandling_of_Exceptional_Conditions.md @@ -0,0 +1,132 @@ +# A10:2025 부적절한 예외 처리 ![icon](../assets/TOP_10_Icons_Final_Mishandling_of_Exceptional_Conditions.png){: style="height:80px;width:80px" align="right"} + +## 배경 + +부적절한 예외 처리는 2025년에 신설된 카테고리다. 이 카테고리는 24개의 CWE를 포함하며, 부적절한 오류 처리, 논리적 오류, 페일 오픈(fail open), 그 외 시스템이 비정상적인 상황에서 마주할 수 있는 시나리오를 다룬다. 이 카테고리에는 이전에 낮은 코드 품질과 연관되었던 일부 CWE가 포함되어 있다. 기존의 낮은 코드 품질 카테고리는 너무 광범위했기에, 부적절한 예외 처리라는 구체적인 카테고리로 분리하여 더 명확한 가이드를 제공하고자 했다. + +대표적인 CWE로는 *CWE-209: 민감한 정보가 포함된 오류 메시지 생성*, *CWE-234: 누락된 파라미터 처리 실패*, *CWE-274: 권한 부족 처리 미흡*, *CWE-476: NULL 포인터 역참조*, 그리고 *CWE-636: 안전하지 않은 실패 처리('Failing Open')*가 있다. + + +## 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
24 + 20.67% + 2.95% + 100.00% + 37.95% + 7.11 + 3.81 + 769,581 + 3,416 +
+ + + +## 설명 + +부적절한 예외 처리는 프로그램이 비정상적이고 예측 불가능한 상황을 예방, 탐지, 대응하지 못할 때 발생하며, 이로 인해 시스템 충돌, 예상치 못한 동작, 때로는 보안 취약점까지 초래할 수 있다. 이는 다음 세 가지 실패 중 하나 이상을 포함한다. 비정상적인 상황을 사전에 예방하지 못하거나, 발생 시 이를 식별하지 못하거나, 발생 후 적절히 대응하지 못하는 경우다. + +예외 상황은 다음과 같은 원인으로 발생할 수 있다. 누락되거나 불완전한 입력 검증, 발생 지점이 아닌 상위 레벨에서의 지연된 오류 처리, 메모리, 권한, 네트워크 문제 등 예기치 않은 환경 상태, 일관성 없는 예외 처리, 또는 전혀 처리되지 않는 예외로 인해 시스템이 알 수 없고 예측 불가능한 상태에 빠지는 경우다. 애플리케이션이 다음에 무엇을 해야 할지 알 수 없는 상태에 빠진다면, 예외 처리가 실패한 것이다. 이러한 오류와 예외는 발견이 어려워 장기간 보안을 위협할 수 있다. + +부적절한 예외 처리로 인해 다양한 보안 취약점이 발생할 수 있다. 예를 들어 논리 버그, 오버플로우, 레이스 컨디션, 부정 거래, 메모리, 상태, 리소스, 타이밍, 인증, 인가 관련 문제 등이 있다. 이러한 유형의 취약점은 시스템 또는 데이터의 기밀성, 가용성, 무결성에 부정적인 영향을 미칠 수 있다. 공격자는 애플리케이션의 결함 있는 오류 처리를 악용하여 이 취약점을 공격한다. + +## 대응 방안 + +예외 상황을 적절히 처리하려면 이러한 상황에 대비한 계획을 세워야 한다(최악의 상황을 예상하라). 모든 시스템 오류를 발생 지점에서 캐치(catch)하고 이를 처리해야한다. 여기서 처리란 문제 해결을 위한 의미 있는 조치를 취하고 정상 상태로 복구하는 것을 의미한다. 처리 과정에는 오류 발생 시 사용자에게 이해하기 쉬운 방식으로 알리고, 이벤트를 로깅하며, 필요하다고 판단되면 알림을 발송하는 것이 포함되어야 한다. 또한 놓친 예외가 있을 경우를 대비해 전역 예외 핸들러(Global Exception Handler)를 구현해야 한다. 이상적으로는 반복되는 오류나 진행 중인 공격을 나타내는 패턴을 감시하고, 이에 대응, 방어, 차단할 수 있는 모니터링 또는 옵저버빌리티 도구를 갖추는 것이 좋다. 이를 통해 오류 처리 취약점을 악용하는 스크립트와 봇에 대응하고 차단할 수 있다. + +예외 상황을 캐치하고 처리하면 프로그램의 기반 인프라가 예측 불가능한 상황에 노출되는 것을 방지할 수 있다. 트랜잭션 처리 도중이라면, 트랜잭션의 모든 부분을 롤백하고 처음부터 다시 시작하는 것이 매우 중요하다(이를 fail closed라고 한다). 트랜잭션을 중간 상태에서 복구하려는 시도는 종종 복구 불가능한 오류를 만들어낸다. + +가능하다면 속도 제한(rate limit), 리소스 쿼터, 스로틀링 등 다양한 제한을 적용하여 애초에 예외 상황이 발생하지 않도록 예방한다. 정보기술 분야에서 무제한이어야 하는 것은 없다. 제한이 없으면 애플리케이션 복원력 저하, 서비스 거부(DoS), 무차별 대입 공격 성공, 과도한 클라우드 비용 등의 문제가 발생할 수 있다. + +특정 빈도 이상으로 동일한 오류가 반복될 경우, 개별 오류 메시지 대신 발생 횟수와 시간대를 보여주는 통계 형태로 출력하는 것을 고려한다. 이 정보는 자동화된 로깅 및 모니터링을 방해하지 않도록 원본 메시지에 추가하는 방식으로 처리해야 한다. [A09:2025 보안 로깅 및 알림 실패](A09_2025-Security_Logging_and_Alerting_Failures.md)를 참고한다. + +이 외에도 다음 사항을 포함해야 한다. 엄격한 입력 검증(허용해야 하는 위험 문자에 대한 새니타이징 또는 이스케이프 처리 포함), *중앙 집중화된* 오류 처리, 로깅, 모니터링, 알림 체계, 그리고 전역 예외 핸들러다. 하나의 애플리케이션에서 예외 처리를 위한 여러 함수를 두어서는 안 되며, 한 곳에서 동일한 방식으로 처리해야 한다. 또한 이 섹션의 모든 권고 사항에 대해 프로젝트 보안 요구사항을 수립하고, 설계 단계에서 위협 모델링 또는 보안 설계 검토를 수행하며, 코드 리뷰나 정적 분석을 실시하고, 최종 시스템에 대해 스트레스, 성능, 침투 테스트를 수행해야 한다. + +가능하다면 조직 전체가 동일한 방식으로 예외 상황을 처리하는 것이 좋다. 이렇게 하면 이 중요한 보안 통제에 대한 코드 리뷰와 감사가 더 쉬워진다. + +## 공격 시나리오 예시 + +**시나리오 1:** 애플리케이션이 파일 업로드 시 예외를 캐치하되 리소스를 해제하지 않으면, 예외가 발생할 때마다 리소스가 잠긴 채로 남는다. 이로 인해 리소스가 고갈되어 서비스 거부(DoS)로 이어질 수 있다. + +**시나리오 2:** 데이터베이스 오류가 사용자에게 그대로 노출되면 민감한 시스템 정보가 유출된다. 공격자는 이를 악용해 의도적으로 오류를 유발하고, 수집한 정보를 기반으로 더 정교한 SQL 인젝션 공격을 구성할 수 있다. + +**시나리오 3:** 공격자가 네트워크 장애를 일으켜 여러 단계로 이루어진 트랜잭션을 중간에 방해할 수 있다. 예를 들어 트랜잭션이 사용자 계좌 출금, 대상 계좌 입금, 트랜잭션 로깅 순서로 처리된다고 가정한다면, 중간에 오류가 발생해도 시스템이 전체 트랜잭션을 롤백(안전한 실패)하지 않으면 문제가 생긴다. 공격자는 이를 악용해 사용자 계좌에서 돈만 빠져나가게 하거나, 레이스 컨디션을 이용해 대상 계좌로 여러 번 송금할 수 있다. + +## 참조 + +- [OWASP MASVS‑RESILIENCE](https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/) + +- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) + +- [OWASP Cheat Sheet: Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html) + +- [OWASP Application Security Verification Standard (ASVS): V16.5 Error Handling](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md#v165-error-handling) + +- [OWASP Testing Guide: 4.8.1 Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) + +* [Best practices for exceptions (Microsoft, .Net)](https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions) + +* [Clean Code and the Art of Exception Handling (Toptal)](https://www.toptal.com/developers/abap/clean-code-and-the-art-of-exception-handling) + +* [General error handling rules (Google for Developers)](https://developers.google.com/tech-writing/error-messages/error-handling) + +* [Example of real-world mishandling of an exceptional condition](https://www.firstreference.com/blog/human-error-and-internal-control-failures-cause-us62m-fine/) + +## 해당 CWE 목록 +* [CWE-209 Generation of Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html) +* [CWE-215 Insertion of Sensitive Information Into Debugging Code](https://cwe.mitre.org/data/definitions/215.html) +* [CWE-234 Failure to Handle Missing Parameter](https://cwe.mitre.org/data/definitions/234.html) +* [CWE-235 Improper Handling of Extra Parameters](https://cwe.mitre.org/data/definitions/235.html) +* [CWE-248 Uncaught Exception](https://cwe.mitre.org/data/definitions/248.html) +* [CWE-252 Unchecked Return Value](https://cwe.mitre.org/data/definitions/252.html) +* [CWE-274 Improper Handling of Insufficient Privileges](https://cwe.mitre.org/data/definitions/274.html) +* [CWE-280 Improper Handling of Insufficient Permissions or Privileges](https://cwe.mitre.org/data/definitions/280.html) +* [CWE-369 Divide By Zero](https://cwe.mitre.org/data/definitions/369.html) +* [CWE-390 Detection of Error Condition Without Action](https://cwe.mitre.org/data/definitions/390.html) +* [CWE-391 Unchecked Error Condition](https://cwe.mitre.org/data/definitions/391.html) +* [CWE-394 Unexpected Status Code or Return Value](https://cwe.mitre.org/data/definitions/394.html) +* [CWE-396 Declaration of Catch for Generic Exception](https://cwe.mitre.org/data/definitions/396.html) +* [CWE-397 Declaration of Throws for Generic Exception](https://cwe.mitre.org/data/definitions/397.html) +* [CWE-460 Improper Cleanup on Thrown Exception](https://cwe.mitre.org/data/definitions/460.html) +* [CWE-476 NULL Pointer Dereference](https://cwe.mitre.org/data/definitions/476.html) +* [CWE-478 Missing Default Case in Multiple Condition Expression](https://cwe.mitre.org/data/definitions/478.html) +* [CWE-484 Omitted Break Statement in Switch](https://cwe.mitre.org/data/definitions/484.html) +* [CWE-550 Server-generated Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/550.html) +* [CWE-636 Not Failing Securely ('Failing Open')](https://cwe.mitre.org/data/definitions/636.html) +* [CWE-703 Improper Check or Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/703.html) +* [CWE-754 Improper Check for Unusual or Exceptional Conditions](https://cwe.mitre.org/data/definitions/754.html) +* [CWE-755 Improper Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/755.html) +* [CWE-756 Missing Custom Error Page](https://cwe.mitre.org/data/definitions/756.html) diff --git a/2025/docs/ko/X01_2025-Next_Steps.md b/2025/docs/ko/X01_2025-Next_Steps.md new file mode 100644 index 000000000..1522fd819 --- /dev/null +++ b/2025/docs/ko/X01_2025-Next_Steps.md @@ -0,0 +1,324 @@ +# 다음 단계 + +OWASP Top 10은 이름 그대로 가장 중요한 10가지 위험으로만 선정한다. 각 버전의 OWASP Top 10에는 포함 여부를 두고 충분히 검토되었으나, 다른 위험들이 더 빈번하게 발생하고 영향도도 더 컸기 때문에 최종 목록에 포함되지 않은 "경계선상"의 위험들이 존재한다. + +아래의 세 가지 이슈는 발견 및 조치에 투자할 만한 가치가 크며, 성숙한 애플리케이션 보안 프로그램을 목표로 하는 조직, 보안 컨설팅 회사, 또는 제품의 커버리지를 확장하려는 보안 도구 벤더에 특히 유용할 수 있다. + + +## X01:2025 애플리케이션 복원력 부족 + +### 배경 + +이 카테고리의 명칭은 2021년 버전의 서비스 거부(Denial of Service)에서 현재 명칭으로 변경됐다. 기존 명칭은 근본 원인보다는 발생 현상을 설명하는 성격이 강해, 이를 보완하기 위해 재명명되었다. 이 카테고리는 복원력과 관련된 약점을 설명하는 CWE에 초점을 둔다. 점수 산정은 A10:2025-부적절한 예외 처리와 매우 근접했다. 관련된 CWE로는 *CWE-400: 통제되지 않은 자원 소비, CWE-409: 고압축 데이터의 부적절한 처리(데이터 증폭), CWE-674: 통제되지 않은 재귀*, 그리고 *CWE-835: 종료 조건에 도달할 수 없는 루프(무한 루프)*가 있다. + + +### 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
16 + 20.05% + 4.55% + 86.01% + 41.47% + 7.92 + 3.49 + 865,066 + 4,423 +
+ + + +### 설명 + +이 카테고리는 애플리케이션이 스트레스, 장애 및 엣지 케이스에 대응하는 방식 전반에 존재하는 시스템적 약점을 의미하며, 그 결과 장애 발생 시 애플리케이션이 정상 상태로 복구하지 못할 수 있다. 애플리케이션이 예기치 않은 조건, 리소스 제약 및 기타 불리한 이벤트를 우아하게(gracefully) 처리하지 못하거나, 견디지 못하거나, 또는 복구하지 못할 경우, 가용성 문제(일반적으로)로 이어지며, 그 외에도 데이터 손상, 민감 데이터 노출, 연쇄 장애 또는 보안 통제 우회를 유발할 수 있다. + +또한 [X02:2025 메모리 관리 실패](#x022025) 역시 애플리케이션, 또는 심지어 전체 시스템의 장애로 이어질 수 있다. + +### 대응 방안 + +이 유형의 취약점을 예방하기 위해서는 시스템의 장애와 복구를 기본 전제로 설계해야 한다. + +* 제한, 할당량 및 페일오버(failover) 기능을 추가하되, 특히 자원을 가장 많이 소모하는 작업에 주의를 기울인다. +* 자원 소모가 큰 페이지를 식별하고 사전에 대비해야 한다. 공격 표면을 줄이되, 특히 불명의 또는 신뢰할 수 없는 사용자에게 불필요한 '가젯'과 많은 자원(예: CPU, 메모리)을 요구하는 기능을 노출하지 않도록 한다. +* 입력값은 크기 제한을 적용하고 허용 리스트 기반으로 엄격히 검증한 뒤, 철저히 테스트한다. +* 응답 크기를 제한하고, 가공되지 않은(raw) 응답을 클라이언트에 그대로 반환하지 않는다(서버 측에서 우선 처리한다). +* 기본적으로 페일 클로즈드(fail closed)를 사용하고 절대로 페일 오픈(fail open)을 사용하지 않는다. 우선 거부 정책(deny by default)을 사용하며, 오류가 발생하면 롤백한다. +* 리퀘스트 스레드에서 동기식 차단 호출(blocking synchronous call)을 피한다(비동기/논블로킹 사용, 타임아웃 설정, 동시성 제한 등). +* 에러 처리 기능을 신중하게 테스트한다. +* 서킷 브레이커, 격벽(bulkhead), 재시도 로직, 우아한 성능 저하(graceful degradation)와 같은 복원력 패턴을 구현한다. +* 성능 및 부하 테스트를 수행한다. 조직의 위험 수용 범위 내에서 카오스 엔지니어링을 도입한다. +* 합리적이고 비용적으로 감당 가능한 범위에서 이중화를 구현하고, 이를 전제로 아키텍처를 설계한다. +* 모니터링, 옵저버빌리티, 알림을 구현한다. +* RFC 2267을 준수해 잘못된 발신자 주소를 필터링한다. +* 핑거프린트, IP 또는 행위 기반 동적 탐지로 알려진 봇넷을 차단한다. +* 작업 증명(Proof-of-Work)을 적용하여 자원 소모 작업을 서버가 아니라 *공격자* 측에 부과한다. 정상 사용자 경험에 미치는 영향은 최소화하고, 시스템 부하가 상승할수록 작업 증명 난이도를 높이고, 특히 신뢰도가 낮거나 봇으로 판단되는 트래픽에는 더 높은 난이도를 적용한다. +* 비활성 시간과 최종 타임아웃을 기준으로 서버 측 세션 시간을 제한한다. +* 세션에 저장되는 상태 정보는 최소화한다. + + +### 공격 시나리오 예시 + +**시나리오 1:** 공격자가 리소스 소모를 유도해 시스템 장애를 유발하고, 결과적으로 서비스 거부(DoS) 상태를 만든다. 예로 메모리 고갈, 디스크 용량 소진, CPU 사용량 포화, 커넥션 무제한 연결 등이 있다. + +**시나리오 2:** 입력값 퍼징을 통해 비정상 입력을 대량 주입하고, 비즈니스 로직을 오동작시키는 조작된 응답을 유도한다. + +**시나리오 3:** 공격자가 애플리케이션의 의존성을 공격하여 API 또는 기타 외부 서비스를 다운시키며, 애플리케이션이 정상 동작할 수 없게 만든다. + + +### 참조 + +* [OWASP Cheat Sheet: Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) +* [OWASP MASVS‑RESILIENCE](https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/) +* [ASP.NET Core Best Practices (Microsoft)](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/best-practices?view=aspnetcore-9.0) +* [Resilience in Microservices: Bulkhead vs Circuit Breaker (Parser)](https://medium.com/@parserdigital/resilience-in-microservices-bulkhead-vs-circuit-breaker-54364c1f9d53) +* [Bulkhead Pattern (Geeks for Geeks)](https://www.geeksforgeeks.org/system-design/bulkhead-pattern/) +* [NIST Cybersecurity Framework (CSF)](https://www.nist.gov/cyberframework) +* [Avoid Blocking Calls: Go Async in Java (Devlane)](https://www.devlane.com/blog/avoid-blocking-calls-go-async-in-java) + +### 해당되는 CWE 목록 +* [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) +* [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) +* [CWE-256 Plaintext Storage of a Password](https://cwe.mitre.org/data/definitions/256.html) +* [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) +* [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) +* [CWE-286 Incorrect User Management](https://cwe.mitre.org/data/definitions/286.html) +* [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) +* [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) +* [CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) +* [CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) +* [CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html) +* [CWE-382 J2EE Bad Practices: Use of System.exit()](https://cwe.mitre.org/data/definitions/382.html) +* [CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) +* [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) +* [CWE-436 Interpretation Conflict](https://cwe.mitre.org/data/definitions/436.html) +* [CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')](https://cwe.mitre.org/data/definitions/444.html) +* [CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) +* [CWE-454 External Initialization of Trusted Variables or Data Stores](https://cwe.mitre.org/data/definitions/454.html) +* [CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) +* [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) +* [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) +* [CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) +* [CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) +* [CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) +* [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) +* [CWE-628 Function Call with Incorrectly Specified Arguments](https://cwe.mitre.org/data/definitions/628.html) +* [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) +* [CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) +* [CWE-653 Improper Isolation or Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) +* [CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) +* [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) +* [CWE-676 Use of Potentially Dangerous Function](https://cwe.mitre.org/data/definitions/676.html) +* [CWE-693 Protection Mechanism Failure](https://cwe.mitre.org/data/definitions/693.html) +* [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) +* [CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) +* [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) +* [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) +* [CWE-1022 Use of Web Link to Untrusted Target with window.opener Access](https://cwe.mitre.org/data/definitions/1022.html) +* [CWE-1125 Excessive Attack Surface](https://cwe.mitre.org/data/definitions/1125.html) + + +## X02:2025 메모리 관리 실패 + +### 배경 + +Java, C#, JavaScript/TypeScript(Node.js), Go, 그리고 "안전한" Rust와 같은 언어는 메모리 안전한 언어이다. 메모리 관리 문제는 C 및 C++와 같은 메모리가 안전하지 않은 언어에서 발생하는 경향이 있다. 이 카테고리는 관련 CVE가 세 번째로 많음에도 불구하고, 커뮤니티 설문에서는 가장 낮은 점수를 받았고 데이터상에서도 낮게 나타났다. 이는 전통적인 데스크톱 애플리케이션보다 웹 애플리케이션이 우세하기 때문이라고 본다. 메모리 관리 취약점은 대체로 가장 높은 CVSS 점수를 가진다. + + +### 점수표 + + + + + + + + + + + + + + + + + + + + + + + + + +
해당 CWE 개수 + 최대 발생률 + 평균 발생률 + 최대 커버리지 + 평균 커버리지 + 평균 가중 익스플로잇 점수 + 평균 가중 영향 점수 + 총 발생 건수 + 총 CVE 건수 +
24 + 2.96% + 1.13% + 55.62% + 28.45% + 6.75 + 4.82 + 220,414 + 30,978 +
+ + + +### 설명 + +애플리케이션이 메모리를 직접 관리해야 할 때 실수가 발생하기 쉽다. 메모리 안전 언어가 더 많이 사용되고 있지만, 전 세계 운영 환경에는 여전히 많은 레거시 시스템이 존재하며, 메모리가 안전하지 않은 언어가 필요한 새로운 저수준 시스템과 메인프레임, IoT 장치, 펌웨어 및 자체 메모리를 관리해야 할 수 있는 기타 시스템과 상호작용하는 웹 애플리케이션도 여전히 많다. 대표적인 CWE로는 *CWE-120 입력 크기 확인 없이 버퍼 복사('클래식 버퍼 오버플로')* 및 *CWE-121 스택 기반 버퍼 오버플로*가 있다. + +메모리 관리 실패는 다음과 같은 경우에 발생할 수 있다. + +* 변수에 대해 충분한 메모리를 할당하지 않는 경우. +* 입력을 검증하지 않아 힙, 스택 또는 버퍼에서 오버플로가 발생하는 경우. +* 변수 타입이 수용할 수 있는 크기보다 큰 데이터 값을 저장하는 경우. +* 할당되지 않은 메모리 또는 주소 공간을 사용하려고 시도하는 경우. +* 오프 바이 원(off-by-one, 0이 아니라 1부터 카운팅) 오류가 있는 경우. +* 해제(free)된 이후에 객체에 접근하려고 하는 경우. +* 초기화되지 않은 변수를 사용하는 경우. +* 메모리 누수 또는 비정상 메모리 소모로 가용 메모리가 고갈되어 장애로 이어지는 경우. + +메모리 관리 실패는 애플리케이션뿐만 아니라 심지어 전체 시스템의 장애로 이어질 수 있으며, 이는 [X01:2025 애플리케이션 복원력 부족](#x012025)를 함께 참고한다. + + +### 대응 방안 + +메모리 관리 실패를 예방하는 최선의 방법은 메모리 안전 언어를 사용하는 것이다. 예로는 Rust, Java, Go, C#, Python, Swift, Kotlin, JavaScript 등이 있다. 새로운 애플리케이션을 개발할 때는 학습 곡선이 있더라도 메모리 안전 언어로 전환할 가치가 있음을 조직 내에서 적극적으로 설득해야 한다. 전면적인 리팩터링을 수행하는 경우에는 가능하고 실현 가능한 범위에서, 메모리 안전 언어로의 재작성을 추진한다. + +메모리 안전 언어를 사용할 수 없다면 다음을 수행한다. + +* 메모리 관리 오류의 악용을 어렵게 만드는 서버 기능을 활성화한다. 주소 공간 배치 무작위화(Address Space Layout Randomization, ASLR), 데이터 실행 방지(Data Execution Protection, DEP), 구조화된 예외 처리(Structured Exception Handling Overwrite Protection). +* 애플리케이션의 메모리 누수를 모니터링한다. +* 시스템으로 들어오는 모든 입력을 매우 신중하게 검증하고, 기대 조건을 충족하지 않는 입력은 모두 거부한다. +* 사용 중인 언어를 학습하여 위험한 함수와 비교적 안전한 함수의 목록을 작성하고, 이를 팀과 공유한다. 가능하다면 이를 시큐어 코딩 가이드라인이나 표준에 추가한다. 예를 들어, C 언어에서는 strcpy() 대신 strncpy()를, strcat() 대신 strncat()을 우선적으로 사용한다. +* 언어나 프레임워크에서 메모리 안전 라이브러리를 제공한다면 이를 사용한다. 예: Safestringlib 또는 SafeStr. +* 가능하면 원시 배열과 포인터보다 관리형 버퍼 및 문자열을 사용한다. +* 메모리 이슈나 사용 중인 언어에 초점을 맞춘 시큐어 코딩 교육을 받는다. 교육 담당자에게 메모리 관리 실패에 대해 우려하고 있음을 알린다. +* 코드 리뷰 및 정적 분석을 수행한다. +* StackShield, StackGuard, Libsafe 등 메모리 관리를 돕는 컴파일러/도구를 사용한다. +* 시스템의 모든 입력에 대해 퍼징을 수행한다. +* 모의침투 테스트를 수행하는 경우, 테스터에게 메모리 관리 실패에 대한 우려가 있으며 테스트 중 해당 부분에 특별히 주의를 기울여 줄 것을 요청한다. +* 컴파일러 오류와 경고를 *모두* 수정한다. 프로그램이 컴파일된다고 해서 경고를 무시하지 않는다. +* 기반 인프라가 정기적으로 패치, 스캔, 하드닝되도록 보장한다. +* 특히 기반 인프라를 대상으로 한 잠재적 메모리 취약점 및 기타 장애 요인을 모니터링한다. +* 오버플로 공격으로부터 주소 스택을 보호하기 위해 [카나리](https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries) 사용을 고려한다. + +### 공격 시나리오 예시 + +**시나리오 1:** 버퍼 오버플로는 가장 유명한 메모리 취약점으로, 공격자가 필드가 수용할 수 있는 것보다 더 많은 데이터를 입력하여 해당 변수에 대해 생성된 버퍼를 넘치게 만드는 상황을 말한다. 공격이 성공하면 넘친 데이터가 스택 포인터를 덮어쓰게 되며, 이를 통해 공격자가 프로그램에 악의적인 명령을 삽입할 수 있게 된다. + +**시나리오 2:** 유즈 에프터 프리(Use-After-Free)은 비교적 자주 발생하여 브라우저 버그 바운티에서 흔히 제보되는 유형의 버그다. 예를 들어 웹 브라우저가 DOM 요소를 조작하는 JavaScript를 처리하는 상황을 가정하자. 공격자는 객체(예: DOM 요소)를 생성하고 그에 대한 참조를 획득하는 JavaScript 페이로드를 작성한다. 이후 정교한 조작을 통해, 브라우저가 해당 객체의 메모리를 해제하도록 유도하면서도 그 객체를 가리키는 댕글링 포인터(dangling pointer)는 유지하게 만든다. 브라우저가 메모리 해제를 인지하기 전에, 공격자는 *동일한* 메모리 공간을 차지하도록 새 객체를 할당한다. 브라우저가 원래 포인터를 사용하면, 이제 그 포인터는 공격자가 삽입한 데이터를 참조하게 된다. 만약 이 포인터가 가상 함수 테이블을 가리키는 것이었다면, 공격자는 코드 실행 흐름을 자신의 페이로드로 리다이렉션할 수 있다. + +**시나리오 3:** 사용자 입력을 받아 적절히 검증하거나 정제하지 않고 로깅 함수로 직접 전달하는 네트워크 서비스를 가정해 보자. 사용자 입력은 형식을 지정하는 syslog("%s", user_input) 대신 형식을 지정하지 않은 syslog(user_input) 형태로 로깅 함수에 전달된다. 공격자는 스택 메모리를 읽기 위한(민감한 데이터 노출) %x 또는 메모리 주소에 값을 쓰기 위한 %n과 같은 형식 지정자(format specifier)를 포함한 악성 페이로드를 전송한다. 공격자는 여러 형식 지정자를 결합하여 스택 구조를 파악하고, 중요한 주소를 찾아낸 뒤 이를 덮어쓸 수 있다. 이는 포맷 스트링 취약점에 해당한다. + +참고: 현대의 브라우저는 [브라우저 샌드박스](https://www.geeksforgeeks.org/ethical-hacking/what-is-browser-sandboxing/#types-of-browser-sandboxing), ASLR, DEP/NX, RELRO 및 PIE를 포함한 심층적 방어 체계를 사용하기에, 브라우저에 대한 메모리 관리 실패 공격이 쉽지 않다. + +### 참조 + +* [OWASP community pages: Memory leak,](https://owasp.org/www-community/vulnerabilities/Memory_leak) [Doubly freeing memory,](https://owasp.org/www-community/vulnerabilities/Doubly_freeing_memory) [& Buffer Overflow](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow) +* [Awesome Fuzzing: a list of fuzzing resources](https://github.com/secfigo/Awesome-Fuzzing) +* [Project Zero Blog](https://googleprojectzero.blogspot.com) +* [Microsoft MSRC Blog](https://www.microsoft.com/en-us/msrc/blog) + +### 해당되는 CWE 목록 +* [CWE-14 Compiler Removal of Code to Clear Buffers](https://cwe.mitre.org/data/definitions/14.html) +* [CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer](https://cwe.mitre.org/data/definitions/119.html) +* [CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')](https://cwe.mitre.org/data/definitions/120.html) +* [CWE-121 Stack-based Buffer Overflow](https://cwe.mitre.org/data/definitions/121.html) +* [CWE-122 Heap-based Buffer Overflow](https://cwe.mitre.org/data/definitions/122.html) +* [CWE-124 Buffer Underwrite ('Buffer Underflow')](https://cwe.mitre.org/data/definitions/124.html) +* [CWE-125 Out-of-bounds Read](https://cwe.mitre.org/data/definitions/125.html) +* [CWE-126 Buffer Over-read](https://cwe.mitre.org/data/definitions/126.html) +* [CWE-190 Integer Overflow or Wraparound](https://cwe.mitre.org/data/definitions/190.html) +* [CWE-191 Integer Underflow (Wrap or Wraparound)](https://cwe.mitre.org/data/definitions/191.html) +* [CWE-196 Unsigned to Signed Conversion Error](https://cwe.mitre.org/data/definitions/196.html) +* [CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition](https://cwe.mitre.org/data/definitions/367.html) +* [CWE-415 Double Free](https://cwe.mitre.org/data/definitions/415.html) +* [CWE-416 Use After Free](https://cwe.mitre.org/data/definitions/416.html) +* [CWE-457 Use of Uninitialized Variable](https://cwe.mitre.org/data/definitions/457.html) +* [CWE-459 Incomplete Cleanup](https://cwe.mitre.org/data/definitions/459.html) +* [CWE-467 Use of sizeof() on a Pointer Type](https://cwe.mitre.org/data/definitions/467.html) +* [CWE-787 Out-of-bounds Write](https://cwe.mitre.org/data/definitions/787.html) +* [CWE-788 Access of Memory Location After End of Buffer](https://cwe.mitre.org/data/definitions/788.html) +* [CWE-824 Access of Uninitialized Pointer](https://cwe.mitre.org/data/definitions/824.html) + + + +## X03:2025 AI 생성 코드에 대한 부적절한 신뢰('바이브 코딩') + +### 배경 + +현재 전 세계가 AI에 대해 이야기하고 활용하고 있으며, 소프트웨어 개발자도 예외는 아니다. 아직 AI 생성 코드와 직접 관련된 CVE나 CWE는 없지만, AI 생성 코드가 인간이 작성한 코드보다 더 많은 취약점을 포함하는 경우가 많다는 사실은 널리 알려져 있고 문서로도 입증되어 있다. + + +### 설명 + +우리는 소프트웨어 개발 관행이 변화하여, AI의 도움을 받아 작성한 코드뿐 아니라 사람의 검토 없이 거의 전적으로 작성되어 그대로 커밋되는 코드(흔히 '바이브 코딩'이라 불림)까지 포함하는 흐름을 보고 있다. 예전에도 블로그나 웹사이트의 코드 스니펫을 깊이 생각하지 않고 복사하는 것이 결코 바람직하지 않았던 것과 마찬가지로, 이 경우에는 문제가 더 악화된다. 양질의 보안 코드 스니펫은 예나 지금이나 드물며, 시스템적 제약으로 인해 AI가 이런 좋은 예시를 통계적으로 잘 나타내지 못할 수 있다. + + +### 대응 방안 +AI를 활용해 코드를 작성하는 모든 사람에게 다음 사항을 고려할 것을 권고한다. + +* AI가 작성했거나 온라인 포럼에서 복사한 코드일지라도, 제출하는 모든 코드를 읽고 완전히 이해할 수 있어야 한다. 커밋하는 모든 코드에 대한 책임은 본인에게 있다. +* 모든 AI 지원 코드를 취약점 관점에서 철저히 검토해야 하며, 이상적으로는 직접 육안으로 확인하고 목적에 맞게 제작된 (정적 분석 같은) 보안 도구를 병행해야 한다. [OWASP Cheat Sheet Series: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html)에 기술된 전통적인 코드 리뷰 기법의 사용을 고려한다. +* 이상적으로는 직접 코드를 작성하고, AI가 개선안을 제시하게 한 뒤, 제안된 코드를 검증하고, 결과에 만족할 때까지 AI가 수정을 하도록 한다. +* 조직의 보안 코딩 가이드라인/표준/정책 등과 같이, 자체적으로 수집, 검토한 안전한 코드 샘플과 문서를 기반으로 하는 RAG(Retrieval Augmented Generation) 서버 사용을 고려한다. 또한 RAG 서버가 정책이나 표준을 강제하도록 한다. +* 선택한 AI와 함께 사용할 수 있도록, 개인정보 보호와 보안을 위한 가드레일 구현 도구를 구매하는 방안을 고려해야 한다. +* 사설(private) AI의 구매를 고려하며, 이상적으로는 조직의 데이터, 쿼리, 코드 또는 기타 민감한 정보로 AI를 학습시키지 않는다는 계약(개인정보 보호 협약 포함)을 체결한다. +* IDE와 AI 사이에 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 서버를 구축하고, 선택한 보안 도구의 사용을 강제하도록 설정하는 것을 고려한다. +* 개발자(및 전 직원)에게 조직 내에서 AI를 어떻게 사용해야 하고 사용하지 말아야 하는지 안내하기 위해, 소프트웨어 개발 생명 주기(Software Development Life Cycle, SDLC)의 일부로 정책과 프로세스를 수립한다. +* IT 보안 모범 사례를 반영한, 유용하고 효과적인 프롬프트 목록을 작성한다. 이상적으로는 내부 시큐어 코딩 가이드라인도 반영해야 한다. 개발자는 해당 프롬프트를 프로그램 개발의 출발점으로 사용할 수 있다. +* AI는 시스템 개발 생명 주기의 각 단계에 포함될 가능성이 높으므로, 효과적이고 안전하게 사용해야 한다. AI는 지혜롭게 사용해야 한다. +* 실제로 복잡한 함수, 비즈니스 크리티컬 프로그램, 또는 장기간 사용되는 프로그램에는 바이브 코딩을 사용하는 것을 권장하지 **않는다**. +* 섀도우 AI(Shadow AI) 사용에 대한 기술적 점검과 보호 조치를 구현한다. +* 개발자에게 조직의 정책뿐만 아니라, 안전한 AI 사용 및 소프트웨어 개발에서의 AI 활용 모범 사례에 대한 교육을 실시한다. + + +### 참조 + +* [OWASP Cheat Sheet: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) + + +### 해당되는 CWE 목록. +-none- diff --git a/2025/docs/ko/assets/2025-algorithm-diagram-ko.png b/2025/docs/ko/assets/2025-algorithm-diagram-ko.png new file mode 100644 index 000000000..c6a07af28 Binary files /dev/null and b/2025/docs/ko/assets/2025-algorithm-diagram-ko.png differ diff --git a/2025/docs/ko/assets/Top10Mapping-ko.PNG b/2025/docs/ko/assets/Top10Mapping-ko.PNG new file mode 100644 index 000000000..32af569e8 Binary files /dev/null and b/2025/docs/ko/assets/Top10Mapping-ko.PNG differ diff --git a/2025/docs/ko/assets/Top10Mapping-ko.xlsx b/2025/docs/ko/assets/Top10Mapping-ko.xlsx new file mode 100644 index 000000000..f4c5acf33 Binary files /dev/null and b/2025/docs/ko/assets/Top10Mapping-ko.xlsx differ diff --git a/2025/docs/ko/index.md b/2025/docs/ko/index.md new file mode 100644 index 000000000..036ce88e3 --- /dev/null +++ b/2025/docs/ko/index.md @@ -0,0 +1,41 @@ +# OWASP Top 10:2025 + +OWASP Top 10:2025 버전에 오신 것을 환영합니다. + +OWASP Top 10은 개발자와 웹 애플리케이션 보안을 위한 인식 제고용 자료이며, 웹 애플리케이션의 가장 중대한 보안 위험에 대한 업계의 공감대를 반영한다. + +## 이번 버전 소개 + +이 문서는 OWASP Top 10의 **2025**년 버전이다. 최신 데이터와 보안 동향을 반영하여 업데이트되었다. + +## 메인 프로젝트 페이지 +[메인 프로젝트 페이지](https://github.com/OWASP/www-project-top-ten)에는 과거 자료를 포함한 해당 프로젝트의 메타데이터가 정리되어 있다. + +## 시작하기 + +2025년 버전에서 변경되거나 추가된 내용을 파악하려면 [소개](0x00_2025-Introduction.md) 페이지를 확인한다. + +## 목차 + +- [소개](0x00_2025-Introduction.md) +- [OWASP 소개](0x01_2025-About_OWASP.md) +- [애플리케이션 보안 위험이란 무엇인가?](0x02_2025-What_are_Application_Security_Risks.md) +- [현대적 애플리케이션 보안 체계 수립](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) + +### Top 10:2025 목록 + +1. [A01:2025 - 불충분한 접근 제어](A01_2025-Broken_Access_Control.md) +2. [A02:2025 - 보안 설정 오류](A02_2025-Security_Misconfiguration.md) +3. [A03:2025 - 소프트웨어 공급망 실패](A03_2025-Software_Supply_Chain_Failures.md) +4. [A04:2025 - 암호 실패](A04_2025-Cryptographic_Failures.md) +5. [A05:2025 - 인젝션](A05_2025-Injection.md) +6. [A06:2025 - 안전하지 않은 설계](A06_2025-Insecure_Design.md) +7. [A07:2025 - 인증 실패](A07_2025-Authentication_Failures.md) +8. [A08:2025 - 소프트웨어 또는 데이터 무결성 실패](A08_2025-Software_or_Data_Integrity_Failures.md) +9. [A09:2025 - 보안 로깅 및 알림 실패](A09_2025-Security_Logging_and_Alerting_Failures.md) +10. [A10:2025 - 부적절한 예외 처리](A10_2025-Mishandling_of_Exceptional_Conditions.md) + + +--- + +**참고:** 번역은 준비되는 대로 순차적으로 추가될 예정이다. diff --git a/2025/mkdocs.yml b/2025/mkdocs.yml index 35bee0cc0..01d6a4bf6 100644 --- a/2025/mkdocs.yml +++ b/2025/mkdocs.yml @@ -48,6 +48,27 @@ plugins: default: true name: en - English build: true + - locale: ko + name: ko - 한국어 + build: true + nav_translations: + Home: 홈 + Introduction: 소개 + About OWASP: OWASP 소개 + What are Application Security Risks?: 애플리케이션 보안 위험이란 무엇인가? + Establishing a Modern Application Security Program: 현대적 애플리케이션 보안 체계를 수립하는 법 + Top 10:2025 List: OWASP Top 10:2025 목록 + A01 Broken Access Control: A01 불충분한 접근 제어 + A02 Security Misconfiguration: A02 보안 설정 오류 + A03 Software Supply Chain Failures: A03 소프트웨어 공급망 실패 + A04 Cryptographic Failures: A04 암호 실패 + A05 Injection: A05 인젝션 + A06 Insecure Design: A06 안전하지 않은 설계 + A07 Authentication Failures: A07 인증 실패 + A08 Software or Data Integrity Failures: A08 소프트웨어 또는 데이터 무결성 실패 + A09 Security Logging and Alerting Failures: A09 보안 로깅 및 알림 실패 + A10 Mishandling of Exceptional Conditions: A10 부적절한 예외 처리 + Next Steps: 다음 단계 nav_translations: SAMPLE: @@ -77,8 +98,11 @@ plugins: extra: alternate: # see https://squidfunk.github.io/mkdocs-material/setup/changing-the-language/#site-language-selector - name: en - English - link: ./en/ + link: ./ lang: en + - name: ko - 한국어 + link: ./ko/ + lang: ko # - name: de - Deutsch # link: ./de/ # lang: de