OWASP Top 10 실전 예제로 알아보기
해마다 수천 개의 웹 애플리케이션이 반복되는 동일한 보안 결함으로 인해 침해당하고 있습니다. OWASP Top 10은 웹 애플리케이션에 가장 치명적인 보안 위험을 정리한 표준 인식 문서입니다. 이 글에서는 각 위험을 하나씩 살펴보고, 실제 예제와 함께 대응 방법을 설명합니다. 개발자, DevOps 엔지니어, 보안에 관심 있는 분이라면 안전한 시스템을 구축하기 위해 이러한 위험을 반드시 이해해야 합니다.
1. 접근 제어 실패 (Broken Access Control)
접근 제어 실패는 사용자가 의도된 권한 범위를 벗어나 행동할 수 있을 때 발생합니다. 예를 들어, 사용자가 URL 파라미터를 변경하여 다른 사용자의 데이터에 접근할 수 있습니다.
예시: 애플리케이션이 /api/user/123을 사용하여 사용자 데이터를 가져옵니다. 로그인한 사용자가 실제로 사용자 123인지 확인하지 않으면, 공격자는 ID를 /api/user/124로 변경하여 다른 사람의 프로필을 볼 수 있습니다.
대응: 서버 측 접근 제어 검사를 구현하세요. 기본적으로 거부하세요. 역할 기반 접근 제어(RBAC)를 사용하고 모든 요청에서 권한을 검증하세요.
2. 암호화 실패 (Cryptographic Failures)
이전에는 '민감 데이터 노출'로 알려졌으며, 전송 중이거나 저장된 민감 데이터를 보호하지 못하는 위험입니다.
예시: 비밀번호를 평문으로 저장하거나 MD5와 같은 취약한 해시 알고리즘을 사용하는 경우.
대응: 저장 데이터에는 강력한 암호화(예: AES-256)를, 전송 데이터에는 TLS 1.2+를 사용하고, 강력한 비밀번호 해싱(bcrypt, Argon2)을 사용하세요.
3. 인젝션 (Injection)
SQL, NoSQL, OS, LDAP 인젝션과 같은 인젝션 결함은 신뢰할 수 없는 데이터가 명령이나 쿼리의 일부로 인터프리터에 전달될 때 발생합니다.
예시: 다음과 같은 SQL 쿼리를 생성하는 로그인 폼:
SELECT * FROM users WHERE username = '$username' AND password = '$password';공격자가 사용자 이름에 ' OR '1'='1을 입력하면 인증을 우회할 수 있습니다.
대응: 파라미터화된 쿼리나 준비된 문(prepared statements)을 사용하세요. 특수 문자를 이스케이프하고 입력을 검증하세요.
4. 안전하지 않은 설계 (Insecure Design)
안전하지 않은 설계는 단순한 구현 버그가 아니라 애플리케이션의 아키텍처와 설계 결함을 의미합니다.
예시: 쉽게 추측할 수 있는 답변을 가진 보안 질문을 사용하는 비밀번호 재설정 기능.
대응: 설계 단계에서 위협 모델링, 안전한 설계 패턴, 참조 아키텍처를 적용하세요.
5. 보안 설정 오류 (Security Misconfiguration)
기본 계정, 사용하지 않는 페이지, 패치되지 않은 결함, 보호되지 않은 파일 및 디렉터리 등이 포함됩니다.
예시: CMS에 기본 관리자 자격 증명을 그대로 두거나 디렉터리 목록을 노출하는 경우.
대응: 설정을 강화하고, 사용하지 않는 기능을 제거하며, 설정 검사를 자동화하세요.
6. 취약하고 오래된 컴포넌트 (Vulnerable and Outdated Components)
알려진 취약점이 있는 라이브러리, 프레임워크 또는 소프트웨어를 사용하는 경우입니다.
예시: 알려진 XSS 취약점이 있는 오래된 버전의 JavaScript 라이브러리를 실행하는 경우.
대응: 의존성을 정기적으로 업데이트하고, npm audit이나 OWASP Dependency-Check와 같은 도구를 사용하며, 사용하지 않는 의존성을 제거하세요.
7. 식별 및 인증 실패 (Identification and Authentication Failures)
인증 및 세션 관리의 취약점입니다.
예시: 약한 비밀번호 허용, 로그인 시도에 대한 속도 제한 없음, URL에 세션 ID 노출 등.
대응: 다중 인증(MFA)을 구현하고, 강력한 비밀번호 정책을 적용하며, 안전한 세션 관리를 사용하세요.
8. 소프트웨어 및 데이터 무결성 실패 (Software and Data Integrity Failures)
무결성 위반을 방지하지 못하는 코드와 인프라입니다.
예시: Subresource Integrity(SRI) 없이 신뢰할 수 없는 CDN의 스크립트를 사용하는 경우.
대응: SRI를 사용하고, 서명을 검증하며, CI/CD 파이프라인이 안전한지 확인하세요.
9. 보안 로깅 및 모니터링 실패 (Security Logging and Monitoring Failures)
불충분한 로깅과 모니터링은 공격자가 탐지되지 않고 지속적으로 활동할 수 있게 합니다.
예시: 실패한 로그인 시도를 기록하지 않아 무차별 대입 공격을 알아차리지 못하는 경우.
대응: 보안 관련 이벤트를 로깅하고, 로그를 모니터링하며, 의심스러운 활동에 대한 경고를 설정하세요.
10. 서버 측 요청 위조 (SSRF)
SSRF는 공격자가 서버로 하여금 내부 리소스에 요청을 보내도록 할 수 있을 때 발생합니다.
예시: 사용자가 제공한 URL을 가져오는 웹훅 기능. 공격자는 http://169.254.169.254/latest/meta-data/를 제공하여 클라우드 메타데이터에 접근할 수 있습니다.
대응: URL을 검증 및 정제하고, 허용 목록을 사용하며, 아웃바운드 트래픽을 제한하세요.
비교 표
| 위험 | 예시 | 대응 |
|---|---|---|
| 접근 제어 실패 | IDOR을 통한 다른 사용자 데이터 접근 | 서버 측 권한 검사 |
| 암호화 실패 | 비밀번호를 평문으로 저장 | 강력한 해싱과 TLS 사용 |
| 인젝션 | 로그인 폼을 통한 SQL 인젝션 | 파라미터화된 쿼리 |
| 안전하지 않은 설계 | 취약한 비밀번호 재설정 질문 | 위협 모델링 |
| 보안 설정 오류 | 기본 관리자 자격 증명 | 설정 강화 |
| 취약한 컴포넌트 | XSS 결함이 있는 오래된 라이브러리 | 정기적 업데이트 |
| 인증 실패 | 로그인에 속도 제한 없음 | MFA와 속도 제한 |
| 무결성 실패 | 신뢰할 수 없는 CDN 스크립트 | Subresource Integrity |
| 로깅 실패 | 실패한 로그인에 대한 로그 없음 | 중앙 집중식 로깅과 경고 |
| SSRF | 내부 메타데이터 가져오기 | URL 허용 목록 |
시작하는 방법
- 평가: OWASP Top 10에 대해 자동화된 스캐너와 수동 검토를 실행하세요.
- 우선순위 지정: 가장 치명적인 문제(예: 인젝션, 접근 제어 실패)를 먼저 해결하세요.
- 교육: 개발자에게 안전한 코딩 관행을 교육하세요.
- 모니터링: 보안 이벤트에 대한 로깅과 경고를 구현하세요.
- 반복: 의존성을 정기적으로 업데이트하고 재테스트하세요.
자주 묻는 질문
OWASP Top 10이란 무엇인가요?
OWASP Top 10은 Open Web Application Security Project(OWASP)에서 발행하는 웹 애플리케이션에 가장 치명적인 보안 위험 목록으로, 정기적으로 업데이트됩니다.
OWASP Top 10은 얼마나 자주 업데이트되나요?
약 3~4년마다 업데이트되며, 최신 버전은 2021년에 발표되었습니다. 그러나 OWASP는 지속적인 지침과 업데이트를 제공합니다.
보안을 위해 OWASP Top 10에만 의존해도 되나요?
아니요, 이는 시작점일 뿐입니다. Application Security Verification Standard(ASVS)와 같은 다른 OWASP 프로젝트도 따르고 정기적인 보안 테스트를 수행해야 합니다.
SQL 인젝션이나 XSS와 같은 공격 징후가 있는지 Nginx 로그를 빠르게 분석하려면 Nginx Log Analyzer를 사용해 보세요. 의심스러운 패턴을 발견하고 웹 서버를 안전하게 보호하는 데 도움이 됩니다.