안녕하세요! 👋 디지털 시대의 정보 지킴이를 꿈꾸는 여러분, 오늘은 2017년 OWASP Top 10에서 세 번째로 위험한 취약점으로 지목된 A3: 민감한 데이터 노출(Sensitive Data Exposure)에 대해 이야기해 보겠습니다.

주민등록번호, 신용카드 정보, 비밀번호... 이런 민감한 정보들이 제대로 보호받지 못하고 인터넷 세상을 떠돌아다닌다면 어떻게 될까요? 오늘 포스트를 통해 그 위험성과 안전하게 지키는 방법을 알아보겠습니다! 🛡️
🤔 민감한 데이터 노출이란 무엇인가요?
민감한 데이터 노출은 이름 그대로 보호되어야 할 중요한 정보가 암호화 등의 안전장치 없이 외부에 노출되는 취약점을 말합니다. 이는 데이터가 전송 중(in-transit)일 때 발생할 수도 있고, 저장된 상태(at-rest)에서 발생할 수도 있습니다.
공격자는 이렇게 노출된 정보를 이용해 신분 도용, 금융 사기 등 심각한 2차 범죄를 저지를 수 있기 때문에, 단순히 정보가 보이는 것 이상의 큰 피해를 유발합니다. 💥
어떤 데이터가 민감한 정보일까요?
- 개인 식별 정보 (PII): 주민등록번호, 여권번호, 운전면허번호, 주소, 전화번호
- 금융 정보: 신용카드 번호, 계좌번호
- 의료 정보: 건강 기록, 진료 내역
- 인증 정보: 아이디, 비밀번호, 보안 질문과 답변
- 기타 중요한 비즈니스 정보
데이터는 언제, 어떻게 노출될까요?
민감한 데이터는 크게 두 가지 상황에서 공격자에게 탈취될 수 있습니다.
1. 전송 중인 데이터 탈취 (Data in Transit)
사용자의 웹 브라우저와 서버가 데이터를 주고받는 과정에서 암호화가 적용되지 않았을 때 발생합니다. 대표적인 예가 바로 HTTP 프로토콜입니다.
예시: 카페 공용 와이파이에서의 위험 ☕
여러분이 카페의 공용 와이파이에 접속해 http://로 시작하는 쇼핑몰에서 로그인을 한다고 상상해 보세요. 만약 같은 와이파이에 접속한 공격자가 '패킷 스니핑'이라는 기술을 사용하면, 여러분이 입력한 아이디와 비밀번호를 암호화되지 않은 평문(Plain Text) 그대로 훔쳐볼 수 있습니다.
- 주요 원인:
- 암호화되지 않은 HTTP 프로토콜 사용
- 취약한 버전의 SSL/TLS 프로토콜 사용 (예: SSLv3, TLSv1.0)
- 약한 암호화 알고리즘 사용
2. 저장된 데이터 탈취 (Data at Rest)
데이터베이스, 파일 서버, 백업 파일 등에 정보가 저장될 때 암호화되지 않은 상태로 보관되어 있을 경우 발생합니다.
예시: 허술하게 보관된 비밀번호 🗄️
만약 웹사이트 운영자가 사용자의 비밀번호를 데이터베이스에 my_password123과 같이 평문 그대로 저장했다고 가정해 봅시다. 공격자가 SQL 인젝션 등의 다른 공격을 통해 이 데이터베이스를 통째로 탈취한다면, 모든 사용자의 비밀번호가 그대로 노출되는 대참사가 발생합니다.
- 주요 원인:
- 데이터베이스, 파일 시스템에 데이터를 평문으로 저장
- MD5, SHA1과 같이 현재는 안전하지 않은 오래된 해시 함수로 비밀번호를 암호화
- 암호화에 사용된 키(Key)를 소스코드에 하드코딩하거나 안전하지 않은 곳에 보관
- 브라우저 캐시에 민감한 정보가 그대로 저장되도록 설정
🛡️ 내 정보를 지키는 금고 만들기 (대응 방안)
민감한 데이터를 안전하게 보호하기 위한 핵심은 '강력한 암호화'와 '최소화 원칙'입니다.
1. 전송 계층 암호화는 기본! (TLS)
모든 통신 구간에 TLS(Transport Layer Security), 즉 HTTPS를 적용해야 합니다. 최신 브라우저들은 http:// 사이트에 '주의 요함' 경고를 표시할 정도로 HTTPS는 이제 선택이 아닌 필수입니다.
- 체크리스트:
- 웹사이트 전체 페이지에 HTTPS 적용하기
- 안전한 최신 버전의 TLS 프로토콜(예: TLS 1.2, 1.3) 사용하기
- 강력한 암호화 스위트(Cipher Suite)와 완벽한 순방향 비밀성(PFS) 설정하기
2. 저장 데이터 암호화 철저히 하기
데이터를 저장하기 전, 반드시 강력한 표준 암호화 알고리즘을 사용하여 암호화해야 합니다.
- 데이터 종류별 암호화:
- 비밀번호: bcrypt, scrypt, Argon2, PBKDF2와 같이 '적응형 단방향 해시 함수'를 사용해야 합니다. 이 함수들은 의도적으로 계산 속도를 느리게 만들어 무차별 대입 공격을 어렵게 만듭니다. 반드시 솔트(Salt)를 추가하여 레인보우 테이블 공격을 방어해야 합니다.
- 개인정보/금융정보: AES(Advanced Encryption Standard)와 같은 강력한 대칭키 또는 비대칭키 암호화 알고리즘을 사용하여 암호화해야 합니다.
- 암호화 키 관리: 암호화 알고리즘만큼 중요한 것이 바로 암호화 키(Key) 관리입니다. 키는 HSM(하드웨어 보안 모듈)이나 전용 키 관리 솔루션을 사용하여 안전하게 보관하고, 접근 권한을 최소화해야 합니다.
3. 데이터 최소화 및 폐기
- 수집 최소화: 정말 필요한 정보가 아니라면 처음부터 수집하지 않는 것이 가장 안전합니다.
- 보관 기간 설정: 법적으로 정해진 보관 기간이 지나거나 더 이상 필요 없는 데이터는 즉시 안전하게 파기해야 합니다.
- 불필요한 노출 방지: API 응답이나 로그 파일에 불필요한 민감 정보가 포함되지 않도록 주의해야 합니다.
4. 브라우저 캐싱 비활성화
민감한 정보가 포함된 페이지는 브라우저나 중간 프록시 서버에 캐시(저장)되지 않도록 HTTP 헤더에 Cache-Control: no-store, Pragma: no-cache 등의 설정을 추가해야 합니다.
2021년 OWASP Top 10에서는 A3: 민감한 데이터 노출이 A2: 암호화 실패(Cryptographic Failures)라는 이름으로 바뀌며 그 중요성이 더욱 강조되었습니다. 이는 단순히 데이터가 노출되는 현상을 넘어, 암호화 과정 자체의 실패가 근본 원인임을 명확히 한 것입니다.
데이터는 디지털 시대의 자산입니다. 우리의 소중한 자산이 공격자의 손에 넘어가지 않도록, 개발 단계부터 철저한 암호화와 보안 원칙을 적용하는 습관이 무엇보다 중요합니다.
'일반IT > IT보안' 카테고리의 다른 글
| 🚪"출입금지" 팻말이 무색할 때: OWASP A5:2017 - 취약한 접근 통제(Broken Access Control) (5) | 2025.08.16 |
|---|---|
| 📜 오래된 문서의 역습! OWASP A4:2017 - XML 외부 개체(XXE) 파헤치기 (3) | 2025.08.16 |
| 🔐 "내 계정이 내 계정이 아니야!" OWASP A2:2017 - 취약한 인증(Broken Authentication) 완전 정복 (2) | 2025.08.16 |
| 😱 웹 애플리케이션의 오랜 숙적: OWASP A1:2017 - 인젝션(Injection) 파헤치기 (1) | 2025.08.16 |
| 🛡️ 웹 스캐너 완전 정복: 내 웹사이트의 숨은 보안 구멍 찾기 (4) | 2025.08.16 |