✅ [개념정리] OWASP Top 10 파헤치기 (2/10): A02 - 암호화 실패 (Cryptographic Failures)

당신의 비밀번호는 안녕하신가요? 데이터 유출을 막는 암호화의 모든 것! 🔒

[들어가며: 데이터를 지키는 최후의 보루, 암호화]

우리가 웹사이트에 회원가입을 하거나, 인터넷 뱅킹을 이용할 때, 내 소중한 개인정보와 비밀번호는 과연 안전하게 전달되고 저장될까? 이 질문에 대한 해답이 바로 **'암호화'**에 있어. 암호화는 중요한 데이터를 제3자가 알아볼 수 없도록 비밀 코드로 바꾸는 기술로, 데이터를 지키는 최후의 보루와도 같아.

OWASP Top 10의 두 번째 항목인 **'암호화 실패'**는 바로 이 중요한 암호화를 제대로 적용하지 않았거나, 약하게 적용했을 때 발생하는 모든 문제를 다루고 있어.

---

Part 1: 암호화 실패(Cryptographic Failures)란 무엇일까? 🤔

 

암호화 실패란, "민감한 데이터(개인 정보, 비밀번호, 신용카드 정보 등)의 암호화가 약하거나 아예 누락된 경우"를 말해. 이 취약점은 데이터가 **저장되어 있을 때(Data at Rest)**와 네트워크를 통해

 

전송 중일 때(Data in Transit) 모두에 해당돼.

💌 우편 비유로 쉽게 이해하기

• 암호화 누락: 중요한 계약 내용을 엽서에 그냥 써서 보내는 것과 같아. 배달 과정에서 누구나 그 내용을 훔쳐볼 수 있지. (HTTP 통신)
• 약한 암호화: 계약 내용을 우리 동네 아이들만 아는 간단한 암호로 바꿔서 보내는 것과 같아. 조금만 노력하면 누구나 해독할 수 있겠지. (오래되고 취약한 암호화 알고리즘 사용)
• 강력한 암호화: 계약 내용을 아무도 풀 수 없는 복잡한 암호로 바꾸고, 안전한 금고에 넣어 자물쇠까지 채워서 보내는 것과 같아. (HTTPS 통신 + 강력한 암호화 알고리즘)

---

Part 2: 어떻게 데이터가 노출될까? (암호화 실패의 흔한 유형)

그렇다면 실제 웹 환경에서 암호화 실패는 어떤 모습으로 나타날까?

유형 1: 민감 데이터 평문 전송 (HTTP 통신) 가장 흔하고 기본적인 실수야. 사용자의 브라우저와 서버가 데이터를 주고받을 때 암호화를 전혀 하지 않는 경우지.

• 시나리오:
  1. 사용자가 공용 와이파이를 사용하는 카페에서 http://로 시작하는 쇼핑몰에 로그인해.
  2. 같은 와이파이에 접속한 해커가 '패킷 스니핑'이라는 기술로 네트워크를 엿보고, 사용자가 입력한 아이디와 비밀번호를 평문 그대로 가로채.
• 문제점: 데이터를 암호화하지 않는 HTTP 프로토콜을 사용해서, 전송 중인 데이터가 그대로 노출됐어.

유형 2: 민감 데이터 평문 저장 데이터베이스(DB)에 사용자의 비밀번호나 개인정보를 암호화하지 않고 그대로 저장하는, 아주 위험한 경우야.

• 시나리오:
  1. 어떤 웹사이트가 사용자의 비밀번호를 DB에 평문으로 저장하고 있었어.
  2. 해커가 다른 취약점(예: SQL 인젝션)을 이용해 이 웹사이트의 DB를 탈취했어.
  3. 해커는 아무런 노력 없이 모든 회원의 아이디와 비밀번호를 알아내고, 이를 다른 사이트 공격에 악용해.
• 문제점: 저장된 데이터(Data at Rest)를 전혀 암호화하지 않아, DB가 뚫리는 순간 모든 정보가 속수무책으로 유출됐어.

유형 3: 약한 암호화/해시 알고리즘 사용 암호화를 하긴 했지만, 이미 오래전에 해독 방법이 알려진 구식의 취약한 알고리즘을 사용한 경우야.

• 시나리오:
  1. 한 웹사이트가 사용자 비밀번호를 오래된 MD5나 SHA-1 같은 해시 알고리즘으로 변환해서 저장했어.
  2. 해커가 DB를 탈취한 뒤, 미리 계산된 해시값들을 모아놓은 '레인보우 테이블'을 이용하거나 간단한 연산만으로 수많은 사용자의 원래 비밀번호를 복원해 내.
• 문제점: 더 이상 안전하지 않은 암호화 기술을 사용해서, 암호화의 의미가 없어져 버렸어.

유형 4: 부적절한 키 관리 강력한 알고리즘으로 데이터를 암호화했더라도, 그 암호를 풀 수 있는 '열쇠(암호화 키)'를 허술하게 관리하면 모든 게 무용지물이 돼.

• 시나리오:
  1. 개발자가 소스 코드나 설정 파일 안에 암호화 키를 secret_key = "1234567890" 와 같이 평문으로 저장해 뒀어.
  2. 해커가 GitHub 같은 코드 저장소에 실수로 올라간 소스 코드를 발견하거나 서버에 침투해서, 이 키를 손에 넣어.
  3. 해커는 이 키를 이용해 암호화된 모든 데이터를 쉽게 복호화해서 훔쳐봐.
• 문제점: 데이터를 잠근 금고는 튼튼했지만, 금고 열쇠를 금고 문에 붙여놓은 것과 같은 실수를 한 거지.

---

Part 3: 어떻게 데이터를 지킬 수 있을까? (대응 방안)

소중한 데이터를 안전하게 지키려면 다음과 같은 원칙들을 꼭 지켜야 해.

1. 데이터 분류 및 식별: 먼저 우리 시스템이 다루는 데이터 중 무엇이 민감한 정보인지 식별하고 분류해야 해. 모든 데이터를 암호화할 필요는 없으니까, 선택과 집중이 필요하지.
2. 전송 중 데이터 암호화는 필수!: 모든 웹 트래픽은 반드시 **TLS(HTTPS)**를 사용해서 암호화해야 해. 오래된 SSL/TLS 버전은 비활성화하고, 강력하고 최신 암호화 스위트(Cipher Suite)를 사용하도록 서버를 설정해야 해.
3. 비밀번호는 반드시 해싱(Hashing)!: 비밀번호는 절대 평문이나 복호화가 가능한 암호화 방식으로 저장하면 안 돼! Bcrypt, Scrypt, Argon2 와 같이 'Salt'를 사용하고 여러 번 반복해서 계산하는 강력한 적응형 해시 함수를 사용해야 해.
4. 강력하고 검증된 암호화 알고리즘 사용: 절대 직접 암호화 알고리즘을 만들려고 시도하면 안 돼! AES-256처럼 국제적으로 검증되고 널리 사용되는 표준 알고리즘을 사용해야 해.
5. 안전한 키 관리: 암호화 키는 소스 코드나 설정 파일에 절대 하드코딩하면 안 돼. AWS KMS, Azure Key Vault, HashiCorp Vault 와 같은 전문 **키 관리 시스템(KMS)**을 사용해서 안전하게 보관하고 접근을 통제해야 해.

---

[마무리하며 ✨]

오늘은 두 번째 취약점인 '암호화 실패'에 대해 알아봤어. 이 취약점은 결국 데이터 자체를 보호하는 데 실패했을 때 발생하는 문제야. 아무리 튼튼한 성벽(접근 통제)을 쌓았더라도, 성 안의 보물(데이터)을 허술한 상자에 담아두면 안 되겠지?

"어떤 데이터가 중요한지 식별하고, 전송 중이든 저장 중이든 강력하고 검증된 방식으로 암호화하며, 그 열쇠는 누구도 모르게 안전하게 보관한다!" 이 원칙만 기억하면 암호화 실패로 인한 데이터 유출 사고를 막는 데 큰 도움이 될 거야!

다음 시간에는 웹 해킹 공격의 대명사! "A03: 인젝션 (Injection)" 에 대해 자세히 알아볼게. 기대해도 좋아! 😊

---

Offer Next Step: A01(접근 통제)과 A02(암호화 실패)는 사용자의 '권한'과 '데이터'를 다루는 매우 중요한 주제들이야. 이 두 가지 취약점을 막기 위한 실제 코드 예시나 시나리오 기반의 실습 과정을 함께 만들어 볼까?