Owasp Top10 2021

OWASP 정의

■ OWASP(The Open Web Application Security Project)는 웹 애플리케이션 보안 증진을 목표로 하는 비영리단체
■ OWASP Top 10 이라는 안전한 웹 애플리케이션 개발을 위한 가이드를 2004년부터 매 3, 4년마다 발행

OWASP 2021 항목

A01 - Broken Access Control (취약한 접근 통제)

개요

■ 접근 제어(Access Control)는 사용자가 권한을 벗어난 행동을 할 수 없도록 정책을 만들고 실행하는 기능
■ 접근 제어가 취약하게 구현되면 사용자는 주어진 권한을 벗어나 인가되지 않은 데이터에 무단으로 접근해, 조작이나 삭제하는 등을 할 수 있음
■ OWASP Top 10 - 2017에서 A05번에 위치하던 Broken Access Control(취약한 접근 통제)이 4단계 상승하여 첫 번째 위치(A01)로 이동
■ 과거에는 하나의 서비스 또는 시스템(Monolithic Architecture)으로 소프트웨어를 구성하는 방식으로 애플리케이션을 구성했지만 현재 애플리케이션들은 상호 독립적인 구성 요소로 분할 되어 있는 방식 (Microservice Architecture)으로 개발되는 경우가 많아짐
■ 기존에는 하나의 서비스에서 접근통제(Access Control)를 담당하였지만, 기능이 여러 개로 분할되면서 접근 통제에 어려움이 존재하기 때문에 첫 번째 위치로 이동한 것으로 보임

취약점 예시

■ 특정 사용자에게만 부여해야 하는 권한을 기본적으로 모든 사용자에 부여하는 경우
■ 인증되지 않은 사용자가 인증이 필요한 페이지를 강제로 탐색할 수 있는 경우
■ 사용자로 로그인해 관리자 권한으로 활동할 수 있는 경우
■ POST, PUT, DELETE API 요청에 대한 접근 제어가 누락된 경우
■ 파라미터나 쿠키 등의 요청을 조작해 권한 상승 혹은 타 사용자의 권한을 사용할 수 있는 경우

예방 방법

■ 공용 리소스를 제외하고 기본적으로 접근을 거부하는 정책 수립(화이트 리스트 기반)
■ 접근제어 정책이 애플리케이션 전체에 일괄 적용되도록 확인

A02 - Cryptographic Failures (암호학적 실패)

개요

■ 암호화에 관련한 문제들을 전반적으로 이야기하는 항목
■ 암호화에 오류가 있거나 미흡한 부분이 있는 경우, 민감 데이터 노출로 이어짐
■ 특히 개인정보와 금융 데이터 같은 법과 규정에 강력하게 영향을 받는 경우라면 안전하게 보호하기 위한 추가 요구 사항을 지켜야 함
■ OWASP Top 10 - 2017에서 A03번에 위치하던 Sensitive Data Exposure(민감 데이터 노출) 항목이 Cryptographic Failures (암호학적 실패)라는 이름으로 변경
■ 해당 항목은 1단계 상승하여 두 번째 위치(A02)로 이동했다.
■ OWASP에서는 2017년에 존재하였던 민감 데이터 노출이 근본적인 원인이 존재하였던 것이 아니라 여러가지 분야에서 광범위하게 발생하는 증상으로 판단
■ 2017년 이후 데이터 암호화와 관련된 이슈가 상당히 많았기 때문에 OWSAP에서는 이러한 점을 토대로 해당 항목에 대하여 단계 상승을 한 것으로 보임

취약점 예시

■ 내·외부망에 관계없이 데이터가 전송구간에서 평문으로 전송되는 경우(HTTP, FTP, TELNET 등)
■ 취약한 암호화 프로토콜을 사용하는 경우(SSL v2.0, SSL v3.0, TLS v1.0, TLS v1.1)
■ 취약한 암호화 알고리즘을 사용하는 경우(DES, RC4, MD5 등)
■ 취약한 암호화 컴포넌트를 사용하는 경우(취약한 버전의 openssl 사용 등)
■ 보안 헤더 설정을 통한 HSTS가 누락된 경우(HSTS: HTTP를 HTTPS로 강제 리다이렉트)
■ 고정된 암호문을 사용하는 경우(Salt, 일회용 난수 미포함)
■ 사설 인증서 사용, 인증서와 도메인 불일치
■ 암호키 관리가 미흡한 경우(소스코드 하드코딩 등)

예방 방법

■ FTP, TELNET과 같은 레거시 프로토콜 미사용
■ 최신 버전의 암호 프로토콜 및 안전한 암호 알고리즘 사용
■ HSTS(HTTP를 HTTPS로 강제 리다이렉트) 설정
■ 암호화 시 암호문이 고정되지 않도록 의사 난수 생성기를 포함
■ 신뢰할 수 있는 기관에서 발급한 인증서 사용

A03 - Injection (인젝션)

개요

■ Injection은 사용자가 전달하는 데이터(파라미터, 헤더, URL, 쿠키(Cookie), Json 데이터, SOAP, XML 등 모든 형태)를 신뢰할 수 없는 데이터로 조작해서, 서버 측에서 명령어나 쿼리문의 일부로 인식하게 만들 때 발생하는 취약점
■ OWASP Top 10 - 2017에서 A01번에 위치하던 Injection(인젝션)이 2단계 하락하여 세 번째 위치(A03)로 이동
■ 2017년에 존재하였던 A1 - Injection 과 A7 - Cross Site Scripting(XSS)이 통합되었다. 애플리케이션에서 Broken Access Control 항목에 이어서 두 번째로 많은 취약점이 발현됨
■ Injection은 과거부터 SQL, NoSQL, 운영체제 명령어, ORM(Object Relational Mapping), LDAP, EL(Expression Languages), OGNL(Object Graph, Navigation Library) 인젝션 등 다양한 취약점이 존재하였고, Cross site Scripting 취약점이 통합됨에 따라 여전히 위험성을 가진 취약점으로 판단되기 때문에 OWASP에서 세 번째에 위치시킨 것으로 보임

취약점 예시

■ SQL injection, NoSQL injection
■ OS Command Injection
■ ORM(Object Relational Mapping) injection
■ LDAP injection
■ EL(Expression Language) injection
■ OGNL(Object Graph Navigation Library) injection
■ Cross-site Scripting

③ 예방 방법

■ 사용자 입력이 SQL 문법으로 인식되지 않도록 Binding 변수를 사용(예: Prepared statement)
■ 사용자 제공 데이터에 대한 화이트리스트 기반 서버 측 검증

A04 - Insecure Design (안전하지 않은 설계) ① 개요 ■ Insecure Design 항목은 OWASP Top 10 - 2017에서는 존재하지 않았던 새로운 항목이다.
■ 기획 단계와 애플리케이션 설계 과정에서의 보안사항 준수를 의미하고 있으며, 설계 과정에서 발생하는 보안적인 결함을 의미
■ 설계가 잘못된 애플리케이션은 추후에 진행하는 보안테스트로 발견한 사항을 쉽게 조치할 수 없거나, 위험성을 가지고 운영해야 하는 경우들이 많기 때문에 해당 항목이 새롭게 등장한 것으로 보임

소프트웨어 개발보안 방법론(출처: KISA)

A05 - Security Misconfiguration (보안 오류 설정)

개요

■ 보안 설정 오류(Security Misconfiguration)는 애플리케이션을 최초 설치하거나 업데이트할 때 보안성을 고려하지 않은 설정으로 인해 취약점이 발생하는 경우
■ OWASP Top 10 - 2017에서 A06번에 위치하던 Security Misconfiguration(보안 오류 설정) 항목이 A04번 XML External Entities(XXE)항목과 통합되었고, 이로 인하여 한 단계 상승하여 다섯 번째 위치(A05)로 이동
■ 안전하게 설계된 애플리케이션을 개발하더라도 테스트 및 디버깅을 위하여 옵션을 잘못 설정하는 경우가 다수 존재하기 때문에 OWASP에서는 해당 취약점의 순위를 한 단계 상승 시킨 것으로 보임

취약점 예시

■ 불필요한 기능을 활성화했거나 설치함(예: 불필요 포트, 불필요 페이지, 불필요 계정/권한 등)
■ 벤더사에서 기본으로 제공하는 관리자 계정(ID/Password)을 변경하지 않고 사용
■ 에러 페이지를 통한 애플리케이션 에러 정보 노출
■ 보안 헤더 설정 누락
■ 서버 OS, 프레임워크, 라이브러리, 데이터베이스 등의 보안 설정 누락

예방 방법

■ 애플리케이션 설치 시 불필요한 기능, 구성요소, 샘플, 문서 등은 제거
■ 보안 헤더 설정
■ 모든 환경에서 애플리케이션 보안 설정을 검증하고 자동화된 프로세스 구현

A06 - Vulnerable and Outdated Components (취약하고 지원이 종료된 컴포넌트)

개요

■ 취약하고 지원이 종료된 구성 요소(Vulnerable and Outdated Components)는 취약한 버전 또는 EOS/EOL/EOD(소프트웨어 기술 지원 중단) 상태인 소프트웨어를 계속 사용하는 경우를 뜻하며, 그로 인해 발생할 수 있는 모든 보안 위협을 포함
■ 서비스를 구성하는 모든 요소(OS, WEB/WAS, 데이터베이스, 애플리케이션, API, 라이브러리, 프레임워크 등)가 여기에 해당
■ 오픈소스를 기반으로 다양한 라이브러리와 컴포넌트들이 연결되는 애플리케이션의 경우 제공되는 라이브러리와 컴포넌트에 알려진 취약점이 존재할 수 있음
■ 이런 상황에서 라이브러리, 컴포넌트에 존재하는 취약점은 어플리케이션 자체에도 취약점을 내포하게 할 수 있고, 가장 큰 문제점은 개발자가 이를 쉽게 식별하기 어렵다는 문제가 있다.
■ OWASP Top 10 - 2017에서A09번 위치하던Using Components with Known Vulnerabilities(알려진 취약점이 있는 구성요소 사용) 항목이 Vulnerable and Outdated Components(취약하고 오래된 컴포넌트)라는 이름으로 변경
■ 해당 항목은 3단계 상승하여 여섯 번째 위치(A06)로 이동되었으며 최근 소프트웨어 개발을 모듈화하여 진행하는 경우가 많아지고 있기 때문에 OWASP에서는 해당 취약점의 순위를 변경한 것으로 보임

취약점 예시

■ 지원 종료된 OS 사용(Windows XP, Windows server 2000 등)
■ 알려진 취약점이 존재하는 버전의 애플리케이션 사용(nginx, apache tomcat, 오픈소스 웹 에디터, WordPress 등)
■ 알려진 취약점이 존재하는 버전의 프레임워크 사용(Apache Struts 2, Spring 등)
■ 알려진 취약점이 존재하는 버전의 라이브러리 사용(OpenSSL 등)

③ 예방 방법

■ 불필요한 소프트웨어는 제거
■ 형상 관리를 통해 사용하는 모든 소프트웨어 버전 체크
■ 패치 관리 프로세스를 수립해 소프트웨어 최신 버전 유지
■ 알려진 취약점을 지속적으로 모니터링해 취약한 소프트웨어 사용 확인

A07 - Identification and Authentication Failures (식별 및 인증 실패)

개요

■ OWASP Top 10 - 2017에서 A02에 위치하던 Broken Authentication(취약한 인증)항목이 Identification and Authentication Failures(식별 및 인증 실패)라는 이름으로 변경됨
■ 다섯 단계 하락하여 일곱 번째 위치(A07)로 이동했다.
■ 해당 항목은 현재 개발되는 소프트웨어에서 개발 프레임워크의 가용성이 증가함에 따라 순위가 하락한 것으로 보이지만 많은 서비스들에서 자주 발견되는 취약점이기 때문에 주의를 요할 필요가 있다.

취약점 예시

■ Multi-factor 인증이나 2차 인증 부재로 Credential Stuffing, Brute forcing 공격 등에 노출되는 경우
■ 인증 실패에 대한 제한이 없어 Brute forcing 공격에 노출되는 경우
■ 안전한 비밀번호 생성 정책이 없어, 취약한 비밀번호 생성을 허용하는 경우
■ URL에 인증 세션 ID가 노출되는 경우(GET Method)
■ 로그인 후 새로운 세션 ID로 발급하지 않고 기존 세션 ID를 재사용하는 경우
■ 세션 타임아웃이 없거나 로그아웃 후 세션 파기를 하지 않는 경우

예방 방법

■ Multi-factor 인증이나 2차 인증 구현
■ 안전한 비밀번호 생성 정책 및 인증 실패 횟수 제한 적용
■ 로그인 시 새로운 세션 ID를 생성하고 인증 세션은 암호화된 채널에서 헤더를 통해 전송
■ 세션 파기 및 만료 정책 수립

A08 - Software and Data Integrity Failures (소프트웨어와 데이터 무결성 실패)

개요

■ OWASP Top 10 - 2017에서 존재하지 않았던 항목 존재하지 않았던 새로운 항목이며, 2017년에 존재했던 Insecure Deserialization(안전하지 않는 역직렬화)가 해당 항목에 포함됨
■ 소프트웨어 및 데이터 무결성 오류는 애플리케이션이 신뢰할 수 없는 소스, 저장소 및 CDN, 플러그인, 라이브러리, 모듈에 의존하는 경우에 발생
■ 안전하지 않은 CI/CD 파이프라인은 개발 및 배포 과정에서 애플리케이션이 변조되면 무결성이 훼손될 가능성이 있으므로, 애플리케이션이 사용하는 코드에 대한 무결성 검증 절차를 추가해야 함
■ 무결성을 증명하지 않은 소프트웨어 업데이트, 중요 데이터 및 CI/CD 파이프라인과 관련된 내용이다. 대표적인 예로 애플리케이션에서의 신뢰할 수 없는 소스코드, 라이브러리 또는 모듈에 의존하는 경우를 들 수 있다.

취약점 예시

■ 애플리케이션이 사용하는 라이브러리나 모듈에 대한 무결성 검증이 없어 변조가 가능한 경우
■ 업데이트 공급망에 대한 검증이 없는 경우
■ CI/CD 파이프라인에 대한 적절한 보안성 검토가 없는 경우
■ 직렬화된 데이터에 대한 무결성 검증이 없는 경우

③ 예방 방법

■ 전자서명, 해시 알고리즘 등을 사용해 애플리케이션 무결성을 검증
■ 사용하고 있는 라이브러리가 신뢰할 수 있는 저장소를 사용하고 있는지 확인하고, 중요한 서비스라면 내부 저장소를 별도로 지정해 사용
■ CI/CD 파이프라인에 대한 정기적인 보안성 검토 수행
■ 직렬화/역직렬화 라이브러리를 사용하는 경우, 직렬화 된 데이터에 대해 무결성 검증을 수행

A09 - Security Logging and Monitoring Failures (보안 로깅과 모니터링 실패)

개요

■ OWASP Top 10 - 2017에서 A10번에 위치하던 Insufficient Logging & Monitoring(불충분한 로깅과 모니터링)항목으로 이름이 새롭게 변경됨
■ 해당 항목은 보안 업계 설문조사에서 3위를 차지하였고, 한단계 상승한 아홉 번째 위치 (A09)로 이동하였다.
■ 해당 항목은 기존 보다 더 많은 종류의 이슈를 포함하도록 확장됨
■ 적절한 로깅과 모니터링이 없다면 공격을 감지하고 대응할 수가 없기 때문에, 취약점 공격 예방 뿐 아니라 공격 발생 감지 및 대응까지 포함하는 것으로 개정됨

취약점 예시

■ 로그인, 인증 실패, 권한 설정 등 중요 기능 수행에 대한 로깅이 없는 경우
■ 일정 주기로 로그에 대한 백업 절차가 없는 경우
■ 로깅 및 모니터링이 필요한 부분을 명확하게 구분해서 로깅하지 않아, 불명확한 로깅 및 모니터링을 하는 경우

예방 방법

■ 모든 로그인, 접근 제어, 인증 실패에 대해 로깅을 하고 정기적인 백업을 통해 보관
■ 로그 관리 솔루션 등을 활용하기 위해 적절한 형식으로 로깅이 생성되는지 확인
■ 의심스러운 활동을 감지하고 신속하게 대응할 수 있도록 임계치를 설정하고 모니터링
■ 침해 사고 대응 및 복구 계획 수립

A10 - Server Side Request Forgery (서버 사이드 요청 변조)

개요

■ OWASP Top 10 - 2017에는 존재하지 않았던 항목이고, 보안 업계 설문조사에서 1위를 차지하며 새롭게 추가된 항목
■ 애플리케이션이 사용자 제공 데이터를 적절한 검증 없이 로컬 및 원격 리소스를 가져와 취약점을 발생시키는 상황을 의미
■ 웹 어플리케이션 방화벽(WAF), 방화벽, 또는 네트워크 ACL이 보호하고 있는 시스템을 SSRF을 통해 공격 가능 다양한 취약점이 발현될 수 있어 새롭게 추가됨

취약점 예시

■ 서버가 적절한 검증 절차 없이 사용자 요청을 로컬 혹은 원격 리소스에 접근하도록 하는 경우

예방 방법

■ 서버가 속한 내부 네트워크끼리 통신할 때에도 방화벽을 통해 접근제어 규칙을 적용
■ 모든 사용자 제공 데이터에 대한 검증
■ 사용자 요청에 대한 서버 측 수행 결과 검증

출처 및 참고자료