[Day 17] 네트워크 위의 엿보기 방지: 데이터 평문 전송 취약점 진단과 대응

안녕하세요! Hackerstory 공부방의 IT/보안 튜터 정다은입니다. 👋

어느덧 21일 완성 코스의 후반부인 17일 차에 접어들었습니다! 지난 시간까지 우리는 애플리케이션 내부의 세션, 파일, 권한 관리 등 로직 중심의 취약점들을 다루었는데요. 오늘은 시선을 조금 넓혀 **'네트워크 구간에서의 데이터 보호'**에 대해 이야기해 보려고 합니다.

오늘 학습할 주제는 [Day 17] 데이터 평문 전송(Data Transmitted in Plaintext) 취약점입니다.

내가 입력한 비밀번호, 주민등록번호, 신용카드 번호가 네트워크를 떠돌 때 누군가 이를 그대로 들여다볼 수 있다면 어떻게 될까요? 웹 보안 진단 현장에서 가장 기본적이면서도 법적 규제(개인정보보호법, ISMS-P 등)와 직접적으로 연결되는 매우 중요한 항목입니다. 차근차근 기본 개념부터 실무 조치 방법까지 알아보겠습니다!

1. 개념 설명: 데이터 평문 전송이란?

(1) 데이터 평문 전송의 정의

데이터 평문 전송 취약점은 로그인 인증 정보, 개인정보, 금융정보 등 보호해야 할 민감한 데이터가 암호화되지 않은 평문(Plaintext) 형태(예: HTTP, FTP, Telnet 등)로 네트워크 망을 통해 송수신될 때 발생합니다.

암호화되지 않은 채 네트워크로 날아가는 데이터는, 동일한 네트워크(공용 Wi-Fi, 스위칭 환경 등)에 존재하는 공격자가 스니핑(Sniffing) 툴이나 **중간자 공격(Man-in-the-Middle, MitM)**을 통해 너무나 손쉽게 패킷을 수집하고 원본 내용을 훔쳐볼 수 있게 됩니다.

(2) 쉬운 비유: 엽서 vs 봉인된 편지

• HTTP (평문 전송): 내용을 누구나 읽을 수 있는 **'엽서'**를 우체통에 넣는 것과 같습니다. 우체부, 중간 전달자, 심지어 길가에 있는 사람도 엽서 뒤에 적힌 비밀번호를 읽을 수 있습니다.
• HTTPS (암호화 전송): 강력한 자물쇠가 달린 **'금고 상자'**에 편지를 넣어 보내는 것과 같습니다. 오직 받는 사람(서버)만이 열쇠(복호화 키)를 가지고 있어 내용을 열어볼 수 있습니다.

[클라이언트]  ---- (HTTP: 평문 전송 / 패킷 감청 가능) ---->  [공격자/스니퍼]
   "ID: admin, PW: password123"  -->  "아주 잘 보이는군!"

[클라이언트]  ---- (HTTPS: TLS 암호화 전송) ------------>  [공격자/스니퍼]
   "a8f9b2c7e1..." (암호문)       -->  "무슨 내용인지 알 수 없군..."

(3) 주요정보통신기반시설 진단 기준 (KISA)

• 취약 (Vulnerable): 로그인, 회원가입, 개인정보 변경, 결제 등 민감 정보를 송수신할 때 HTTP 프로토콜을 사용하거나, 전송 데이터에 대한 암호화가 적용되어 있지 않은 경우
• 양호 (Secure): 민감 정보를 송수신하는 모든 구간에 **TLS/SSL(HTTPS)**이 적용되어 있거나, 애플리케이션 단에서 중요 데이터가 암호화되어 전송되는 경우

2. 실무 진단 및 취약점 예시

실무 진단원들은 보통 Burp Suite와 같은 웹 프로시 툴이나 Wireshark 패킷 분석기, 혹은 브라우저의 **개발자 도구(F12)**를 활용해 이 취약점을 진단합니다.

(1) 취약한 웹 애플리케이션 예시

사용자가 로그인 페이지에서 아이디와 비밀번호를 입력하고 [로그인] 버튼을 누를 때, HTTP 프로토콜을 이용해 요청(Request)을 보내는 상황입니다.

[취약한 HTTP 요청 패킷]

POST /login.php HTTP/1.1
Host: vulnerable-bank.com
User-Agent: Mozilla/5.0 ...
Content-Type: application/x-www-form-urlencoded
Content-Length: 45

user_id=daeun_tutor&user_pw=MySuperSecretPW123!

• 문제점: HTTP(80번 포트)를 통해 전송되므로, 네트워크 구간에서 패킷을 캡처하면 user_id와 user_pw가 어떠한 보호 조치도 없이 raw text(생 문자열) 형태로 노출됩니다.

(2) 패킷 감청(Sniffing) 시나리오

1. 공격 위치: 카페나 공공장소의 암호화되지 않은 Wi-Fi 망.
2. 공격 도구: Wireshark 실행 후 http.request.method == "POST" 필터링 적용.
3. 결과: 동일 Wi-Fi 망에 있는 다른 피해자가 로그인할 때 전송된 POST Body 값을 그대로 수집하여 계정을 탈취.

+-----------------------------------------------------------------------+
| Wireshark Packet Capture                                              |
+-----------------------------------------------------------------------+
| Line | Source        | Destination   | Protocol | Info                |
|  42  | 192.168.0.15  | 211.X.X.X     | HTTP     | POST /login.php ... |
+-----------------------------------------------------------------------+
| Frame Details:                                                        |
| JavaScript content-type / Form item: "user_id" = "daeun_tutor"        |
| JavaScript content-type / Form item: "user_pw" = "MySuperSecretPW123!"|
+-----------------------------------------------------------------------+

3. 완벽 대응 방안 및 보안 대책

데이터 평문 전송을 막기 위해서는 단순한 '일부 페이지 암호화'가 아닌, 전 구간 암호화(HTTPS Everywhere) 방침을 적용해야 합니다.

대책 1: 웹 애플리케이션 전 구간 TLS/SSL (HTTPS) 적용

로그인 페이지뿐만 아니라, 로그인 후 이용하는 모든 서비스 페이지에 **HTTPS(기본 포트 443)**를 적용해야 합니다. (이전에는 로그인 시에만 HTTPS로 보냈으나, 이는 세션 쿠키 탈취 위험이 있어 현재는 전 구간 HTTPS가 표준입니다.)

또한, HTTP(80 포트)로 접속을 시도하는 사용자는 **자동으로 HTTPS(443 포트)로 리다이렉트(301/302 Redirect)**되도록 웹 서버를 설정해야 합니다.

Nginx 웹 서버 설정 예시

server {
    listen 80;
    server_name example.com www.example.com;

    # HTTP로 들어오는 모든 요청을 HTTPS로 리다이렉트
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    # TLS 인증서 설정
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # 취약한 SSLv2, SSLv3, TLS 1.0, TLS 1.1 비활성화 및 TLS 1.2 이상 지정
    ssl_protocols TLSv1.2 TLSv1.3;
    
    # ... 이하 생략 ...
}

대책 2: HSTS (HTTP Strict Transport Security) 헤더 설정

리다이렉트 방식만 사용하면 최초 HTTP 요청 시 공격자가 **SSL Stripping(HTTPS를 HTTP로 강제 다운그레이드하는 공격)**을 시도할 수 있습니다. 이를 방지하기 위해 웹 서버에서 HSTS 응답 헤더를 보냅니다.

HSTS를 설정하면 브라우저는 해당 웹사이트에 접속할 때 HTTP 접속 시도 자체를 차단하고, 무조건 클라이언트단에서 HTTPS로만 연결합니다.

HSTS 헤더 적용 예시 (Apache / Nginx)

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age=31536000: 브라우저가 이 설정을 1년(31,536,000초) 동안 기억합니다.
• includeSubDomains: 모든 서브도메인에도 HSTS를 동일하게 적용합니다.
• preload: 구글 등 주요 브라우저의 HSTS Preload 리스트에 등록되어 첫 방문부터 HTTPS로 강제 접속하게 합니다.

대책 3: 중요 데이터의 애플리케이션단 이중 암호화 (보조 수단)

금융 서비스 등 고도화된 보안이 요구되는 환경에서는 TLS 통신 구간 암호화 외에도, 클라이언트(JavaScript)단에서 공개키(RSA) 등으로 데이터를 1차 암호화하여 전송하는 방 방식을 병행하기도 합니다. (단, 이는 HTTPS의 대체재가 아닌 보조 수단이어야 합니다.)

4. 요약 및 정리

오늘 배운 핵심 내용을 요약해 볼까요?

보안의 기본은 **"보호해야 할 데이터는 통신망을 지날 때 무조건 암호화한다"**는 철칙을 지키는 것입니다!

5. 다음 차시 예고: [Day 18] 쿠키 변조 (Cookie Manipulation)

오늘 우리는 네트워크 구간에서 데이터가 암호화되어 안전하게 이동하는 법을 배웠습니다. 그렇다면 사용자의 브라우저에 저장된 **'쿠키(Cookie)'**는 과연 안전할까요?

다음 시간에는 [Day 18] 쿠키 변조 취약점에 대해 다룹니다. 웹 서버가 클라이언트를 식별하기 위해 발행한 쿠키 값을 공격자가 임의로 수정(admin=true, role=manager 등)하여 타인의 권한을 획득하거나 인증을 우회하는 원리와, 이를 방지하기 위한 Secure/HttpOnly 옵션 및 쿠키 검증 로직에 대해 자세히 알아보겠습니다.

오늘도 수고 많으셨습니다! 질문이 있으시다면 언제든 댓글로 남겨주세요. 다음 시간에 만나요! 😊