네트워크 면접 질문(3)- 인증 및 보안

쿠키와 세션

- 웹 개발에서 사용자의 상태를 관리하는 기술

 

쿠키란?

- 사용자의 웹 브라우저에 저장되는 작은 데이터 파일

- 웹사이트가 사용자의 상태나 정보를 유지하기 위해 사용된다.
- 쿠키는 클라이언트 측에서 저장되며, 웹 브라우저가 해당 웹 서버의 쿠키가 있다면 사용자가 해당 웹사이트를 방문할 때마다 HTTP 요청에 담아서 자동으로 전송한다.

- 쿠키는 주로 세션 관리(로그인 상태 유지), 사용자 맞춤 설정(언어 선택, 테마), 웹사이트 분석(사용자 활동 추적) 등에 사용된다.

 

특징

- Key-Value 쌍으로 구성된다

- 쿠키이름, 쿠키값, 만료시간, 전송할 도메인명, 전송할 경로, 보안연결여부, HttpOnly 여부 등의 정보가 저장됨

- 기본적으로 쿠키는 웹 브라우저가 종료되면 삭제된다.(만료 시간이 지정되어 있으면 만료 시간에 삭제됨)

- 도메인 당 20개의 쿠키를 가질 수 있다.

- 하나의 쿠키는 4KB까지 저장이 가능하다.

 

작동 방식

쿠키는 HTTP 통신 위에서 이뤄지기 때문에 HTTP 요청과 응답에 따라 작동된다.

1. 클라이언트(웹 브라우저)에서 웹 서버로 요청을 보냄

2. 요청을 받은 서버에서 쿠키를 클라이언트에게 보내고
    클라이언트는 받은 쿠키를 도메인 서버 이름으로 정렬된 디렉토리에 저장

3. 이후 클라이언트가 동일한 서버로 요청을 보내면 자동으로 요청 헤더에 저장된 쿠키를 함께 전송

4. 만약 변경된 내용이 있다면 응답시 함께 업데이트된 쿠키를 전달

 

세션이란?

- 일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술

- 서버 측에서 저장하는 사용자 상태 정보이다.
- 사용자가 웹사이트에 접속할 때 서버는 고유한 세션 ID(웹 애플리케이션에서 사용자 세션을 식별하는 고유한 식별자)를 생성하고, 이를 통해 사용자의 활동을 추적한다.
예를 들어, 사용자가 로그인할 때 서버는 이 세션 ID를 사용해 사용자의 로그인 상태를 유지한다.
세션 정보는 서버에 저장되며, 사용자가 웹사이트를 떠나거나 세션이 만료되면 해당 정보는 삭제된다.
일반적으로 세션 ID는 쿠키를 통해 클라이언트에 저장되어 서버와 주고받는다.

 

특징

- 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
- 웹 서버의 저장되는 쿠키(=세션 쿠키)
- 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.
- 저장 데이터에 제한이 없다. (서버 용량이 허용하는 한에서)
- 각 클라이언트에 고유 Session ID를 부여한다. Session ID로 클라이언트를 구분해 각 요구에 맞는 서비스를 제공

 

작동 방식

1. 클라이언트가 페이지에 요청한다.
2.서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하여, 클라이언트가 해당 session-id를 보냈는지 확인한다.
3. session-id가 존재하지 않는다면 서버는 session-id를 생성해 클라이언트에게 넘겨준다.
4. 클라이언트는 서버로부터 받은 session-id를 쿠키에 저장한다.
5. 클라이언트는 서버에 요청시 이 쿠키의 session-id 값을 같이 서버에 전달한다.
6. 서버는 전달받은 session-id로 session에 있는 클라이언트 정보를 가지고 요청을 처리 후 응답한다.

 

쿠키와 세션의 주요 차이는?

 

- 저장 위치

쿠키와 세션의 가장 큰 차이점은 데이터가 저장되는 위치이다.
쿠키는 클라이언트 측의 웹 브라우저에 저장되며, 세션은 서버 측에 저장된다.

 

- 만료 기간

쿠키는 사용자가 직접 삭제하지 않는 한 만료 기간이 지나기 전까지 유지되지만

세션은 사용자가 로그아웃하거나 브라우저를 닫는 등의 행동을 취할 때 종료된다.

 

JWT 토큰이란?

- Json Web Token

- 네트워크를 통해서 JSON의 형태로 된 데이터를 서로 다른 장치끼리 안전하게 전송하기 위해 설계되었다.

- 현재 웹 애플리케이션에서 사용자 인증 및 권한 부여를 위해 자주 사용되는 토큰 기반의 표준이다.

 

JWT는

header,  payload, signature로 구성되어 있다.

 

header

서명 시 사용하는 키(kid), 사용할 타입(typ), 서명 암호화 알고리즘(alg)의 정보가 담겨 있다.

• kid : 서명 시 사용하는 키(Public/Private Key)를 식별하는 값
• typ : 토큰 유형
• alg : 서명 시 사용하는 암호화 알고리즘
  ex HS256(HMAC SHA-256)

{
    "alg": "HS256",
    "typ": "JWT",
    "kid": "Key ID"
}

payload

JWT의 내용으로 토큰에 포함될 클레임(Claim)들을 담고 있다.

페이로드에 있는 속성들을 클레임 셋(Claim Set)이라 부른다.
클레임은 JWT에서 사용자의 정보나 추가 데이터(예: 사용자 ID, 만료 시간 등)를 포함할 수 있다.

• iss : 토큰 발급자(issuer) – Public Claims
• sub : 토큰 제목(subject) – Public Claims
• iat : 토큰 발급 시간(issued at) – Public Claims
• exp : 토큰 만료 시간(expiration) – Public Claims
• roles : 권한 – Private Cliams

{
  "iss": "John Doe",
  "sub": "1234567890",
  "iat": 2406239022,
  "exp": 2406249022,
  "roles": "ROLE_USER"
}

signature

헤더와 페이로드의 무결성을 검증하기 위해 사용된다.
서명은 헤더와 페이로드를 인코딩한 후 비밀 키를 사용해 생성되며 이 서명을 통해 JWT가 변조되지 않았음을 확인할 수 있다.

 

이를 이해하기 쉽게 편지에 비유하여 설명하면header는 다양한 정보가 적혀있는 봉투payload는 실제 내용이 담겨 있는 편지지signature는 누가 쓴 글인지 확인시켜주는 서명 정도로 이해할 수 있다.

 

JWT의 헤더와 페이로드는 JSON 객체로 작성되지만, 이를 그대로 전송하기에는 효율적이지 않으며 보안 상의 문제도 발생할 수 있기 때문에 JWT는 헤더와 페이로드를 Base64URL로 인코딩한다.

(바이너리 데이터 => ASCII 문자열로 변환)

 

인코딩된 JWT는 Header.Payload.Signature의 구조를 가지게 된다.

 

XSS 공격이란?

웹 애플리케이션에서 사용자 입력을 적절히 검증하지 않아서 발생하는 보안 취약점이다.

악의적인 사용자가 웹 페이지에 악성 스크립트를 삽입하여 해당 스크립트가 다른 사용자의 브라우저에서 실행되도록 하는 것을 목표로 한다.

주로 JavaScript로 작성되며, 사용자의 세션 쿠키를 탈취하거나, 악성 코드를 실행시키고, 심지어 사용자의 계정 정보를 탈취할 수도 있다.

 

XSS 공격은 저장형 XSS, 반사형 XSS, DOM 기반 XSS로 나뉜다.

• 저장형 XSS (Stored XSS)
  악성 스크립트가 서버에 저장되어 다수의 사용자에게 노출되어 영향을 미치는 형태이다.
  ex) 공격자가 게시판에 악성 스크립트를 포함한 댓글을 달면, 해당 게시물을 조회하는 모든 사용자가 공격의 대상이 될 수 있다.
• 반사형 XSS (Reflected XSS)
  악의적인 스크립트가 사용자의 입력을 통해 서버로 전달되고, 서버에서 바로 클라이언트로 반환될 때 발생한다. 
  사용자가 악성 링크를 클릭했을 때 발생할 수 있다.
• DOM 기반 XSS
  클라이언트 측에서 실행되는 스크립트가 DOM(Document Object Model) 조작 중에 발생하는 XSS이다.
  서버와의 통신 없이 클라이언트 측 코드만으로 발생하는 것이 특징이다.

 

어떻게 XSS 공격을 방어하는가?

입력 유효성 검사
사용자 입력을 받을 때, 입력 필드에서 허용되지 않는 문자나 스크립트를 걸러내는 유효성 검사를 수행한다.

 

출력 이스케이프

사용자가 입력한 데이터를 HTML로 출력하기 전에 이스케이프하여 사용합니다. 이를 통해 사용자가 입력한 데이터가 HTML 태그로 해석되는 것을 방지한다.

 

콘텐츠 보안 정책 설정

Content Security Policy(CSP)와 같은 콘텐츠 보안 정책을 설정하여 허용되는 리소스 및 스크립트 실행 정책을 명시한다.

 

세션 쿠키 속성 설정

HttpOnly와 Secure 속성을 사용하여 세션 쿠키를 설정한다. HttpOnly 속성은 JavaScript에서 쿠키에 접근할 수 없게 하고, Secure 속성은 암호화된 연결(HTTPS)에서만 쿠키를 전송하도록 한다.

 

정기적인 보안 감사 및 업데이트

웹 애플리케이션을 정기적으로 검토하고 보안 취약점을 식별하며, 필요한 보안 업데이트를 수행하여 최신 보안 대책을 유지한다.

CSRF 공격이란?

 사용자가 인증된 상태에서 악의적인 웹사이트에 접속하여, 해당 웹사이트가 사용자 대신 인증된 상태에서 악의적인 요청을 다른 웹사이트로 전송하는 공격이다.
이 공격을 통해 공격자는 사용자의 계정에서 비정상적인 활동을 수행할 수 있다.

ex) 사용자가 은행 사이트에 로그인한 상태에서 공격자가 만든 악성 웹페이지를 방문하면 그 페이지에서 사용자의 모르게 이체 요청을 해당 은행 사이트로 보낼 수 있다.
이때, 공격은 사용자가 인증된 세션을 이용하므로, 서버는 이 요청을 합법적인 사용자 요청으로 간주하여 처리할 수 있다.

어떻게 CSRF 공격을 방어하는가?

CSRF 토큰 사용
CSRF 방어의 가장 일반적인 방법은 CSRF 토큰을 사용하는 것이다.
이는 각 요청에 대해 고유하고 예측 불가능한 토큰을 발급하여 요청 시 함께 전송하게 한다.
서버는 이 토큰이 올바른지 확인함으로써, 요청이 신뢰할 수 있는 출처에서 온 것임을 보장한다.
공격자는 CSRF 토큰을 예측할 수 없기 때문에, 토큰이 없는 요청이나 잘못된 토큰을 가진 요청은 서버에서 거부된다.

 

Referer 검증
서버는 요청의 Referer 헤더를 확인하여, 요청이 신뢰할 수 있는 출처(자신의 도메인)에서 발생했는지 확인할 수 있다. 그러나 Referer 헤더는 브라우저 설정에 따라 전송되지 않을 수 있으므로, 단독으로 사용하기에는 제한적일 수 있다.

 

SameSite 쿠키 속성 설정
SameSite 쿠키 속성은 CSRF 공격을 방어하기 위한 또 다른 방법이다.
SameSite 속성을 Strict 또는 Lax로 설정하면, 해당 쿠키는 같은 사이트에서만 요청에 포함되도록 제한된다.
이 설정을 통해 다른 사이트에서 발생한 요청은 사용자의 쿠키를 전송할 수 없게 되어, CSRF 공격을 방어할 수 있다

 

HTTP 메서드 제한
서버는 중요한 상태 변경 작업(POST, PUT, DELETE)에 대해서만 CSRF 방어를 강화하고, GET 요청에서는 이러한 방어를 완화할 수 있다. 중요한 작업은 GET 요청이 아닌 POST 요청을 통해서만 처리하게 하여, CSRF 공격의 위험을 줄일 수 있다.

 

사용자 세션 관리
세션 관리를 통해 사용자의 인증 상태를 안전하게 유지하고, 세션 만료 및 재인증 정책을 적용하여 보안을 강화한다.

 

CSRF 방어 라이브러리 사용
웹 프레임워크에서 제공하는 CSRF 방어 라이브러리를 사용하여 자동으로 CSRF 공격을 방어할 수 있다. 이러한 라이브러리는 CSRF 토큰을 생성하고 검증하여 보안을 강화한다.

SQL Injection 공격이란?

웹 애플리케이션의 데이터베이스와 상호작용하는 과정에서 발생하는 보안 취약점이다.
공격자는 애플리케이션의 입력 필드나 URL 파라미터에 악성 SQL 코드를 삽입하여, 데이터베이스 쿼리를 조작함으로써 권한이 없는 데이터에 접근하거나, 데이터를 조작할 수 있다.
이로 인해 데이터베이스에서 중요한 정보가 유출되거나, 데이터가 손상될 수 있다.

SQL Injection 공격을 어떻게 방어하는가?

매개변수화된 쿼리 사용
매개변수화된 쿼리(Prepared Statements)를 사용하여 사용자 입력을 쿼리에 동적으로 삽입하는 대신, 매개변수로 전달하여 쿼리를 실행한다. 이를 통해 입력값이 쿼리에 직접 삽입되는 것을 방지할 수 있다.

 

ORM(Object-Relational Mapping) 사용
ORM을 사용하여 데이터베이스에 접근하고 쿼리를 생성하는 것이 좋다. ORM은 사용자 입력을 쿼리에 안전하게 삽입할 수 있도록 도와준다.

 

입력 유효성 검사
사용자 입력을 받을 때, 입력값에 대한 유효성을 검사하여 예상치 못한 문자나 명령을 필터링한다. 이를 통해 악의적인 SQL 쿼리를 방지할 수 있다.

 

최소 권한 원칙 적용
데이터베이스 사용자에게 최소한의 권한만을 부여하여, 악의적인 쿼리가 실행될 경우에도 최소한의 피해를 입힐 수 있도록 한다.

 

에러 메시지 노출 제한
악의적인 사용자에게 공격에 대한 세부 정보를 노출하지 않도록 에러 메시지를 제한하거나 사용자 친화적이지 않은 메시지를 제공한다.

 

보안 업데이트 및 패치 적용
데이터베이스 시스템 및 웹 애플리케이션에서 보안 업데이트와 패치를 정기적으로 적용하여 최신 보안 취약점에 대비한다.

SQL 인젝션 공격으로부터 웹 애플리케이션을 보호하기 위해 이러한 방어적 조치를 수행하는 것이 매우 중요하다.

---

https://noahlogs.tistory.com/38

[네트워크] HTTP 쿠키와 세션이란 ?

https://www.google.com/search?q=%EC%BF%A0%ED%82%A4%EC%99%80+%EC%84%B8%EC%85%98&oq=&gs_lcrp=EgZjaHJvbWUqCQgAEEUYOxjCAzIJCAAQRRg7GMIDMgkIARBFGDsYwgMyCQgCEEUYOxjCAzIJCAMQRRg7GMIDMgkIBBBFGDsYwgMyCQgFEEUYOxjCAzIJCAYQRRg7GMIDMgkIBxBFGDsYwgPSAQszNzMyNDM2ajBqN6gCCLACAQ&sourceid=chrome&ie=UTF-8

🔎 쿠키와 세션: Google 검색

https://f-lab.kr/insight/cookie-vs-session

쿠키와 세션의 차이점 및 보안 고려사항

https://4rgos.tistory.com/1

XSS(Cross Site Scripting) 공격이란?

https://blog.bizspring.co.kr/%ED%85%8C%ED%81%AC/jwt-json-web-token-%EA%B5%AC%EC%A1%B0-%EC%82%AC%EC%9A%A9/

JWT (Json Web Token)의 구조와 사용하기 – BizSpring BLOG