OWASP Top 10 – 2021 톺아보기(1/2)

🧐 | 2021-12-30

안녕하세요, 넷마블 보안실 게임보안팀 전희창입니다.

2021년을 마무리하며 ‘OWASP Top 10 – 2021’을 같이 되돌아볼 수 있게 2부작 글을 준비했습니다. 그럼, 지금부터 1부를 시작합니다!

OWASP Top 10

먼저, OWASP는 ‘Open Web Application Security Project’라는 비영리 보안 프로젝트 재단을 통칭하는 약자입니다. 이 재단에서는 애플리케이션에서 발생할 수 있는 취약점을 분석하고 연구하고 있습니다. 2001년 12월 1일에 OWASP 재단으로 발족한 이후, 2004년 4월 21일에 비영리 단체로 등록됐습니다. (더 자세한 소개는 OWASP 소개 페이지를 참고해주세요.)

OWASP에서는 취약점을 공격 가능성과 기술적 영향을 기준으로 순위를 매겨, 상위 10개 취약점을 OWASP Top 10으로 선정합니다. 2004년에 처음 공개했으며, 국내외 여러 기관 및 기업에서 애플리케이션을 개발하거나 보안성 검토 기준을 수립할 때 많이 참고하고 있습니다.

OWASP Top 10 (출처: owasp.org)

2021년 개정 사항

2021년 9월 24일에 발표한 ‘OWASP Top 10 – 2021’에는 신규 3개 항목이 추가됐으며, 기존 3개 항목은 다른 항목에 병합되는 등 새롭게 개정된 내용이 있습니다.

OWASP Top 10 – 2021에서 개정된 내용(출처: owasp.org)

신규 항목으로는 Insecure Design(안전하지 않은 설계), Software and Data Integrity Failures(소프트웨어 및 데이터 무결성 오류), Server-Side Request Forgery(서버 측 요청 변조)가 추가됐습니다. 기존 항목 중 XML External Entities(XXE)와 Cross-Site Scripting(XSS)는 Injection(인젝션)에, Insecure Deserialization(안전하지 않은 역직렬화)은 Software and Data Integrity Failures(소프트웨어 및 데이터 무결성 오류)에 병합됐습니다.

OWASP Top 10 – 2021

지금부터 OWASP Top 10 – 2021에 선정된 내용을 하나씩 살펴보겠습니다.

A01: Broken Access Control(취약한 접근 제어: 권한/인가)

접근 제어(Access Control)는 사용자가 권한을 벗어난 행동을 할 수 없도록 정책을 만들고 실행하는 기능입니다. 접근 제어가 취약하게 구현되면 사용자는 주어진 권한을 벗어나 인가되지 않은 데이터에 무단으로 접근해, 조작이나 삭제하는 등을 할 수 있습니다.

2017 대비 4계단 상승해 첫 번째 항목으로 선정됐으며, 그만큼 다양한 방식으로 많은 취약점이 발생하고 있습니다. 적절한 예방을 위해서 설계 단계에서부터 올바른 접근 제어 정책을 수립하고 애플리케이션 모든 범위에 누락 없이 적용해야 합니다.

취약점 예시

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

예방 방법

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

공격 시나리오

시나리오1: 애플리케이션이 계정 정보를 조회하는 SQL을 호출하는 경우, 이를 조작해 허가되지 않은 데이터에 접근할 수 있습니다.

계정 정보를 조회하는 SQL 호출
userID 파라미터 조작

공격자가 HTTP 요청을 할 때 ‘userId’ 파라미터를 조작해, 타 사용자의 계정 정보를 요청할 수 있습니다. 서버 측에서 ‘userId’를 검증하지 않는다면 공격자는 모든 사용자의 계정 정보에 접근할 수 있습니다.

관리자 페이지 접근제어

시나리오2: 정상적인 방법을 통해서는 접근할 수 없는 관리자 페이지 URL을 클라이언트 소스코드 내에서 획득하거나, 추측 또는 무작위 대입 등을 통해 해당 URL로 직접 접근을 시도했을 때 서버 측 접근 권한 검증이 없다면 공격자는 관리자 페이지에 접근할 수 있습니다.

A02: Cryptographic Failures(암호화 실패)

기존에는 민감 데이터 노출(Sensitive Data Exposure)이라고 했었으나, 이번에 암호화 실패(Cryptographic Failures)로 명칭이 변경됐습니다. 2017년 대비 한 단계 상승해 두 번째 항목으로 선정됐습니다. 이 항목에서는 암호화와 관련된 전반적인 내용을 광범위하게 다루고 있습니다.

암호화에 오류가 있거나 미흡한 부분이 있는 경우, 민감 데이터 노출로 이어집니다. 특히 개인정보와 금융 데이터 같은 법과 규정에 강력하게 영향을 받는 경우라면 안전하게 보호하기 위한 추가 요구 사항을 지켜야 합니다. (국내의 경우 개인정보보호법, 정보통신망법, 신용정보법, ISMS-P 인증, ISO-27001 인증, 주요정보통신기반시설 취약점 분석평가, 전자금융기반시설 취약점 분석평가 등이 있습니다.)

취약점 예시

  • 내·외부망에 관계없이 데이터가 전송구간에서 평문으로 전송되는 경우(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로 강제 리다이렉트) 설정
  • 암호화 시 암호문이 고정되지 않도록 의사 난수 생성기를 포함
  • 신뢰할 수 있는 기관에서 발급한 인증서 사용

공격 시나리오

평문으로 노출된 아이디와 패스워드

공격자가 스니핑하고 있는 네트워크에서 중요 정보가 포함된 데이터를 평문으로 전송하는 경우, 공격자는 평문으로 노출된 아이디와 패스워드를 획득해 해당 시스템에 로그인할 수 있습니다.

세션ID 획득 후 시스템 접근

공격자가 인증한 세션ID를 획득하면, 해당 세션ID에 부여된 권한으로 시스템에 접근할 수 있게 됩니다.

A03: Injection(인젝션)

역사적으로 웹 애플리케이션 취약점 중 가장 많이 알려진 인젝션(Injection)이 세 번째 항목으로 선정됐습니다. 이번에 XSS(Cross-site Scripting)가 인젝션 항목에 포함되면서, 사용자 제공 데이터 조작을 통한 공격은 모두 인젝션 항목으로 통일됐습니다.

인젝션은 사용자가 전달하는 데이터(파라미터, 헤더, URL, 쿠키(Cookie), Json 데이터, SOAP, XML 등 모든 형태)를 신뢰할 수 없는 데이터로 조작해서, 서버 측에서 명령어나 쿼리문의 일부로 인식하게 만들 때 발생하는 취약점입니다.

취약점 예시

  • 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)
  • 사용자 제공 데이터에 대한 화이트리스트 기반 서버 측 검증

공격 시나리오

// SQL 호출을 취약하게 구현한 애플리케이션
\
String query = “SELECT \* FROM accounts WHERE custID=’” + request.getParameter(“id”) + “‘“;
Query HQLQuery = session.createQuery(“FROM accounts WHERE custID=’” + request.getParameter(“id”) + “‘“);
id 파라미터 조작

SQL 호출을 취약하게 구현한 애플리케이션에서 사용자 제공 데이터를 공격자가 조작할 수 있도록 방치한다면, 공격자는 사용자 제공 데이터에서 id 파라미터를 조작하는 것만으로도 해당 컬럼의 모든 데이터를 조회할 수 있습니다.

A04: Insecure Design(안전하지 않은 설계)

안전하지 않은 설계(Insecure Design)는 새롭게 추가된 항목입니다. 코드 구현 단계에 앞서 기획과 설계 단계에서 발생하는 보안 결함을 의미합니다. 안전하지 않게 설계한 애플리케이션은 개발을 완료한 후에 코드를 수정해도 보안 결함을 완벽하게 방어하는데 한계가 있을 수밖에 없습니다. 그래서 설계 단계에서부터 보안성을 고려해야 합니다.

소프트웨어 개발보안 방법론(출처: KISA)
  • 요구사항 및 리소스 관리: 모든 데이터 자산과 예상되는 비즈니스 로직의 기밀성, 무결성 가용성 및 신뢰성에 관한 보안 요구사항을 포함하여 기획
  • 보안 설계: 알려진 공격 기법을 방지하기 위해 위협을 지속적으로 평가하고 코드가 안전하게 설계되고 테스트됐는지 확인하는 문화 및 방법론 적용
  • 보안 개발 생명 주기: 전체 프로젝트 및 소프트웨어 유지 관리의 전반에 걸쳐 프로젝트 시작 단계에서부터 보안 전문가의 검증 필요

우선, 여기까지 OWASP와 OWASP Top 10 – 2021에 선정된 4개 항목을 먼저 살펴봤습니다. 다음 글에서 나머지 6개 항목으로 돌아오겠습니다.

OWASP | OWASP Top 10 | OWASP Top 10 2021 | 보안개발팀 | 보안실
Table of Contents
2
3