[Normaltic 웹해킹 입문] 3강 관련 복습&리뷰-②(세션)

 

3주차 수업 정리: 웹 인증 기초 (Basic, Cookie, JWT)

빠른 목차 · 1. PHP: $ vs define() · 2. 웹은 왜 무상태(Stateless)? · 3. HTTP Basic 인증 · 4. 쿠키 & 세션 · 5. 토큰 & JWT · 6. 비교표 · 보안 체크리스트 · 미니 퀴즈 · TL;DR

---

1) PHP 문법: $ (변수) vs define() (상수)

• $변수: 값이 바뀔 수 있음. 가변
• define('NAME', 값): 한 번 정하면 바뀌지 않는 값(상수). 불변
• 상수는 $ 기호 없이 어디서든 접근 가능, 변수는 함수 스코프에 주의.

// 변수
$rate = 0.1;
$rate = 0.2; // 변경 OK

// 상수
define('PI', 3.14159);
// define('PI', 3.14); // 이미 정의된 상수는 재정의 불가

---

2) 웹은 왜 무상태(Stateless)라고 할까?

HTTP는 이전 요청을 기억하지 않는 프로토콜. 그래서 서버는 “이 사용자가 로그인했는지”를 추가 장치 없이는 알 수 없음.

이를 해결하기 위한 대표적인 방법이 인증 정보를 매 요청에 함께 보내는 것(예: Basic 인증)이거나, 세션을 만들어 세션 ID를 쿠키로 주고받는 방식

주의:

• Basic 인증은 “로그인 상태를 서버에 유지”하는 게 아니라, 매 요청마다 자격증명을 보내 무상태로 인증하는 방식입니다.
• 세션+쿠키는 보통 서버가 상태를 들고 있어 “로그인 상태”를 표현합니다.

 

---

3) HTTP Basic Authentication

무엇? 브라우저가 Authorization 헤더에 Basic <base64(username:password)> 형태로 자격증명을 보내는 방법.

흐름

1. 보호된 리소스 접근 → 서버가 401 Unauthorized + WWW-Authenticate: Basic ... 반환
2. 브라우저가 사용자에게 자격증명(팝업) 요청
3. 이후 같은 보호영역에 대한 요청마다 자동으로 Authorization 헤더를 매번 첨부

GET /private HTTP/1.1
Authorization: Basic dXNlcjpzZWNyZXQ=  // Base64는 '인코딩'이지 '암호화'가 아님

장점:

• 간단함, 별도 세션 저장소 불필요(무상태)

주의:

• 반드시 HTTPS에서만 사용(아니면 자격증명 노출·재사용 위험)
• “한 번 인증하면 안 보내는 것”이 아님. 브라우저가 매 요청 자동 첨부

---

4) 쿠키 & 세션

아이디어: 로그인 성공 시 서버가 세션 ID를 발급 → 브라우저는 쿠키로 저장 → 이후 요청마다 Cookie 헤더에 담아 전송 → 서버는 세션 저장소에서 사용자 상태를 확인.

// 서버 → 클라이언트 (로그인 성공 응답)
Set-Cookie: SESSIONID=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

// 클라이언트 → 서버 (이후 요청)
Cookie: SESSIONID=abc123

• 위협: 세션 ID 탈취(XSS/가로채기), 예측 가능 ID, 세션 고정(Session Fixation)
• 대응: 난수형 ID, 짧은 만료, 재로그인 시 ID 재발급, HttpOnly/Secure/SameSite 설정

한계:

• 브라우저 중심(비브라우저 클라이언트에선 불편할 수 있음)
• 도메인 간 공유 제한(예: naver.com 쿠키를 daum.net에서 사용 불가)

---

5) 토큰 기반 & JWT(Json Web Token)

왜? 브라우저 외 다양한 클라이언트(API, 모바일, 서버-서버)에서도 쓰기 편한 표준화된 토큰 필요 → Authorization: Bearer 방식.

JWT 구조

xxxxx.yyyyy.zzzzz (마침표로 3부분) = Header.Payload.Signature (모두 Base64URL 인코딩)

• Header: 서명 알고리즘 등
• Payload: 사용자 정보(claims), 만료(exp) 등 (암호화 아님, 열어볼 수 있음)
• Signature: 비밀키(HMAC) 또는 공개키(RSA/ECDSA)로 무결성 보장

GET /api/profile HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

장점:

• 서버 간 공유 용이(검증키만 알면 누구나 검증)
• 세션 저장소 없이도 동작 가능(무상태 API에 적합)

주의:

• Payload에 민감정보 금지(그냥 인코딩일 뿐)
• 만료/폐기 설계 중요(리프레시 토큰, 짧은 만료, 블랙리스트/키 롤링)
• 브라우저 환경에선 저장 위치/XSS·CSRF 전략이 필요(예: HttpOnly 쿠키 + SameSite)

---

6) 한눈에 비교

항목	HTTP Basic	쿠키+세션	JWT(Bearer)
상태	무상태	서버 상태 보유(세션)	무상태(보통)
전송 위치	Authorization: Basic ...	Cookie: SESSIONID=...	Authorization: Bearer ...
주요 용도	간단 보호, 내부/프록시	웹앱 로그인	API, 멀티도메인/서버간
보안 핵심	반드시 HTTPS	HttpOnly/Secure/SameSite, 재발급	서명키 관리, 만료/폐기
도메인 제약	없음	도메인/경로 정책 영향	없음(헤더 기반)

---

보안 체크리스트 (실무 팁)

• 공통: HTTPS 필수, 전송·저장 최소화(최소 권한)
• Basic: 외부 노출 서비스엔 가급적 지양, 쓰더라도 VPN/사내용, 강력한 암호 정책
• 세션: 난수형 세션ID, 로그인/권한변경 시 세션 재발급, HttpOnly/Secure/SameSite, 유휴 타임아웃
• JWT: 짧은 만료(Access), 긴 만료 Refresh + 회전(Rotation), 키 롤링, aud/iss 검증, 민감정보 비포함
• 브라우저: XSS/CSRF 대응(CSP, 입력검증, SameSite, 토큰 더블 서밋 등)

---

미니 퀴즈(복습)

1. Basic 인증에서 Base64는 암호화일까요, 인코딩일까요?
2. JWT의 Payload에 비밀번호를 넣어도 될까요? 이유도 써보세요.

---

TL;DR (요약)

• PHP: $는 변수(변경 가능), define()은 상수(변경 불가)
• HTTP는 무상태 → 인증정보를 매 요청에 전달(Basic)하거나, 세션ID를 쿠키로 주고받음
• Basic은 간단하지만 항상 HTTPS 필수, 매 요청 헤더에 자격증명 포함
• 쿠키+세션은 웹앱에 일반적, HttpOnly/Secure/SameSite 제대로 설정
• JWT는 헤더 기반 토큰, 무결성 서명으로 검증·짧은 만료·키 관리가 핵심