OWASP (Open Web Application Security Project)
OWASP Top 10은 약 3~4년 주기로 웹에 관한 정보 노출, 악성 파일 및 스크립트, 보안 취약점 등을 연구하며 웹 보안에서 빈도가 가장 많이 발생하고 보안상 크게 위협이 되는 10가지 이슈를 말합니다.
1. Broken Access Control (취약한 접근제어)
해당 취약점은 사용자 접근제어가 제대로 인증되지 않을 경우에 발생하게됩니다.
이 문제가 발생하면 공격자가 다른 사용자의 계정 및 데이터에 접근해 중요한 파일을 볼 수 있을 뿐 아니라 접근 권한을 수정하는 등 민감한 작업도 실행할 수 있습니다.
해당 취약점을 예방하기 위해서는 공용 리소스를 제외하고 기본적으로 접근을 제한하는 것이 좋습니다. 웹 서버 디렉토리 목록을 비활성화하고 파일 메타데이터 및 백업 파일이 웹 루트 내에 존재하지 않도록 확인해야 합니다.
2. Cryptographic Failures (암호화 오류)
민감 데이터 노출의 원인이 암호화의 실패 또는 부족이라고 분석되어 보다 근본적인 원인으로 명칭이 2017년에 Sensitive Data Exposure(민감 데이터 노출)에서 Cryptographic Failures(암호화 오류)로 변경되었습니다.
해당 취약점을 예방하기 위해서는 애플리케이션에서 처리 및 저장 또는 전송하는 데이터를 분류하고 개인정보보호법, 규제 요구 사항 또는 비즈니스 요구 사항에 따라 민감 데이터를 식별해야 합니다.
민감한 데이터는 불필요하게 저장하지 않고 저장된 모든 민감 데이터는 안전하게 암호화해야 합니다. 최신의 강력한 표준 알고리즘, 프로토콜 및 암호화 키가 제대로 설정되어 있는지 확인하는 것이 중요합니다.
3. Injection (인젝션)
SQL, OS, XXE, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 전달될 때 나타납니다. 공격자의 악의적인 데이터로 인해 예상하지 못하는 명령을 실행하거나 알맞은 권한 없이 데이터에 접근하여 피해를 입을 수 있습니다. 이로 인해서 ID, PW, 개인정보 등의 유출 가능성이 높아집니다.
이에 대응하기 위해서 사용자 입력 창에 일부 특수문자 입력 차단, SQL서버 에러 메시지 표시 금지, 일반 사용자 권한으로 시스템 저장 프로시저 접근을 차단하는 등의 방안이 있습니다.
4. Insecure Design (불안전한 설계)
보안 설계, 즉 설계부터 보안을 고려하는 시큐어 코딩은 위협을 지속적으로 평가하고 알려진 공격 방법을 방지하기 위해 코드가 견고하게 설계 및 테스트되었는지 확인하는 문화 및 방법론입니다. 보안 설계는 소프트웨어에 추가할 수 있는 도구가 아닙니다. 안전한 보안 설계를 위해서는 보안 개발 수명 주기, 보안 설계 패턴 또는 위협 모델링 등이 필요합니다. 소프트웨어 프로젝트를 시작할 때 보안 전문가를 통해 전체 프로젝트와 소프트웨어 유지 관리에 대해 도움을 받는 것이 좋습니다.
5. Security Misconfiguration (보안 구성 오류)
소프트웨어의 구성이 계속해서 고도화됨에 따라 OWASP는 보안 구성 오류 취약점이 앞으로도 계속 상승할 수 있다고 예측합니다. 안정적인 보안은 애플리케이션, 프레임워크, 서버, 플랫폼 등이 함께 구성됩니다. 애플리케이션, 프레임워크, 애플리케이션 서버, 데이터베이스 서버 플랫폼 등에 보안을 적잘하게 설정하고 최적화된 값을 유지하며, 소프트웨어는 최신 업데이트 상태로 유지해야 합니다. 보안 구성 오류는 수동 또는 ad hoc 설정(또는 구성되지 않음), 안전하지 않은 기본 구성, 열린 S3 bucket, 잘못 구성된 HTTP 헤더, 민감정보가 포함된 오류 메시지, 패치되지 않은 시스템, 프레임워크 종속성, 컴포넌트를 적시에 업그레이드 하지 않는 것이 일반적입니다.
이 취약점을 예방하기 위해서는 불필요한 기능, 구성 요소를 최소화하는 것이 좋습니다. 사용하지 않는 기능 및 프레임워크를 제거하거나 불필요하게 설치하지 않아야 합니다.
6. Vulnerable and Outdated Components (취약하고 오래된 요소)
관리되지 않은 타사 구성 요소를 사용하거나 사용하고 있는 구성 요소의 버전을 모르는 경우 위와 같은 취약점에 해당될 수 있습니다. 운영 체제, 웹/애플리케이션 서버, 데이터베이스 관리 시스템(DBMS), API 및 라이브러리 등이 취약하거나 더이상 유지 관리가 지원되지 않거나 오래된 경우도 이 취약점에 해당됩니다.
이를 예방하기 위해서는 보안 취약점에 대한 식별 목록(CVE, NVD 등)을 지속적으로 모니터링하는 것이 좋습니다. 구성 요소, 소프트웨어구성 분석 도구를 사용하여 프로세스를 자동화하고 사용하는 구성 요소와 관련된 보안 취약점에 대한 이메일 경고를 구독하는 것도 좋은 방법입니다. 유지 관리되지 않거나 이전 버전에 대한 보안 패치를 생성하지 않는 라이브러리 및 구성 요소를 모니터링하고 보안 패치를 적용할 수 없는 경우 가상 패치를 배포하여 발견된 문제를 모니터링하고 보호해야 합니다.
7. Identification and Authentication Failures (식별 및 인증 오류)
"Password1234" 또는 "admin/admin"과 같은 기본 암호, 취약하거나 잘 알려진 암호를 허용하는 경우가 위 취약점에 해당됩니다. 또한 안전할 수 없는 지식 기반 답변을 허용하는 경우도 해당되는데, 예를 들어 사용자가 알고 있는 어떤 지식을 확인하여 사용자를 인증하게 되면 보통 사용자 개인정보를 이용해 비밀번호를 생성하기 때문에 공격자가 이러한 점을 이용하면 쉽게 비밀번호를 추측 가능합니다.
이처럼 취약하거나 비효율적인 인증 방법을 사용하거나 다중 인증을 사용하지 않는 경우가 위 취약점에 해당됩니다.
따라서 가능한 경우 도난된 계정 정보 재사용을 막기 위해 다중 인증을 구현하는 것이 좋습니다.
또한 상위 10,000개 최악의 비밀번호 목록에 대해서는 새 비밀번호 또는 변경된 비밀번호를 테스트하는 등 보안에 취약한 비밀번호 검사 시스템을 구현하는 것도 위 취약점을 예방하는 좋은 방법 중 하나입니다.
8. Software and Data Integrity Failures (소프트웨어 및 데이터 무결성 오류)
소프트웨어 및 데이터 무결성 오류는 무결성 위반으로부터 보호하지 않는 코드 및 인프라와 관련되어 있습니다. 예를 들어 공격자가 보고 수정할 수 있는 구조로 개체 또는 데이터가 인코딩되거나 직렬화되는 경우가 이 취약점에 해당됩니다. 많은 애플리케이션들이 충분한 무결성 확인 없이 업데이트되는데, 공격자는 악의적인 파일을 심은 업데이트 파일을 업로드하여 배포하고 실행할 수 있습니다.
따라서 이와 같은 취약점을 예방하기 위해서는 서명되지 않았거나 암호화되지 않은 직렬화된 데이터가 무결성 검사 또는 디지털 서명 없이 신뢰할 수 없는 클라이언트로 전송되지 않도록 하는 것이 중요합니다. 또한 코드의 무결성을 보장하기 위해 CI/CD 파이프라인에 적절한 구성 및 접근제어가 있는지 확인하는 것도 좋습니다.
9. Security Logging and Monitoring Failures (보안 로깅 및 모니터링 오류)
데이터들이 많아짐에 따라 한 곳에서 데이터를 시계열로 기록(로깅)하고 모니터링할 필요성이 높아지고 있습니다. 적절한 로깅 및 모니터링이 이뤄지지 않는다면 의심스러운 활동이 언제 일어났는지 확인하기 어렵습니다.
따라서 이같은 오류를 예방하기 위해서는 의심스러운 활동을 감지하고 신속하게 대응할 수 있도록 효과적인 모니터링 및 경고 시스템을 설정하는 것이 중요합니다. 또한 로깅 및 모니터링 시스템에 대한 공격을 방지하기 위해 로그 데이터가 올바르게 인코딩 되었는지 확인하는 것이 좋습니다.
10. Server-Side Request Forgery (SSRF, 서버측 요청 위조)
CSRF (Cross Site Request Forgery)와는 다르게 클라이언트 측의 요청을 변조시키는 것이 아닌 서버 측 자체의 요청을 변조하여 공격자가 원하는 형태의 악성 행위를 서버에 던져주고, 서버가 이를 검증 없이 그대로 받아 응답하는 공격입니다. 최근 클라우드 서비스와 아키텍쳐의 복잡성으로 인해 SSRF의 심각도가 높아지고 있습니다.
이 취약점을 예방하기 위해서는 네트워크 계층에서 필수 인트라넷 트래픽을 제외한 모든 트래픽을 차단하기 위해 기본적으로 거부하는 방화벽 정책을 적용하거나 네트워크 액세스 제어 규칙을 적용하는 것이 좋습니다. 또한 애플리케이션 계층 측면에서는 HTTP 리디렉션을 비활성화하고 클라이언트가 제공한 모든 입력 데이터를 삭제하고 검증하는 것이 좋습니다.
