secure coding

HTTPS / JWT / CSRF 개념 정리

Digital Audio Player 2025. 3. 11. 11:17

🔍 HTTPS의 역할과 중요성

1️⃣ HTTPS란?

**HTTPS (HyperText Transfer Protocol Secure)**는 HTTP + SSL/TLS를 결합한 프로토콜이다.
즉, HTTP 통신을 암호화하여 안전하게 데이터를 주고받을 수 있도록 하는 기술이다.

💡 HTTP vs HTTPS

HTTPHTTPS

보안 수준	암호화 없음 (평문 통신)	암호화 (TLS/SSL 적용)
데이터 보호	네트워크에서 데이터 탈취 가능	데이터 암호화로 보호
사용 사례	일반 웹사이트 (보안 중요X)	로그인, 결제, 개인정보 처리 등
브라우저 표시	🔴 "안전하지 않음" 경고	🟢 자물쇠 아이콘 (🔒) 표시

2️⃣ HTTPS의 주요 역할

✅ 1) 데이터 암호화 (Encryption) → 데이터 탈취 방지
✅ 2) 데이터 무결성 (Integrity) → 데이터 변조 방지
✅ 3) 서버 인증 (Authentication) → 신뢰할 수 있는 서버와 통신 보장

📌 1. 데이터 암호화 (Encryption)

HTTPS는 SSL/TLS 암호화를 적용하여 데이터를 보호한다.
즉, 클라이언트(브라우저)와 서버가 암호화된 상태로 데이터를 주고받기 때문에, 네트워크에서 데이터가 노출되지 않는다.

💡 HTTP 통신 (암호화 X)

POST /login HTTP/1.1
Host: example.com
username=admin&password=1234

❌ 공격자가 네트워크에서 패킷을 가로채면 로그인 정보가 그대로 노출됨.

💡 HTTPS 통신 (암호화 O)

POST /login HTTP/1.1
Host: example.com
[암호화된 데이터]

✅ 공격자가 패킷을 가로채더라도 내용을 해독할 수 없음.

🔹 암호화 방식

HTTPS는 TLS(Transport Layer Security) 또는 **SSL(Secure Sockets Layer)**을 사용하여 데이터를 암호화한다.
사용되는 암호화 방식:
- 대칭키 암호화: AES, ChaCha20 (빠르고 강력한 암호화)
- 비대칭키 암호화: RSA, ECC (공개키-개인키 사용)

📌 2. 데이터 무결성 (Integrity)

HTTPS는 데이터 변조를 방지한다.
즉, 전송 중에 공격자가 데이터를 변경하지 못하도록 보호한다.

🔹 HTTP에서는 공격자가 데이터를 변조할 수 있음

GET /profile HTTP/1.1
Host: example.com

🔥 공격자가 중간에서 응답을 변조하여 악성 코드 추가:

HTTP/1.1 200 OK
Content-Type: text/html

<html>
<script>alert('Hacked!')</script>
</html>

→ 결과: 사용자가 악성 코드가 삽입된 페이지를 보게 됨.

🔹 HTTPS에서는 데이터 변조가 불가능

TLS는 **메시지 인증 코드(MAC, Message Authentication Code)**를 사용하여 데이터 무결성을 보장함.
즉, 공격자가 데이터를 변조하면 브라우저가 이를 감지하고 연결을 차단함.

📌 3. 서버 인증 (Authentication)

HTTPS는 클라이언트(사용자)가 신뢰할 수 있는 서버에 연결되었는지 확인하는 역할을 한다.
즉, 피싱 사이트(가짜 사이트)로 유도되는 것을 방지할 수 있다.

📍 피싱 공격 예시 (HTTP)

사용자가 http://bank.example.com에 접속한다고 생각함.
공격자가 DNS를 변조하여 http://fake-bank.com으로 유도함.
사용자는 가짜 은행 사이트에 비밀번호를 입력하고, 공격자는 이를 탈취함.

📍 HTTPS 사용 시 방어

HTTPS는 서버가 인증서를 사용하여 신뢰할 수 있는 도메인인지 검증한다.
브라우저는 인증서를 확인하고 가짜 사이트라면 "위험" 경고를 표시한다.

💡 브라우저에서 HTTPS 인증 확인

주소창 자물쇠 아이콘 🔒 클릭
"보안 연결" 또는 "이 웹사이트는 인증되었습니다" 표시 확인
인증서 발급 기관(CA) 확인 (예: DigiCert, Let's Encrypt)

📌 4. HTTPS가 필요한 이유

🚀 HTTPS를 사용하지 않으면 발생할 수 있는 보안 문제 1️⃣ 패킷 스니핑(Packet Sniffing) → 로그인 정보, 신용카드 정보 탈취 가능
2️⃣ MITM(Man-In-The-Middle) 공격 → 중간에서 데이터 변조 가능
3️⃣ 피싱(Phishing) 공격 → 가짜 사이트로 유도 가능

💡 특히 JWT 기반 인증에서는 HTTPS가 필수!

JWT가 헤더에 포함되어 전송되므로, HTTPS가 없으면 토큰이 탈취될 위험이 큼.
HTTP를 사용할 경우, 공격자가 네트워크에서 패킷을 가로채 JWT를 훔칠 수 있음.
HTTPS를 사용하면 JWT가 암호화되어 공격자가 탈취해도 내용을 알 수 없음.

📌 5. 결론

🔹 HTTPS의 역할 요약

✔ 데이터 암호화 → 네트워크에서 패킷을 가로채도 내용을 볼 수 없음.
✔ 데이터 무결성 → 전송 중에 데이터가 변조되지 않음.
✔ 서버 인증 → 사용자가 신뢰할 수 있는 서버에 접속하도록 보장.

🔹 HTTPS를 반드시 사용해야 하는 경우

✅ 로그인 시스템 (JWT 인증, OAuth 2.0 등)
✅ 신용카드 결제, 개인정보 입력이 필요한 사이트
✅ API 통신 (프론트엔드 ↔ 백엔드)

📌 6. 추가 질문: "HTTPS를 사용하면 완벽한 보안인가?"

❌ 아니다. HTTPS는 데이터 전송 구간을 보호할 뿐, 서버 내부 보안까지 책임지지는 않는다.
예를 들어:

XSS(Cross-Site Scripting) 공격 → 웹사이트에 악성 JavaScript가 삽입될 수도 있음.
SQL Injection → 서버의 DB가 안전하지 않으면 공격자가 데이터를 가져갈 수 있음.

🚀 따라서, HTTPS 외에도 보안 모범 사례를 따라야 한다.

JWT를 HttpOnly 쿠키에 저장 (XSS 방지)
JWT 만료 시간 짧게 설정
강력한 비밀번호 해싱 사용 (BCrypt 등)
SQL Injection 방어 (Prepared Statement 사용)

✅ 결론: HTTPS는 필수다!

1️⃣ HTTP는 데이터가 평문으로 전송되므로 매우 위험
2️⃣ HTTPS는 데이터를 암호화하여 탈취 및 변조를 방지
3️⃣ JWT 같은 토큰 인증 방식에서는 HTTPS 없이는 보안이 취약
4️⃣ HTTPS를 사용하더라도, 추가적인 보안 조치가 필요

즉, JWT, 로그인, 개인정보 보호를 위해 HTTPS는 선택이 아니라 필수다! 🚀

-------------- -------------- -------------- -------------- -------------- -------------- -------------- -------------- -------------- -------------- ------------- -------------- -------------- -------------- -------------- -------------- -------------- -------------- -------------- -------------- -------------- -------------

🔍 CSRF를 비활성화했는데, JWT는 안전한가?

CSRF(Cross-Site Request Forgery) 보호를 비활성화했는데 JWT는 안전한가? 하는 질문이 나올 수 있다.
결론부터 말하면, CSRF와 JWT는 보안 목적이 다르기 때문에, JWT를 사용할 경우 CSRF 보호가 필요 없다.
하지만, JWT가 탈취되었을 때의 보안 문제는 별개로 존재하며, 이를 방지하기 위한 조치를 해야 한다.

📌 1. CSRF가 하는 역할

CSRF는 사용자의 세션을 악용하여 악의적인 요청을 서버로 보내는 공격을 막기 위한 보안 기능이다.

💡 CSRF 공격 예시
1️⃣ 사용자가 로그인하면 브라우저의 세션 쿠키에 로그인 정보가 저장됨
2️⃣ 사용자가 공격자가 만든 악성 웹사이트를 방문함
3️⃣ 악성 사이트에서 fetch("https://example.com/user/delete", { method: "POST" }) 같은 요청을 실행
4️⃣ 브라우저는 자동으로 세션 쿠키를 포함하여 요청을 보냄 → 사용자가 의도치 않게 데이터 삭제됨

✅ CSRF 토큰을 사용하면 서버가 요청을 받을 때, 이 요청이 진짜 사용자의 요청인지 확인할 수 있다.

📌 2. JWT 사용 시 CSRF가 필요 없는 이유

✅ JWT는 세션을 사용하지 않고, 클라이언트가 직접 HTTP 헤더에 토큰을 포함하여 보냄.
✅ 따라서 브라우저가 자동으로 JWT를 포함하지 않음 → CSRF 공격이 불가능.
✅ 즉, JWT 기반 인증을 사용할 때는 CSRF 보호가 필요하지 않다.

💡 CSRF 공격이 가능한 이유는 브라우저가 자동으로 쿠키를 포함하기 때문인데,
JWT는 로컬 스토리지 또는 세션 스토리지에 저장 후, 직접 Authorization 헤더에 포함하여 요청을 보내므로 CSRF 공격이 불가능하다.

GET /user/profile
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

→ CSRF 공격은 브라우저가 자동으로 세션 쿠키를 포함하는 방식에서 발생하는데, JWT는 수동으로 헤더에 추가하므로 해당되지 않는다.

📌 3. JWT가 탈취되면 어떻게 되는가?

JWT는 헤더에서 탈취될 경우 공격자가 그대로 사용할 수 있다는 보안 취약점이 존재한다.
이는 CSRF 문제와는 별개이며, 토큰 탈취(TOKEN THEFT) 문제에 해당한다.

🚨 공격자가 JWT를 탈취하는 방법 1️⃣ Man-in-the-Middle (MITM) 공격

HTTPS가 아닌 HTTP를 사용할 경우, 네트워크에서 JWT가 탈취될 수 있다.
2️⃣ XSS (Cross-Site Scripting) 공격
JWT를 로컬 스토리지에 저장할 경우, XSS 취약점이 있는 사이트에서 공격자가 JavaScript를 실행해 토큰을 탈취할 수 있다.
3️⃣ 토큰을 너무 오래 유지할 경우
JWT가 탈취되면 세션처럼 무효화할 방법이 없기 때문에, 만료 시간이 길 경우 위험하다.

📌 4. JWT 탈취를 방지하는 방법

✅ 1) HTTPS 사용 (필수)

JWT는 헤더에 포함하여 전송되므로, 네트워크에서 탈취되는 것을 방지하려면 반드시 HTTPS를 사용해야 한다.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
            .requiresChannel(channel -> channel.anyRequest().requiresSecure()) // 모든 요청을 HTTPS로 강제
            .build();
}

🚨 HTTP를 사용하면 공격자가 JWT를 탈취할 가능성이 매우 높아진다.

✅ 2) JWT를 로컬 스토리지 대신 HttpOnly 쿠키에 저장

XSS 공격을 방지하기 위해, JWT를 localStorage가 아닌 HttpOnly 쿠키에 저장하는 방법이 있다.

Set-Cookie: token=eyJhbGciOiJIUzI1Ni...; HttpOnly; Secure

HttpOnly → JavaScript로 접근할 수 없음 (XSS 방어)
Secure → HTTPS에서만 전송

🚀 이렇게 하면 XSS 공격으로 JavaScript가 JWT를 읽어가지 못함.

✅ 3) 짧은 JWT 만료 시간 + Refresh Token 사용

JWT가 탈취될 경우, 무효화할 방법이 없기 때문에 만료 시간을 짧게 설정하는 것이 좋다.

private static final long JWT_EXPIRATION = 1000 * 60 * 15; // 15분

짧은 만료 시간 (15분 이하) → 토큰이 탈취되더라도 오래 사용할 수 없음
Refresh Token 사용 → 만료되면 재발급

✅ 4) 로그아웃 시 서버에서 블랙리스트 관리

JWT는 기본적으로 로그아웃 기능이 없음, 하지만 서버에서 블랙리스트를 관리하면 가능하다.

Set<String> tokenBlacklist = new HashSet<>();

public void logout(String token) {
tokenBlacklist.add(token);
}
public boolean isTokenBlacklisted(String token) {
return tokenBlacklist.contains(token);
}

→ 사용자가 로그아웃하면 해당 JWT를 서버에서 무효화하여 더 이상 사용할 수 없도록 함.

📌 5. 결론

Q. CSRF 보호를 비활성화했는데 보안 문제는 없는가?
→ JWT는 쿠키 기반 인증이 아니라 CSRF 공격이 불가능하기 때문에 CSRF 보호가 필요 없다.

Q. 하지만 JWT를 헤더에서 탈취할 가능성은 없는가?
→ 맞다. JWT 탈취(TOKEN THEFT)는 다른 보안 문제이며, 이를 방지하려면 HTTPS, HttpOnly 쿠키, 짧은 만료 시간, Refresh Token 등을 사용해야 한다.

🚀 결론: CSRF는 비활성화해도 되지만, JWT 탈취를 방지하는 추가 조치를 해야 한다.

✅ CSRF 공격은 브라우저가 세션 쿠키를 자동으로 포함하는 방식에서 발생하는 문제 → JWT는 해당되지 않음
✅ 하지만 JWT가 탈취될 경우 그대로 사용할 수 있기 때문에, 추가적인 보안 조치가 필요
✅ HTTPS, HttpOnly 쿠키, 짧은 만료 시간, Refresh Token 등을 활용해야 함

즉, JWT를 안전하게 사용하려면 CSRF가 아니라 "토큰 탈취"에 대한 대비가 중요하다! 🚀