OWASP Top 10이란?

OWASP Foundation Open Source Foundation for Application Security

보안 취약점 진단하면 빠질 수 없는 가이드로 OWASP Top 10이 있다. 이 리스트는 무엇이고 어떤 항목이 포함되어 있길래 이렇게 자주 언급되는 것일까?

OWASP Top 10

OWASP, Open Web Application Security Project는 웹 애플리케이션 보안 증진을 목표로 하는 비영리단체로 여러 오픈 소스 소프트웨어와 교육, 콘퍼런스 등을 제공하고 있다. 그중에서도 제일 유명한 것은 OWASP Top 10 이라는 안전한 웹 애플리케이션 개발을 위한 가이드로 2004년부터 매 3, 4년마다 발행하고 있다. 이 가이드는 보안 콘퍼런스나 교육을 듣다 보면 웹 취약점 진단에 꼭 등장하는 가이드로 그만큼 중요하고 빠질 수 없는 문서인 것이다.

Table of Contents | OWASP

문서에서도 당부하고 있지만 이 10개의 취약점이 웹 애플리케이션의 모든 보안 취약점이 아니며 이 10가지에서 멈추지 않고 더 많은 취약점이 애플리케이션에 존재할 수 있다고 가정하고 진단 임해야 한다. 그리고 꼭 수동으로 진단하지 말고 이런저런 툴을 이용하여 자동으로, 현명하게 진단할 수 있도록 하자.

 

비슷한 내용으로 OWASP Application Security Verification Standard가 있다. 이는 웹 애플리케이션 보안 검증을 위한 점검 항목 목록으로 안전한 웹 애플리케이션 개발을 위해 가이드로 사용하거나 어떤 판단의 척도로 사용할 수 있다.

OWASP Application Security Verification Standard

이름만 들어보면 OWASP Top 10과 별 차이가 없어보이지만 Top 10은 위협적인 웹 공격 10가지를 다루는 반면에 위의 ASVS는 '사용자 계정의 비밀번호는 영문자와 숫자를 조합하여 12글자를 넘어야 한다' 같은 지침 같은 내용을 담고 있다는 차이점이 있다.

 

OWASP Top 10은 2017년 버전이 나온 이후 아직 2020년 버전은 출시되지 않았지만 곧 출시될 예정이라고 한다. 2017년 버전에 어떤 항목이 있었으며 이는 무슨 취약점을 의미하는지, 그 전판인 2014년과 비교하면 어떤 항목이 추가되고 사라졌는지 알아보자.

OWASP Top 10(2017)

웹 생태계에도 많은 변화가 있었기 때문에 OWASP Top 10에도 많은 변화가 일어났다. 노드(node.js)와 스프링 부트(Spring Boot)로 작성된 마이크로서비스(API로 통신하는 가벼운 아키텍처)는 기존의 모노리스(모든 기능이 내부에 축적된 거대한 아키텍처) 애플리케이션을 대체하고 있고 이 마이크로 서비스는 다른 요소와 통신할 때 자체적으로 보안 요소를 구축해야 하는 부담을 안게 되었다. 낡은 코드들은 API나 RESTful 웹사이트 뒤에 숨게 되었으며 Single Page Applications(SPA), 모바일 애플리케이션 등이 이를 활용하는 형태를 띠게 되었다. 특히 Angular나 React를 활용한 Single Page Application들이 등장하면서 서버 측에서 처리하던 기능을 클라이언트 측에서 처리하게 되었고 보안 부담 역시 SPA가 맡게 되었다. 이런 상황에서 자바스크립트는 node.js, Bootstrap, Electron, Angular, React 등에서 클라이언트 측의 주요 언어로 떠오르게 되었다.

 

2017년 판에는 A4:2017-XML External Entities와 A8:2017-Insecure Deserialization, A10:2017-Insufficient Logging & Monitoring이 새로운 화두로 떠올랐다. 커뮤니티에서 다양한 의견을 수렴하고 광범위한 실제(real-world) 애플리케이션, API에서 수집한 자료들과 source code analysis security testing tools (SAST)의 데이터셋으로 발견된 새로운 취약점들로 신규 항목이 많이 추가된 만큼 보안 위협이 얼마나 급변하고 있는지 알 수 있다. 2013년의 A4-Insecure Direct Object References와 A7-Missing Function Level Access Control은 A5:2017-Broken Access Control로 통합되었으며 A8-Cross-Site Request Forgery (CSRF)는 CSRF 방어 체계가 잘 갖춰지면서 오직 5%의 애플리케이션에서만 발견되었기 때문에, A10-Unvalidated Redirects and Forwards는 8%의 애플리케이션에서 발견되었기 때문에 A4:2017-XML External Entities(XXE)에 밀려 순위에서 내려가게 되었다.

A1:2017-Injection

SQL, NoSQL, OS, LDAP 인젝션 같은 인젝션 취약점들은 신뢰할 수 없는 데이터가 명령어나 쿼리의 일부로 포함될 때 발생한다. 공격자의 악의적인 데이터는 명령어나 쿼리를 실행하는 인터프리터가 의도하지 않았던 작업(데이터 접근 인증 우회 등)을 수행하도록 할 수 있다. DBMS는 다양하고 그에 따른 SQL도 다양하기 때문에 수많은 인젝션이 발생할 수 있지만 잘 알려져 있는 것은 MySQL이나 NoSQL일 것이다. 이 취약점은 운영체제 명령어로 사용자 입력이 삽입되는 커맨드 인젝션도 포함한다.

A2:2017-Broken Authentication

애플리케이션의 세션이나 인증 관리 로직이 불충분하게 구현되어 공격자가 이를 악용하여 비밀번호, 비밀키, 세션 ID 등을 노출시키거나 다른 사용자들의 개인 정보를 추측할 수 있다. 최근에는 이를 방지하기 위해 SameSite Cookie나 HttpOnly 등 HTTP 쿠키를 보호하는 기법이 많이 적용되어 있다.

A3:2017-Sensitive Data Exposure

수많은 애플리케이션, API들은 재정(financial)이나 건강(healthcare), 개인 식별 정보(PII)같은 중요한 데이터를 적절하게 보호하지 않아 공격자들은 이를 탈취하여 추가적인 범죄에 악용할 수 있다. 이런 중요한 데이터는 전송 전이나 전송 중에 암호화하는 등 추가적인 보호 조치가 없다면 쉽게 노출될 수 있으며 웹 브라우저를 통해 교환될 때는 각별한 주의가 필요하다.

A4:2017-XML External Entities

오래되거나 보안 수칙이 제대로 적용되지 않은 XML 문서 처리기들은 XML 문서를 파싱할 때 외부 개체에 대한 참조(external entity references)를 수행한다. 이때 외부 개체에 악의적인 데이터가 들어 있다면 공격자는 다른 웹사이트로 요청을 위조하는 SSRF나 내부 파일 공유, 포트 스캐닝, 원격 코드 실행(RCE) 등의 방법으로 내부 파일에 접근할 수 있다. 혹은 서비스 거부 공격도 수행할 수 있다. XML 문서는 현대 웹사이트에서 API나 데이터 공유 시 많이 사용되는 형식이다. 하지만 XML 문서에서는 단순히 데이터를 정의하거나 속성을 부여하는 것뿐 아니라 새로운 데이터 타입을 정의할 수도 있다. 이는 XML Schema Definition이나 Document Type Definition 두 가지 방법으로 정의할 수 있는데 후자의 경우에서 이 취약점이 발생한다. 자세한 내용은 추가 포스트에서 다루겠다. 관련 문서는 What Are XML External Entity (XXE) Attacks (acunetix.com)를 참고하면 좋다.

What Are XML External Entity (XXE) Attacks

A5:2017-Broken Access Control

특정 작업(비밀 파일 접근, 개인정보 조회 등)이나 파일들은 오직 인증된 사용자만 접근, 수행할 수 있어야 하지만 인증 과정이 제대로 적용되지 않으면(파라미터 변조 등) 공격자들은 자신의 권한 밖에 있는 작업을 수행하거나 파일에 접근할 수 있다.

A6:2017-Security Misconfiguration

잘못된 보안 설정은 가장 흔히 보이는 취약점으로 안전하지 않은 기본값 설정을 사용하거나 불완전한, 혹은 특정 상황에만 동작하는 설정, 개방된 클라우드 저장소, 잘못 설정된 HTTP 헤더, 민감한 정보를 출력할 수 있는 에러 메시지 노출 등 다양한 곳에서 발생할 수 있다. 이 취약점은 운영 체제 뿐 아니라 프레임워크, 라이브러리 등 다양한 곳에서 발생할 수 있다. 그러므로 항상 설정을 확인하고 시스템을 최신 상태로 유지해야 한다.

A7:2017-Cross Site Scripting

크로스 사이트 스크립팅(XSS)은 애플리케이션이 사용자 입력을 검증하지 않고 새로운 웹 페이지에 이를 포함하거나 HTML, 자바스크립트를 사용하는 브라우저 API로 기존에 존재하는 웹 페이지를 업데이트할 때 발생할 수 있는 취약점이다. 쉽게 말해서 공격자의 스크립트가 클라이언트 측 브라우저에서 실행되어 브라우저 쿠키 탈취, 웹사이트 변조나 원치 않는 리디렉션 등이 발생할 수 있다.

A8:2017-Insecure Deserialization

안전하지 않은 역직렬화는 원격 코드 실행(RCE) 취약점이나 재전송 공격(replay attack), 인젝션 공격, 권한 상승 등 다른 공격을 수행하는 기반이 될 수 있다. 직렬화, 역직렬화란 무엇인가? 이는 네트워크나 디스크에서 표준 프로토콜로 데이터를 전송하기 위해 데이터를 적절한 포맷의 문자열로 변환하거나 다시 원래 데이터로 변환하는 과정을 뜻한다. 데이터는 특정 객체가 될 수도 있고 어떤 바이너리가 될 수도 있다. 이런 데이터를 시스템 간 전송을 위해 송신 시스템에서 직렬화했다가 수신 시스템에서 역직렬화할 때 이 직렬화된 데이터(문자열)가 공격자에 의해 변조되었다면 원래 의도했던 것과 다른 결과를 얻을 수 있다. 그렇기 때문에 해시값 등 암호학적인 기법과 함께 전송되는 것이 일반적이다. 이 예시를 보인 Insecure Deserialization: Attack examples, Mitigation and Prevention | Hdiv Security를 참고하면 좋다.

Insecure Deserialization: Attack examples, Mitigation and Prevention | Hdiv Security

A9:2017-Using Components with Known Vulnerabilities

컴포넌트란 라이브러리나 프레임워크, 소프트웨어 모듈 등을 의미한다. 이들은 애플리케이션의 구성원이기 때문에 애플리케이션과 동일한 권한을 갖고 실행되는데 만약 이 컴포넌트들 중에서 취약점이 발견된 것들이 있다면 이는 애플리케이션 전체의 보안을 깎을 수 있다. '시스템은 가장 취약한 연결고리만큼 보안에 강건하다'라는 말이 있는 것처럼 애플리케이션 구성원 중 일부가 취약점이 발견됐다면 해당 취약점으로 말미암아 애플리케이션 전체에 데이터 손실이나 다른 공격이 발생할 수 있는 것이다.

A10:2017-Insufficient Logging & Monitoring

불충분한 로깅과 모니터링은 말 그대로 로그 감사와 실시간 감시가 부족하다는 것을 의미한다. 이는 공격자들이 어떻게 공격에 성공해도 이를 탐지하거나 차단하지 못해 추가적인 공격(다른 시스템 공격, 백도어 설치 등 거점 확보, 데이터 파괴 등)으로 이어질 수 있다. 통계 결과 대부분의 기업에서 침해 사실을 탐지하는 데 200일이 넘게 소요되었으며 내부 감사나 모니터링보다 외부 업체에 의해 발견되었다고 한다.

 

 

이렇게 간단하게 10가지 항목을 정리해보았다. 각 항목에 대한 세부적인 정보는 각각 포스트를 작성해서 진행하도록 하겠다.