OWASP
OWASP(Open Worldwide Application Security Project)는 이전 포스팅에서도 종종 등장했던 개방형 웹 애플리케이션 보안 프로젝트이다.
개발자와 관리자, 보안 전문가 등의 웹 보안 위협 인식을 제고하도록 표준화된 가이드라인과 오픈소스 프로젝트를 제공한다.
OWASP Top 10
그 중 가장 유명한 프로젝트는 OWASP Top 10이다.
웹 애플리케이션에서 가장 빈번하게 발생하며, 보안에 큰 영향을 미치는 주요 취약점을 정리해준다.
3~4년마다 업데이트되며, 해당 포스트에서는 2021년 발표한 Top 10을 기준으로 포스팅한다.
2017년 기준 순위와 2021년 기준 순위가 여럿 바뀌고 새로운 취약점이 등장하기도 했다. 1위로 급부상한 Broken Access Control과 가장 순위가 많이 떨어진 Broken Authentication이 가장 눈에 띈다.
물론 1위에 올라와있다고 중요하고 랭킹에 존재하지 않는다고 중요하지 않은 취약점인 것은 아니나, 업데이트 주기인 3~4년 간 발생빈도(Frequency), 심각도(Severity), 노출도(Exposure)가 높은 취약점이라는 의미이므로 최근 트렌드에 맞춘 보안 점검과 개발 과정의 우선순위를 정할 수 있겠다.
참고로 곧 새로운 버전의 OWASP Top 10 2025가 발표할 예정이기도 하다.
포스팅했던 내용은 복기하며, 새로운 내용은 알아가며 내려가본다.
1. Broken Access Control
웹 사이트는 일반 유저가 접근할 수 없는 페이지가 있다. (Admin 등)
만약 일반 유저가 접근 불가능하도록 보호된 페이지에 접근할 수 있게 된다면, Access Control 취약점이 존재하는 것이다.
일반 유저가 보호된 페이지에 접근할 수 있다면 아래와 같은 문제가 발생할 수 있다.
- 다른 유저의 민감한 정보 열람 가능
- 권한이 없는 기능을 사용 가능
공격자가 인증(Authorisation)을 우회해 민감한 데이터를 보거나 권한이 없는 작업을 수행한다면 Broken Access Control 취약점을 이용한 것이다.
실제로 2019년 유튜브의 Private 동영상 중 단일 프레임을 가져올 수 있는 취약점이 발견됐고, 해당 취약점으로 여러 프레임을 요청해 비공개 동영상을 어느 정도 재구성할 수 있음을 보여주었다.
비공개 동영상에 접근할 수 없을 것을 기대했지만 접근 후 정보를 탈취할 수 있었으므로 Broken Access Control 취약점으로 인정되었다.
2. Cryptographic Failures
암호화 실패(Cryptographic Failures)는 민감한 정보를 보호하기 위한 암호화 알고리즘을 잘못 사용하거나 사용하지 않아 발생하는 모든 취약점이다.
이메일 애플리케이션에서 전송중인 데이터를 암호화(Encrypting data in transit)하거나, 저장된 데이터를 암호화(Encrypting data in rest)하는 것은 필수이다. 그런데 암호화 실패 취약점이 존재한다면 저장된 민감한 데이터가 노출되는 결과를 낳는다.
암호화되지 않은 정보가 있을 수 있는 장소는 여러가지가 있지만 많은 양이 존재하고 쉽게 상호작용할 수 있는 장소는 역시 데이터베이스이다.
작은 애플리케이션에서는 데이터베이스를 파일로 저장할 수 있고 이를 플랫 파일 데이터베이스라고 하는데, 이 역시 디스크에 저장된다. 그렇다면 만약 루트 디렉토리 아래에 저장된 데이터베이스 플랫 파일이 접근된다면 해당 데이터베이스의 모든 데이터에 접근할 수 있고, 민감 데이터 노출에 해당한다.
3. Injection
주입(Injection)이라고 할 수 있다. 매우 흔하게 발생하는 취약점이고, 흔한 빈도수화 함께 위험도가 높은 취약점이다.
로그인 등의 사용자 입력을 명령이나 매개변수로 해석하기 때문에 일어나는데, 해당 입력을 쿼리나 명령어로 해석하지 않도록 하는 것이 매우 중요하다.
서버 코드가 콘솔과 직접 상호작용하는 함수를 호출하면 Command Injection이 일어나기도 한다.
이는 서버에서 임의의 운영 체제 명령을 실행할 수 있게하고 결국 파일을 나열하거나 내용을 읽고 다른 시스템으로 이동할 방법을 찾을 수도 있다.
4. Insecure Design
구조적으로 내재된 취약점을 가지는 애플리케이션이 있다. 구현 과정이나 설정의 문제가 아니라 프로젝트 초기의 설계부터의 잘못된 아이디어가 반영돼 프로덕션 환경에 배포되는 경우 발생할 수 있다.
과거 인스타그램에서 SMS로 6자리의 인증 코드를 보내 비밀번호를 재설정할 수 있었는데, 공격자가 브루트포스 공격으로 동일 IP에서 250번의 시도 이후 차단하는 속도 제한을 구현해놨다.
하지만 이 제한은 IP 주소별로 적용되었고 공격자는 다른 IP를 사용해 000000-999999의 100만개의 수를 4000개의 IP만 있으면 모든 조합을 시도할 수 있었다.
심지어 클라우드 서비스를 이용해 저렴하게 수많은 IP를 확보할 수 있게 되면서 큰 위협이 되었다.
때문에 개발 초기 단계에서 존재할 수 있는 취약점을 발견해내 다시 설계해야한다. 이는 단순히 코드를 수정하는 것보다 더 어렵고 비용이 많이 들기도 한다.
5. Security Misconfiguration
보안 설정의 오류로 발생하거나 적절하지 않은 설정으로 발생하는 취약점이다.
예를 들어서
- S3 버킷과 같은 클라우드 서비스의 접근 권한을 잘못 설정
- 불필요한 기능의 활성화
- 기본 계정의 비밀번호를 바꾸지 않고 사용
- 시스템 정보를 노출하는 지나치게 상세한 오류 메세지
- HTTP의 보안 헤더를 설정하지 않고 사용
와 같은 취약점을 뜻한다.
디버깅 인터페이스를 프로덕션 환경에서 노출하는 것이 흔한 보안 설정의 오류이다.
2015년 패이트리온(Patreon) 해킹사건에서 Werkzeug 디버그 콘솔이 노출되었고, 웹 서버가 파이썬 코드를 실행하도록 돕는 역할을 했다. 한 페이지를 통해서 서버의 모든 정보가 노출될 수 있던 것이다.
/console URL을 통해서 접근하거나 예외가 발생할 경우 사용자에게 디버그 콘솔이 노출됐고, 무려 공격자가 웹 서버에서 모든 코드를 실행할 수 있도록 해 큰 피해가 발생했다.
